La IA Ya Puede Crear Sitios Web. Entonces, ¿Por Qué Seguimos Necesitando Desarrolladores?

Subestimar las herramientas actuales sería un error. La Inteligencia Artificial ya puede participar prácticamente en todo el ciclo de desarrollo. Puede ayudar a:

• Crear interfaces
• Transformar diseños en componentes
• Generar código frontend y backend
• Estructurar APIs
• Crear modelos de datos
• Escribir pruebas
• Producir documentación
• Sugerir infraestructura
• Identificar posibles bugs
• Refactorizar código
• Generar scripts
• Investigar alternativas técnicas
• Explicar bases de código existentes
• Crear prototipos funcionales

Para determinadas tareas, algo que antes tomaba horas ahora puede producirse en minutos. El impacto es real.

La conclusión equivocada es imaginar que, como producir código se volvió más fácil, el desarrollo profesional también se volvió trivial. No fue así. Lo que cambió fue la distribución del trabajo. Cuanto más fácil se vuelve producir código, más importante se vuelve saber qué código debería existir, por qué debería existir y qué consecuencias puede generar esa implementación.

No necesariamente. Cualquier persona puede pedirle a una IA que cree una página. Eso es diferente de saber:

• Qué arquitectura utilizar
• Cuánto JavaScript es realmente necesario
• Dónde debe ocurrir determinado procesamiento
• Cómo proteger los datos
• Cómo modelar la autenticación y la autorización
• Cómo estructurar el contenido para los motores de búsqueda
• Cómo evitar dependencias innecesarias
• Cómo mantener un buen desempeño
• Cómo garantizar la accesibilidad
• Cómo planificar el crecimiento
• Cómo monitorear errores
• Cómo actualizar el sistema con seguridad
• Cómo evitar la deuda técnica

Esa diferencia no siempre aparece en una demostración. Una página puede tener un diseño bonito, animaciones agradables y botones que funcionan y, aun así, esconder problemas importantes.

Lo que aparece en la pantalla es solo una parte del producto:

Esa es una de las razones por las que comparar el desarrollo solo por el resultado visual puede llevar a conclusiones equivocadas.

Existe una diferencia importante entre:

• Que el código se ejecute
• Que la funcionalidad aparentemente funcione
• Que la solución sea técnicamente adecuada

Una autenticación puede funcionar y aun así haber sido implementada de forma insegura. Una página puede renderizarse correctamente para un usuario y ser problemática para los rastreadores. Una imagen puede verse perfecta y, al mismo tiempo, perjudicar la carga de la página. Una biblioteca puede resolver el problema de inmediato y crear una dependencia completamente innecesaria. Una aplicación puede funcionar bien con cien usuarios y presentar dificultades importantes cuando el volumen aumenta.

Aquí es donde entran en juego la experiencia y la ingeniería.

El desempeño es más que “se siente rápido”. Google usa las Core Web Vitals para evaluar aspectos concretos de la experiencia, incluyendo carga, capacidad de respuesta y estabilidad visual. Como referencia técnica, los rangos considerados buenos son un LCP de hasta 2,5 segundos, un INP de hasta 200 milisegundos y un CLS de hasta 0,1, evaluados en el percentil 75 de las visitas. Esto significa que “cargó rápido en la computadora del desarrollador” no es un criterio suficiente.

Es necesario considerar, entre otros factores:

• Tamaño de las imágenes
• Carga de fuentes
• JavaScript enviado al navegador
• Llamadas de red
• Caché
• Estrategia de renderización
• Recursos que bloquean la página
• Comportamiento en dispositivos móviles
• Estabilidad del layout
• Velocidad de respuesta a las interacciones

Los problemas de seguridad también suelen ser invisibles durante una demostración. La versión 2025 del OWASP Top 10, referencia internacional de concientización sobre seguridad de aplicaciones web, incluye riesgos como control de acceso roto, configuración insegura, fallas en la cadena de suministro, fallas criptográficas, inyección y problemas de autenticación.

Que un formulario envíe datos correctamente no significa que su implementación sea segura. Que un login funcione no significa que la autorización, la gestión de sesión y la protección de la información sean correctas. Que una API responda no significa que los usuarios solo puedan acceder a lo que deberían. Que una dependencia funcione no significa que debería formar parte de la aplicación.

