Introdução

Pedir a uma inteligência artificial para implementar uma funcionalidade é apenas uma das etapas do desenvolvimento. Em um sistema embarcado, essa implementação precisa respeitar restrições de memória, temporização, concorrência, armazenamento e comunicação. Também precisa conviver com o hardware disponível e, muitas vezes, com dispositivos que já estão em campo.

Quando o produto inclui firmware, serviços e uma aplicação de configuração, uma solicitação aparentemente simples pode atravessar todas essas partes. O código produzido precisa fazer sentido dentro desse conjunto.

É nesse ponto que a organização do trabalho ganha importância. Precisamos definir como os requisitos chegam à implementação, onde as decisões ficam registradas, quais mudanças estão autorizadas e quais evidências permitem considerar uma entrega concluída.

Este artigo apresenta uma forma de estruturar esse fluxo, combinando desenvolvimento orientado por especificações, monorepo, limites de arquitetura e validação. Um exemplo fictício de dispositivo conectado acompanha a discussão.

O ponto de partida é reconhecer que o prompt contém apenas uma parte do contexto necessário para desenvolver.

Considere a solicitação:

“Permita configurar remotamente o intervalo de envio das leituras de um sensor de temperatura”.

Uma implementação pode adicionar um campo na interface, criar uma operação no serviço e alterar um temporizador no firmware. Ainda assim, decisões importantes permanecem abertas: os valores permitidos, a persistência após uma reinicialização, o tratamento de um dispositivo desconectado e o momento em que a interface pode informar que a configuração foi aplicada.

Quando essas decisões ficam implícitas, o desenvolvedor ou o agente acaba preenchendo as lacunas durante a implementação. Componentes diferentes podem adotar interpretações diferentes do mesmo pedido.

O primeiro trabalho de engenharia é transformar a intenção em comportamento verificável.

Especificação e planejamento

É aqui que entra o Spec-Driven Development, ou SDD: desenvolvimento orientado por especificações. Na abordagem adotada neste artigo, a especificação registra o resultado esperado e orienta planejamento, implementação e validação. O Spec Kit, do GitHub [1], oferece uma referência pública para organizar esse percurso, separando especificação, plano técnico, tarefas e implementação.

A especificação deve ter a precisão necessária para a mudança. Para o exemplo do sensor, poderíamos começar com as seguintes decisões. Os valores e as políticas da tabela são ilustrativos, em um produto real, precisam vir dos requisitos e das restrições do sistema.

ASPECTO	COMPORTAMENTO DEFINIDO
Valores permitidos	Aceitar intervalos inteiros entre 10 e 3.600 segundos, incluindo os limites.
Entrada inválida	Rejeitar a solicitação e preservar a configuração vigente.
Persistência	Confirmar a aplicação somente após persistir e ativar o novo intervalo.
Dispositivo desconectado	Mostrar a solicitação como pendente, distinguindo-a da última configuração confirmada.
Reinicialização	Recuperar a última configuração válida persistida.
Limite da mudança	Preservar o funcionamento do sensor, o provisionamento e o mecanismo de atualização do firmware.

Esse pequeno registro já orienta decisões que poderiam ficar espalhadas pelo código.

A interface precisa distinguir solicitação de confirmação. O serviço precisa representar o estado pendente. O firmware precisa tratar falhas de persistência. A validação precisa verificar valores fora da faixa, perda de conexão e reinicialização.

A especificação também evolui com o aprendizado. Se um teste revelar uma restrição do dispositivo que exige alterar o comportamento pretendido, essa decisão deve ser revista e registrada. Isso permite manter requisitos, código e testes coerentes ao longo das iterações.

Depois de esclarecer o comportamento, vem o plano técnico.

No exemplo, o plano deve indicar quem valida a solicitação, como a configuração será representada no contrato de comunicação, qual módulo controla o intervalo no firmware e como o dispositivo confirma o resultado. Também deve identificar os componentes afetados e a compatibilidade necessária com versões anteriores.

As tarefas derivam dessas decisões. “Implementar configuração remota” ainda é amplo demais para acompanhar o trabalho. “Validar os limites do intervalo”, “preservar a configuração em caso de falha de gravação” e “distinguir estado pendente de confirmado na interface” descrevem resultados que podem ser revisados e testados.

