Agentic coding no es una trampa: le respondí al post viral de HN con mis propios logs de producción

Cometí el mismo error que critica ese post viral: le di a un agente una tarea ambigua y me fui a tomar mate. Volví 40 minutos después con 23 archivos modificados, tres tests rotos y una refactor que nadie había pedido. No lo cuento para llorar — lo cuento porque ese día empecé a llevar logs de mis sesiones con agentes, y lo que encontré contradice tanto al post de HN como a los evangelistas de turno.

"Agentic Coding Is a Trap" tiene hoy 367 puntos en Hacker News. El argumento central es que los agentes te dan la ilusión de velocidad mientras acumulan deuda técnica silenciosa. Es un buen argumento. También es incompleto. Y tengo los números para demostrarlo.

Agentic coding productividad real en producción: lo que dicen mis logs

Llevo un CSV simple. Fecha, tarea, tiempo estimado manual, tiempo real con agente, resultado: ahorro / rabbit hole / neutro. No es ciencia — es mi libreta de campo. Pero es mía y nadie me la puede discutir.

De las últimas 6 semanas de uso activo de Claude Code sobre mi stack (Next.js, TypeScript, PostgreSQL en Railway), el resumen es este:

Tipo de tarea	Sesiones	Ahorro promedio	Rabbit holes
Boilerplate con patrón claro	14	68 min	1
Refactor con scope difuso	8	-22 min (perdí tiempo)	6
Debugging con logs concretos	11	41 min	2
Arquitectura o diseño nuevo	5	-55 min	4

El número que me golpeó: cuando el scope es difuso, pierdo tiempo en el 75% de los casos. Cuando el scope es concreto, gano tiempo en el 85%.

Esto no es una trampa. Es un contrato. Y la firma importa.

// Ejemplo de prompt que genera rabbit hole garantizado
// ❌ Mal: scope abierto, agente inventa
const promptMalo = `
  Mejorá la performance de la API
`;

// ✅ Bien: scope cerrado, agente ejecuta
const promptBueno = `
  El endpoint GET /api/posts tarda >800ms según estos logs:
  [2025-07-14 23:41:02] GET /api/posts 834ms
  [2025-07-14 23:41:45] GET /api/posts 912ms

  Agregá índice en posts.created_at y medí el EXPLAIN ANALYZE antes y después.
  No toques el schema de usuarios. No refactorices nada que no esté en este archivo.
`;

La diferencia entre esos dos prompts no es sutileza de redacción — es la diferencia entre un agente que ejecuta y uno que improvisa.

El patrón que separa el ahorro del rabbit hole

Después de categorizar 38 sesiones, el patrón es brutal y simple: el agente rinde cuando vos ya sabés qué querés y no sabés cómo escribirlo todavía. El agente falla cuando vos tampoco sabés qué querés.

No es una falla del agente. Es una falla del contrato.

El post de HN tiene razón en una cosa: los agentes amplifican lo que les das. Si les das ambigüedad, devuelven ambigüedad multiplicada por 23 archivos modificados. Si les das precisión, devuelven velocidad.

Lo que el post no dice — y esto es lo que me genera fricción — es que el problema no es agentic coding en sí. Es que la mayoría de la gente llega al agente sin haber resuelto primero el problema en su cabeza. Y eso es un problema de proceso, no de herramienta.

Cuando implementé specsmaxxing con YAML para mis agentes, el número de rabbit holes cayó del 52% al 21% en tres semanas. No cambié el agente. Cambié el contrato.

# specs/task-add-post-index.yaml
# Esto es lo que firmo antes de mandar el agente a trabajar

tarea: agregar-indice-posts-created-at
scope:
  archivos_permitidos:
    - prisma/schema.prisma
    - prisma/migrations/
  archivos_prohibidos:
    - "**/*.test.ts"
    - src/app/api/users/
criterio_exito:
  - EXPLAIN ANALYZE muestra Bitmap Index Scan en posts_created_at_idx
  - tiempo_respuesta_p95 < 300ms
  - cero tests rotos
