De fato, em parte um prompt com maior qualidade produz um resultado melhor, mas quando estamos falando de programação, apidamente se alcança o limite de contexto e ele começa alucinar, então para projetos reais, não tem muita utilidade fora aplicar em pequenos trechos de código.
Temos utilizado em projetos reais, complexos e com milhares de linhas de codigo.
Seu argumento sobre limitação de janela de contexto/tokens está correto. Mas é justamente aqui que entra a necessidade de criar métodos de trabalho que contornem isso.
Listo alguns exemplos que temos aplicado:
No Visual Code, plug-on Cline.
No Cline, API da OpenAI, API da Anthropic , Ollama e até API Gemmini.
Cada API com um propósito!
Ollama com Modelo Mistral:latest, rodando local, sendo usado para:
Ler códigos da pasta do projeto;
Gerar arquivo README.md descrevendo o projeto.
Para cara "pod" com suas classes gerar um .md descrevendo as user stories, diagrama de classes e diagrama de sequência (estes 2 últimos em formato json para economizar tokens).
Fase 1: Arquivos de código muito extensos, com várias classes, precisam ser adaptados ao SOLID. Por exemplo, código gerado pelo entity framework com mais de 1000 linhas: foi preciso criar, via GEN-Ai, código em python (por ser mais simples) para quebrar esse código em arquivos menores respeitando SOLID em termos de cada arquivo 1 classe.
Fase 2: criação de uma excelente memória de contexto sem ter que ficar a cada iteração lendo todo o código (e na instrução base do cline você coloca essa orientação de onde buscar o contexto).
Fase 3: Trabalhar por user story, de preferência pequenas. Evitando rotinas do tipo "faça todo o sistema" ou "revise todo o projeto". Trabalhe em "tokens" do código, ou seja, uma classe por vez.
Fase 4: Melhoria contínua: aperfeiçoe semanalmente sua rotina de trabalho com GEN-Ai , pois a cada dia aprendemos algo novo e devemos incorporar isso no método de trabalho.
Faze 5: Com o trabalho concluído em um determinado conjunto de user stories, quando começamos a perceber que começou "mundo do chapeleiro maluco" (entropia), no Cline, está na hora de iniciar uma nova task para ZERAR a janela de contexto e dar continuidade de onde parou.
Mas sim, concordo com você que sempre vai ter momento em que o Dev precisará assumir integralmente o controle e meter a mão na massa. Mas a entrega de valor do uso de GEN-AI não está na tentativa de que 100% do trabalho foi automatizado, pelo contrário. Se com essa rotina de trabalho foi possível resolver 20% a 50% do trabalho, acho que já tá valendo.
O que exatamente você está definindo como um projeto "complexo"? E qual a escala dessas "milhares de linhas de código"? E qual a porcentagem de utilização exclusiva ou majoritária da AI pra resolver esses problemas que você definiu como complexos?
Por fim, qual valor esses produtos trouxeram, eles já estão a venda e tendo sucesso comercial?
Limitação de memória de contexto é ainda obstáculo para prover sistemas mais complexos com alto quantitativo de instruções.
Por isso a importância de ter um sistema de trabalho usando técnicas e ferramentas variadas.
Por exemplo, Google Gemmini com maior janela de contexto e usando outras ferramentas e técnicas específicas para esse propósito (ex: LongRoPe).
Ficar dependendo apenas e somente de simples
chamadas de API a uma determinada ferramenta (OpenAI, Anthropic ou Google) , você está completamente correto!
Mas entendo não ser essa a resposta/método.
Mas veja, longe de mim querer trazer aqui a bala de prata que resolve tudo.
Acredito que existem muitos cenários e características de projeto onde não usar GEN-AI é não abraçar oportunidades. Da mesma forma, outros cenários talvez, e reforço aqui o talvez, não tenha como aplicar integralmente GEN-AI.
O resumo do que pretendo dizer é:
Não há uma forma estática de usar isso! Precisa adaptar a cada cenário para tirar o máximo de proveito.