Cuando el caos se convierte en método: AI y GitHub para gestionar un proyecto que nadie quería tocar

Me llama un cliente. Voz tensa, palabras medidas.

“Ivan, tenemos un problema. Mejor dicho, tenemos el problema.”

Conozco ese tono. Es el tono de quien ya ha intentado resolver las cosas internamente, ha fracasado, y ahora busca a alguien que le diga la verdad sin rodeos.

El problema es un software de gestión — no un sitio web, no una app — un sistema crítico sobre el que funcionan procesos empresariales importantes. Tiene algunos años. Creció rápido, como siempre sucede cuando el negocio corre más rápido que la arquitectura. Y ahora se ha acumulado todo: bugs abiertos que nadie cierra, solicitudes de evolución que nadie planifica, desarrolladores que trabajan en versiones diferentes del código sin saber qué hace el otro.

El clásico escenario que, en palabras, “funciona”. Pero que por dentro es un campo minado.

🧠 La primera reunión: entender qué es lo que realmente no funciona #

Cuando entro en un proyecto como este, no miro el código primero.
Miro a las personas. Miro cómo se comunican. Miro dónde se pierde la información.

El equipo estaba compuesto por cuatro desarrolladores buenos. Serios. Competentes.
Pero trabajaban así:

• el código estaba en una carpeta compartida en la red
• los cambios se comunicaban por email o en una hoja Excel
• los bugs se reportaban verbalmente, por chat, por tickets — sin un criterio único
• nadie sabía con certeza cuál era la versión “buena” del software

¿Y sabes qué pasa en estas situaciones?
Cada uno tiene razón desde su punto de vista. Pero el proyecto, en su conjunto, está fuera de control.

El problema no es técnico. Es organizativo.
Y aquí cambia todo.

📌 La propuesta: GitHub como columna vertebral del proyecto #

Lo primero que puse sobre la mesa fue claro, directo, sin adornos:

Adoptamos GitHub. Todo el código pasa por ahí. Sin excepciones.

No es cuestión de moda. No es porque “lo hacen todos”.
Es porque GitHub resuelve, con herramientas concretas, problemas que ninguna hoja Excel podrá gestionar jamás:

• Versionado real: cada cambio está rastreado, comentado, reversible
• Branches y Pull Requests : cada desarrollador trabaja en su copia, luego propone los cambios al equipo — no sobrescribe el trabajo de los demás
• Issue tracker integrado: los bugs y las solicitudes de evolución viven en el mismo lugar que el código
• Historial completo: quién hizo qué, cuándo, por qué

Vi la cara del desarrollador senior. Una mezcla de curiosidad y desconfianza.
“Pero nosotros siempre lo hemos hecho así.”

Le respondí con calma: “Lo sé. Y el resultado es la razón por la que estoy aquí.”

No lo dije para provocar. Lo dije porque es la verdad.
Y la verdad, cuando se dice de la manera correcta, no ofende. Libera.

🔬 El segundo paso: la AI como acelerador, no como sustituto #

Una vez definido el flujo de trabajo en GitHub — branches, review, merge controlados — hice la segunda propuesta.

“Integremos la inteligencia artificial en el proceso de resolución de bugs.”

Silencio.

Entiendo la reacción. Cuando dices “AI” en una sala de desarrolladores, la mitad piensa en ChatGPT generando código al azar, la otra mitad piensa que les estás diciendo que su trabajo ya no sirve.

Ninguna de las dos cosas.

Lo que propuse es muy diferente:

• Cuando un desarrollador toma un bug, antes de escribir una línea de código, usa la AI para analizar el contexto
• La AI lee el código involucrado, los logs, la descripción del problema
• Propone hipótesis. No soluciones definitivas — hipótesis razonadas
• El desarrollador evalúa, verifica, y luego implementa

La AI no sustituye al programador.
La AI le ahorra las primeras dos horas de análisis — esas en las que estás leyendo código escrito por otra persona, intentando entender qué diablos pasa.

Y esas dos horas, multiplicadas por cada bug, por cada desarrollador, por cada semana, se convierten en un número que cambia las cuentas del proyecto.

📊 Los números que puse sobre la mesa #

No vendí sueños. Presenté estimaciones conservadoras.

