Ideia principal

O software viveu uma época em que analistas especificavam e programadores produziam código a metro. Uns pensavam, outros executavam. Esse recorte desapareceu: hoje um desenvolvedor pega um problema de ponta a ponta — arquitetura, código, segurança, entrega, acompanhamento — e até os arquitetos separados do resto do time estão cada vez mais raros.

Ninguém pede a volta dos analistas-programadores, e ninguém sustenta que se escrevia um software melhor quando a reflexão e a execução viviam em duas cabeças diferentes. A área decidiu pela prática, sem teoria.

Esse precedente vale como argumento: a mesma linha de corte, deslocada do código para o produto, precisa explicar por que escaparia do destino da anterior. O ônus da prova muda de lado.

Por que isso importa

Isso transforma uma opinião sobre a organização de produto em uma questão histórica verificável: a separação concepção / execução já foi tentada em larga escala no mesmo setor, e foi abandonada.

Isso também fornece uma trajetória provável em vez de um simples desacordo: recortes desse tipo recuam quando a ferramentaria reduz o custo de fazer as duas coisas.

Nuances e limites

Um precedente não é uma prova. O desenvolvimento teve razões próprias para costurar de volta as duas metades — ciclos curtos, integração contínua, custo de voltar atrás — e nada garante que essas razões se transponham ao produto.

E o abandono não foi total: papéis de arquiteto, staff engineer ou tech lead continuam existindo, com uma parte de concepção distinta da execução. O que desapareceu foi a correia de transmissão, não toda especialização.

Questões em aberto

• Que condições técnicas realmente permitiram costurar concepção e execução do lado do desenvolvimento, e quais delas existem hoje do lado do produto?