No estás escribiendo código: estás dirigiendo un “equipo de IA”

La mayoría usa los Coding Agent como si siguiera siendo un Tech Lead: diseña el sistema personalmente, revisa cada línea, no sube nada sin haberlo inspeccionado. La calidad sale bien, sí. ¿El precio? Tú eres el mayor cuello de botella de la cadena. Toda decisión te espera a ti, todo detalle pasa por ti, y la productividad del Agent queda secuestrada por tu atención y tu tiempo.

Los desarrolladores independientes que de verdad ganan dinero ya hicieron un cambio de rol clave: de TL a EM. En cristiano: el TL vigila cada línea de código; el EM solo mira si el resultado funciona. El TL pregunta “¿este código está bien escrito?”; el EM pregunta “¿esta funcionalidad pasó la aceptación?”. Parece un matiz sutil, pero es lo que convierte tu capacidad de “producción de una persona” en “producción de un equipo”.

Por qué ahora sí puedes soltar el control: los modelos ya cruzaron el umbral

Soltar el control exige que la calidad del código aguante. Ese requisito ya se cumple este año: los benchmarks públicos más citados muestran que los modelos top superan el 80 % de acierto en código, con ventaja aplastante sobre la generación anterior (las cifras exactas varían según la evaluación; míralo tú mismo en Artificial Analysis o SWE-Bench y no te fíes de segundas fuentes, ni siquiera de mí).

¿Qué implica esto? Que el código de la IA, con una verificación ligera, rara vez se desvía en serio. El beneficio marginal de revisar línea por línea ya es tan bajo que no compensa. Seguir de TL es gastar tu hora más cara en el control de calidad más barato. El mercado no paga por tu “por si acaso”: el cliente paga por el resultado entregado.

Ruta 1: sustituye la vigilancia línea a línea por “plan confirmado + ejecución por objetivos”

¿Cómo se aterriza esto? Primer paso: cambia el flujo de trabajo. Cuando tengas claro qué funcionalidad quieres, revisa primero el plan técnico con el Agent. Plan confirmado, le pasas el objetivo junto con el plan y que ejecute: escribir código, correr tests automatizados, todo suyo. Tu única tarea es aceptar la funcionalidad al final, no auditar el código.

Aquí tienes una plantilla de prompt lista para copiar:

1
2
3
4

Quiero construir [descripción de la funcionalidad].
Restricciones: [stack / plataforma / entornos con los que debe ser compatible].
Primero dame el plan técnico: 1) división en módulos; 2) flujo de datos; 3) posibles trampas.
Cuando confirme el plan, escribes el código. Al terminar, ejecuta los tests tú mismo y pégame los resultados.

Para la aceptación, usa una checklist que bloquee la calidad sin mirar código:

• Recorre a mano el flujo principal: la ruta crítica sin errores
• Prueba un caso límite de cada tipo (entrada vacía, entrada gigante, sin conexión)
• Los tests automatizados que añadió el Agent pasan todos
• Si aparece un bug, no abres el código: describes el síntoma al Agent, él lo reproduce, lo corrige y añade el test; tú vuelves a verificar

La clave de este sistema es adelantar el punto de verificación. En modo TL verificas a nivel de código, carísimo; en modo EM verificas a nivel de funcionalidad: unos clics, una pasada, unos minutos. En todo el ciclo, tu tiempo solo va a dos cosas: pensar bien qué construir y confirmar que se construyó bien.

Ruta 2: la elección de stack pasa de “lo que sé” a “lo que mejor encaja”

El cambio de rol trae un beneficio oculto: la elección técnica deja de estar secuestrada por los límites de tu propia experiencia. Con mentalidad TL eliges por defecto el stack que dominas, porque si algo falla puedes arreglarlo. Con mentalidad EM solo decides qué tecnología encaja mejor con el proyecto; el resto es del Agent.