A rastreabilidade surge dessa relação: cada comportamento previsto deve encontrar uma implementação correspondente e uma forma de verificação. Uma lista de tarefas concluída precisa ser confrontada com a especificação para identificar o que ainda ficou de fora.

Monorepo e arquitetura

Quando uma mudança atravessa vários componentes, a organização do repositório passa a fazer parte desse fluxo.

Um monorepo reúne diferentes componentes em um único repositório versionado. Uma estrutura possível para o nosso exemplo seria:

ESTRUTURA ILUSTRATIVA DE UM MONOREPO

produto/
├── especificacoes/
├── contratos/
├── firmware/
├── servicos/
├── interface/
├── testes/
└── ferramentas/

Essa organização permite revisar, na mesma alteração, o requisito, o contrato, o firmware, o serviço e a interface. Uma revisão do repositório registra uma combinação identificável desses elementos.

A ideia de uma fonte compartilhada e a necessidade de ferramentas para sustentar esse modelo aparecem no relato técnico de Rachel Potvin e Josh Levenberg sobre o repositório único do Google [2]. Para um produto embarcado, a decisão deve considerar o próprio contexto: frequência de mudanças conjuntas, responsabilidades, permissões e custo de manutenção.

Reunir os arquivos, por si só, deixa várias questões em aberto. Cada componente continua precisando de limites claros, comandos de compilação conhecidos e verificações adequadas. Alterações em um contrato compartilhado precisam considerar todos os seus consumidores.

Também há uma distinção essencial entre versionamento e implantação. Um commit pode reunir uma mudança coerente de código, enquanto os dispositivos em campo continuam executando versões anteriores. O planejamento ainda precisa definir compatibilidade de mensagens, ordem de implantação e comportamento diante de versões incompatíveis.

A arquitetura ajuda a manter essas responsabilidades compreensíveis.

No firmware do sensor, receber uma mensagem, interpretar seus campos, validar uma regra, persistir uma configuração e alterar o agendamento são responsabilidades relacionadas. Concentrá-las em um único callback dificulta testar falhas e compreender o estado do dispositivo.

Uma organização possível mantém o transporte responsável pela recepção, o protocolo pela interpretação da mensagem e a lógica de aplicação pela mudança de configuração. O acesso ao armazenamento e ao hardware fica atrás de interfaces pequenas, adequadas ao sistema.

Essa separação permite testar parte do comportamento no computador de desenvolvimento. Podemos exercitar a validação de intervalos ou simular uma falha de persistência sem depender da comunicação real em todos os testes.

Em sistemas embarcados, essas escolhas precisam respeitar custos concretos. Uma abstração deve ajudar a controlar dependências, testar comportamento ou compreender o ciclo de vida dos recursos. Consumo de memória, alocações, cópias de buffers e impacto na temporização continuam sendo critérios de engenharia.

Contexto e autonomia dos agentes

O agente de IA precisa conhecer essas regras de trabalho.

Uma forma prática de fornecer esse contexto é manter um documento inicial curto, com o mapa do repositório, os comandos principais, os limites de atuação e as referências necessárias. Guias específicos podem ser consultados conforme a tarefa: firmware, contratos, testes, arquitetura ou operação de ambientes.

Esse contexto deve incluir o trabalho atual, objetivo, decisões aceitas, componentes envolvidos e pendências. Assim, a retomada depende de registros versionados que possam ser consultados e revisados.

Rotinas reutilizáveis também ajudam a organizar atividades recorrentes. Uma rotina de alteração pode orientar a inspeção inicial, a caracterização do problema, a implementação e os testes. Uma rotina de validação de firmware pode reunir compilação, análise de recursos e procedimentos de bancada.

As instruções escritas precisam ser acompanhadas por mecanismos verificáveis. Se o fluxo limita os caminhos que podem ser alterados, uma ferramenta pode conferir o diff. Se um contrato precisa permanecer compatível, testes podem exercitar consumidores anteriores. Permissões de acesso e restrições de operação precisam existir nos mecanismos que executam as ações.

Esse cuidado dá significado à autonomia do agente.

O responsável pelo produto define o comportamento desejado e aceita os resultados. O agente pode inspecionar código, propor um plano, implementar e executar verificações dentro do escopo combinado. Decisões que mudam esse escopo ou afetam contratos importantes voltam para revisão humana.

