La historia de la programación web se cuenta a menudo como una sucesión de herramientas: HTML, CSS, JavaScript, los gestores de contenido, los frameworks, la nube. Es una forma cómoda de ordenar el pasado, pero explica poco. Lo que cambia de verdad no es el editor ni el lenguaje: cambia la unidad de trabajo y cambia el cuello de botella.
En 1995, una página era un archivo que se editaba a mano y se subía por FTP. En 2015, era una aplicación con estado, componentes, compilación y despliegue continuo. En 2026, una parte creciente del trabajo se le encarga a un agente que lee archivos, ejecuta comandos y propone un cambio completo. El oficio no ha desaparecido; se ha desplazado hacia arriba.
Este artículo repasa esa evolución y separa tres cosas que suelen confundirse: el modelo, el agente y el harness. También explica qué acelera la IA, qué sigue siendo responsabilidad de una persona y por qué la revisión se ha convertido en la parte más cara del proceso.
La web antes de las herramientas
La primera web era artesanal en el sentido literal. Tim Berners-Lee describe un sistema de documentos enlazados, servidores y navegadores; el trabajo consistía en escribir HTML, enlazar páginas y publicar archivos. No había componentes, ni frameworks, ni una noción moderna de aplicación. La creatividad estaba en el contenido y en la estructura.
Ese modelo aguantó más de lo que parece. Durante los años noventa, una web corporativa era un conjunto de páginas estáticas con una navegación manual. El coste principal no era escribir código, sino mantener la información coherente y subir los cambios. La unidad de trabajo era la página; el cuello de botella, la edición manual y la coordinación.
La llegada de los gestores de contenido cambió el reparto. WordPress, Movable Type y sus contemporáneos separaron el contenido de la plantilla. Publicar dejó de requerir conocimientos de HTML. La web se volvió editable por personas que no programaban, y el trabajo técnico se concentró en temas, plugins, rendimiento y seguridad. La unidad de trabajo pasó a ser el artículo o la plantilla; el cuello de botella, la configuración y el mantenimiento.
Seis etapas, una misma pregunta
La línea de tiempo siguiente no es una cronología exhaustiva. Es una forma de ver cómo se ha movido el esfuerzo.
- 011991–1999
Documentos a mano
HTML, FTP y enlaces. Cada página era un archivo y cada cambio, una edición manual.
- 022000–2009
CMS y plantillas
WordPress y los gestores de contenido separan el texto del código. Publicar deja de ser programar.
- 032010–2019
Frameworks y componentes
React, Vue y los bundlers convierten la web en una aplicación. El estado y el rendimiento entran en la conversación.
- 042020–2022
Autocompletado inteligente
Copilot y los modelos de código sugieren líneas dentro del editor. La unidad de trabajo sigue siendo la función.
- 052023–2024
Chat y contexto
El modelo lee archivos, recibe instrucciones y propone cambios. La unidad de trabajo pasa a ser la tarea.
- 062025–2026
Agentes y harness
El agente ejecuta comandos, usa herramientas y verifica. La unidad de trabajo es el cambio completo, con revisión.
Hay un patrón en las seis etapas. Cada una añade abstracción y reduce el trabajo repetitivo, pero también añade una capa que hay que entender. Los frameworks resolvieron la manipulación del DOM y crearon problemas de estado, bundling y rendimiento. Los CMS resolvieron la publicación y crearon problemas de plugins, actualizaciones y seguridad. La IA resuelve la generación de código y crea problemas de revisión, confianza y deuda invisible.
| Etapa | Interfaz principal | Unidad de trabajo | Cuello de botella |
|---|---|---|---|
| Documentos a mano | Editor de texto y FTP | Página | Edición y publicación manual |
| CMS y plantillas | Panel web | Artículo o plantilla | Configuración, plugins, seguridad |
| Frameworks y componentes | Editor, terminal, navegador | Componente o aplicación | Estado, rendimiento, complejidad |
| Autocompletado | IDE | Línea o función | Confianza en la sugerencia |
| Chat con contexto | Chat e IDE | Tarea | Contexto y verificación |
| Agentes y harness | IDE, CLI, escritorio | Cambio completo | Revisión y criterio |
La tabla deja una idea incómoda: la IA no elimina el trabajo, lo mueve. Si antes se dedicaba tiempo a escribir boilerplate, ahora se dedica a describir el problema, comprobar el resultado y decidir si el cambio es correcto. La cantidad de código producido puede crecer mucho más rápido que la capacidad de revisarlo.
Qué es cada pieza
En las conversaciones sobre IA se mezclan cuatro conceptos que conviene separar. Un modelo es la red neuronal que genera texto o código a partir de un contexto. Un agente es un bucle que usa ese modelo para decidir acciones: leer un archivo, ejecutar un test, buscar en la web, editar el repositorio. Un harness es el entorno que pone las herramientas, los permisos y el estado alrededor del agente; puede ser una aplicación de escritorio, una CLI, una TUI o una extensión del editor. Y el producto es la web o la aplicación que se entrega.
- 01ProductoWeb, aplicación o herramienta
Lo que usa una persona y lo que tiene que funcionar.
- 02ProyectoRepositorio, pruebas, documentación
El estado real del trabajo: código, decisiones y verificación.
- 03HerramientasIDE, terminal, CI, preview
El entorno donde se escribe, se ejecuta y se revisa.
- 04HarnessBucle del agente y permisos
Lee, propone, ejecuta herramientas y comprueba el resultado.
- 05ModeloContexto, tokens y razonamiento
La pieza que genera, pero no la que decide el alcance.
La distinción importa porque muchas expectativas se colocan en la capa equivocada. Un modelo mejor no compensa un alcance mal definido. Un harness con muchas herramientas no sustituye las pruebas. Un agente que escribe rápido no sabe si el cambio rompe una factura, una cita o un cálculo de IVA.
También importa el contexto. Un modelo no ve el repositorio como lo ve una persona. Ve una ventana de tokens: los archivos que se le pasan, las instrucciones, el historial de la conversación y las salidas de las herramientas. Si el contexto está mal elegido, la respuesta puede ser plausible y estar equivocada. La calidad del contexto es una habilidad técnica, no un truco de prompting.
Lo que la IA cambia de verdad
La IA es especialmente buena en tres tareas que antes consumían tiempo de forma desproporcionada:
- Explorar alternativas. Puede proponer tres formas de modelar una entidad, dos estrategias de caché o una lista de casos límite. No decide cuál es correcta, pero amplía el espacio de búsqueda.
- Escribir código repetitivo. Formularios, validaciones, tipos, migraciones, pruebas de snapshot y adaptadores entre servicios. Es trabajo necesario y, a menudo, poco informativo.
- Explicar y documentar. Resumir un módulo, traducir un error, generar un README o describir un cambio en un pull request. La documentación sigue siendo responsabilidad de quien conoce el sistema, pero la IA reduce el coste de escribirla.
En un proyecto real, esto puede notarse en las primeras fases: crear la estructura, conectar un formulario, montar una página de administración o escribir las pruebas de un flujo sencillo. La velocidad de arranque aumenta. El riesgo es confundir velocidad de arranque con velocidad de entrega.
Lo que no cambia
Hay decisiones que siguen necesitando una persona con contexto y responsabilidad:
- Definir el problema. Qué se quiere cambiar, para quién, con qué restricciones y cómo se sabrá si funciona. Un agente puede hacer preguntas, pero no puede asumir el coste de una decisión equivocada.
- Diseñar la arquitectura. Qué datos se guardan, dónde viven, quién puede verlos, qué pasa cuando el servicio falla. La IA puede proponer, pero la elección tiene consecuencias.
- Proteger datos y accesos. Secretos, permisos, autenticación, copias, retención. Un error aquí no se arregla con un test unitario.
- Garantizar accesibilidad y rendimiento. Contraste, foco, navegación con teclado, tamaño de las imágenes, tiempo de carga. Son requisitos, no detalles estéticos.
- Revisar y responder. Alguien tiene que leer el cambio, entenderlo y firmar que está bien. La responsabilidad no se delega en un modelo.
La IA puede escribir una función que parece correcta y falla en el caso raro. Puede introducir una dependencia innecesaria, cambiar una firma sin actualizar a los llamantes o “arreglar” un test para que pase. Ninguna de esas cosas se detecta leyendo el mensaje del agente; se detecta con revisión, pruebas y un diff pequeño.
El nuevo cuello de botella es la revisión
Cuando generar código deja de ser el límite, el límite se mueve a la verificación. Un agente puede producir en minutos un cambio que antes costaba una tarde. Si ese cambio tiene 800 líneas y toca cinco módulos, la revisión puede costar más que haberlo escrito a mano. La ganancia desaparece.
Por eso los flujos que funcionan no optimizan la generación: optimizan la revisión. Dividen el trabajo en cambios pequeños, hacen que cada cambio tenga una prueba, ejecutan la compilación antes de abrir el diff y dejan por escrito qué se ha comprobado. La IA acelera el trabajo mecánico; la disciplina reduce el trabajo de revisión.
Hay una segunda trampa: el código generado se siente terminado antes de serlo. Tiene nombres plausibles, comentarios y una estructura coherente. Esa apariencia es útil para empezar y peligrosa para confiar. La pregunta correcta no es “¿parece bien?”, sino “¿qué evidencia tengo de que hace lo que debe?”.
Un flujo razonable en 2026
No hay una configuración universal, pero hay un patrón que reduce riesgos:
- Escribir el alcance. Un documento corto con el problema, lo que entra, lo que no y cómo se comprobará. Si el alcance no cabe en una página, probablemente hay que dividirlo.
- Aislar el trabajo. Una rama o un worktree por tarea. El agente no debería tener acceso a producción ni a datos reales durante la exploración.
- Dar contexto útil. Los archivos relevantes, las convenciones del proyecto y los comandos de prueba. Más contexto no siempre es mejor; el contexto correcto sí.
- Pedir cambios pequeños. Una tarea, un diff revisable. Si el agente necesita tocar diez archivos, conviene dividir la tarea antes de aceptar el resultado.
- Ejecutar la verificación. Tipos, pruebas, lint y una compilación real. La salida del agente no es evidencia; la salida del sistema sí.
- Revisar el diff. Buscar cambios no intencionados, dependencias nuevas, datos expuestos y casos límite. Si no se entiende, no se acepta.
- Probar en un entorno realista. Un preview con datos de prueba, navegación real y una comprobación visual. El código que compila no siempre se ve bien ni funciona.
Este flujo es más lento que “pedir y aceptar”. También es la diferencia entre usar IA como una herramienta y usarla como una fuente de deuda.
Qué significa para un estudio pequeño
Para un estudio independiente, la IA reduce el coste de ciertas tareas y aumenta la importancia del criterio. Un encargo pequeño puede permitirse una landing, una aplicación interna o una integración que antes no tenía sentido económico. Pero el estudio sigue respondiendo del resultado: si el formulario no envía, si la web no se ve en móvil o si los datos se pierden, el problema no es del modelo.
La consecuencia práctica es que el trabajo se organiza mejor. Menos tiempo escribiendo boilerplate, más tiempo definiendo el alcance, revisando y documentando. La entrega incluye el código, pero también las decisiones: por qué se eligió una arquitectura, qué se probó y qué queda pendiente. Esa documentación es lo que permite que el cliente no dependa de una conversación privada con una IA.
Conclusión
La web ha pasado de la página escrita a mano al cambio generado por un agente. Cada etapa ha añadido abstracción y ha movido el cuello de botella. La IA no es una excepción: acelera la producción y traslada el esfuerzo a la definición, la verificación y la responsabilidad.
Programar con IA no consiste en escribir menos. Consiste en decidir mejor qué se escribe, qué se prueba y qué se acepta. El modelo es una pieza; el oficio sigue estando en el criterio que lo rodea.
Comentarios
Conversación
Los comentarios se apoyan en GitHub Discussions. Para participar necesitas una cuenta de GitHub. Al cargar el hilo, GitHub puede usar cookies y tratar tu cuenta según su política. Más información.