Este é o Artigo 5 da Série: Seu Próximo Passo em Dados e IA. Aproveite a leitura, tem insights valiosos aqui! A série completa pode ser encontrada aqui.

Imagine encerrar uma sessão de desenvolvimento com uma nova funcionalidade pronta para ser testada. Até aí, nada de extraordinário. Mas existe um detalhe interessante: você não escreveu manualmente uma única linha de código. E isso não significa que ficou de braços cruzados. Pelo contrário! Você analisou o problema, definiu regras, explorou alternativas, tomou decisões, orientou um Assistente de IA e verificou se a solução realmente atendia ao que precisava ser construído.

Esse cenário, que há poucos anos parecia distante, está se tornando cada vez mais comum no desenvolvimento de software. A IA assume boa parte do trabalho de escrever o código, enquanto o profissional concentra sua atenção naquilo que realmente importa: compreender o problema, definir o comportamento esperado, planejar a solução e avaliar os resultados.

E aqui está uma reflexão importante: desenvolver software nunca foi apenas escrever código. Sempre foi, acima de tudo, resolver problemas e tomar decisões. O código é simplesmente a maneira de transformar essas decisões em instruções que o computador consegue executar. Agora que a IA pode assumir grande parte dessa tarefa, outras habilidades ganham ainda mais relevância.

Isso também muda a maneira como interagimos com a tecnologia. Já não basta abrir um Assistente de IA, escrever um prompt e esperar que tudo funcione perfeitamente. É preciso saber exatamente o que se deseja construir, compreender as decisões envolvidas e, principalmente, ter condições de avaliar se aquilo que a IA entregou é realmente uma boa solução.

É nesse contexto que entra o SDD (Spec-Driven Development), ou Desenvolvimento Orientado por Especificações. A proposta é bastante interessante: antes de pedir que a IA escreva o código, organizamos o problema, definimos os requisitos e estabelecemos critérios claros para orientar a implementação. Em outras palavras, damos à IA algo muito mais valioso do que um pedido genérico: uma especificação bem construída.

Mas como isso funciona na prática? O que muda na rotina de quem desenvolve software? E por que essa abordagem está ganhando tanta importância na era da programação com IA?

Neste artigo, vamos explorar o conceito de SDD de maneira simples e didática, utilizando exemplos e analogias para mostrar como essa abordagem funciona e por que ela representa uma mudança importante na forma de desenvolver software.

Boa leitura!

A Aplicação Começa nas Decisões Que Você Toma

Imagine que um laboratório precise de uma aplicação para reservar seus equipamentos. O pedido inicial parece simples: criar um catálogo, mostrar os horários disponíveis e permitir que os usuários façam reservas.

Um Assistente de IA pode trabalhar nessa descrição e gerar a estrutura da aplicação. Antes de considerar a funcionalidade concluída, porém, algumas decisões precisam estar claras.

O laboratório tem dois equipamentos do mesmo modelo. Cada reserva corresponde a uma unidade específica? Uma reserva que termina às 15h permite que outra comece exatamente às 15h? Quem pode cancelar uma reserva? O que deve acontecer quando duas pessoas tentam confirmar o mesmo equipamento para o mesmo período?

Cada resposta altera o software. A identificação das unidades afeta o modelo de dados. A regra dos horários muda a verificação de disponibilidade. As permissões influenciam o comportamento da aplicação. A confirmação simultânea exige atenção à forma como as informações são gravadas.

Você pode pedir que a IA escreva todas as funções envolvidas. Para orientar e avaliar esse trabalho, precisa entender quais regras elas devem implementar e como essas regras se relacionam.

É aí que aparece o valor do profissional. A qualidade da solução depende de representar adequadamente o funcionamento do laboratório, transformar essa compreensão em decisões técnicas e verificar se elas foram respeitadas.

O Que Muda Quando a Especificação Orienta o Desenvolvimento?

SDD significa Spec-Driven Development, ou desenvolvimento orientado por especificações. Nessa abordagem, a descrição estruturada do que deve ser construído orienta o desenho técnico, as tarefas de implementação e a avaliação do resultado.

A especificação registra comportamentos esperados, regras, restrições e critérios de aceitação. O desenho técnico explica como os componentes da solução serão organizados para atender a essas necessidades. Esses materiais dão contexto ao agente que participa da implementação.

