5 de mayo de 2026 · 6 min de lectura
No-coder engineer: cómo shipeo sin escribir código
Hace dos años que no escribo código a mano. Mi flow es: yo diseño, yo decido la arquitectura, yo priorizo, yo reviso los diffs, yo decido cuándo mergear. Pero los caracteres concretos que terminan en producción los tipea un modelo. Primero ChatGPT con copy-paste, después Cursor, ahora Claude Code.
Esto no es una declaración filosófica. Es una observación práctica: en los últimos 6 meses shipeé 17 paquetes npm funcionales, 3 productos web (astro.ar, publi.ar, helloastro.co), ~30 páginas de landing, decenas de demos. Si tuviera que tipear cada línea, no se habría hecho.
Lo que el modelo hace bien
- Convertir mi descripción en código que compila a la primera, casi siempre, en ~30 segundos.
- Recordar convenciones del codebase si las mantengo consistentes (e.g. todos los packages tienen AGENTS.md, todos los adapters tienen una variante Unconfigured).
- Escribir tests más exhaustivos que los que yo escribiría a mano. Si pido
tests para la rama de error de X
, el modelo encuentra ramas de error que yo me había olvidado. - Refactorizaciones tediosas (renames, extracciones, mover archivos) en segundos.
Lo que el modelo hace mal
- Decidir qué construir. El modelo es excelente al "cómo", pésimo al "qué". Si yo no tengo opinión clara sobre qué construir, el modelo me devuelve código genérico, sin alma.
- Detalles sutiles del API real. Va a inventar endpoints, va a usar versiones obsoletas, va a alucinar parámetros. Tengo que chequear contra docs reales.
- Diseño visual con sabor. El modelo me da Tailwind genérico, buenos diseños promedio. Para sacar algo con personalidad (como este sitio) tengo que iterar 4 o 5 rondas dando feedback específico.
- Detectar que algo es una mala idea. El modelo es servicial: si le pido construir algo mal pensado, me lo construye sin objeciones. La objeción tiene que venir de mí.
Mi rol cambió, pero no desapareció
Lo que sigue siendo crítico:
- Decidir qué construir y por qué. Esto es 80% del valor que aporto.
- Mantener una arquitectura consistente. El modelo escribe el archivo que le pedís; vos asegurás que los archivos formen un sistema coherente.
- Decir que no. El modelo nunca dice "no agregues ese feature". Vos sí.
- Conexiones extra-código. Distribución, regulación, política, financiación. El modelo no piensa en eso.
Lo que aprendí sobre mí
Que mi ventaja comparativa nunca fue tipear. Fue diseñar sistemas y mantener fricción baja entre decisión y resultado. El modelo me da exactamente eso: cierra el ciclo "tengo una idea" → "está en producción" de 4 horas a 30 minutos.
Que tengo que ser muy honesto sobre dónde paro y dónde empieza el modelo. Si alguien me ofrece un trabajo de code-junkie hardcore compilando C++, no soy yo. Si alguien necesita 17 paquetes npm interconectados shipeados en 6 meses, sí soy yo.
Que esto no es trampa, es una herramienta nueva. Hace 20 años nadie ponía uso compiladores en lugar de escribir ensamblador
en su CV. Hace 10 años nadie ponía uso npm en lugar de copiar librerías a mano
. Hoy nadie pone uso Stack Overflow
. Dentro de 5 años, uso Claude Code
va a ser la versión adulta de eso.
Si querés intentarlo
Mi consejo concreto: bajate Claude Code, gastá una semana usándolo en un proyecto chico (idealmente algo que vos nunca terminás porque escribir código te aburre), y notá la diferencia. Lo que cambió para mí no fue solo velocidad: fue mi umbral de qué proyectos arrancar.
Antes pensaba nah, eso son 2 semanas de trabajo
y no arrancaba. Ahora pienso nah, eso son 2 días de trabajo con Claude Code
y arranco. El bajo umbral cambia más cosas que la velocidad bruta.
Este sitio entero, por ejemplo, lo armé con Claude Code en una tarde de domingo. El código está en GitHub si querés mirarlo.