Entrevista · Luis Fernando Cajas
PRESENTACIÓN
¿Desde qué experiencia observa hoy el cambio en la programación?
Luis Fernando Cajas se define ante todo como desarrollador. Acumula cerca de diez años de experiencia en software y actualmente coordina un equipo orientado a análisis de datos, business intelligence y presentación de información. Ese recorrido le permite mirar la IA desde dos perspectivas: como alguien formado en la depuración y la documentación tradicional, y como responsable de equipos que hoy pueden automatizar gran parte del trabajo mecánico.
ANTES
Antes de los asistentes de IA, ¿cómo investigaba, depuraba y refactorizaba código?
El proceso dependía mucho más de documentación oficial, buscadores, foros técnicos, Stack Overflow y videos especializados. Cuando aparecía un error había que reproducirlo, entender exactamente qué ocurría, buscar casos similares, formular hipótesis y probar soluciones una por una. Era más lento, pero obligaba a conocer el código. Para Luis, la IA redujo drásticamente el tiempo de búsqueda; lo que no eliminó fue la necesidad de comprender aquello que se está intentando resolver.
ANTES
¿Qué diferenciaba a un buen programador?
No era escribir más rápido, sino resolver mejor. Había que descomponer una necesidad en problemas pequeños, reconocer restricciones y seleccionar una solución adecuada. Estructuras de datos, algoritmos, bases de datos, arquitectura, sistemas operativos, redes y patrones de diseño eran -y siguen siendo- fundamentos. A ello se sumaba una habilidad esencial: depurar. Seguir la ejecución, plantear hipótesis y comprobar dónde se rompe un sistema forma un criterio que ninguna respuesta generada sustituye automáticamente.
TRANSICIÓN
¿Cuál fue una de las primeras tareas que cambió con estas herramientas?
En su trabajo reciente con grandes volúmenes de información, Luis vio el cambio en tareas mecánicas como la generación de consultas SQL. La IA puede acelerar la sintaxis, pero el valor profesional aparece después: revisar índices, pensar en rendimiento, anticipar problemas y optimizar la consulta. El aprendizaje de la transición fue claro: no se traslada el problema completo a la herramienta. La calidad del resultado depende del contexto entregado y de la capacidad de revisar lo que devuelve.
TRANSICIÓN
¿Qué riesgos encuentra en el llamado vibe coding?
Le parece una ventaja enorme porque reduce la barrera de entrada y permite obtener prototipos con rapidez. El riesgo aparece cuando se confunde que una aplicación funcione con que esté bien construida. Puede ejecutar una tarea y aun así contener fallos de seguridad, arquitectura, rendimiento, manejo de errores o mantenimiento. El problema no es utilizar lenguaje natural para construir; es hacerlo sin comprender las decisiones que terminaron dentro del sistema.
DESPUÉS Si la IA produce código que funciona pero el desarrollador no puede explicarlo, ¿debería integrarse?
Para Luis, no de forma directa. Que compile es apenas una condición. Hay que saber qué hace, por qué lo hace, cuáles son sus límites y cómo reaccionará en escenarios no previstos. Si el desarrollador no puede explicar el fragmento tampoco puede garantizar mantenimiento ni responder ante una falla. Antes de integrarlo deberían existir revisión técnica, pruebas de seguridad y arquitectura y, cuando la criticidad lo amerite, una segunda persona que revise la solución.
DESPUÉS ¿Cómo debería revisarse el rendimiento y la mantenibilidad del código generado?
La automatización no elimina áreas de revisión; puede volverlas más importantes. Equipos de QA, revisión técnica y pruebas ayudan a confirmar que la velocidad de generación no se convierta en velocidad para introducir errores. En sistemas con grandes volúmenes de información, por ejemplo, una consulta correcta puede seguir siendo costosa o difícil de mantener. La revisión debe mirar más allá de la salida inmediata y considerar cómo se comportará el componente cuando el sistema crezca.
DESPUÉS ¿Está cambiando el rol del programador?
Sí, hacia un nivel de abstracción mayor. Parte del tiempo que antes se dedicaba a escribir cada línea puede trasladarse a definir restricciones, diseñar soluciones, integrar componentes y validar resultados. Eso no vuelve prescindible al programador; vuelve más importante su criterio. La IA puede hacer a un buen profesional más productivo, pero también permite que un mal criterio produzca errores a una velocidad mucho mayor.
Automatizar la búsqueda de una solución no significa automatizar la definición del problema.
RESPONSABILIDAD ¿Por qué sigue siendo humana la definición de una buena solución?
Porque optimizar no equivale a comprender el propósito. Si una función de aptitud, una restricción o un objetivo están mal definidos, el algoritmo puede encontrar una solución técnicamente óptima para una pregunta equivocada. La máquina puede buscar, generar y optimizar; alguien debe establecer qué significa éxito, qué límites no pueden cruzarse y qué impacto es aceptable. Automatizar la búsqueda de una solución no automatiza la definición del problema.
CIERRE ¿Qué debería dominar un programador aunque una herramienta pueda generar casi cualquier implementación?
Lógica, fundamentos y capacidad de programar sin depender por completo del asistente. Luis insiste en que comprender algoritmos, estructuras, arquitectura y depuración sigue siendo necesario. Sobre esa base pueden añadirse agentes, automatización, inteligencia computacional o nuevas plataformas. La diferencia profesional no estará en negarse a usar IA, sino en poder utilizarla sin entregar a la herramienta el criterio con el que se juzga el sistema construido.
