existem diversas ferramentas de WorkBench para "gerar" o código, a estratégia de CI/CD a partir de mudanças no Diagrama, se estiver-mos usando as ferramentas corretas de modo correto, uma atualização de diagrama já "cospe" o pipeline que será necessário no CI/CD e o novo diagrama, mostra para os Devs o que fazer, e como fazer.
Startups hoje, em suma maioria, usam a estratégia de fatiar pão francês com motosserras, ou seja, partem para uma solução que aparenta ser viável e escalável, e barata. No caso, quando tiverem milhares de usuários a faca terá que ser mecanizada e automática para fatiar muito mais pães sem precisar de pessoas, porém uma maquina industrial de fatiar pães custa muito caro, e uma motosserra que consegue cortar arvores também deve servir.
SaaS existem alguns muito bons, hoje virou roupa, todo mundo tem e quer usar da maneira que se sente melhor, alguns tem qualidade, outros tem preço, outros tem disponibilidade.... na pior situação dessas 3 opções você fica com 2.
Infelizmente, o modelo de negócios de alguns projetos acaba priorizando a divida técnica. A filosofia ágil foi distorcida para se tornar sinônimo de sem documentação ou que a entrega é a prioridade, o resto fica pra depois.
O ágil, realmente, é ter o controle de cada pequena ação cada pequeno sprint, e ser tão SIMPLES que no final do SPRINT ele já esta AUTODOCUMENTADO a filosofia, deveria seguir o principio de que ao colocar a mão na massa e fazer, o projeto já foi definido ANTES. Ou seja, é o ponto CENTRAL não o gargalo.
Em times menores, esse cenário deveria ser ainda mais importante, tudo o que foi planejado antes deveria estar em execução, a dinamicidade, vem mascarando a falta de conhecimento, ou a vontade de empurrar com a barriga disfarçado de velocidade.
Desculpe, bato muito nesse contexto, pois a cada dia, o mercado DEV vem perdendo qualidade, o ego de muitos gerentes de projeto, acaba destruindo o mercado. Quando mudamos a prioridade, mais cedo ou mais tarde, temos a cobrança da dívida.
Acho que a gente concorda em mais pontos do que parece — principalmente no objetivo final: controle, previsibilidade e redução de dívida técnica.
Onde vejo a divergência não é no valor da documentação nem no modelo ideal, mas na aderência desse modelo ao contexto mais comum hoje, especialmente fora de ambientes altamente regulados.
Em setores como fiscal, contábil e trabalhista, o projeto técnico precisa ser a fonte da verdade. Aí não existe espaço para improviso. Já em produtos digitais, SaaS e startups, o que observo com mais frequência é um cenário onde:
o domínio muda rápido
hipóteses são testadas em produção
decisões de schema acontecem em ciclos curtos
nem sempre há um “engenheiro de software” dedicado apenas ao projeto e documentação
Nesse contexto, o problema não é falta de consciência — é escala. Manter diagramas e documentação manualmente sincronizados com dezenas de migrations semanais simplesmente não se sustenta bem.
Por isso minha provocação não é “documentar menos”, e sim reduzir o quanto a documentação depende exclusivamente de disciplina humana. Quando o diagrama passa a ser:
derivado do schema real
versionado junto com migrations
integrado ao pipeline
tratado como artefato vivo do código
ele deixa de competir com a entrega e passa a fazer parte dela.
No fim, vejo dois caminhos convergindo para o mesmo ponto:
em ambientes maduros e regulados, o projeto segue sendo a fonte da verdade
em ambientes altamente dinâmicos, a automação ajuda a preservar essa verdade ao longo do tempo
Talvez o erro do mercado não seja abandonar o projeto, mas insistir em modelos manuais onde a realidade já exige algo mais integrado e automático.