Programar é Muito Mais do que Codar: Veja o Diagrama Científico que Mostra uma Verdade

Atualmente na minha empresa estamos trabalhando na refatoração da featire de pix, ela foi feita as pressas logo no início, e agora pra escalar precisamos praticamente refazer do 0, e o que mais fazemos é definir coisas, a gente passa mais tempo estudando soluções, validando idéias, testando arquiteturas e oitras coisas do que codando o projeto, e acredito quae codar vai ser a coisa mais simples da refatoração quando já tiver tudo definido, visto que a IA automatiza a escrita de código, e o código fica bom desde que você saiba guiar ela para o que você quer de código (Não é só pedir pra ela fazer a feature, é pedir pra ela fazer de acordo com tudo o que você definiu e ajustar caso ela não consiga)

Que publicação enxuta e precisa!

Eu gostei bastante do exemplo aqui apresentado, porque nunca foi uma questão de programar, mas como você disse de investigar de forma profunda um determinado problema, ou conjundo de informações e transformar elas em conhecimento.

Atualmente, eu utilizo IA porque percebi os benefícios ao longo da jornada até mesmo de trabalho, e lendo muito sobre, percebo que utilizar esta lupa pode beneficiar coisas como deixar de dar atenção a processos mecânicos que na sua grande maioria das vezes, pode atrapalhar, mesmo quando você treina esta parte também.

Então, buscar entender como o ferramental funciona, você consegue navegar de um ponto a outro e economizar o seu tempo em uma parte do processo como o digitar, e criar coisas repetitivas, que antes só eram possíveis com geradores de código, que nunca foram tão bons porque nenhum cliente quer ver material repetido ou partes do sistema iguais a de um concorrente e focar em questionar, produzir artefatos que fazem o projeto ser mais compreensivo para um par que vai contribuir com ele.

Além do mais, se você entregar "exatamente" o que foi pedido dentro de um orçamento bacana, sendo contratado ou trabalhando em uma jornada "própria" você vai ganhar muitos pontos, seja para assumir projetos com maior valor ou ser indicado para um novo projeto, e entender antes de codificar algo, evita que você construa uma ferramenta que pode prejudicar um conjunto de pessoas de algum modo, só pelo dinheiro.

Ética é importante neste caso, porque a evolução na carreira de um engenheiro pode ser alguma outra área, como a de segurança que necessita muito mais de você ao passo que entra mais capital, é desta forma que penso e isso não esta gravado em pedra. É necessário pensar de forma estratégica sempre, ou o trabalho não será bem feito, e continuaremos como simplesmente amadores.

Cada um tem uma história e quando conseguimos contar ela bem, tudo fica mais proveitoso, porque pode aprender com outras pessoas, como nesta experiência que trocamos, parabéns de verdade.

Forte Abraço!

Eu não diria wue rastrear é algo sombrio, afinal, pra você drbugsr precisar ssber o que está acontecendo e pra isso voce rastreia os dados. So que se faz com os dados após a resolução é que de fato deve se preocupar.

Excelente post, clacerda!
Faz total sentido o que você escreveu.

A sua análise sobre programar ser muito mais do que apenas "codar" bate perfeitamente com a minha própria experiência, e acho que a de muitos outros desenvolvedores.

Eu mesmo já passei por isso muitas vezes, principalmente em projetos pessoais. No passado, eu ficava semanas preso no desenvolvimento. A minha ânsia era codificar tudo o mais rápido possível, pensando que estava ganhando tempo, otimizando a entrega. Mas aí, quando me dava conta, estava gastando um tempo enorme adaptando funcionalidades, corrigindo bugs inesperados e lidando com coisas que nem tinham passado pela minha cabeça no início, que surgiram totalmente fora do escopo original. Tudo isso por causa daquela ânsia de "codar rápido".

E, como você bem mencionou sobre a época de "vibecoding", percebo como o uso descuidado de IA, apenas para gerar código mais rápido, poderia até piorar essa situação se não houver planejamento.

Até que resolvi dar um basta nisso e mudei completamente minha abordagem, inspirado justamente por essa percepção que seu texto ilustra tão bem. Hoje, ao invés de sair programando de cara, eu invisto um tempo considerável na fase de planejamento e análise, usando a IA como uma ferramenta antes de escrever código:

- Valido hipóteses: Uso a IA para discutir a ideia central, possíveis problemas e cenários.
- Analiso a stack: Peço para a IA comparar tecnologias, listar prós e contras de usar X ou Y para aquele contexto específico.
- Refino a arquitetura: Discuto a arquitetura que imaginei, questiono as decisões ("por que seguir o caminho X e não Y?"), e peço sugestões de padrões ou abordagens alternativas.
- Só depois de passar por essa fase de validação e planejamento é que eu realmente coloco a mão no código.

O resultado? Sim, eu demoro mais para começar a codar. A fase inicial se estendeu. No entanto, depois que começo, o desenvolvimento flui de forma muito mais suave. Aquele ciclo interminável de "coda > testa > arruma > quebra outra coisa > arruma de novo" diminuiu demais. Estou levando mais tempo para dar o pontapé inicial, mas estou salvando um tempo precioso de depuração, refatoração e retrabalho lá na frente.

Seu post e o diagrama do estudo capturam essa realidade perfeitamente: focar apenas na velocidade de escrita do código é uma ilusão.

O verdadeiro ganho de produtividade vem de entender o problema, pesquisar, planejar e validar antes – exatamente as atividades que o estudo mostrou serem tão significativas.

Ótima reflexão! Um abraço.

Sensacional esse grafo de macro atividades da programação, embora está abstraindo uma série de pequenas tarefas que conduzem uma macro.