Para uma funcionalidade que exige planejamento explícito, três momentos de revisão são úteis: depois da especificação, antes da implementação e na avaliação final dos resultados. Entre eles, o trabalho pode avançar enquanto respeita as decisões aprovadas.

Validação e rastreabilidade da entrega

A validação começa antes da alteração do código existente.

Em uma correção, vale reproduzir o defeito e registrar uma verificação que o exponha. Na introdução de um comportamento, os critérios de aceitação devem orientar os testes desde o início. Isso ajuda a evitar que os testes apenas reproduzam as escolhas feitas na implementação.

No exemplo do sensor, a verificação deve cobrir os limites permitidos, valores inválidos, falha de persistência, desconexão e recuperação após reinicialização. Se houver repetição de comandos ou mensagens atrasadas, o contrato também precisa definir como tratá-las.

Parte dessa verificação pode ocorrer sem a placa. Parsers, regras de validação e máquinas de estado são candidatos a testes no ambiente de desenvolvimento. Compilação com a ferramenta do alvo, análise estática e avaliação de tamanho acrescentam outras evidências.

A bancada responde às questões que dependem do dispositivo real. É nela que podemos observar o intervalo efetivo das publicações, o comportamento após reinicialização e a recuperação da comunicação. Quando a mudança afeta consumo, temporização ou concorrência, essas propriedades precisam de medições apropriadas.

As evidências devem indicar seus limites. Um teste com armazenamento simulado demonstra o comportamento diante das falhas modeladas. Uma compilação demonstra que aquela configuração de código foi aceita pela cadeia de ferramentas. A validação na placa observa o comportamento no hardware e nas condições utilizados.

A seleção dos testes também precisa acompanhar o impacto da mudança. Durante a implementação, verificações focadas permitem corrigir problemas com rapidez. Antes da integração, executa-se o conjunto mais amplo definido para os componentes afetados. Mudanças em contratos compartilhados exigem atenção aos consumidores, mesmo quando o diff é pequeno.

Há ainda um detalhe fácil de perder: o resultado de uma validação precisa estar associado ao candidato que será entregue.

Para firmware, isso envolve registrar a revisão do código, a versão das ferramentas, a configuração de compilação, a identificação do binário e o hardware utilizado. Os testes executados e suas condições completam esse registro.

Se o código ou uma configuração relevante mudar depois da validação, é necessário avaliar novamente quais evidências continuam válidas. A entrega deve permitir identificar o artefato que efetivamente foi testado.

O mesmo cuidado vale para a recuperação. Restaurar um binário anterior pode ser insuficiente quando uma mudança também altera o formato dos dados persistidos. Compatibilidade de armazenamento e estratégia de retorno precisam aparecer no planejamento quando forem afetadas.

Adoção e evolução do fluxo

Esse fluxo tem custos. Especificações exigem manutenção, ferramentas de validação precisam acompanhar o produto e revisões humanas consomem atenção. Documentos duplicados ou aprovações sem uma decisão concreta podem tornar o processo lento.

Por isso, a estrutura deve ser proporcional ao trabalho. Uma correção localizada pode precisar de uma descrição objetiva, uma reprodução do defeito e testes focados. Uma mudança de protocolo ou armazenamento exige análise de impacto, compatibilidade e recuperação mais detalhadas.

Também vale acompanhar o efeito do processo: quanto retrabalho ocorre por ambiguidade, quais falhas escapam da validação e quanto esforço é necessário para retomar uma atividade. Esses sinais ajudam a ajustar o fluxo com base no uso.

É possível começar com poucos elementos: um contexto inicial confiável, requisitos claros para a próxima mudança, responsabilidades por componente e um procedimento de validação que outra pessoa consiga repetir.

O prompt continua sendo uma forma de iniciar e conduzir o trabalho. Ao seu redor, o fluxo mantém as decisões acessíveis e conecta cada implementação ao comportamento que se pretende entregar. Para o desenvolvimento embarcado, essa conexão precisa chegar até o dispositivo: a funcionalidade descrita, o firmware instalado e a evidência observada na bancada devem contar a mesma história.

Referências

[1] GITHUB. Spec Kit. Repositório e documentação. Disponível em: github.com/github/spec-kit.

[2] POTVIN, Rachel; LEVENBERG, Josh. Why Google Stores Billions of Lines of Code in a Single Repository. Communications of the ACM, v. 59, p. 78-87, 2016. Disponível em: Google Research.