Mi gráfica de contribuciones de GitHub de 2025 parece pertenecer a dos desarrolladores distintos. La primera mitad del año está casi vacía. En la segunda hay más de 4.000 commits.
No fue porque de repente tuviera más tiempo libre. Seguía compaginando un trabajo a tiempo completo con side projects. Lo que cambió fue la fricción entre una idea y una versión que funcionara: empecé a usar herramientas de coding con AI de una forma mucho más seria.
Conviene ser preciso con esa cifra. El número de commits no es por sí solo una métrica de productividad. Cuatro mil commits no demuestran cuatro mil mejoras útiles ni que el código fuera bueno. Lo que sí demuestra la gráfica es un cambio real en mi forma de trabajar: construía, iteraba y llegaba a versiones funcionales con mucha más constancia que antes.
El verdadero cuello de botella era la energía para empezar
En los side projects me encontraba una y otra vez con el mismo problema: la primera versión útil suele estar detrás de bastante trabajo rutinario. Routing, validación, scripts, tests, configuración y limpieza pueden consumir el impulso antes de saber siquiera si una idea merece continuar.
Antes posponía experimentos cuando el primer resultado parecía requerir varias noches de setup. Las herramientas de AI coding no eliminaron ese trabajo, pero redujeron el coste del primer borrador y me permitieron llegar antes a una versión que pudiera probar.
Por eso el mayor beneficio no fue escribir más rápido. Fue reducir la energía de activación: más ideas llegaban realmente al punto en que podía obtener evidencia.
Cómo cambió mi workflow con Node.js
No sustituí mi proceso de desarrollo por una ventana de chat. En mis side projects con Node.js usé DeepSeek como un segundo par de manos para tareas bien delimitadas: preparar una primera implementación, leer código desconocido, proponer tests, analizar un stack trace, dividir un refactor grande y revisar supuestos de deployment.
- Scaffolding: crear la primera versión aburrida de handlers, validación, scripts o tests.
- Lectura de código: seguir el recorrido de un request o un valor antes de editar.
- Refactoring: dividir cambios mecánicos en diffs pequeños y revisables.
- Debugging: generar varias hipótesis a partir de logs en vez de casarme con la primera.
- Verificación: buscar edge cases y regresiones después de hacer funcionar el happy path.
Cuanto más claros eran los inputs, outputs, restricciones y convenciones existentes, más fácil era verificar la respuesta. Las tareas vagas producían con más frecuencia una abstracción plausible pero equivocada.
Por eso trataba cada output como un candidate patch, no como una solución final. Type checking, tests, build y el flujo real eran evidencia; una explicación segura de sí misma no lo era.
Dónde me ayudó más DeepSeek — y dónde no
DeepSeek me resultó útil sobre todo porque podía usarlo de forma repetida en tareas de programación concretas. Podía pedir un primer intento, rechazar una parte, devolver el error real, reducir el scope e iterar con rapidez.
No lo presento como un benchmark. No hice un estudio controlado contra todos los modelos competidores y las familias de modelos cambian muy rápido. La afirmación defendible es más modesta: DeepSeek encajó suficientemente bien en mi workflow como para que empezara a usar asistencia de AI con mucha más frecuencia.
Funcionaba mejor cuando el feedback era barato: una función, tests y un error real. Era peor cuando la tarea dependía de contexto de producto no escrito o de trade-offs arquitectónicos sutiles. En esos casos, una respuesta fluida podía hacer que una mala suposición pareciera terminada.
La AI cambió el coste de experimentar
La mayor mejora no fue “la AI escribe código, por tanto el desarrollo es automático”. Fue que muchas piezas pequeñas se volvieron lo bastante baratas como para intentar hacerlas. Una función de un side project que antes parecía implicar demasiado setup podía convertirse en un prototipo mientras la idea todavía me interesaba.
La diferencia importa. La AI redujo el coste de llegar a una versión que se podía probar. No hizo desaparecer la arquitectura, el criterio de producto, el deployment ni la corrección. Una implementación generada puede estar mal; un build correcto puede fallar en runtime; un prototipo desplegado puede seguir siendo un mal producto.
Para mí, el beneficio práctico fue el impulso. Cuando podía ver el sistema completo funcionando, me resultaba mucho más fácil seguir refinándolo.
Qué necesitaría un benchmark más sólido
Para convertir la experiencia en un benchmark reproducible registraría versiones exactas de modelos, tareas de programación fijas, snapshots del repositorio, prompts, outputs originales, tiempo, patches aceptados y rechazados, tiempo de review, resultados de tests y rework.
También mediría algo más que commits: tiempo desde la idea hasta una versión verificada, defectos, rollbacks y trabajo reescrito. Sin ese contexto, 4.000 commits son evidencia de actividad y de un cambio de hábitos, no una prueba de calidad de software.
Lo que cambió para mí
2025 fue el año en que dejé de ver cada side project como una montaña de setup que tenía que escalar manualmente. La AI hizo que la primera versión funcional fuese lo bastante barata como para que yo pudiera llegar con más frecuencia al punto en el que de verdad importan las decisiones de producto.
Por eso la segunda mitad de mi gráfica de GitHub parece tan distinta. No porque la AI me diera más horas al día ni porque cada línea generada fuera buena. Redujo la fricción que había matado ideas anteriores antes de que se hicieran reales.
En 2026 me interesa la parte menos vistosa de la ecuación: refinar el workflow, medir la calidad con más seriedad y asegurarme de que desarrollar más rápido produce mejor software y no simplemente más commits.