Em Ratatouille, o chef Gusteau acredita que cozinhar deve estar ao alcance de todos. Remy está menos convencido: saber cozinhar não significa necessariamente que alguém deva ser solto na cozinha. A breve conversa entre eles captura uma tensão que agora parece familiar no desenvolvimento de software.
Dê a alguém um assistente de programação com IA, e essa pessoa poderá transformar uma ideia em uma aplicação funcional. Um painel. Um portal do cliente. Uma automação que elimina horas de trabalho repetitivo.
Essa é uma oportunidade extraordinária. Pessoas que entendem um problema de negócio podem participar diretamente de sua resolução, mesmo que nunca tenham se considerado desenvolvedoras.
Mas uma aplicação funcional é o início de uma responsabilidade.
Ainda é preciso decidir onde seus dados ficarão, quem poderá acessá-los, como as mudanças chegarão à produção e o que acontecerá quando algo der errado. Alguém precisa garantir que ela se encaixe nos sistemas, nas políticas e nas formas de trabalho da empresa.
Qualquer pessoa pode preparar um prato. Um restaurante precisa de uma cozinha inteira por trás dele.
Quando experimentos se tornam essenciais
Considere um cenário.
Uma pessoa colaboradora quer uma forma melhor de acompanhar solicitações de clientes. Com um assistente de programação com IA, ela cria uma pequena aplicação. A aplicação tem boa aparência, economiza tempo e rapidamente atrai alguns colegas.
Ela é conectada a dados reais de clientes. Um processo em segundo plano é adicionado para manter tudo atualizado. Para torná-la acessível, a pessoa compartilha um link.
Em poucas semanas, a equipe passa a depender dela.
Mas a aplicação é executada no laptop da pessoa colaboradora. Sua integração usa uma credencial pessoal. Ninguém definiu quem deveria ter acesso, testou a restauração de um backup ou documentou como mantê-la. Quando o laptop é fechado, o processo em segundo plano é interrompido.
O código pode funcionar exatamente como planejado. Ainda assim, a empresa passa a ter uma dependência sem gestão.
Nada disso exige má-fé ou uma ferramenta de programação incompetente. Cada etapa pode parecer razoável quando o objetivo imediato é simplesmente criar algo útil.
A dificuldade está em reconhecer quando um experimento se tornou um sistema do qual outras pessoas dependem.
O trabalho além do código
O desenvolvimento de software contém uma grande quantidade de trabalho que quase não aparece em uma demonstração bem-sucedida:
- Arquitetura e consistência. Esse recurso deve ampliar uma aplicação existente? Qual banco de dados, framework e componentes compartilhados devem ser usados? Como ele se encaixa nos sistemas e nas convenções de interface já existentes na empresa?
- Integridade dos dados. Como a estrutura do banco de dados pode mudar sem danificar registros existentes ou interromper outras aplicações? Se uma solicitação for repetida, ela criará um pagamento, chamado ou cliente duplicado?
- Gestão de mudanças. Onde o código é versionado? Qual branch contém a mudança? Como são gerenciados trabalhos simultâneos, rebases, revisões, lançamentos e recuperação?
- Requisitos e evidências. O que foi solicitado e o que conta como sucesso? Alguém consegue acompanhar uma tarefa do Jira ou um chamado de suporte desde a implementação, passando por testes e evidências, até o lançamento? Encerrar o chamado significa que o problema da pessoa usuária foi realmente resolvido?
- Ambientes e estações de trabalho. Quais runtimes, dependências, contêineres e serviços locais são aprovados? Outra pessoa consegue reproduzir a configuração? Os dados e as credenciais de desenvolvimento, teste, homologação e produção estão devidamente separados?
- Operações e responsabilidade. Quem monitora a aplicação, controla seus custos, atualiza suas dependências, responde a falhas e cuida dela quando sua pessoa criadora seguir em frente?
Também existem decisões sobre a experiência oferecida às pessoas. Duas aplicações podem funcionar corretamente e, ainda assim, apresentar interfaces conflitantes, calcular a mesma métrica de negócio de maneiras diferentes ou manter versões concorrentes do mesmo registro de cliente.
As políticas da empresa também se aplicam a todo o processo. Uma política de uso de IA pode determinar quais ferramentas e contas são aprovadas. Os requisitos de privacidade influenciam quais dados podem entrar em prompts, logs, capturas de tela e evidências de teste. As regras de acesso determinam quais sistemas uma pessoa — ou um agente que atua em seu nome — pode ler ou alterar.
Essas responsabilidades permanecem mesmo com a evolução da geração de código.
Na verdade, podemos defender esse argumento sem discutir se a IA escreve um bom código: mesmo que cada linha gerada estivesse correta, essas perguntas ainda precisariam de respostas.
Dar contexto à IA
Codex e Claude Code podem ajudar em grande parte desse trabalho. Um agente pode inspecionar uma arquitetura existente, preparar uma alteração no banco de dados, trabalhar em uma branch, executar testes, documentar evidências e atualizar uma tarefa.
Mas ele precisa do contexto da empresa. Um pedido para “criar um painel de clientes” não explica, por si só, qual sistema de clientes é a fonte oficial, quais campos são sensíveis ou qual aprovação é necessária antes do lançamento.
O mesmo vale para desenvolvedores experientes que ingressam em uma organização desconhecida. Capacidade técnica e conhecimento institucional são coisas diferentes. Ambos são importantes.
A parte positiva é que esse conhecimento pode se tornar parte do ambiente de desenvolvimento.
O Codex oferece suporte a instruções compartilhadas de projeto por meio de AGENTS.md. O Claude Code oferece orientação persistente por meio de CLAUDE.md. Skills, plugins personalizados e integrações podem fornecer fluxos de trabalho reutilizáveis e acesso aos sistemas onde o trabalho é acompanhado.
Em vez de explicar repetidamente como a empresa desenvolve software, as equipes podem manter a orientação junto desse software: quais componentes reutilizar, como testar uma mudança, onde inserir evidências e o que precisa acontecer antes que uma tarefa seja considerada concluída.
Apoiar a orientação com controles
Uma instrução que orienta um agente a evitar dados de produção deve ser respaldada por credenciais e permissões que restrinjam o acesso. Uma exigência de executar testes deve ser apoiada por verificações de lançamento. Ambientes aprovados devem facilitar a reprodução da configuração esperada.
A documentação do Claude Code distingue explicitamente instruções que orientam o comportamento de permissões que controlam ações. Essa distinção é essencial para uma configuração empresarial confiável.
As pessoas também precisam compreender claramente suas responsabilidades. A liberdade para experimentar pode ser ampla, enquanto o acesso a informações sensíveis e a autoridade para lançar mudanças dependem da função da pessoa e das consequências da aplicação.
Engenheiros experientes continuam sendo essenciais nesse modelo. Seu julgamento orienta a arquitetura, estabelece os controles, revisa mudanças relevantes e transforma os aprendizados de projetos individuais em bases que outras pessoas podem reutilizar.
Como a Guanta ajuda
Na Guanta, ajudamos empresas a construir esse ambiente para o desenvolvimento com assistência de IA.
O trabalho começa pela organização: seus sistemas, dados, políticas, equipes e responsabilidades operacionais. A partir daí, reunimos orientação de desenvolvimento, componentes reutilizáveis, integrações, ambientes controlados e fluxos de trabalho que conectam uma solicitação de negócio a um resultado verificável.
O objetivo é tornar os padrões da empresa parte da forma como o trabalho é realizado, para que as pessoas possam dedicar mais tempo à resolução de problemas úteis com IA.
É assim que uma participação mais ampla se torna sustentável. Alguém com uma boa ideia deve poder explorá-la, construir sobre bases existentes e seguir um caminho claro até algo que a organização consiga manter e oferecer suporte.
A promessa por trás de “qualquer pessoa pode programar” merece se tornar realidade.
Ofereça a elas uma cozinha preparada para isso.