El equipo gestionaba una media de 15-20 bugs por semana.
El tiempo medio de resolución era de aproximadamente 6 horas por bug (entre análisis, fix, testing, deploy).

Con la introducción de GitHub + AI en el workflow, mi estimación era:

Una reducción de más del 90% en el tiempo total de resolución.
Un aumento de 12 veces en la capacidad del equipo para cerrar tickets.
Sin contratar a nadie. Sin cambiar a las personas. Cambiando el método.

🛠️ Cómo funciona en la práctica #

El workflow que diseñé es simple. Intencionadamente simple.

1. El bug llega como Issue en GitHub
Título claro, descripción, etiqueta de prioridad. Basta de emails, basta de chat.

2. El desarrollador crea un branch dedicado
fix/issue-234-error-calculo-iva — el nombre lo dice todo.

3. Antes de tocar el código, consulta a la AI
Le pasa el código involucrado, el error, el contexto. La AI devuelve un análisis estructurado: dónde podría estar el problema, qué archivos están involucrados, qué tests verificar.

4. El desarrollador implementa el fix
Con una ventaja enorme: ya sabe dónde mirar.

5. Pull Request con revisión
Un colega revisa el código. No por formalidad — por calidad.

6. Merge en el branch principal
Solo después de la aprobación. El código “bueno” sigue siendo bueno.

7. El Issue se cierra automáticamente
Trazabilidad completa. Del problema a la solución, todo documentado.

📈 Qué cambió después de tres semanas #

Los primeros días fueron los más duros. Siempre es así.
Nuevas herramientas, nuevos hábitos, la tentación de volver al “cómo se hacía antes”.

Pero después de tres semanas ocurrió algo.

El desarrollador senior — el que me había mirado con desconfianza — me escribió:

“Ivan, ayer resolví un bug que el año pasado me había bloqueado durante dos días. Con la AI tardé cuarenta minutos. No porque la AI escribió el código. Sino porque me mostró inmediatamente dónde estaba el problema.”

Ahí está. Ese es el punto.
La AI no escribe mejor código que un desarrollador experto.
La AI acelera el camino entre el problema y la comprensión del problema.

Y la comprensión es siempre el paso más costoso.

🎯 La lección que me llevo a casa #

Cada vez que entro en un proyecto en dificultades, encuentro el mismo patrón:

1. Personas competentes
2. Herramientas inadecuadas
3. Procesos ausentes o informales
4. Frustración creciente

La solución nunca es “trabajar más”.
La solución es trabajar de manera diferente.

GitHub no es una herramienta para desarrolladores. Es una herramienta para equipos.
La AI no es un juguete. Es un multiplicador de competencia.

Pero ninguno de los dos funciona si no hay alguien que mire el proyecto desde arriba, entienda dónde se pierden las horas, y tenga el coraje de decir: “Cambiemos.”

💬 Para quienes se reconocen en esta historia #

Si estás gestionando un proyecto de software y te ves reflejado en lo que he descrito — el código disperso, los bugs que vuelven, el equipo que trabaja mucho pero cierra poco — ten claro que no es culpa de las personas.

Es culpa del sistema en el que trabajan.

Y el sistema se puede cambiar.
Se debe cambiar.

No hacen falta revoluciones. Hacen falta decisiones precisas, implementadas con método.

Un repositorio compartido. Un flujo de trabajo claro. Un asistente inteligente que acelera el análisis.

Tres cosas. Tres decisiones.
Que transforman el caos en control.

Glosario #

Pull Request — Solicitud formal de incorporar cambios de un branch al branch principal, con code review obligatoria. El mecanismo que garantiza que el código “bueno” siga siendo bueno.

Version Control — Sistema que rastrea cada cambio en el código, manteniendo el historial completo. Git es el estándar; GitHub añade colaboración sobre Git.

Issue Tracker — Sistema de seguimiento integrado para bugs y solicitudes de evolución. En GitHub, las issues viven en el mismo lugar que el código, con trazabilidad del problema a la solución.

Code Review — Revisión del código por parte de un colega antes del merge. Captura bugs, mejora la calidad y difunde el conocimiento del codebase en el equipo.

Branch — Rama de desarrollo independiente que permite trabajar en cambios aislados sin afectar el código principal hasta el merge aprobado.