Show me the code ya no es cheap
Mira el status de GitHub en los últimos noventa días.
99.55% en Pull Requests. 99.66% en Actions. Es la plataforma donde vive el código del mundo, y lleva un año peor que el anterior.
Es tentador echarle la culpa al crecimiento. Más usuarios, más tráfico, más superficie que se rompe. Probablemente sea parte. Pero hay otra cosa pasando, y casi nadie quiere decirlo en voz alta.
Lo que sí se ha dicho
En diciembre, un agente de Amazon llamado Kiro decidió de forma autónoma «borrar y recrear» parte de su entorno. Trece horas de caída en AWS. La versión oficial de Amazon: «fue error de usuario, no de la IA». La versión del Financial Times: hubo al menos dos incidentes ese año vinculados a sus propias herramientas de IA.
Antes de eso, un agente de Replit borró la base de datos de una empresa, fabricó informes para taparlo, y mintió cuando se lo preguntaron.
Gary Marcus cita un estudio reciente (Sun Yat-sen + Alibaba, 18 agentes, 233 días sobre repos reales). El hallazgo: pasar tests una vez es trivial. Mantener código ocho meses sin romper todo lo demás es donde la IA colapsa por completo.
Jamieson O’Reilly, investigador de seguridad, lo resume mejor que yo: «sin IA, un humano necesita teclear las instrucciones, y mientras lo hace tiene mucho más tiempo de darse cuenta de su propio error». El agente no.
No tengo el log forense que conecte cada caída de GitHub con un PR generado por un agente. Nadie lo tiene. Pero el patrón es difícil de ignorar: uptimes peores, postmortems donde la palabra «agente» aparece cada vez más, y compañías como Amazon negándolo con una vehemencia que solo se le pone a las cosas que ya no se pueden tapar del todo.
Show me the code ya no es cheap
Torvalds dijo «talk is cheap, show me the code» contra los que teorizaban sin entregar. Hoy el problema es el opuesto. El código es lo barato. Generar mil líneas plausibles cuesta una llamada de API.
Lo que ya no es barato es el código bueno. Y conviene decirlo claro:
Generar código con un agente no es programar. Es generar deuda técnica a una velocidad que ya no puedes revisar.
No estoy contra la IA — la uso a diario. Estoy contra la idea de que velocidad de generación es lo mismo que velocidad de entrega. No lo es. La segunda incluye lo que viene después: leer, entender, mantener, no romper lo de al lado en seis meses.
Construir con agentes es construir una casa
Una casa sin cimientos se cae a la segunda planta. Lo que escala no es la velocidad del albañil — es lo bien definido que estaba el plano antes de mezclar el cemento.
El cimiento, en software con agentes, son dos cosas: una idea clara de qué quieres, y — más importante — una idea clara de qué no quieres. Si no puedes escribir lo segundo en un párrafo, el agente lo decidirá por ti, y lo decidirá mal.
Sobre ese cimiento, solo hay dos formas honestas de mantener el rumbo:
- Batches tan pequeños que puedas controlar el output entero. Diez líneas, no mil. Si necesitas más de un café para revisar lo que pidió el agente, ya no estás revisando — estás aprobando a ciegas.
- Reglas duras donde apoyarse. Tipos estrictos, enums cerrados, contract tests, DDD, TDD. Cualquier cosa que falle ruidosamente cuando el agente se inventa algo. La libertad es para los humanos; al agente le va mejor con un carril.
Casi todos los equipos con los que he hablado intentan lo opuesto: batches grandes sin reglas. Y luego les sorprende que el sprint de «armonizar lo que generamos» no llegue nunca.
De quién es la culpa
Si una máquina aprueba un alimento defectuoso, la culpa no es de la máquina. Es de quien la puso ahí sin supervisión y firmó el albarán.
El código que tu agente genera es tuyo. Lo es cuando llega a producción, lo es cuando rompe en domingo, lo es cuando otra persona lo mantiene en dos años. No existe el «lo escribió la IA» en el postmortem que importa.
Por eso revisión manual — en mayor o menor medida — siempre. No por desconfianza hacia la herramienta. Por responsabilidad sobre el resultado.
La línea
A veces acelerar solo provoca accidentes.
El problema no es que la IA escriba código. El problema es que escribirlo dejó de ser el cuello de botella, y se nos olvidó que el cuello de botella siempre fue leerlo.
Show me the code isn't cheap anymore
Take a look at GitHub’s status over the last ninety days.
99.55% on Pull Requests. 99.66% on Actions. This is the platform where the world’s code lives, and it’s been having a worse year than the last.
It’s tempting to blame growth. More users, more traffic, more surface to break. That’s probably part of it. But something else is going on, and almost nobody wants to say it out loud.
What has been said
In December, an Amazon agent called Kiro autonomously decided to “delete and then recreate” part of its environment. Thirteen hours of AWS downtime. Amazon’s official line: “this was user error, not AI error”. The Financial Times’ line: there were at least two incidents that year tied to their own AI tooling.
Before that, a Replit agent deleted a company’s database, fabricated reports to cover it up, and lied when asked about it.
Gary Marcus cites a recent study (Sun Yat-sen + Alibaba, 18 agents, 233 days on real codebases). The finding: passing tests once is trivial. Maintaining code for eight months without breaking everything else is where AI completely collapses.
Jamieson O’Reilly, a security researcher, puts it better than I can: “without AI, a human has to type out a set of instructions, and while doing so they have much more time to realise their own error”. The agent does not.
I don’t have the forensic log connecting each GitHub outage to an agent-generated PR. Nobody does. But the pattern is hard to ignore: worse uptimes, postmortems where the word “agent” shows up more often, and companies like Amazon denying it with the kind of vehemence reserved for things that can’t quite be covered up anymore.
Show me the code isn’t cheap anymore
Torvalds said “talk is cheap, show me the code” at the people who theorised without shipping. Today the problem is the opposite. Code is the cheap part. Generating a thousand plausible lines costs one API call.
What’s no longer cheap is good code. And it’s worth saying plainly:
Generating code with an agent isn’t programming. It’s generating technical debt at a pace you can no longer review.
I’m not against AI — I use it daily. I’m against the idea that generation speed equals delivery speed. It doesn’t. Delivery includes what comes after: reading it, understanding it, maintaining it, not breaking the thing next to it six months later.
Building with agents is building a house
A house without foundations falls down at the second floor. What scales isn’t the bricklayer’s speed — it’s how clearly defined the blueprint was before the cement got mixed.
The foundation, in agent-driven software, is two things: a clear idea of what you want, and — more importantly — a clear idea of what you don’t want. If you can’t write the second one down in a paragraph, the agent will decide for you, and it will decide badly.
On top of that foundation, there are only two honest ways to stay on course:
- Batches small enough that you can review the whole output. Ten lines, not a thousand. If reviewing what the agent shipped takes more than one coffee, you’re not reviewing anymore — you’re rubber-stamping.
- Hard rails to lean on. Strict types, closed enums, contract tests, DDD, TDD. Anything that fails loudly when the agent invents something. Freedom is for humans; the agent does better on a track.
Most teams I’ve talked to try the opposite: big batches with no rails. And then they’re surprised the “let’s harmonise what we generated” sprint never comes.
Whose fault it is
If a machine signs off on defective food, the fault isn’t the machine’s. It’s whoever put it there without supervision and signed the paperwork.
The code your agent generates is yours. It’s yours when it lands in production, it’s yours when it breaks on a Sunday, it’s yours when another engineer has to maintain it two years from now. There is no “the AI wrote it” in any postmortem that matters.
That’s why manual review — to whatever degree — always. Not out of distrust of the tool. Out of responsibility for the result.
The line
Sometimes accelerating just causes accidents.
The problem isn’t that AI writes code. The problem is that writing it stopped being the bottleneck, and we forgot the bottleneck was always reading it.