Mientras la AI escribe más código, por qué aún necesitamos comprenderlo

Usé AI para crear un producto que ayuda a las personas a comprender el código.

Pero ocurrió algo interesante: cuanto más complejo se hacía el producto, menos lo comprendía yo mismo.

Empecé a desarrollar FiboCode alrededor de julio de 2025. Vibe Coding estaba despegando y todo el mundo hablaba de usar AI para ayudar a escribir código y reducir el coste del desarrollo de software. Una idea surgió de forma natural:

Si la AI puede ayudar a escribir código, ¿también podría ayudar a comprenderlo?

El coste de escribir código sigue bajando, pero comprender un proyecto desconocido continúa siendo doloroso. Más aún ante una base de código con años de historia, una estructura de directorios compleja, dependencias entre módulos, decisiones de diseño históricas y toda clase de convenciones. A menudo, solo averiguar por dónde empezar lleva mucho tiempo.

FiboCode nació de esa idea sencilla: usar AI para analizar código y generar documentos y diagramas de relaciones, y permitir después navegar entre el código, los documentos y los diagramas.

En ese momento solo era una herramienta de análisis de código.

Más tarde añadí un Agent sencillo para facilitar las preguntas sobre el código. Para mejorar la lectura integré Monaco Editor. Con un editor, la navegación, las referencias de símbolos y los diagnósticos del lenguaje también parecían necesarios, así que añadí compatibilidad con LSP.

Una vez cubierta la lectura, editar era el siguiente paso natural.

Cuando FiboCode pudo modificar código, empecé a pensar cómo lograr que el Agent entendiera de verdad un proyecto, en lugar de juzgarlo solo por los pocos archivos abiertos. Poco a poco añadí MCP y Skills para que la AI también pudiera acceder a las convenciones de diseño, el contexto arquitectónico y la historia del proyecto.

Después comprendí que muchos desarrolladores ya se sentían cómodos con Agent CLI como Claude y Codex. Quizá no necesitaban otro Agent integrado, sino una interfaz diseñada para revisar los resultados de su trabajo.

Por eso FiboCode incorporó un terminal y mejoras específicas para la salida de Agent CLI, conectando las referencias de archivos, los cambios de código y los pasos de ejecución del terminal con el código, los documentos y los diagramas de relaciones.

Así, un módulo sencillo de análisis de código creció pieza a pieza hasta convertirse en un sistema cada vez más complejo.

Empecé a olvidar el proyecto que había creado

Programar con ayuda de AI es realmente cómodo.

Aunque los primeros modelos no eran tan capaces como hoy, revisaba cuidadosamente el código que generaban, a menudo varias veces. Observaba cómo se dividían los módulos, cómo fluían los datos y por qué la arquitectura se había diseñado así.

El proyecto pasó por muchas refactorizaciones. Algunas fueron extensas, pero como entonces conocía los detalles del diseño, ninguna acabó rompiendo el proyecto.

Después los modelos mejoraron, aumentó la velocidad de generación y la base de código empezó a crecer con rapidez.

Poco a poco noté que ya no recordaba los detalles de diseño del código que había revisado apenas una o dos semanas antes.

Al principio me asustó un poco.

Era mi propio proyecto. Cada función había nacido de mí y, aun así, ya no recordaba por qué cada módulo se había diseñado de cierta manera ni cómo funcionaba cada parte de la lógica.

Con el tiempo entendí que quizá solo debía aceptarlo.

Ya no era el pequeño proyecto del comienzo. En un sistema suficientemente complejo, nadie puede recordar todos los detalles de implementación. Lo importante quizá no sea guardar cada línea en la cabeza, sino saber dónde está el núcleo, cómo colaboran los módulos, qué partes pueden confiarse con seguridad a la AI y cuáles deben comprenderse con cuidado.

Tenía que aprender a elegir.

Debía encontrar las rutas críticas entre todo el código, construir una imagen mental amplia del sistema y dar después a la AI requisitos y restricciones más precisos.

Desde esa perspectiva, FiboCode también me ayudaba a construir FiboCode.

Usaba AI para desarrollar el producto; el producto se volvía más útil y, a su vez, me ayudaba a comprenderlo e iterarlo más rápido. Ese ciclo positivo era verdaderamente emocionante y una razón importante para seguir trabajando tanto tiempo.

Pero, más allá de la emoción, me preguntaba con frecuencia:

¿Qué quedaba para mí en este proceso de desarrollo?

