DEV Community

Cover image for Por que não fui pelo caminho comum
jreeeedd
jreeeedd

Posted on

Por que não fui pelo caminho comum

O momento atual no desenvolvimento de software empurra muitos devs para dois caminhos: microsaas (ou produto fechado) para monetizar rápido, ou apostar em agentes de IA e automação com agentes — produtos e ferramentas em que o agente “resolve” tarefas sozinho. Este artigo é sobre por que não fui por aí. Uma análise do cenário, uma escolha consciente e uma provocação: o caminho comum é legítimo, mas não é o único.


O que está em jogo

Há pressão por receita, por impacto visível e surfar a onda da vez. Microsaas virou atalho para muitos indies: produto enxuto, assinatura, crescimento. Do outro lado, agentes de IA e workflows agentic ganharam tração — a ideia de que a IA não é só assistente, mas workforce autônoma que lê código, implementa features, abre PRs. Em 2025–2026 isso deixou de ser só experimento e virou opção concreta de produto e de posicionamento.

Nada disso é errado. São escolhas. O que quero deixar claro é: por que, no caso do Schepta, escolhi outro caminho.


Base antes de agente, valor antes de preço

Em algum momento você provavelmente viu o mesmo que eu: devs lançando microsaas, outros automatizando tudo com agents, a sensação de que quem não está nessa trilha está deixando dinheiro na mesa.

Eu considerei os dois caminhos.

  1. Microsaas traz contrato, preço e vendor lock-in antes de o valor estar provado. Para um problema como esse — transformar um schema em UI real, de forma estável em vários frameworks — isso é fricção antes da hora. O valor precisa ser demonstrado primeiro; o modelo de negócio vem depois.

  2. Agents têm um apelo parecido: automatizar a geração de interface parece o passo óbvio. Mas agents que geram ou alteram UI precisam de uma base estável para operar — um contrato claro e auditável entre backend, agent e frontend. Construir o agent antes dessa base é frágil. A ordem importa: primeiro a engine funciona bem, depois o agent tem onde se apoiar.

Mas base estável tem um custo: precisa ser provada. Formulários e fluxos quebrados impactam usuário e negócio diretamente — é um problema mission critical. Os mais de 100 testes unitários e E2E do Schepta existem exatamente por isso: para que a engine seja confiável o suficiente para ser estendida, contribuída e usada em produção sem surpresas.

E esse foi o caminho que eu escolhi, se foi o correto ou não, somente o tempo dirá.

Se essa discussão de caminhos fez sentido pra você, a documentação e os exemplos do Schepta estão te esperando em schepta.org.

E você: está no caminho do microsaas, dos agentes ou tá construindo alguma outra coisa? Qual foi a linha que você seguiu pra tomada de decisão?


Próximo passo

No próximo artigo da série falamos de Quando a IA gera a interface: o schema como guardrail: como o ecossistema (json-render, A2UI) valida essa abordagem, como o Schepta responde ao problema do não-determinismo das IAs e como ele se encaixa em fluxos que vão do código assistido ao 100% automatizado com agents.

Top comments (0)