Un sitio profesional no debería pensarse solo para quien navega con mouse, ve perfectamente la pantalla y usa un dispositivo reciente.

Las WCAG, desarrolladas por la Web Accessibility Initiative del W3C, son un estándar internacional para hacer que los sitios, aplicaciones y otros contenidos digitales sean más accesibles para personas con discapacidad. La especificación contempla los niveles A, AA y AAA, y el propio W3C destaca el nivel AA como un objetivo adoptado por muchas organizaciones.

En la práctica, esto implica decisiones sobre:

• HTML semántico
• Navegación por teclado
• Foco
• Contraste
• Textos alternativos
• Formularios
• Mensajes de error
• Estructura de encabezados
• Componentes interactivos
• Compatibilidad con tecnologías asistivas

Generar una interfaz visualmente bonita no garantiza ninguna de estas características.

Los errores evidentes son relativamente fáciles de notar. Si la aplicación no inicia, hay una señal. Si el código no compila, hay una señal. Si un botón no funciona, hay una señal.

El problema más difícil aparece cuando la respuesta es:

• Convincente
• Organizada
• Aparentemente sofisticada
• Funcional en un análisis superficial
• Técnicamente inadecuada

Este tipo de resultado crea una falsa sensación de competencia. Una persona sin bagaje técnico puede mirar la implementación y concluir: “Funcionó. Entonces está bien.”

Un profesional experimentado probablemente empezará a hacer otras preguntas:

• ¿Por qué se está usando esta biblioteca?
• ¿Realmente necesitamos esta dependencia?
• ¿Este dato debería estar disponible en el frontend?
• ¿Esta autenticación está ocurriendo en el lugar correcto?
• ¿El usuario puede manipular esta información?
• ¿Esta página realmente necesita ser totalmente client-side?
• ¿Por qué hacemos tres solicitudes cuando podríamos hacer una?
• ¿Esta abstracción es necesaria?
• ¿Existe una solución más simple?
• ¿Cómo funciona este comportamiento sin JavaScript?
• ¿Cómo se comporta esta implementación con un error de red?
• ¿El contenido es accesible para los motores de búsqueda?
• ¿El componente funciona con teclado?
• ¿Cómo vamos a monitorear una falla en producción?
• ¿Qué pasa si necesitamos cambiar esta regla dentro de seis meses?

Saber orientar a una IA es útil. Aportar contexto, criterios, restricciones, ejemplos y objetivos mejora considerablemente la calidad de las respuestas. Pero hay una diferencia enorme entre saber pedir y saber evaluar.

Un prompt elaborado como “Actúa como un ingeniero de software sénior con 30 años de experiencia y crea la mejor arquitectura posible” no convierte automáticamente a quien recibió la respuesta en arquitecto de software.

El problema no está en el prompt. Está en imaginar que una respuesta convincente elimina la necesidad de validación.

El diferencial profesional aparece después de la respuesta. Un desarrollador experimentado puede mirar un resultado producido por IA y concluir:

• Esto es correcto
• Esto funciona, pero es excesivamente complejo
• Esto viola una decisión arquitectónica del proyecto
• Esta solución es insegura
• Esta dependencia no es necesaria
• Este código debería estar en el servidor
• Esto puede crear un cuello de botella
• Esta abstracción todavía no tiene sentido
• Esta solución dificulta las pruebas
• Esta estructura no combina con el resto de la aplicación
• Esto necesita validarse antes de pasar a producción

Imagina a dos personas usando exactamente la misma herramienta.

La Persona A, con poco o ningún conocimiento técnico, hace un pedido simple: “Crea un sitio institucional moderno usando React.” La IA genera un proyecto. La persona abre el navegador. La página se ve bonita. Los menús funcionan. Hay una animación al hacer scroll. En el celular, aparentemente todo está bien. Para esta persona, el trabajo puede parecer terminado.

La Persona B, una profesional experimentada, probablemente investigaría incluso antes de decidir si React es necesario:

• ¿Cuál es el objetivo del sitio?
• ¿Quiénes son los usuarios?
• ¿Cuál es la estrategia de adquisición?
• ¿Cuánto contenido se publicará?
• ¿Con qué frecuencia cambia?
• ¿Existe un área con inicio de sesión?
• ¿Qué integraciones serán necesarias?
• ¿Es un sitio institucional o una aplicación?
• ¿Cuánto JavaScript necesita realmente el proyecto?
• ¿El contenido necesita renderizarse en el servidor?
• ¿Existe un CMS?
• ¿Quién hará las actualizaciones?
• ¿Cuál es la expectativa de tráfico?
• ¿Existen requisitos de seguridad o privacidad?
• ¿Qué métricas hay que monitorear?

Después vendrían decisiones sobre:

• Arquitectura
• Framework
• Renderización
• Caché
• Imágenes
• Semántica HTML
• Responsividad
• Accesibilidad
• SEO técnico
• Datos estructurados
• Analytics
• Observabilidad
• Infraestructura
• Deploy
• Mantenimiento

Esta persona también puede usar IA intensamente. La diferencia es que la herramienta está inserta en un proceso de ingeniería.

Una de las mejores formas de entender la IA en el desarrollo es tratarla como un multiplicador. En manos de profesionales capacitados, puede acelerar:

• Prototipado
• Investigaciones técnicas
• Boilerplate
• Creación inicial de componentes
• Documentación
• Pruebas
• Refactorizaciones
• Análisis de código
• Investigación de bugs
• Migraciones
• Creación de scripts
• Comparación entre enfoques
• Revisión inicial de accesibilidad
• Optimizaciones de desempeño

Pero los multiplicadores funcionan en ambos sentidos. Cuando nadie tiene el conocimiento suficiente para revisar el resultado, esa misma velocidad puede acelerar:

• Malas decisiones arquitectónicas
• Vulnerabilidades
• Dependencias innecesarias
• Complejidad
• Código duplicado
• Abstracciones inadecuadas
• Problemas de mantenimiento
• Deuda técnica
• Soluciones frágiles

Cuanto mayor es la capacidad de producir, mayor se vuelve también la importancia de revisar lo que se está produciendo.

Negar este cambio también sería un error. Hay actividades que antes consumían una parte considerable del tiempo de desarrollo y que ahora pueden acelerarse significativamente, por ejemplo:

• Creación de boilerplate
• Componentes iniciales
• Pruebas básicas
• Tipos
• Documentación
• Scripts
• Pequeñas refactorizaciones
• Investigación de APIs
• Explicaciones de código
• Conversión de estructuras

Esto modifica el centro de valor de la profesión. El desarrollador deja de ser evaluado solo por la velocidad con la que produce líneas de código. Ganan aún más importancia:

• La capacidad de comprender problemas
• Arquitectura
• Modelado
• Visión de producto
• Conocimiento del negocio
• Toma de decisiones
• Evaluación de trade-offs
• Seguridad
• Revisión
• Integración
• Pruebas
• Mantenimiento

En un proceso maduro, la IA no sustituye las etapas de ingeniería. Participa en ellas.

• 1. Descubrimiento: Antes de escribir código, es necesario comprender el problema, los objetivos, el público, las funcionalidades, los recorridos, las integraciones, las restricciones, las reglas de negocio y los requisitos técnicos. Una IA puede ayudar a organizar el brief, pero no debería determinar por sí sola cuáles son las prioridades del negocio.

• 2. Arquitectura: Hay que definir el stack, la estructura de la aplicación, la estrategia de renderización, las APIs, la persistencia de datos, la autenticación, la autorización, la infraestructura y las integraciones. La IA puede sugerir alternativas, pero el profesional necesita evaluar los trade-offs.

• 3. UX y UI: Entran decisiones sobre jerarquía de la información, navegación, flujos, responsividad, componentes, estados, errores, accesibilidad e identidad visual. La IA puede acelerar la producción, pero la experiencia sigue necesitando planificarse para personas reales.

• 4. Desarrollo asistido: La IA puede participar activamente en la implementación — generar componentes, crear estructuras iniciales, sugerir pruebas, documentar, refactorizar, explicar errores y proponer alternativas. Aquí es donde la ganancia de productividad se ve más claramente.

• 5. Code review y validación humana: El código generado por IA debe tratarse como código: necesita ser analizado. Las preguntas importantes incluyen si es correcto, seguro, si sigue la arquitectura, si es necesario, si podría ser más simple, si es testeable, sostenible, si introduce nuevas dependencias y si genera deuda técnica.