Cuando entregué cada vez más de mi pensamiento a la AI

Durante mucho tiempo desarrollé poco a poco un hábito.

Cuando había un requisito, se lo daba primero a la AI.

Cuando había un problema, pedía primero a la AI que investigara.

Después de que propusiera una solución, yo la verificaba. Si fallaba, devolvía el resultado y pedía otro análisis y otra corrección.

A veces pasaba un día entero describiendo requisitos, explicando el estado de un error y devolviendo resultados de pruebas una y otra vez.

Parecía que la AI realizaba casi todo el trabajo intelectual difícil y que mi papel se reducía a definir requisitos y devolver resultados.

En aquella época sentí algo con mucha fuerza:

Parecía que yo ya no tenía demasiado valor.

Pero al continuar descubrí que no era exactamente así.

Desarrollando con AI conocí muchas tecnologías que antes no habría estudiado y una gran variedad de enfoques. Empecé a mirar deliberadamente el diseño y la arquitectura antes de examinar la implementación concreta.

En algunas tareas podía ver enseguida que el alcance era pequeño y que la AI podía resolverlas directamente.

Pero cuando una tarea atravesaba varios módulos o afectaba a la estructura central, sabía de inmediato que no era tan sencilla. La AI podía ver solo el requisito actual sin entender por qué existía un diseño histórico ni qué áreas sufrirían efectos indirectos.

También había código que necesitaba comprender casi por completo aunque la AI pudiera escribirlo, porque si algo fallaba allí las consecuencias serían difíciles de controlar.

Dejé de insistir en comprender cada detalle, pero me volví más sensible a los límites, las dependencias, los riesgos y los cambios del sistema.

Quizá el trabajo humano no ha desaparecido; simplemente está cambiando.

Antes comprendíamos un sistema implementando nosotros mismos su código.

En el futuro quizá dediquemos menos esfuerzo a la implementación repetitiva y más atención a la arquitectura, el proceso, las restricciones, la verificación y la evolución a largo plazo.

Que la AI pueda escribirlo no significa que podamos confiar en ello

No sé si la AI llegará realmente a sustituir a los expertos humanos y a realizar todo el trabajo de programación.

Es una cuestión técnica, pero creo que también es una cuestión de confianza.

Aunque algún día la AI genere por sí sola un sistema muy complejo, eso no significa que estemos dispuestos a confiar en él sin reservas.

Cuando el sistema se comporte de forma inesperada, ¿sabremos por qué?

¿Podremos localizar el error?

¿Podremos verificar la corrección?

¿Podrá otra persona hacerse cargo?

Si el sistema causa daños graves, ¿quién será responsable?

Estas preguntas no se resuelven por completo elevando la precisión del modelo del 99 % al 99,9 %.

En aplicaciones de bajo riesgo y fáciles de sustituir podemos tolerar más caja negra. Si la función sirve y el desarrollo es suficientemente rápido, quizá no importe cada detalle.

Pero en software fundamental como sistemas operativos y bases de datos, o en sistemas financieros, eléctricos y otros con gran impacto social, cuesta aceptar una caja negra que no pueda comprenderse, auditarse ni traspasarse.

Esos sistemas todavía necesitan personas que los mantengan.

No tienen que escribir cada línea, pero alguien debe saber aproximadamente cómo funciona el sistema, dónde están los riesgos críticos y por dónde empezar a investigar cuando algo sale mal.

Por eso creo cada vez más que la comprensión del código no desaparecerá con el auge de la programación con AI.

Simplemente adoptará otra forma.

Antes necesitábamos comprender el código para escribirlo.

En el futuro quizá necesitemos comprenderlo para verificar, mantener, asumir y seguir evolucionando sistemas creados por AI.

Las tareas de entrada que están desapareciendo

Comprender el código tiene otro significado.

La AI está reduciendo algunos puestos iniciales centrados en implementación repetitiva y tareas básicas. Incluso cuando los puestos no desaparecen, gran parte del trabajo que antes se asignaba a principiantes se automatiza primero con AI.

Esto no ayuda a quienes empiezan.

El camino tradicional de crecimiento de un ingeniero suele comenzar con tareas simples: arreglar un error, leer una pequeña sección, completar una función pequeña y participar gradualmente en módulos más complejos y en el diseño del sistema.

Con esas tareas que parecen poco importantes, los principiantes construyen poco a poco su comprensión de proyectos reales.

Pero ahora la AI puede completar directamente esas tareas fundamentales.

