Durante muito tempo, usei inteligência artificial todos os dias sem deixar que ela conduzisse grandes partes do desenvolvimento.
Isso pode parecer contraditório. Na prática, a IA já estava presente em quase tudo: pesquisa, planejamento, escrita, análise, exploração de ideias, revisão de código, exemplos de implementação e pequenas refatorações. Ferramentas como o ChatGPT e o GitHub Copilot rapidamente se tornaram parte natural do trabalho.
Mas havia uma fronteira que eu demorava a atravessar: deixar agentes de código assumirem tarefas maiores, mexerem em vários arquivos, proporem planos, executarem mudanças e validarem resultados.
Eu gostava da IA como apoio. Como copiloto. Definia uma intenção clara e pedia um bloco de código, uma explicação, uma alternativa de arquitetura ou um ajuste localizado. Muitas vezes, ela fazia o trabalho pesado de transformar uma decisão minha em código escrito. Mas eu continuava trabalhando praticamente da mesma forma: pensava, decidia, desenhava o plano mentalmente e usava a IA como ferramenta de velocidade.
A IA acelerava o trabalho. Ainda não tinha mudado profundamente a forma como o trabalho era desenhado.
Quando a IA deixa de ser autocomplete
Essa percepção mudou quando os modelos ficaram bons demais para serem tratados apenas como um autocomplete sofisticado.
Uma pergunta simples começou a gerar soluções quase completas. Um pedido pequeno desbloqueava duas ou três tarefas paradas. Uma investigação rápida revelava dependências, riscos e caminhos que talvez levassem horas para aparecer manualmente. Aos poucos, ficou claro que o limite já não estava apenas na capacidade dos modelos. O limite também estava na forma como os orientávamos.
Foi nessa época que comecei a observar com mais atenção os agentes de código, as ferramentas de terminal e os workflows estruturados.
Em vez de pedir apenas respostas pontuais, comecei a estudar como essas ferramentas funcionavam de verdade: ler documentação, abrir --help, entender permissões, contexto, modos de execução, limites, revisão de alterações, testes e formas de recuperar o controle quando algo dava errado.
Mais importante do que aprender a pedir código era aprender a orientar um agente para produzir algo que pudesse ser revisado.
E essa foi a conclusão inesperada: a IA me fez valorizar uma coisa que durante anos associei a peso, atrito e burocracia.
Processo.
Não processo no sentido pesado, cheio de reuniões vazias e documentos que ninguém lê. Processo no sentido de clareza, contexto, intenção, validação e memória.
Quando agentes entram no fluxo, muitas práticas que pareciam excessivas para equipes pequenas passam a fazer muito mais sentido: documentação curta, critérios de sucesso, planos de implementação, plano de QA, testes, revisão, Definition of Done, registros de decisão, instruções por repositório, arquivos como AGENTS.md e convenções explícitas de trabalho.
Isso deixa de ser cerimônia. Passa a ser infraestrutura.
O agente precisa do que o humano muitas vezes deixa implícito
Uma pessoa experiente consegue trabalhar com muito contexto implícito. Lembra-se de decisões anteriores, sabe quais arquivos evitar, percebe nuances do domínio, reconhece riscos pelo histórico e se adapta ao longo do caminho.
Um agente não tem esse histórico da mesma forma. Precisa que o contexto esteja explícito. Precisa saber quais arquivos considerar, quais comandos pode executar, quais padrões deve seguir, quais testes validam a mudança, quais decisões não deve tomar sozinho e qual resultado é considerado aceitável.
Foi aí que a pergunta mudou.
Deixou de ser apenas: “como posso pedir código à IA?”
Passou a ser: “como desenho um sistema de trabalho no qual um agente consegue investigar, produzir, validar e melhorar uma entrega?”
Essa é a essência do que muitos hoje chamam de agentic engineering, ou engenharia agentiva.
Não é deixar a IA fazer tudo. Também não é aceitar qualquer resultado gerado por um modelo e esperar que funcione. É quase o oposto.
É transformar intenção em workflow.
Um bom workflow agentivo começa com uma tarefa clara. Essa tarefa passa por investigação. Depois, vira um plano. O plano identifica riscos, arquivos afetados, critérios de sucesso e verificações necessárias. Só então vem a execução. Depois, a validação. Depois, a revisão. Depois, o registro do que foi feito e aprendido.
Em termos simples:
intenção -> contexto -> plano -> execução -> validação -> revisão -> memória.
Esse fluxo pode parecer mais lento no início. Mas, quando bem aplicado, reduz retrabalho, diminui a ambiguidade e permite que agentes assumam partes maiores do trabalho sem transformar o projeto em um conjunto de alterações soltas.
A IA desloca o centro da engenharia
O ponto central é este: a IA não substitui a engenharia. Ela desloca o centro da engenharia.
Durante muito tempo, uma parte grande do trabalho técnico estava em escrever código linha por linha. Esse trabalho continua existindo, mas cada vez mais valor passa para outra camada: definir contexto, desenhar o fluxo de execução, criar critérios de validação, organizar conhecimento, revisar decisões e garantir que o resultado final faça sentido para o produto e para a operação.
Isso muda o papel de quem constrói software.
O desenvolvedor continua sendo técnico. Continua responsável. Continua precisando entender arquitetura, domínio, dados, segurança, performance e experiência do usuário. Mas passa também a atuar como alguém que desenha sistemas de trabalho para agentes.
Na Makers, essa reflexão não fica limitada ao código.
A mesma lógica aparece em operações comerciais, CRM, atendimento, marketing, analytics, formulários, dashboards e processos internos. Não basta ter dados. Não basta ter uma ferramenta que responde a perguntas. Não basta conectar um modelo a um canal e chamar isso de automação.
O salto acontece quando dados, IA e revisão humana entram em um ciclo estruturado:
- detectar um sinal;
- levantar uma hipótese;
- priorizar uma ação;
- executar com limites claros;
- validar o resultado;
- aprender para o ciclo seguinte.
Sem workflow, a IA responde a perguntas.
Com workflow, a IA participa de um sistema de melhoria contínua.
Isso se aplica a desenvolvimento, vendas, atendimento, BI, produto e operações. A pergunta deixa de ser “como usamos IA nesta tarefa?” e passa a ser “qual processo podemos redesenhar para que pessoas, dados e agentes trabalhem melhor em conjunto?”
De ferramenta para sistema de trabalho
Quando uma empresa usa IA apenas como uma camada de resposta, ganha velocidade pontual. Quando usa IA dentro de um processo bem desenhado, ganha capacidade operacional: mais contexto, mais consistência, mais rastreabilidade e mais aprendizado acumulado.
É por isso que, para nós, agentes de IA não são apenas uma nova interface. São uma nova exigência de desenho operacional.
Quanto mais autonomia damos aos sistemas, mais importantes se tornam os limites. Quanto mais rápido um agente consegue executar, mais importante se torna saber o que validar. Quanto mais tarefas automatizamos, mais importante se torna preservar memória, critério e responsabilidade.
A IA não eliminou a necessidade de processo.
Tornou bons processos mais importantes.
Talvez essa seja uma das grandes mudanças profissionais dos próximos anos. Não apenas aprender a escrever prompts melhores. Não apenas adotar a ferramenta mais recente. Mas aprender a desenhar workflows nos quais agentes operam com contexto, limites, validação e propósito.
No fim, o futuro não pertence necessariamente a quem “usa IA”.
Pertence a quem sabe transformar trabalho em sistema.