O Kiro, por exemplo, trabalha com requisitos, desenho técnico e tarefas, permitindo começar pelos requisitos ou por um desenho já existente. O GitHub Spec Kit também separa a definição do comportamento, o planejamento técnico e a implementação. São formas de tornar explícitas as decisões que orientam o código.

Para o sistema do laboratório, uma regra poderia estabelecer que cada reserva deve identificar uma unidade física, um usuário e um intervalo de utilização. Duas reservas confirmadas para a mesma unidade não podem ocupar períodos sobrepostos. Reservas de unidades diferentes podem ocorrer simultaneamente.

Essa descrição já fornece uma direção muito mais precisa do que “crie um sistema de reservas”. Ela permite discutir o comportamento esperado antes de examinar uma função específica.

A especificação também pode evoluir. Se o laboratório decidir que determinados equipamentos exigem uma autorização adicional, essa regra precisa ser incorporada aos requisitos, ao desenho, à implementação e aos testes. O documento continua ligado ao software durante sua evolução.

Como a Especificação se Transforma em Código?

Um ponto de partida útil é escolher uma funcionalidade pequena e completa. No exemplo, o primeiro objetivo pode ser permitir que um usuário autorizado reserve uma unidade disponível e consulte a confirmação.

A partir desse objetivo, o profissional descreve as condições de entrada e o resultado esperado. O usuário deve estar identificado, o equipamento deve existir e o intervalo precisa ser válido. Também define o que a aplicação deve apresentar quando alguma condição não for atendida.

Em seguida, organiza o desenho da solução. É preciso decidir quais dados serão armazenados, como a interface se comunicará com o serviço responsável pelas reservas e onde as regras serão verificadas. Se a aplicação fizer parte de um sistema existente, as convenções e integrações desse ambiente entram no planejamento.

A IA pode ajudar a formular perguntas, apontar ambiguidades e propor alternativas. Cabe a quem conduz o projeto avaliar essas propostas e registrar as escolhas. Uma sugestão tecnicamente plausível precisa fazer sentido para o contexto em que será utilizada.

Com esse contexto, o agente pode implementar a funcionalidade em etapas, criando ou alterando os arquivos necessários. O profissional acompanha a correspondência entre o que foi especificado e o que foi produzido, examina os testes e solicita ajustes quando identifica diferenças.

O fluxo documentado pelo Spec Kit inclui esclarecer ambiguidades, produzir um plano, decompor o trabalho em tarefas e verificar a implementação em relação aos artefatos do projeto. A ideia central é manter uma relação verificável entre intenção, decisões e código. 

Por Que Isso Exige Conhecimento Sólido?

A necessidade de fundamentos fica evidente quando a especificação encontra situações que uma descrição superficial deixaria de fora.

Considere as duas pessoas tentando reservar o mesmo equipamento. Se a aplicação apenas consultar a disponibilidade e depois gravar a reserva, ambas as solicitações podem encontrar o horário livre antes que qualquer gravação seja concluída. Reconhecer essa possibilidade exige compreender concorrência e o comportamento das transações. O mecanismo que preserva a regra precisa ser escolhido e verificado de acordo com a arquitetura e o banco utilizados, incluindo suas garantias de isolamento de transações.

O mesmo acontece com as permissões. Definir que apenas o titular pode cancelar a própria reserva exige verificar a identidade de quem solicita a operação e sua relação com aquele registro. Essa verificação precisa ocorrer no lado responsável por processar a solicitação. Esconder um botão na interface, por si só, deixa a regra sem uma proteção suficiente, como explica a orientação da OWASP sobre autorização. 

Conhecer modelagem de dados ajuda a distinguir o modelo de um equipamento de cada unidade física. Conhecer APIs permite definir quais informações entram em uma operação e quais respostas os demais componentes podem esperar. Conhecer testes ajuda a transformar regras em verificações que continuem úteis quando o sistema mudar.

Lógica de programação, estruturas de dados e organização do código também sustentam esse raciocínio. Esses fundamentos permitem avaliar uma proposta da IA, investigar um comportamento e compreender as consequências de uma alteração. A leitura de código continua sendo uma ferramenta para esse trabalho, mesmo quando sua escrita foi delegada.

O conhecimento técnico aparece na qualidade das decisões que você consegue formular, explicar e verificar. A IA amplia as possibilidades de implementação; uma base sólida permite conduzir essas possibilidades com critério e responsabilidade.

