Antes, construir era caro. Isso obrigava a escolher.

A inteligência artificial reduziu o custo de gerar código, telas, textos e automações. Hoje, times pequenos constroem produtos que antes exigiam organizações inteiras, e uma boa decisão pode chegar às mãos das pessoas em dias.

Essa velocidade é uma oportunidade real. Ela também desloca o limite: quando construir deixa de ser a parte difícil, a dificuldade passa a ser decidir o que merece existir e qual deve ser a sensação ao usá-lo.

Construir software ficou mais barato. O custo não desapareceu: passou para a pessoa que o utiliza. Ele é pago em atenção, aprendizado e decisões que ninguém veio tomar.

Quando construir é barato, uma ideia fraca se transforma rapidamente em uma implementação extensa, e uma ambiguidade de produto, em um comportamento que parece concluído. O código pode estar correto e, ainda assim, deixar nas mãos da pessoa a complexidade que o time não resolveu.

A tese cabe em uma ideia: o produto não é o software, mas o progresso que uma pessoa alcança com ele. Por isso, a experiência não é um acabamento acrescentado ao final; ela faz parte da função.

Um sistema que entrega o resultado correto, mas obriga as pessoas a interpretar a interface, lembrar convenções ou temer errar, ainda não resolveu o problema. Apenas o transferiu.

Os princípios não são aspirações. Cada um tem que poder mudar uma decisão, interromper uma implementação ou exigir mais evidência; se uma frase não tem consequências práticas, ela não cumpre uma função. Cada princípio tem sua própria página, com sua tensão, seu significado, um exemplo, um contraexemplo e as perguntas para usá-lo em uma revisão real.

Um princípio é útil quando muda o que é feito. Há três maneiras pelas quais ele pode atuar sobre uma decisão concreta.

Muda uma decisão. Uma tela inicial apresenta cinco ações com o mesmo peso. Com P06 em discussão, a questão é o que a pessoa precisa naquele momento: resta uma ação principal, e as demais aparecem onde o contexto as torna relevantes.

Exige evidência. Uma história diz: “Como estudante, quero receber dicas para resolver derivadas”. Com P01, a pergunta é quando o bloqueio aparece e como o avanço seria reconhecido. Enquanto não houver uma observação que a respalde, a história é uma hipótese a ser testada, não um requisito.

Interrompe uma implementação. Um assistente reescreve textos e os publica sem pré-visualização. Com P10, a implementação é interrompida até que a pessoa possa revisar, aceitar ou rejeitar a alteração antes que ela seja publicada.

Os princípios se tornam prática em um método: um fundamento de produto com autoridade, as Job Stories como forma de referência, um fluxo de oito passos, artefatos que existem apenas se respondem a uma pergunta, um contrato para agentes de código, razões explícitas para parar e uma definição de conclusão que não se contenta com código correto.

Veja como construir com IA.

O manifesto pode ser aplicado com qualquer método. Uma implementação de referência o leva ao SpecKit: o núcleo governa uma constituição operacional, essa constituição condiciona o agente de código, e o SpecKit, adaptado sem modificar seu código, organiza a especificação, o plano, as tarefas, a análise e a implementação. Como funciona a adaptação.

Para continuar: leia o manifesto completo, percorra os princípios, veja como construir com IA ou conheça o estado da adaptação.