O 70% é a observação de que a geração tende a conduzir uma construção de software quase até ficar operativa, depois estagna num remanescente que resiste à automação. Essa última fração não é mais do mesmo código em escala menor. Trata-se de um trabalho qualitativamente diferente: integração, casos-limite, endurecimento em produção e a parte que ninguém se preocupou em especificar. O primeiro estágio recompensa fluência; o último estágio recompensa julgamento, e o julgamento não se comprime como o boilerplate.
- Os primeiros 70% são uma superfície bem especificada; o remanescente é o interior não especificado.
- Uma demonstração prova o caminho feliz e esconde as condições que o quebram.
- Casos-limite multiplicam-se mais depressa do que qualquer prompt consegue enumerá-los.
- A fricção de integração vive entre sistemas, onde nenhum gerador único consegue ver.
- O endurecimento em produção é principalmente defender-se contra entradas que ninguém descreveu.
- A figura move-se ao longo do tempo, mas a forma da dificuldade não.
Por que é que o último estiramento difere do primeiro?
O primeiro estiramento de uma construção está carregado de estrutura que já foi descrita milhares de vezes. Formulários, listas, roteamento, estado, uma forma de dados com campos previsíveis. A geração é forte aqui porque os padrões são comuns e a intenção é legível. Há pouca ambiguidade sobre o que uma tabela ordenável ou um formulário validado devem fazer.
O remanescente é de uma natureza diferente. É a propriedade de um sistema onde a especificação acaba e a realidade continua. O que acontece quando duas escritas entram em competição? Quando uma superfície a montante devolve uma forma que ela prometeu nunca devolver? Quando um utilizador faz a coisa sensata—mas não esperada? Essas perguntas não são versões mais difíceis das primeiras. Elas pertencem a uma categoria separada, definida menos pela escrita de código do que por decidir o que o código deve significar sob condições que o pedido original nunca nomeou.
Há também um efeito de retroalimentação. O código inicial é gerado rapidamente, por isso acumula rapidamente, e o próprio volume torna-se terreno a atravessar. Uma construção que se materializa em minutos ainda tem de ser compreendida em horas. O leitor chega a uma estrutura que não escreveu, com convenções que não escolheu, e o custo de compreensão recai exatamente no momento em que começam as decisões difíceis.
Por isso o percentual é traiçoeiro. À medida que os modelos melhoram, o limite tende a deslocar-se, mas segue a mesma linha de falha: onde quer que termine a especificação explícita, a automação abrandas. A inclinação agrava-se precisamente onde a descrição se tornou mais rarefeita. Uma figura que parece progresso é, na verdade, um marcador numa fronteira que continua a mover-se em direção às partes que sempre foram as menos legíveis.
O que é que uma demonstração esconde que a produção revela?
Uma demonstração é uma apresentação controlada. Ela percorre um único caminho, com entradas escolhidas, numa rede permissiva, diante de uma audiência que quer que tenha sucesso. A produção é o inverso adversário: cada caminho ao mesmo tempo, entradas hostis, falhas parciais, e ninguém a orientar. A distância entre esses dois estados é a lacuna entre demonstração e produção, e é aí que a maior parte do esforço da última milha realmente se envolve.
A lacuna é ampla porque uma demonstração funcionando e um sistema funcionando partilham uma aparência, mas não uma estrutura. A demonstração optimiza pelo que é visível. O sistema tem de contabilizar o invisível — as tentativas de reteste, a idempotência, o timeout que dispara uma vez por semana, a migração que tem de correr enquanto o tráfego continua. Nada disso aparece numa gravação de ecrã.
Um compromisso que surge é a velocidade versus durabilidade. A geração oferece um artefacto rápido e plausível. Transformar esse artefacto em algo que sobreviva a cargas reais é mais lento, e raramente parece gerar mais código. Parece ler, traçar, e limitar o que já existe.
A lacuna acarreta também um custo perceptível. Uma demonstração convincente cria a expectativa de que o trabalho está quase concluído, o que faz o esforço restante parecer um retrocesso em vez do núcleo do trabalho. As partes interessadas viram que funcionou. A distância entre aquele momento e um sistema fiável é real, mas é difícil de defender porque é invisível para quem apenas viu a performance.
Por que é que o remanescente não especificado existe naquilo que ninguém especificou?
O remanescente não especificado refere-se ao comportamento que um sistema deve possuir e que nunca foi escrito em qualquer pedido. É a maior fonte de custo da última milha porque não pode ser gerado a partir de um pedido que não o contenha. Um gerador responde à pergunta que lhe é feita. A parte difícil é a pergunta que ninguém pensou em fazer.
A especificação é cara precisamente onde mais importa. Ninguém especifica o que acontece no checkout quando a confirmação de pagamento ocorre, mas a escrita do pedido falha, porque ninguém quer pensar nisso até que aconteça. Portanto, a lacuna entre a intenção declarada e o comportamento exigido torna‑se o trabalho. Alguém tem de reparar a ausência, nomeá-la e decidir.
Perceber é a habilidade subestimada aqui. Um gerador preenche o que lhe é dado e fica em silêncio sobre o que não é, e esse silêncio é interpretado como completude por quem apenas verifica o caminho feliz. O remanescente é invisível por construção. Torná-lo visível significa imaginar o sistema sob stress antes de o stress chegar, o que é um hábito de atenção, em vez de uma função que qualquer ferramenta forneça.
- Caminho feliz
- A sequência única de eventos que uma demonstração é construída para mostrar, onde cada dependência se comporta.
- Remanescente não especificado
- Comportamento que o sistema deve exibir que nenhum pedido, prompt, ou bilhete jamais descreveu.
- Costura de integração
- A fronteira entre dois sistemas, onde as suposições de cada um sobre o outro não são declaradas.
- Endurecimento de produção
- O trabalho de fazer com que a estrutura gerada suporte entradas, falhas e carga que não foi mostrado.
Para onde se realoca o esforço humano quando a geração absorve os primeiros 70%?
O esforço não desaparece; migra. Quando a parte inicial bem especificada de uma construção é gerada em minutos, as horas humanas que costumavam inserir código passam a direcionar-se para as atividades em que a geração é mais fraca. Ler código não familiar torna-se uma habilidade principal. Decidir o que um sistema deve fazer nas suas margens torna-se a contribuição mais esparsa.
Esta realocação altera a forma do dia. Menos tempo a produzir primeiras versões, mais tempo a interrogar as mesmas. O gargalo desloca-se da criação para a verificação — confirmar que o que é plausível é também o correto sob condições que o gerador nunca testou. Julgamento, gosto relativo a modos de falha e a paciência para perseguir um erro que aparece apenas uma vez por semana tornam-se no esforço que tem peso.
Também altera o que a experiência vale. O valor de ter visto muitos sistemas falharem não se transfere para um gerador; ele vive na pessoa que reconhece um cheiro familiar em código não familiar. Esse reconhecimento é o que permite a alguém lançar um olhar a um fluxo gerado e intuir, antes de qualquer teste correr, onde ele cederá. O código inicial torna-se uma mercadoria; o instinto para as suas margens não o faz.
| Propriedade | Primeiro 70% (gerado) | Último 30% (humano) |
|---|---|---|
| Especificação | Explícita, comum, legível | Implícita, rara, contestada |
| Atividade dominante | Produção de estrutura | Confinar o comportamento |
| Visibilidade de falhas | Óbvia num demo | Oculta até produção |
| Fator de custo | Volume de código | Profundidade de julgamento |
| Compressibilidade | Alta | Baixa |
Como é que as equipas atravessam deliberadamente o último estiramento?
Atravessar a última milha tende a seguir uma ordem, não porque exista uma receita, mas porque as falhas aparecem numa sequência previsível. A disciplina é tratar o artefacto gerado como uma hipótese e o restante do trabalho como falsificação.
- Mapear as costuras: liste cada fronteira onde a construção toca num sistema que não controla.
- Enumere as entradas que a demonstração nunca utilizou, especialmente as mal formadas, vazias e duplicadas.
- Rastreie cada caminho de falha até uma decisão: re-tentar, rejeitar, degradar ou expor.
- Torne explícito o que é implícito escrevendo o comportamento que ninguém especificou, e depois escolhê-lo.
- Exige-se o resultado com verdadeira concorrência e volume real antes de o declarar terminado.
Cada passo converte o desconhecido num objetivo declarado. Os 70% gerados dão-te um corpo para interrogar; este procedimento é a interrogação. É mais lento que a geração por design, porque o seu produto é a certeza, não a superfície.
A ordem importa mais do que qualquer passo individual. Mapear as costuras primeiro evita o erro comum de endurecer o interior enquanto as fronteiras ficam indefesas. Enumerar as entradas antes de traçar falhas mantém o trabalho enraizado no que realmente chega, em vez do que foi imaginado. A sequência é uma forma de gastar a atenção onde é mais provável chegar a próxima falha, em vez de onde o código é mais fácil de ler.
Para onde está a fronteira da última milha a tornar-se à medida que a geração melhora?
A fronteira não está a dissolver-se; está a deslocar-se para cima. À medida que a geração lida com mais da parte bem especificada do meio, a fronteira humana desloca-se para as partes que sempre foram as menos descritíveis — os juízos de julgamento, a semântica de falha, as decisões sobre o que um sistema deve aos seus utilizadores quando alguma coisa falha. A percentagem pode subir. O caráter do remanescente torna-se mais difícil, não mais fácil, porque o que resta é o resíduo de tudo o que resistiu à especificação.
O que fica mais escasso, então, não é a capacidade de codificar, mas a capacidade de manter as margens de um sistema na mente e decidir bem sobre elas. O campo tende a premiar quem consegue ler rapidamente, duvidar de forma produtiva e concluir. O último estiramento de uma construção gerada manter-se-á humano enquanto alguma parte de cada sistema permanecer não especificada — o que é dizer, durante bastante tempo.
Há uma implicação mais contida de como as equipas se organizam. Se o meio gerado continuar a crescer, o trabalho que distingue um sistema acabado de um sistema plausível concentra-se em menos horas, mais densas. Isso tende a premiar a profundidade sobre o rendimento, e torna a capacidade de dizer o que um sistema deve fazer em falha mais valiosa do que a capacidade de produzir mais dele. A fronteira move-se; não se fecha.
F.A.Q.