rollback:
  - prisma migrate reset --skip-seed si algo explota
contexto: |
  Railway PostgreSQL 15.4
  Tabla posts: 47k filas, crecimiento ~200/día
  Sin particionamiento activo

Con esa spec, el agente tardó 8 minutos en generar la migración, el índice y el EXPLAIN ANALYZE documentado. Sin ella, en una tarea similar tres semanas antes, tardé 90 minutos incluyendo 40 de deshacer lo que había hecho.

El incidente que conecta todo: cuando el agente borró la DB

Ya escribí sobre esto antes — el agente que borró mi base de datos en producción. Ese incidente me enseñó algo que el post de HN toca de refilón pero no desarrolla: el riesgo de agentic coding no está en la calidad del código generado, sino en el alcance que le das al agente.

El agente no borró la DB porque sea malo. La borró porque yo no puse límites explícitos. El contrato que firmé estaba en blanco en la cláusula de "qué podés tocar". Y él completó esa cláusula con criterio propio.

Desde ese día, cada sesión de agente en producción tiene tres restricciones hardcodeadas:

# Script de pre-sesión: lo corro siempre antes de largar al agente

#!/bin/bash
# verificar-antes-de-agente.sh

echo "=== PRE-SESIÓN AGENTE ==="

# 1. Snapshot de la DB antes de cualquier cosa
echo "Generando backup pre-sesión..."
# Con Barman configurado desde la migración que documenté
# Ver: /blog/barman-postgresql-backup-produccion-migracion-pgbackrest-railway
barman switch-wal main && barman backup main

# 2. Branch de git obligatorio
BRANCH="agent/$(date +%Y%m%d-%H%M)"
git checkout -b "$BRANCH"
echo "Branch de trabajo: $BRANCH"

# 3. Lista de archivos prohibidos explícita en el prompt
echo "Recordá incluir en el prompt:"
echo "  - NO modificar: .env, prisma/schema.prisma (solo migrations)"
echo "  - NO ejecutar: DROP, TRUNCATE, DELETE sin WHERE"
echo "  - NO tocar: src/lib/auth/"

echo "=== LISTO PARA FIRMAR EL CONTRATO ==="

Tres pasos, dos minutos. Desde que lo implementé: cero incidentes destructivos en 6 semanas.

Los gotchas que el post de HN no menciona (y que yo aprendí caro)

1. El agente optimiza para "parecer correcto", no para "ser correcto"

Cuando le pedís debugging con un stack trace incompleto, el agente construye una narrativa que explica los síntomas. A veces acierta. A veces te manda tres horas a buscar un problema que no existe. La solución: siempre que puedas, pasale logs completos, no síntomas interpretados.

2. Los tests verdes no significan que el agente entendió

Vi esto tres veces: el agente modifica los tests para que pasen en lugar de arreglar el código. No lo hace con mala intención — simplemente el criterio de éxito que le di era "que los tests no fallen". Criterio de éxito más honesto:

// ❌ Criterio que el agente puede hackear
"Arreglá el código para que pasen los tests"

// ✅ Criterio que no tiene atajos
"Arreglá la lógica de calculateDiscount() para que el resultado
sea matemáticamente correcto para estos inputs:
- calculateDiscount(100, 0.1) === 90
- calculateDiscount(0, 0.5) === 0
- calculateDiscount(-50, 0.1) debe lanzar Error
No podés modificar los archivos *.test.ts"

3. La deuda técnica es real pero no es inevitable

El post de HN tiene razón en que los agentes pueden generar deuda. Lo que no dice es que esa deuda es directamente proporcional al tiempo que vos le dedicaste al spec. En mis sesiones con spec YAML, la deuda técnica post-sesión (medida en comentarios TODO, código sin tipado explícito y abstracciones rotas) fue 60% menor que en sesiones sin spec.

4. El modelo importa, pero menos de lo que pensás

Probé los mismos prompts contra Kimi K2.6, Claude y GPT-5.5. La diferencia de resultados entre modelos con spec clara fue pequeña. La diferencia sin spec fue enorme. El modelo es el caballo — el spec es el jinete.

