Carson Gross, creador de htmx, confía en el futuro de los programadores: los dos pilares de la profesión

Carson Gross, creador de la biblioteca htmx, ha reducido la programación a dos puntos y sobre ellos construye un pronóstico: las herramientas de IA no acabarán con la profesión. Simon Willison destacó en una entrada aparte una cita de su ensayo «Yes, and...», publicado en htmx.org, y esta se difundió rápidamente en los círculos profesionales. Es una declaración breve, pero encaja bien en los debates sobre quién necesita desarrolladores cuando son los modelos quienes escriben el código.

Dos tareas en lugar de una lista de tecnologías

Gross define la programación a través de dos cosas. La primera: resolver problemas con ayuda de ordenadores. La segunda: aprender a controlar la complejidad que surge en el curso de esas soluciones. En su definición no aparecen lenguajes ni frameworks, ni tampoco la palabra «código» entendida como un conjunto de líneas. Describe el oficio por su resultado y por su disciplina.

A continuación llega una conclusión prudente. Gross escribe que le cuesta imaginar un futuro en el que la capacidad de resolver tareas con un ordenador y mantener bajo control la complejidad de las soluciones se valore menos que hoy. Por eso, en su opinión, la profesión seguirá siendo viable después de la aparición de las herramientas de IA. Es una apuesta por la solidez de la habilidad, no una predicción sobre el número de vacantes ni el nivel salarial.

Por qué el énfasis en la complejidad

El segundo punto de esta fórmula es más interesante que el primero. Los modelos de lenguaje resuelven bien las tareas locales: una función, una prueba, una migración, una configuración. Pero cada fragmento generado aumenta la base de código, y toda base de código acaba acumulando con el tiempo dependencias, convenciones y excepciones. ¿Quién se encarga de que el sistema siga siendo comprensible dentro de un año, cuando la mitad del código se haya escrito a partir de sugerencias? Gross responde: quien sabe gestionar la complejidad. Mientras el modelo no asuma por completo esa responsabilidad, la demanda de esa persona se mantiene.

El contexto del autor también importa. Gross es conocido como creador de htmx, una biblioteca que construye interfaces en torno al hipertexto y reduce de forma deliberada el volumen de código del lado del cliente. Para él, la complejidad es un enemigo constante, y su postura parece una prolongación de esa filosofía. El ensayo original no se reproduce íntegro en el material, así que nos limitamos a lo que dice la cita.

Tesis clave

• La programación, según Gross, consta de dos componentes: resolver problemas con ayuda de ordenadores y gestionar la complejidad.
• El valor de estas habilidades, en su valoración, no disminuirá en un futuro previsible.
• Considera las herramientas de IA un complemento de la profesión, no su sustituto. Así lo indica también el título del ensayo, «Yes, and...».
• La tesis se formula como una opinión personal del autor y no se apoya en cifras del mercado laboral.
• La cita la publicó Simon Willison con las etiquetas computer-science, careers y ai.

Qué deberían hacer desarrolladores y equipos

La principal conclusión práctica afecta a la formación y la contratación. Si el valor está en plantear el problema y controlar la complejidad, conviene invertir en pensamiento arquitectónico, lectura de código ajeno, descomposición de tareas y capacidad para renunciar a lo superfluo. Los modelos sugieren sintaxis y API con rapidez, pero la decisión sobre qué construir y cómo mantenerlo, de momento, la siguen dejando en manos de las personas.

Para los responsables de equipo, es un motivo para revisar las métricas. El volumen de código generado dice poco. Resulta más útil observar con qué rapidez una persona nueva se orienta en el sistema, cuánto tiempo lleva introducir un cambio y cuántas dependencias añadió la última versión. Para quienes empiezan, el consejo es sencillo: usar herramientas de IA, pero analizar cada solución hasta ser capaz de explicarla sin ayuda.

La cita de Gross no demuestra que el mercado laboral vaya a soportar la presión, y él tampoco insiste en ello. Propone un criterio: mientras se exija al desarrollador resolver problemas y mantener a raya la complejidad, la profesión hace falta. Ese criterio habrá que comprobarlo en la práctica.