Un desarrollador independiente contaba este recorrido (según su propio post, sin verificación independiente): para una app de traducción de subtítulos eligió Electron porque dominaba frontend, el rendimiento nunca le convenció, y acabó migrando a Swift + AppKit nativo —un stack que no conocía— con ayuda de la IA y sin fricción; para su siguiente producto multiplataforma eligió directamente Rust, que jamás había escrito. Juzga tú si el caso es real, pero la lógica es comprobable: esta misma noche haz el experimento —elige un stack que no dominas y pídele al Agent una herramienta de 100 líneas, a ver si te atascas—. Dicho claro: tus límites técnicos ya no son excusa; el stack se elige solo por idoneidad.

Ruta 3: convierte la velocidad de iteración en tu foso defensivo, y haz las cuentas

Cuando este modo rueda, el ciclo de entrega pasa de semanas a días. El cliente pide por la mañana y por la tarde ve una versión aceptable; la competencia itera una vez por semana, tú una vez al día. En Wallapop, Milanuncios, Fiverr o Upwork hay mucha gente aceptando encargos de desarrollo con IA, pero casi todos siguen en la fase “la IA me ayuda a teclear”. Con el modo EM les pasas por encima.

De nada sirve la teoría sin números. Hagamos cuentas (estimación conservadora; ajusta a tu tarifa):

• Encargo típico de “herramienta pequeña / mini-app”: 250 € por proyecto
• Modo TL: 5 días entre código y correcciones por encargo, 4 encargos al mes a tope, 1.000 €/mes
• Modo EM: plan + aceptación ocupan 1,5 días; mientras el Agent ejecuta, cierras el siguiente encargo en paralelo; ocupación real de 2 días por encargo, 8-10 al mes, 2.000-2.500 €/mes
• Costes: suscripción de IA en el plan más alto, unos 40 €/mes; tasa de retrabajo ~10 % con la checklist aplicada; reserva medio día de colchón por encargo

Es decir: mismo mes, diferencia de más de 1.000 €, y en modo EM tu límite es el volumen de encargos, no tu velocidad de tecleo. Pon en tu anuncio “versión funcional entregada en 48 horas”: eso es una diferenciación que nadie te copia.

El único cuello de botella eres tú cuando no sabes qué construir

Este modo tiene una restricción real: cuando toca concebir una nueva versión grande o una nueva dirección de producto, el humano vuelve a ser el cuello de botella. Por potente que sea el Agent, solo ejecuta objetivos que tú hayas pensado con claridad; si tú no lo tienes claro, no produce ni una línea útil.

Así que el modo EM exige más de la persona, no en profundidad técnica sino en criterio de producto. Tienes que invertir tiempo en estudiar qué busca la gente en Wallapop y Amazon, de qué se quejan los posts de dolor en Pinterest y Lemon8, qué contenido de herramientas explota en TikTok. Todo el tiempo que ahorras revisando código, mételo en “pensar bien qué construir”. Ahí es donde debe estar el humano en este modelo.

Empieza hoy: tres pasos para completar el cambio de rol

Si aún no has aceptado ningún encargo, no te obsesiones con duplicar capacidad. La entrada suave es: publica en Wallapop o Fiverr un anuncio de “herramientas a medida con IA” a 60-100 €, y completa tu primer encargo con estos tres pasos. Saldrás con un flujo reutilizable y criterio real de precios.

Paso uno: coge un proyecto pequeño que tengas a mano y oblígate a no abrir ningún archivo de código. Solo escribe el plan, lanza el objetivo y haz la aceptación funcional. Vive el flujo EM completo y registra los tiempos: ese dato de primera mano vale más que cualquier caso ajeno. Paso dos: convierte en reflejo el “ante un bug, describírselo al Agent para que lo reproduzca y lo arregle”, y no te metas en el código ni una vez. Paso tres: en tu próximo proyecto, elige a propósito un stack que no dominas pero que es el óptimo, y comprueba si la IA te lleva al otro lado.

El umbral de capacidad de la IA para programar ya se cruzó, y la ventaja se está desplazando de “quien sabe usar IA para escribir código” a “quien sabe dirigir un equipo de IA”. Esta noche, elige un proyecto y corre el flujo EM con la plantilla y la checklist de arriba.