• 6. QA y pruebas: Es necesario validar los flujos principales, los edge cases, los formularios, los errores, las integraciones, la responsividad, distintos navegadores, la accesibilidad y las reglas de negocio.

• 7. Desempeño: Evaluar las Core Web Vitals, el peso de las páginas, las imágenes, el JavaScript, el caché, las fuentes, la renderización y las llamadas de red.

• 8. Seguridad: Revisar la autenticación, la autorización, la exposición de información, la validación de entradas, las dependencias, las configuraciones, el manejo de errores, los logs y las superficies de ataque.

• 9. SEO y GEO: Aquí también hay una diferencia importante entre “tener algunas etiquetas” y contar con una arquitectura adecuada. Google recomienda prestar atención específica a los sitios basados en JavaScript, ya que existen diferencias y limitaciones en la forma en que los rastreadores acceden y renderizan las aplicaciones, además de URLs rastreables, sitemaps e implementación adecuada de URLs canónicas. Un proyecto puede necesitar considerar HTML semántico, títulos, descriptions, URLs, canonical, sitemap, robots, enlaces internos, estrategia de renderización, contenido rastreable, datos estructurados, jerarquía de información, contexto semántico, entidades y respuestas claras y autocontenidas. Los datos estructurados ayudan a los motores de búsqueda a comprender mejor el significado de una página, pero incluso una implementación técnicamente correcta no garantiza aparecer en resultados enriquecidos. De la misma manera, el GEO no debe tratarse como una promesa de citación por parte de sistemas de IA — consiste en hacer que el contenido, el contexto y las entidades sean más explícitos, estructurados y recuperables.

• 10. Deploy y observabilidad: Poner el sitio en producción no termina el desarrollo. Hay que pensar en entornos, logs, métricas, alertas, errores, backups, rollback, actualizaciones, dependencias y monitoreo. Un producto profesional necesita ofrecer formas de descubrir cuándo algo no está funcionando.

La conclusión no es que la IA sea poco útil. Es prácticamente lo contrario.

Porque una Software House no debería vender tecleo de código. Debería entregar la capacidad de transformar un problema de negocio en un producto tecnológico confiable. Esto involucra:

• Diagnóstico
• Planificación
• Experiencia
• Decisiones
• Arquitectura
• Diseño
• Ingeniería
• Integración
• Pruebas
• Seguridad
• Desempeño
• Validación
• Continuidad
• Mantenimiento
• Responsabilidad técnica

La IA puede participar en todas estas actividades. Pero el cliente no debería tener que descubrir por su cuenta:

• Qué herramienta elegir
• Qué código aceptar
• Qué respuestas están equivocadas
• Qué riesgos están ocultos
• Cuándo una implementación necesita rehacerse

Ese es justamente uno de los roles del equipo especializado.

Es una pregunta legítima. Si ciertas tareas se volvieron más rápidas, ¿por qué eso no significa simplemente cobrar menos? Porque el cliente no está comprando horas de tecleo. Está comprando un resultado.

La herramienta hizo el trabajo más productivo. No eliminó la necesidad de:

• Comprender el terreno
• Calcular
• Planificar
• Tomar decisiones
• Respetar los requisitos
• Identificar riesgos
• Asumir la responsabilidad por el proyecto

Lo mismo ocurre en el desarrollo. Si una herramienta reduce seis horas de trabajo repetitivo, esa ganancia puede convertirse en:

• Más validación
• Más pruebas
• Más refinamiento
• Mejor documentación
• Más análisis
• Entregas más rápidas
• Investigación de alternativas
• Mayor capacidad del equipo

El valor debería analizarse por el resultado obtenido, no por la cantidad de caracteres tecleados manualmente.

La pregunta más útil tal vez ni siquiera sea “¿ustedes usan IA?”. Hoy, el uso de estas herramientas tiende a volverse cada vez más común. Las preguntas más importantes serían:

• ¿Cómo se revisa el código generado?
• ¿Quién decide la arquitectura antes de la implementación?
• ¿Cómo se validan la seguridad y el control de acceso?
• ¿Qué criterios de desempeño se monitorean?
• ¿Cómo se considera la accesibilidad?
• ¿Cómo se planifican el SEO técnico, la renderización y la rastreabilidad?
• ¿Existen pruebas para los flujos críticos?
• ¿Cómo se monitorean los errores en producción?
• ¿Cómo se evalúan las dependencias externas?
• ¿Quién asume la responsabilidad técnica por las decisiones?

