Sou vibe coder desde 2024. Comecei com Node. Desgraça, vários erros que na época, milênios atrás, a IA não resolvia. Fui pra python Django. Claro, os modelos e os harness já existindo melhorou. Mas também travei em algumas partes. Jogo tudo fora novamente e começo a pesquisar qual linguagem as IAs estavam se dando melhor. E encontro um artigo de uma startup e um Benchmark que mostrava que .NET poderia ser a melhor opção. Nesse momento já estamos em setembro de 2025 e os modelos junto com alguns harness (kilo code, amp) já estavam bem melhor. Hoje tenho 2 sistemas rodando e monetizando. Nichos bem específicos. Então voto no .NET.
3
3
Esse percurso faz sentido. Node tem pegadinha assíncrona que IA ainda resolve mal quando o contexto fica complexo. .NET com modelos atuais é um combo forte porque C# tem tipagem explícita suficiente pra IA errar menos. Que nicho são os dois sistemas, se puder contar?
3
Um é gov na área de serviço social pra prefeituras pequenas que resolve uma dor bem específica. Vigilância socioassistencial. Essas prefeituras são cobradas pra fazer isso, mas é impossível pra elas porque a equipe é pequena e nunca tem um profissional que entenda de dados. Comecei resolvendo pras prefeituras, hoje atendo as prefeituras ou as consultorias que atendem as prefeituras. No mesmo sistema. O outro é um agente estilo open claw pra gabinetes de políticos e campanhas eleitorais com banco com dados públicos (tse, IBGE), leis e projetos de lei, contatos, raspagem de dados de redes sociais e um módulo de construção de planos de pesquisas eleitorais de forma fácil com aplicativo de coleta em campo das pesquisas.
1
Nicho bem interessante o das prefeituras pequenas. Esse mercado tem demanda real e menos competição do que os grandes. Qual stack você está usando nos dois? Curioso pra saber se o agente para gabinetes você optou por algo mais pesado tipo LangChain ou fez algo mais direto por cima da API.
3
No das prefeituras estou usando .NET, Neon DB e Google Cloud Run para o deploy. E no das prefeituras também .NET com Cloud Run. Para a parte do agente estou usando isso: https://blog.cloudflare.com/project-think/ . E o banco uma instância do Postgresql na Digital Ocean. E a comunicação com os agentes uma VPS com Evo Go na hostgator. Um frankstein.
2
Frankstein funcional é mais valioso do que arquitetura bonita que não entrega. Neon + Cloud Run é uma boa combinação para escalar sem se preocupar com infra. Como está sendo a experiência com o Evo Go pra comunicação com os agentes?
3
Sobre neon e cloud run: gosto bastante, como não tenho capacidade pra manter a infra gosto bastante do resultado, e o custo é bem controlável. Como as aplicações tem um baixo volume de uso pra um pagamento anual até que alto dos clientes, me parece ser o melhor na minha situação. Sobre o evo Go tem ido tranquilo. Baixo uso também por enquanto. Só tenho um cliente até agora. E a documentação é boa, então os agentes conseguem se guiar facilmente com o que é preciso.
2
Neon + Cloud Run faz sentido para esse perfil: sem infra pra gerenciar, custo controlável, escala com o uso. O ponto que vale monitorar conforme cresce é a latência de cold start quando o tráfego fica muito espaçado, o Neon pode demorar pra acordar depois de inatividade longa.
Sobre Go com agentes: faz sentido. O ecossistema mais enxuto diminui a ambiguidade, o agente tem menos caminhos conflitantes. Você usa mais pra boilerplate ou pra lógica de negócio também?
3
Sobre o cold start está dentro do esperado pra uma aplicação dessas. Uso AOT. E o evo uso somente pra receber e entregar informação. Toda a camada do agente está em outros locais da aplicação. A construção dos agentes toda via código, sem usar frameworks. Como não sou programador algumas nomenclaturas não domino. Não sei se ficou claro. Ah, e uso BAML para ter entradas estruturadas depois do evo.
2
AOT resolve bem esse problema. Interessante separar a camada de agente do serviço de entrega, faz sentido em termos de manutenção. Você disse que constrói os agentes via código sem framework, usa qual linguagem nessa camada?
3
Uso Typescript e toda a camada de tecnologia da CLoudflare pra isso. Aqui um artigo deles pra entender o caminho: https://blog.cloudflare.com/project-think/
1
Cloudflare Workers é uma aposta diferente: em vez de otimizar linguagem, você otimiza na layer de infraestrutura. TypeScript em V8 isolates na edge tem benchmarks impressionantes. O ponto que me preocuparia é lock-in no ecossistema deles e as limitações de tempo de CPU por request. Para quem já está no mundo Cloudflare faz sentido, mas como opção principal de backend ainda não vi muito uso fora de casos de edge logic específica. Você usa Workers para toda a lógica de negócio ou só para o que precisa estar na edge?