Se delegó a un agente de IA una modificación de software bastante grande.
Parecía algo que podía resolverse en unos minutos. Pero GitHub siguió acumulando commits, pruebas, cambios de integración y correcciones posteriores. Horas después, el código real seguía cambiando.
Mientras tanto, la persona terminó otras tareas del mundo físico, hasta completar una mudanza.
La mudanza terminó antes que la refactorización.
La escena ya parece bastante futurista.
Y la interfaz era solo un smartphone. La persona no necesita dominar personalmente cada módulo de TypeScript, detalle de CI/CD o regla de aprendizaje del grafo. Puede expresar en lenguaje natural el objetivo, las invariantes, los permisos, los cambios prohibidos y los criterios de finalización; el agente puede leer el repositorio, diseñar, programar, añadir pruebas, abrir PR e integrar cambios.
¿Eso significa “convertirse en ingeniero sénior con un teléfono”?
No exactamente. Pero está mucho más cerca de lo que sugería el modelo tradicional del desarrollo de software.
1. El teléfono no está haciendo el cálculo de nivel sénior
El smartphone no genera localmente cientos de líneas de código de producción. Es la consola de mando.
Detrás hay modelos de IA, GitHub, CI, nube, entornos de producción, búsqueda y herramientas de desarrollo. El móvil transmite intención y restricciones.
Por eso es más preciso decir:
“orquestar recursos cognitivos y computacionales remotos desde un teléfono”
que “programar todo en el teléfono”.
El centro de datos no entró en el bolsillo.
El bolsillo obtuvo un mando a distancia para el centro de datos y el agente.
2. Por qué este trabajo se parece al de un sénior
La dificultad no se mide solo por líneas de código.
Este tipo de cambio exige entender la arquitectura existente, evitar implementaciones duplicadas, proteger las rutas de producción, comprender los límites entre scheduler, GitHub, CI y publicación, conectar nueva lógica al bucle central, proteger la privacidad, no confundir datos ausentes con cero, añadir pruebas, separar fallos de código de fallos de infraestructura y decidir qué no debe tocarse.
No es solo completar un ticket. Es gestionar el radio de impacto del cambio dentro de un sistema vivo.
En humanos, se parece a trabajo de backend sénior o Platform Engineer. Si además se asume responsabilidad por toda la arquitectura, parte del juicio se acerca al nivel Staff Engineer.
Lo difícil no es solo escribir código sofisticado.
Es saber dónde puede existir ese código sin provocar un accidente.
3. ¿Qué tamaño tuvo el cambio real?
En un ejemplo anonimizado, el PR principal incluyó 11 archivos modificados, 13 commits y unas 895 líneas añadidas, además de runtime de germinación autónoma, preservación de Article DNA, aprendizaje de comportamiento, feedback limitado sobre optimización de enlaces internos, pruebas y una definición de CI dedicada.
Después del merge siguieron las correcciones: se añadieron gates para impedir que el aprendizaje de comportamiento reescribiera el grafo antes de verificar producción, y la telemetría ausente se mantuvo como UNKNOWN en lugar de interpretarse como cero.
Así que no fue “un trabajo de 895 líneas”.
Fue entender el sistema antes de escribir 895 líneas y después construir una jaula para que esas 895 líneas no se descontrolaran.
Cien líneas pueden borrar una base de datos. Diez mil pueden ser una calculadora extremadamente entusiasta.
4. ¿Cuánto tardaría una persona?
Para un buen ingeniero que entra por primera vez en el repositorio, una estimación aproximada de 5 a 15 persona-días para el mismo alcance no es extraña.
Incluye lectura del código y reglas operativas, diseño, implementación, pruebas, diagnóstico de CI e infraestructura, revisión y comprobación de impacto en producción.
Escribir el código puede ser más rápido.
En producción, demostrar que no rompiste nada puede costar más que escribir el cambio.
La IPA japonesa explica que, cuando no existe otra definición, un persona-mes puede convertirse en 160 horas-persona: 8 horas × 20 días.[1]
Así, 5–15 persona-días equivalen aproximadamente a 0,25–0,75 persona-mes.
5. ¿Cuánto costaría contratar a una persona?
No existe un precio universal. Depende del contrato, responsabilidad, conocimiento previo del sistema, revisión y garantía de producción.
Pero los precios públicos permiten ver el orden de magnitud.
Levtech indica que contratar a un consultor IT freelance a tiempo completo cinco días por semana costaba aproximadamente 1,0–1,1 millones de yenes al mes, según datos de julio de 2025.[2]
Dividido de forma simple entre 20 días laborables, son unos 50.000–55.000 yenes al día. Para 5–15 persona-días, la mano de obra directa queda aproximadamente entre 250.000 y 825.000 yenes.
Un contrato real puede subir por gestión, revisión, riesgo de retrabajo, garantías, gastos y margen.
Por tanto, no parece razonable describirlo como “una pequeña tarea de unos pocos miles de yenes”.
Tampoco sería correcto decir “la IA ganó 800.000 yenes”. Su velocidad, paralelismo, errores, supervisión y costes de herramientas son diferentes.
La lectura útil es otra: trabajo que podría consumir días o semanas de ingeniería especializada puede iniciarse ahora desde un dispositivo diminuto.
6. ¿Seis horas de agente equivalen a seis horas de ingeniero sénior?
No.
La IA no descansa, no entra en reuniones, no pierde media hora con notificaciones ni mira el techo preguntándose quién aprobó la arquitectura.
Pero también puede avanzar muy rápido con una premisa equivocada, interpretar mal producción, confundir un fallo del runner con un fallo de código, ampliar permisos o confundir “hay un test” con “el test realmente pasó”.
Por eso hay que valorar el cambio terminado, las evidencias, la verificación y el readback de producción, no solo el reloj.
“Lleva seis horas y sigue trabajando: perseverante” está bien.
“Lleva seis horas, por tanto acertó durante seis horas” no.
7. ¿Pierde valor quien no sabe programar todo por sí mismo?
Más bien cambia su papel.
Antes, una idea exigía aprender Git, lenguaje, framework, despliegue y testing antes de convertirse en software.
Los agentes de IA reducen esa fricción de implementación.
Entonces el trabajo humano de alto valor se desplaza hacia: qué construir, por qué, qué no debe romperse, hasta dónde se permite cambiar automáticamente, qué significa éxito, qué debe seguir siendo UNKNOWN y cuándo un fallo debe detener todo o aislarse.
“Poder escribir personalmente cada línea” deja de ser la única entrada.
Eso no significa que la comprensión técnica ya no importe. Cuanto mejor entiendes objetivos, riesgos, dependencias y verificación, mejores instrucciones puedes dar.
No hace falta fabricar un motor para conducir.
Pero sí conviene saber qué significa un semáforo rojo.
8. Por qué “que lo haga la IA” puede ser peligroso
El peor fallo no es una pantalla roja.
Es estar equivocado con apariencia de éxito.
Un PR puede estar merged sin estar desplegado; puede existir un archivo CI aunque ningún runner haya iniciado un step; los datos no disponibles pueden convertirse en cero; la lógica nueva puede convivir con la antigua y ejecutarse dos veces; “seguridad” puede detener toda la automatización; “autonomía” puede expandir permisos demasiado.
Una buena automatización no es la que simplemente sigue avanzando.
Es la que distingue hechos de estados no verificados mientras avanza.
9. Cómo delegar con más seguridad desde el móvil
Define primero el resultado
No digas solo “edita este archivo”. Explica qué debe ser cierto al terminar.
Escribe las invariantes
Funciones existentes, privacidad, reglas de imágenes, rutas de publicación y SEO que no deben romperse.
Define autoridad
Aclara si se permite sobrescribir, abrir PR, hacer merge o tocar producción.
Haz que lea el estado actual
Prioriza current main, runtime real y public state real sobre conversaciones antiguas.
Incluye la verificación en el entregable
“Código escrito” no es terminar. Pruebas, CI y readback de producción pueden formar parte del cierre.
Permite UNKNOWN
No conviertas a la fuerza lo desconocido en PASS o FAIL.
La pantalla del móvil es pequeña.
La responsabilidad de la especificación no lo es.
10. Conclusión: quizá lo que se rompió fue la barrera de entrada
Una persona que no puede escribir por sí misma código de producción avanzado puede dirigir durante horas a un agente desde el teléfono e integrar en GitHub cambios con juicio arquitectónico de nivel sénior.
Hace pocos años sonaba raro.
Ahora puede ser real.
Eso no significa que los ingenieros sobren.
Significa que una parte del valor se mueve de la implementación manual hacia arquitectura, restricciones, verificación y límites de responsabilidad.
La IA no elimina el valor.
Cambia dónde está.
Y quizá el mayor cambio sea que quien antes se detenía en “técnicamente no puedo construirlo” ahora puede empezar una pregunta antes:
“Entonces, ¿qué deberíamos construir?”
El smartphone sigue siendo una placa de vidrio.
Pero puede funcionar como mando a distancia para recursos de ingeniería de nivel sénior.
Sí, el mundo parece un poco roto.
Por una vez, de una forma bastante interesante.
- IPA, FAQ de Software Development Data White Paper. Conversión por defecto de 1 persona-mes=160 horas-persona (8×20) ipa.go.jp
- Levtech, guía de costes para consultoría IT, actualizada 2026-08-18. Referencia de aproximadamente ¥1,0–1,1 millones/mes para freelance IT a tiempo completo, basada en datos de julio de 2025 levtech.jp
