Mi vida profesional comenzó desarrollando sistemas, en 1992. Durante años, hasta la primera década de los dos mil, parte de mi trabajo consistía en crear cosas: entender una necesidad y convertirla en algo que funcionara.
Después, mi trayectoria fue tomando otros caminos. Seguí trabajando cerca de los sistemas, pero dejé de acompañar de la misma manera las herramientas con las que se construyen. Hoy hay tecnologías de desarrollo, servicios de hosting y formas de organizar bases de datos que no conozco o que apenas estoy descubriendo.
Sin embargo, cuando empecé a construir con inteligencia artificial, reconocí algo que seguía ahí: sabía explicar lo que necesitaba.
Tal vez esa experiencia inicial tenga mucho que ver con la facilidad que encuentro ahora para pedir un desarrollo, precisar una regla o señalar que el resultado todavía no hace lo que esperaba. A eso se sumaron los años trabajando con los problemas que esos sistemas necesitan resolver.
Las herramientas cambiaron mucho. Mi conocimiento del negocio también. Ahora estoy descubriendo lo que ocurre cuando esas dos evoluciones se encuentran.
Lo que ya estaba disponible y yo no sabía aprovechar
Una de las experiencias recientes fue construir un módulo para gestionar información contractual que había quedado dispersa en distintas carpetas. Los datos históricos existían, pero estaban repartidos. Hoy ese módulo ya trabaja con ellos.
Parte de lo que hizo posible construirlo estaba disponible en nuestro propio entorno corporativo. Eran herramientas que no conocía, algunas cuya existencia ni siquiera tenía presente. Con ayuda de la IA conseguí avanzar, en pocas horas, hacia una primera versión que antes me habría resultado difícil imaginar.
Esas pocas horas describen el comienzo. Después vienen los ajustes, las comprobaciones y las preguntas que aparecen al utilizar lo construido. Conviene distinguir ambas cosas cuando contamos estas experiencias: llegar rápido a una primera versión no significa haber terminado el trabajo.
Algo parecido me ocurrió con CFO One, el sistema que empecé a crear después de treinta años utilizando herramientas financieras. Había necesidades que sabía describir con bastante precisión porque llevaba mucho tiempo conviviendo con ellas.
La posibilidad de construir acercó esas necesidades a una solución. Y me devolvió una satisfacción que reconocía: ver funcionar algo que antes solo podía explicar.
Más personas podrán darle forma a lo que necesitan
En una sesión del programa que estoy cursando en MIT Professional Education, el profesor Abel Sánchez planteó una idea que me dejó pensando: el volumen de código que podremos generar crecerá enormemente. También habló de la democratización del conocimiento especializado.
Relacioné ambas ideas con lo que estaba viviendo.
Hay personas que conocen muy bien una operación y que nunca han tenido los medios para construir una herramienta propia. Saben dónde se repite una revisión, qué información falta y qué excepción obliga a salir del sistema para resolver algo en otro lugar.
La IA puede acercarlas a capacidades que antes requerían una intervención técnica mucho mayor desde el primer momento. Eso abre espacio para soluciones pequeñas, específicas y próximas a quienes las necesitan.
Mi caso tiene un antecedente de programación que importa reconocer. No estoy viviendo exactamente la misma experiencia que alguien que nunca desarrolló un sistema. Pero incluso con esa base, la distancia entre lo que sabía pedir y lo que podía construir por mi cuenta se había vuelto considerable.
Esa distancia está cambiando.
Democratizar el acceso a una capacidad tampoco significa que todos adquiramos automáticamente el mismo conocimiento. Podemos hacer más y, al mismo tiempo, necesitar ayuda para comprender una parte de lo que estamos haciendo.
Construir conversando también exige comprender
En esta conversación aparece con frecuencia el término vibe coding: describir lo que queremos, dejar que la IA genere código, probar el resultado y pedir ajustes.
La expresión tiene un matiz importante. En la descripción original de Andrej Karpathy, incluía avanzar sin leer ni comprender todo el código generado. Como explica Simon Willison al distinguir el vibe coding del desarrollo asistido por IA, utilizar estas herramientas no implica necesariamente trabajar de esa manera.
Me interesa la libertad que abre esa experimentación. Permite darle forma a una idea antes de dominar todas las herramientas necesarias para construirla.
También me obliga a reconocer un límite: saber especificar una necesidad y comprobar que una pantalla entrega lo esperado no equivale a comprender todo lo que sostiene el sistema.
Puedo reconocer una regla de negocio mal aplicada y, aun así, necesitar una revisión técnica para evaluar cómo se protegen los datos, cómo se recupera la información o qué ocurrirá cuando varias personas utilicen la solución.
La facilidad para generar código puede crecer más rápido que nuestra capacidad de comprenderlo.
Por eso, IH+IA empieza antes de pedir el desarrollo, al definir el problema, las reglas y las excepciones. Continúa al revisar lo recibido y reconocer qué podemos validar por nuestra cuenta y dónde necesitamos otro conocimiento.
La primera versión también crea compromisos
Una herramienta puede empezar resolviendo una necesidad personal y terminar siendo utilizada por toda un área. En ese recorrido cambia la responsabilidad de quien la construye y de quien permite que la operación dependa de ella.
¿Quién la mantiene si su creador cambia de función? ¿Quién responde cuando falla? ¿Dónde quedaron documentadas las reglas? ¿Quién autoriza el acceso a los datos? ¿Cómo se adapta cuando cambia el proceso?
Son preguntas que conviene incorporar mientras la solución todavía es pequeña.
En el módulo de contratos, construimos sobre una plataforma homologada, utilizando el control de acceso ya existente. La continuidad quedará en nuestra área, con la intención de ampliar también nuestra autonomía.
De otro modo, podríamos resolver una dependencia y crear otra: una persona que conoce la herramienta, conserva las instrucciones y es la única capaz de repararla. La velocidad inicial habría producido una nueva forma de ser indispensable.
Documentar también necesita acompañar esta forma de construir. Vale la pena conservar las decisiones, los criterios de aceptación, los cambios relevantes y las instrucciones que ayudan a entender el resultado. Un historial extenso de conversaciones puede ser útil, pero alguien más necesita poder encontrar y comprender lo esencial.
En Después del SaaSpocalypse escribí sobre lo que permanece detrás de una interfaz cada vez menos visible. Esa reflexión también se aplica a las soluciones que ahora podemos construir nosotros mismos: siguen necesitando continuidad, controles y capacidad de evolución.
El conocimiento funcional encuentra otra forma de participar
Aquí veo una oportunidad especial para el analista funcional y para quienes conocen los procesos en profundidad.
Comprender cómo trabaja un área, traducir una necesidad en reglas y reconocer excepciones son capacidades que pueden intervenir mucho más directamente en la construcción. La conversación con la IA necesita precisamente ese contexto.
Pero esa participación requiere una buena relación con el área de Tecnología. Quien conoce el proceso aporta sus necesidades y sus particularidades; TI aporta criterio sobre arquitectura, integración, seguridad y continuidad. La calidad de la solución depende de cómo se conectan esos conocimientos.
Me gustaría que esta posibilidad sirviera para construir juntos desde más cerca del problema. Para eso, las organizaciones necesitan ofrecer caminos claros: dónde experimentar, con qué datos, qué apoyo está disponible y qué revisión hace falta antes de compartir una herramienta.
Si cada iniciativa queda fuera de la vista de los demás, será difícil aprovechar lo aprendido. También será más difícil saber de qué soluciones empieza a depender la empresa.
Liderar cuando el equipo también puede construir
Para un líder, descubrir que alguien del equipo puede resolver una necesidad de esta manera debería abrir una conversación.
Hay que comprender qué problema resolvió, cómo comprobó el resultado y qué necesita para seguir. También decidir si conviene mantenerlo como una herramienta personal, compartirlo con otras áreas o convertirlo en una solución con soporte más formal.
No todo experimento necesita transformarse en un sistema de la empresa. Algunos habrán cumplido su función al ayudarnos a entender mejor una necesidad. Otros merecerán crecer.
El liderazgo también tiene una responsabilidad en el aprendizaje: dar espacio para experimentar, acercar apoyo técnico y evitar que toda esa capacidad quede concentrada en unas pocas personas. Aprender a pedir ayuda a la IA forma parte del proceso; aprender a revisar lo que entrega y explicárselo a otros también.
Una solución empieza a convertirse en capacidad del equipo cuando alguien más puede comprenderla y continuarla.
Ese es un resultado que me interesa tanto como la primera versión funcionando.
Volver con más preguntas
Cuando desarrollaba sistemas al comienzo de mi carrera, estaba aprendiendo a construir y a comprender los procesos que debía representar.
Hoy vuelvo con otra experiencia. Conozco mejor muchos de esos problemas, aunque tenga que aprender nuevas herramientas y reconocer cuánto cambió la forma de trabajar.
La IA me permite participar nuevamente en la construcción con una cercanía que había perdido. Me entusiasma ver aparecer algo que necesitaba, probarlo y descubrir qué puede mejorar. También me impresiona la velocidad con la que ese código puede crearse. Recuerdo mis comienzos, cuando pasaba horas y horas, noches y madrugadas enteras, construyendo cada parte.
También quiero que ese entusiasmo me ayude a hacer mejores preguntas: qué estoy resolviendo, qué todavía no comprendo y qué necesita quedar preparado para que la solución pueda seguir funcionando sin depender siempre de mí.
Volver a construir tiene algo familiar. Lo nuevo es todo lo que puedo llevar ahora a esa conversación.