Estas preguntas cambian la discusión. En vez de evaluar si un equipo usa o no una herramienta moderna, se evalúa la madurez del proceso en el que esa herramienta está inserta.

En Zion, la Inteligencia Artificial no necesita tratarse como sustituta de la ingeniería. Puede usarse justamente para ampliar la capacidad de los profesionales involucrados en el proyecto.

Esto significa reducir el esfuerzo en actividades operativas y aumentar el espacio disponible para lo que realmente determina la calidad del producto:

• Análisis
• Arquitectura
• Decisiones
• Pruebas
• Revisión
• Seguridad
• Desempeño
• Experiencia
• Estrategia

La propuesta no es elegir entre IA y profesionales. Es combinar ambas capacidades.

Probablemente esa sea la pregunta equivocada. En el desarrollo de software, la diferencia relevante tiende a estar menos entre humanos vs. IA y más entre profesionales que aprendieron a usar la IA de forma crítica vs. profesionales que no incorporaron estas herramientas a su proceso.

La Inteligencia Artificial ya está cambiando cómo se planifica, se escribe, se prueba, se documenta y se mantiene el software. Esa transformación probablemente continuará.

Pero existe una consecuencia interesante: cuanto mayor es la velocidad de producción, mayor pasa a ser la cantidad de decisiones que pueden tomarse en poco tiempo. Y, en consecuencia, mayor es la importancia de saber qué decisiones tienen sentido.

• ¿La IA ya puede crear un sitio web completo? Sí. Las herramientas de IA pueden generar interfaces, componentes, código frontend y backend, y partes importantes de una aplicación. Sin embargo, eso no significa que la arquitectura, la seguridad, el desempeño, la accesibilidad, el SEO y el mantenimiento estén automáticamente correctos. El resultado debe evaluarse según los requisitos del proyecto.

• ¿Cualquier persona puede crear un sitio usando IA? Cualquier persona puede usar herramientas de IA para generar páginas y aplicaciones. La diferencia está en la capacidad de determinar si la solución cumple con criterios profesionales, identificar problemas y corregir decisiones inadecuadas.

• ¿La IA va a sustituir a los desarrolladores? La IA ya está transformando muchas actividades de la profesión, especialmente tareas repetitivas y la producción inicial de código. El efecto más claro es un cambio en el centro de valor del desarrollador, con más importancia para la arquitectura, el contexto, la revisión, la seguridad y la toma de decisiones.

• ¿El código generado por IA es seguro? No existe una garantía automática. El código generado por IA debe revisarse, probarse y validarse como cualquier otro código usado en una aplicación profesional.

• ¿Los sitios desarrollados con IA son peores? No necesariamente. Cuando se usa dentro de un proceso de ingeniería bien estructurado, la IA puede aumentar la productividad y apoyar mejoras de calidad. El riesgo surge cuando los resultados se usan sin una evaluación adecuada.

• ¿Los desarrolladores necesitan aprender a usar IA? Las herramientas de IA se están volviendo una parte relevante de los flujos de desarrollo. Más importante que simplemente saber usarlas es aprender a aportar contexto, evaluar resultados y reconocer cuándo una sugerencia no es adecuada.

• ¿Qué diferencia a un desarrollador de alguien que solo genera código con IA? Principalmente la capacidad de comprender el contexto, diseñar arquitecturas, evaluar trade-offs, identificar riesgos, revisar implementaciones, probar hipótesis y asumir la responsabilidad técnica por el resultado.

• Si la IA crea código rápidamente, ¿por qué contratar una Software House? Porque el desarrollo profesional no consiste solo en producir código. Una Software House también entrega diagnóstico, arquitectura, integración, calidad, seguridad, validación, mantenimiento y responsabilidad por el producto construido.

• OWASP — Top 10 Web Application Security Risks 2025
• W3C WAI — Pautas de Accesibilidad para el Contenido Web (WCAG)
• web.dev — Core Web Vitals
• Google Search Central — Understand JavaScript SEO Basics
• Google Search Central — Introduction to Structured Data Markup
• Google Search Central — Optimización para funciones de IA generativa