Si quedan menos puntos de entrada para formar a principiantes, ¿de dónde saldrán los ingenieros sénior del futuro?

Esta fue otra razón para crear FiboCode.

Yo también soy nuevo en la profesión. La primera vez que afronté una base de código heredada y compleja, a menudo no sabía qué hacer.

Había demasiados archivos y directorios. Los servicios se llamaban entre sí y los tipos, interfaces y configuraciones estaban dispersos. Sabías que la respuesta estaba en algún lugar del código, pero no dónde empezar, qué era importante o qué era solo un detalle.

A menudo la verdadera dificultad no era comprender una línea concreta, sino no tener un mapa completo.

Siempre quise una herramienta que analizara primero la estructura de todo el proyecto y me dijera dónde estaban los módulos centrales, cómo se conectaba el código y qué áreas podía afectar un cambio.

Así, quienes empiezan no dependerían por completo de alguien que los guiara paso a paso ni tendrían que avanzar a tientas una y otra vez por bases de código desconocidas.

Una herramienta así no reemplaza el crecimiento, pero reduce la barrera de entrada a un sistema complejo.

Mientras la AI corta gradualmente el antiguo camino de aprendizaje, espero que FiboCode pueda volver a conectar una ruta.

No necesariamente un atajo que evite todos los fundamentos, sino algo parecido a un mapa, un sistema de navegación y un camino que ayude a formar antes un modelo mental del sistema.

El código solo registra el presente

Durante el desarrollo descubrí otro problema.

Dar una tarea directamente a la AI y dejar que explore el repositorio por sí sola puede producir a veces un razonamiento incompleto.

La AI ve el código actual, pero quizá no sepa por qué un módulo se diseñó de cierta forma ni que está conectado indirectamente con archivos que parecen no guardar relación.

El código suele decirnos cómo es un sistema ahora, pero le cuesta explicar por qué llegó a ser así.

Al principio pensé en poner toda esa información en comentarios de código.

Después decidí que no era el lugar adecuado.

Grandes cantidades de contexto de diseño, razonamiento histórico y explicaciones de cambios inflarían los archivos y añadirían para la AI mucho contexto irrelevante para la tarea actual. Los comentarios explican bien la lógica local, pero no pueden cargar fácilmente con toda la evolución de un proyecto.

Por eso diseñé una serie de Fibo Skills.

Registran las convenciones, los diseños, el proceso de implementación y las explicaciones de los diff, dejando una huella más completa de cada cambio.

Espero que cuando la AI modifique código en el futuro no solo vea el estado actual, sino que también entienda qué ocurrió antes y por qué se conservaron ciertos diseños.

Cuando la historia de evolución de un proyecto es trazable, la AI puede comprenderlo de forma más completa.

Esto también se convirtió en una de las direcciones que tomó FiboCode:

Al principio se diseñó para ayudar a las personas a comprender código. Más tarde empezó también a ayudar a la AI a comprenderlo mejor.

Cómo FiboCode llegó a ser lo que es

Mirando atrás, FiboCode no fue diseñado desde el principio para ser lo que es hoy.

Comenzó como un módulo sencillo de análisis. Luego llegaron los documentos y diagramas de relaciones, un Agent, un editor y los servicios de lenguaje. Gradualmente incorporó edición de código, un terminal, MCP y Skills.

Quería dar a Agent CLI una experiencia de revisión similar a Cursor y convertir los documentos y relaciones producidos por el análisis en contexto realmente utilizable por la AI.

Evolucionó de módulo sencillo a sistema complejo, y ese crecimiento continuo reflejaba silenciosamente la expansión de la sucesión de Fibonacci.

De ahí proceden también el nombre FiboCode y la imagen del caracol.

La concha del caracol contiene la belleza matemática de la espiral áurea.

No se mueve muy rápido, pero continúa creciendo hacia delante.

FiboCode no pretende que la gente vuelva a escribir cada línea a mano ni dejar fuera a la AI.

Al contrario. Acepta que la AI escribirá cada vez más código y, partiendo de ello, espera ayudar a las personas a seguir comprendiendo, verificando, manteniendo y asumiendo sus propios sistemas.

En una época en la que todos persiguen una generación más rápida, aún espero que podamos frenar de vez en cuando.

Para comprender por qué el código funciona como lo hace y por qué un sistema llegó a ser lo que es hoy.

Y para redescubrir la alegría que nos llevó por primera vez a programar.