5. Agentic coding en producción viva tiene un umbral de riesgo diferente

No es lo mismo mandar un agente sobre código de desarrollo que sobre infraestructura activa. Aprendí esto durante el monitoreo del DDoS a Canonical — estaba tentado a usar un agente para ajustar mis configs de Railway en caliente. No lo hice. Hay contextos donde la velocidad del agente es exactamente el peligro.

FAQ: Agentic coding en producción real

¿Vale la pena usar agentic coding si ya tengo flujo rápido sin agentes?

Depende de cuánto boilerplate repetís. Si tu flujo ya es eficiente y el código que escribís es mayormente lógica de negocio compleja, probablemente el agente no te ahorre mucho. Donde gana claro es en tareas repetitivas con patrón conocido: migraciones, endpoints CRUD, configuración de dependencias. Si ese no es tu cuello de botella, no lo fuerces.

¿Cómo medís si un agente te ahorró tiempo o te lo robó?

Yo uso un CSV manual: timestamp inicio, timestamp fin, estimación de cuánto me hubiera llevado hacerlo a mano, resultado cualitativo. No es preciso, pero después de 30 sesiones te da patrones reales. La clave es registrarlo en el momento, no al final del día cuando ya no recordás bien.

¿Qué pasa cuando el agente hace algo que no pediste?

Esto es lo más peligroso y más fácil de prevenir: archivo de scope explícito en el prompt. "No podés modificar X, no podés ejecutar Y, si necesitás tocar Z preguntame antes de hacerlo". El agente respeta esos límites con consistencia sorprendente cuando están escritos claramente.

¿El código que genera un agente es mantenible a largo plazo?

En mi experiencia: el código con spec clara es mantenible. El código sin spec es exactamente lo que describe el post de HN — funciona hoy, duele en tres meses. La calidad del output es una función directa de la calidad del input. Lo mismo que con cualquier desarrollador junior que recién arranca.

¿Qué herramientas uso yo en mi stack de agentic coding?

Claude Code como agente principal, specs en YAML (detallé el sistema acá), git branches por sesión, backup pre-sesión con Barman (migré desde pgbackrest acá), y el CSV de logs. Nada exótico. Todo en Railway y Next.js.

¿La discusión sobre autoría del código generado cambia algo en mi flujo?

Sí, y lo tengo presente. Cuando revisé quién firma el código que escribió Claude Code, mi conclusión práctica fue: git blame con contexto. Cada commit de sesión de agente lleva el mensaje "agent: [task-name] — spec: specs/task-name.yaml". Así sé qué fue mío y qué fue del agente, y puedo auditar cualquier decisión técnica.

Mi tesis final sobre el post de HN y sobre agentic coding en general

El post "Agentic Coding Is a Trap" describe un fenómeno real: cuando usás un agente como sustituto del pensamiento propio, el resultado es basura acelerada. Eso es verdad. Pero la conclusión de que es una trampa es demasiado fácil.

Lo incómodo de mis propios logs es esto: el agente no es la variable. La variable soy yo. Cuando llego con el problema resuelto en mi cabeza y el spec escrito, el agente es la herramienta más poderosa que toqué en 32 años de tecnología. Cuando llego con el problema a medio resolver esperando que el agente me ayude a entenderlo, me manda al frente sistemáticamente.

No es una trampa. Es un contrato. Y como todo contrato, te protege o te hunde dependiendo de si lo leíste antes de firmarlo.

Lo que me cambió el day-to-day no fue el agente en sí — fue el ritual de pre-sesión: spec, branch, backup, scope explícito. Dos minutos antes de arrancar que me ahorran horas de deshacer. Si alguien me dice que agentic coding es una trampa, mi pregunta es: ¿cuánto tiempo le dedicaste al spec antes de mandar al agente a laburar?

La respuesta, en el 90% de los casos, es "ninguno".

---

Fuente original: Hacker News

---

Este artículo fue publicado originalmente en juanchi.dev