Quanto Melhor a Especificação, Melhor a Orientação da IA

Uma especificação clara, coerente e verificável oferece uma base melhor para o código gerado. Cada regra relevante que fica explícita reduz o espaço para interpretações que não correspondem ao que a aplicação precisa fazer.

A precisão pode estar em detalhes pequenos. “Evitar conflitos de horário” deixa aberta a definição de conflito. Já estabelecer que uma reserva pode começar exatamente quando a anterior termina resolve uma decisão concreta e fornece um caso para os testes. Em outro laboratório, pode ser necessário um intervalo entre utilizações. A especificação precisa representar a regra daquele contexto.

Expressões como “o sistema deve ser rápido” também precisam ser trabalhadas. Para avaliar desempenho, é necessário definir quais operações serão medidas, com qual volume de dados, sob quais condições e qual resultado será considerado aceitável.

A qualidade da especificação depende de selecionar e esclarecer o que importa. Um documento extenso pode continuar cheio de ambiguidades. Uma descrição concisa pode orientar muito bem uma funcionalidade quando registra suas regras e restrições com precisão.

A implementação gerada ainda precisa ser examinada e testada. O próprio GitHub recomenda verificar a aderência do código produzido por IA aos requisitos e à arquitetura, além de executar testes e analisar sua qualidade. Uma boa especificação melhora a orientação do agente; a validação fornece evidências sobre o resultado. Essa combinação faz parte do trabalho de revisão de código gerado por IA. 

No laboratório, os testes poderiam verificar uma reserva válida, a rejeição de períodos sobrepostos, o uso simultâneo de unidades diferentes e o cancelamento por um usuário autorizado. Também seria necessário avaliar o comportamento de solicitações concorrentes. Se código e testes nascerem da mesma interpretação equivocada, ambos podem concordar entre si sem representar a necessidade real. Por isso, os resultados esperados precisam ser confrontados com as regras definidas.

Como Desenvolver Essa Capacidade na Sua Carreira?

Um bom exercício é construir um projeto em que seja possível acompanhar o caminho entre necessidade, especificação e implementação. A aplicação de reservas é uma opção. Um catálogo de dados, uma API de consulta a indicadores ou uma ferramenta para organizar experimentos também podem servir.

Escolha um escopo que permita compreender a solução inteira. Registre o objetivo, descreva os comportamentos e prepare exemplos que mostrem o que significa funcionar corretamente. Use a IA para discutir alternativas, estruturar a implementação e produzir o código. Depois, investigue se o resultado atende ao que foi definido.

Ao apresentar esse projeto, explique as decisões. Mostre como uma regra do negócio alterou o modelo de dados, por que determinada operação exige uma verificação e como um teste demonstra o comportamento esperado. Essa explicação torna visível sua contribuição para a engenharia da solução.

Para quem já trabalha com dados, esse exercício também aproxima o conhecimento analítico da construção de software. Definir corretamente um indicador, compreender a origem de uma informação e estabelecer quem pode acessá-la são decisões que influenciam APIs, aplicações e produtos de dados.

A Formação AI Software Engineer 4.0 da DSA reúne engenharia de software, integração de sistemas e APIs, desenvolvimento Full Stack com IA e arquitetura com agentes. A trilha também inclui conteúdo de Engenharia de Software Guiada por Intenção e Spec-Driven Development, conectando a especificação ao trabalho de construção das aplicações. SDD também é estudado em outras Formações:

Formação Forward Deployed Engineer 4.0

Formação Generative AI Engineer 4.0

Formação Agentic Business Intelligence 4.0

Ao delegar a escrita do código à IA, você pode dedicar mais atenção ao desenho e à avaliação da solução. SDD dá estrutura a essa forma de trabalhar. Para tirar proveito dela, é preciso saber transformar uma necessidade em regras claras, compreender as escolhas técnicas e reconhecer se o software construído corresponde à intenção.

A IA pode escrever as funções do sistema de reservas. Seu conhecimento permite definir o que essas funções precisam garantir e avaliar se a aplicação atende aos critérios estabelecidos para seu uso.

O próximo artigo da série será: Ainda vale a pena estudar Ciência de Dados na era da IA Generativa? Não perca.

Equipe DSA