Imaginemos un repositorio personal cuyo número correlativo de Issues y Pull Requests de GitHub está a punto de llegar a cuatro cifras.
La reacción inmediata suele ser:
«¿Una sola persona hizo casi mil trabajos de desarrollo?»
Casi, pero no es una conversión válida. GitHub considera cada Pull Request como un tipo de Issue a efectos de numeración, y dentro de un mismo repositorio los números de Issues y Pull Requests no se superponen. Por tanto, acercarse al número 1000 no significa haber completado 1000 Pull Requests.[1]
La pregunta realmente interesante sigue en pie:
Si una persona tuviera que hacer casi a mano, y sin IA, este volumen de modificaciones, comprobaciones, reparaciones, publicación y operación, ¿cuánto costaría y sería rentable?
Esa pregunta va al centro de la economía del desarrollo individual asistido por IA.
1. El número de GitHub no es un contador de repeticiones del gimnasio
El número de un repositorio no mide carga de trabajo.
Un desarrollador puede meter 2000 líneas de cambios en un Pull Request. Otro puede abrir uno para modificar una sola línea de CSS. Además están los Issues: errores, notas de diseño, solicitudes de funciones, investigaciones y tareas operativas usan el mismo espacio de numeración.
Por eso:
casi 1000 en la secuencia no equivale a 1000 personas de trabajo.
Tampoco equivale a:
casi 1000 funciones terminadas.
El número se parece más al contador de un torno de entrada que a una báscula.
Aun así, si en poco tiempo se acumularon muchos cambios pequeños, el historial sí revela algo: el ciclo diseño → implementación → verificación → reparación se repitió muchas veces.
Para calcular el coste humano importa menos el número y más el tiempo medio consumido por cada ciclo sustancial.
2. El coste humano se subestima fácilmente cuando cada tarea parece diminuta
Un informe publicado en septiembre de 2026 a partir de ofertas de proyectos para ingenieros freelance en Japón situó la tarifa mensual media de agosto de 2026 en 789.000 yenes.[2]
No es el salario de todos los desarrolladores ni la tarifa horaria de una persona concreta. Es un promedio del mercado de proyectos anunciados.
Pero sirve como una referencia de coste de sustitución: cuánto podría costar comprar fuera una capacidad profesional comparable.
Dividido entre 160 horas mensuales, son unos 4930 yenes por hora.
Ahora supongamos 1000 unidades de cambio sustancial. Es un ejemplo hipotético y no equivale al número #1000 de GitHub.
| Tiempo medio por cambio | Tiempo total | Meses-persona a 160 h/mes | Coste a 789.000 yenes/mes |
|---|---|---|---|
| 15 min | 250 h | 1,56 | aprox. 1,23 M¥ |
| 30 min | 500 h | 3,13 | aprox. 2,47 M¥ |
| 45 min | 750 h | 4,69 | aprox. 3,70 M¥ |
| 1 h | 1000 h | 6,25 | aprox. 4,93 M¥ |
| 2 h | 2000 h | 12,5 | aprox. 9,86 M¥ |
| 3 h | 3000 h | 18,75 | aprox. 14,79 M¥ |
| 4 h | 4000 h | 25 | aprox. 19,73 M¥ |
Incluso 1000 cambios de solo 15 minutos suman 250 horas.
«Cada tarea es pequeña» no significa que «el total sea pequeño».
Además, las tareas pequeñas cargan costes fijos: investigar, crear ramas, revisar, probar, fusionar, verificar el despliegue y pensar en la reversión.
Si una sola persona hace todo manualmente, su tarjeta de visita termina siendo desplegable: redactor, traductor, frontend, backend, QA, infraestructura y director editorial.
3. «Lo hice yo, así que la mano de obra cuesta cero» puede ser cierto en caja y falso en comparación económica
Un sitio personal puede gastar 1000 yenes al mes en alojamiento y ganar 5000 en publicidad.
En efectivo, hay un superávit de 4000 yenes.
Pero si el propietario dedica 50 horas mensuales, para comparar el proyecto como negocio hay que separar dos vistas:
Beneficio de caja = ingresos − gastos monetarios
Beneficio ajustado por trabajo = ingresos − gastos monetarios − horas del propietario × valor horario de sustitución elegido
Si es un hobby, valorar el propio tiempo en cero puede ser perfectamente razonable. Nadie suele decir que jugar 50 horas a un videojuego produjo una pérdida laboral.
El problema aparece solo cuando la contabilidad del hobby se presenta como prueba de rentabilidad empresarial.
Aprendizaje, diversión, reputación y satisfacción creativa son retornos reales. Simplemente no son lo mismo que beneficio comercial.
En una comparación económica, el tiempo no desaparece porque nadie haya emitido una factura.
4. La publicidad puede necesitar un denominador sorprendentemente grande
Una fórmula simplificada es:
Ingresos publicitarios = páginas vistas ÷ 1000 × RPM efectivo
El RPM cambia mucho según país, dispositivo, formato, temporada, tema, audiencia y configuración publicitaria.
Por eso aquí no se afirma un RPM «normal». Solo usamos valores hipotéticos para visualizar la escala.
Si hubiera que recuperar 789.000 yenes al mes únicamente con publicidad:
| RPM efectivo hipotético | PV necesarios para 789.000 yenes/mes |
|---|---|
| 100 yenes | aprox. 7,89 millones |
| 300 yenes | aprox. 2,63 millones |
| 500 yenes | aprox. 1,58 millones |
| 800 yenes | aprox. 0,99 millones |
No es una predicción sobre ningún sitio concreto.
La tabla muestra que si el trabajo manual se valora al coste profesional de sustitución, recuperar todo solo con anuncios puede exigir muchísimo tráfico.
Por eso muchos sitios manuales combinan publicidad con afiliación, venta de productos, captación de clientes, membresías, donaciones, valor de marca o valor de hobby.
5. La IA cambia mucho más que la velocidad de escritura
Reducir la IA a «escribe un artículo en 30 segundos» pierde buena parte de la economía.
Operar una publicación web implica:
- encontrar temas,
- investigar,
- redactar,
- verificar hechos,
- modificar código,
- probar,
- localizar,
- publicar,
- comprobar el resultado real en producción,
- reparar incidentes,
- distribuir en redes y boletines,
- medir y mejorar.
Con trabajo manual, cada nuevo proceso suele aumentar el coste variable.
Con IA y automatización, el coste inicial de construir el sistema puede subir, pero puede bajar el coste marginal de la segunda, décima y centésima pieza.
No es solo «el redactor escribe más rápido».
Se parece más a esto:
una persona puede poseer el sistema operativo de una pequeña redacción y un pequeño equipo de ingeniería.
La persona no desaparece. Su trabajo se desplaza hacia entradas, decisiones, especificaciones, criterios de calidad, excepciones y gobierno.
Pasa de fabricar cada pieza a diseñar la fábrica y editar su producción.
6. La IA no es un turbo mágico que siempre acelera
Los resultados de investigación son interesantes precisamente porque no apuntan en una sola dirección.
Un estudio controlado publicado en 2023 encontró que participantes con GitHub Copilot completaron una tarea concreta de servidor HTTP en JavaScript un 55,8% más rápido que el grupo de control.[3]
En cambio, un ensayo aleatorizado de METR en 2025 encontró que 16 desarrolladores experimentados de código abierto, trabajando en repositorios maduros que conocían desde hacía años, tardaron de media un 19% más cuando podían usar herramientas de IA de principios de 2025.[4]
En febrero de 2026, METR explicó que su experimento posterior se había vuelto difícil de interpretar. Más desarrolladores evitaban participar si tenían que trabajar sin IA y el tiempo real era más difícil de medir cuando varias agentes funcionaban en paralelo. METR considera plausible que las herramientas más recientes aceleren más que las de principios de 2025, pero los nuevos datos no permiten estimar con firmeza un porcentaje concreto por problemas de selección y medición.[5]
Así que la conclusión no es:
la IA siempre acelera un 55%.
Ni:
la IA ralentiza a los expertos un 19%.
Depende de la tarea, la familiaridad con el código, el flujo de agentes, la carga de revisión, el paralelismo y el entorno de pruebas.
La IA puede producir aciertos a gran velocidad. Un mal diseño también puede producir errores a gran velocidad.
La cifra útil es la medida en el flujo real de cada proyecto.
7. Un sitio manual no pierde automáticamente
Un sistema muy automatizado con IA no garantiza más beneficio que un sitio artesanal.
El trabajo manual puede ser racional cuando:
- solo se publican unas pocas piezas al mes,
- la escritura personal del experto es el producto,
- un solo artículo vende un servicio o producto de alto valor,
- no hace falta multilingüismo ni distribución masiva,
- hay pocas actualizaciones,
- el propietario disfruta la producción como hobby,
- o construir automatización costaría más que el trabajo que ahorra.
La automatización es más atractiva cuando:
- el mismo proceso se repite constantemente,
- se mantienen muchos idiomas,
- aumenta el inventario de contenidos,
- cada publicación requiere QA y verificación real,
- crecen los canales de distribución,
- y las personas repiten las mismas comprobaciones una y otra vez.
Es, en esencia, un problema de costes fijos y variables.
La fábrica con IA puede ser cara al principio. El taller manual puede ser caro por unidad.
Y una advertencia: una fábrica completamente automatizada y espectacular, sin lectores, no es el futuro de los medios. Es un almacén extraordinariamente sofisticado.
8. Para entender la rentabilidad de un sitio manual sin IA, bastan unos pocos números
No hace falta juzgar a la persona.
Para comparar sistemas, conviene conocer:
- Horas del propietario al mes
- PV o usuarios únicos mensuales
- Ingresos y gastos monetarios mensuales
- Número de artículos y artículos nuevos al mes
- Número de idiomas
- Años de operación y horas aproximadas de construcción inicial
De ahí salen medidas útiles:
Beneficio de caja = ingresos − gastos monetarios
Retorno de caja por hora del propietario = beneficio de caja ÷ horas
Beneficio ajustado por trabajo = beneficio de caja − horas × valor horario de comparación
Coste marginal por artículo = trabajo y gastos adicionales de redacción + traducción + QA + publicación + distribución
La última es especialmente importante.
Haber gastado 1000 horas en el pasado importa menos para el futuro que cuántas horas cuesta publicar la siguiente pieza ahora.
9. La verdadera ventaja de la IA no es el volumen, sino la repetibilidad
Generar una montaña de archivos en una noche ya no es la parte más difícil.
Lo difícil es construir un sistema donde:
- los mismos criterios de calidad funcionen la próxima vez,
- solo se repita el alcance que falló,
- no haya publicaciones duplicadas,
- se identifique la revisión vigente,
- se verifique el resultado real en producción,
- un canal bloqueado no congele trabajos independientes,
- la autenticación que realmente exige una persona vuelva a una persona,
- y el historial sea auditable.
Eso no es simplemente volumen.
Es un activo operativo.
Un sitio manual puede construir el mismo tipo de activo mediante procedimientos, plantillas, CMS, copias de seguridad y listas de comprobación.
La diferencia de la era de la IA es que una sola persona puede construir estas capas operativas con una profundidad antes poco habitual.
10. Conclusión: la pregunta interesante no es «¿llegó a 1000?», sino «¿cuánto cuesta la siguiente unidad?»
Un número correlativo de Issues y Pull Requests de cuatro cifras impresiona visualmente.
No debería usarse como puntuación de productividad.
Las cifras más útiles son:
horas humanas, coste por cambio, coste marginal por artículo, retrabajo antes de publicar, producción por hora del propietario, y beneficio ajustado por trabajo frente a ingresos.
Un sitio manual puede ser rentable.
Un sitio con IA puede perder dinero.
Pero las curvas de costes son muy distintas entre un modelo en el que humanos repiten manualmente redacción, traducción, desarrollo, QA, publicación, monitorización y distribución, y otro que invierte primero en sistematizar esos pasos para reducir después el coste marginal.
La proximidad al número 1000 no es interesante porque sea una medalla.
Lo interesante es:
¿cuántos de esos ciclos de prueba y corrección terminaron convertidos en mecanismos que evitan repetir el mismo trabajo humano la próxima vez?
Ahí está la diferencia económica más importante del desarrollo individual asistido por IA.
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
