Actualizado el 17 de agosto de 2026. El desarrollo web con ChatGPT puede acelerar una primera propuesta de HTML, CSS y JavaScript, pero el código generado no debe considerarse correcto, seguro, accesible ni listo para producción sin pruebas. Para aportar evidencia propia, congelamos un brief y una rúbrica, ejecutamos tres solicitudes independientes y publicamos las entradas, salidas sin editar, pruebas, capturas, entorno y checksums.
Respuesta corta: en la reevaluación corregida v1.0.2, las tres salidas superaron las 36 reglas automatizadas previstas para este componente: 3/3 salidas aceptadas y 108/108 reglas aprobadas. La corrección del evaluador se hizo después de recibir las respuestas, no estaba preregistrada y no implicó nuevas llamadas a la API ni cambios en el código generado. El resultado describe este brief, estos fixtures y esta fecha; no certifica accesibilidad, seguridad ni preparación para producción.
Qué significa “desarrollo web con ChatGPT” en esta prueba
La expresión describe el uso de un modelo como asistente para proponer código. Esta ejecución no se hizo en la interfaz de consumo de ChatGPT: usamos la Responses API con el identificador solicitado y devuelto gpt-5.6-sol. Producto, API, modelo, parámetros, herramientas y contexto son variables distintas y pueden cambiar el resultado.
El modelo recibió el mismo brief en español neutro, los criterios de aceptación y una referencia visual original en cada repetición. No recibió la implementación del evaluador. Cada respuesta se materializó como index.html, styles.css y app.js, y los candidatos se evaluaron sin reparaciones humanas ni selección de una salida ganadora.
Para especificaciones, precios y contexto del identificador usado, consulta nuestra ficha independiente de GPT-5.6. Las observaciones de esta página proceden del paquete de la prueba y no sustituyen la documentación oficial del proveedor.
El brief original del componente
Diseñamos un ejercicio pequeño y ficticio para que cada requisito pudiera comprobarse. El objetivo era crear un explorador de recursos didácticos en español neutro, no imitar una página real ni medir un proyecto completo.
Entregables y restricciones
- Solo HTML, CSS y JavaScript nativos, sin framework, compilador ni dependencia de ejecución.
- Seis tarjetas visibles desde el HTML, incluso si JavaScript no está disponible.
- Sin solicitudes de red, fuentes remotas, analítica, cookies,
localStorageni formularios que envíen datos. - Búsqueda que ignore mayúsculas y acentos y se combine con filtros de HTML, CSS y JavaScript.
- Un contador anunciado mediante
aria-live, estado de filtros conaria-pressedy nombres de enlace distinguibles. - Una, dos y tres columnas a 320, 768 y 1280 píxeles, sin desplazamiento horizontal.
- Objetivos táctiles acordes con WCAG 2.2 SC 2.5.8: al menos 24 × 24 píxeles CSS o espacio suficiente, con sus excepciones definidas, además de foco visible.
- La entrada escrita en el buscador no debía interpretarse como HTML.
El contenido exacto incluía el título “Explora recursos para aprender”, seis recursos ficticios y el mensaje “No encontramos recursos con esos filtros.” cuando no hubiera coincidencias. También fijamos IDs y atributos del DOM para evitar que una implementación válida fallara por selectores ambiguos.
Cómo reproducir la prueba
Antes de la primera solicitud congelamos el prompt, la referencia, el esquema de salida, la configuración, el evaluador y sus dependencias. El manifiesto anterior a la ejecución tiene SHA-256 efa6a2fdb5bf1339f09029f4f6472b1099d9e575d60c52add038a3449b74e101. El protocolo congelado y el manifiesto previo permiten comprobar qué estaba definido antes de ver las respuestas.
| Campo | Valor ejecutado |
|---|---|
| API | POST /v1/responses |
| Modelo solicitado y devuelto | gpt-5.6-sol |
| Repeticiones | 3 solicitudes independientes; un intento pagado por repetición y sin reintentos |
| Razonamiento | low |
| Límite de salida | 7000 tokens |
| Herramientas y navegación | Ninguna |
| Otros parámetros | store: false, stream: false, detalle de imagen high y timeout de 180.000 ms |
| Ventana de ejecución | 17 de agosto de 2026, 16:58:59–17:00:41 UTC |
Las tres respuestas canónicas y sus metadatos se conservaron. store: false fue un parámetro de estas solicitudes, pero no equivale por sí solo a Zero Data Retention; el tratamiento aplicable depende de los controles oficiales de datos y de la configuración de la cuenta.
Archivos para repetir y auditar
- Registro público de Zenodo y DOI citable.
- Paquete ZIP versionado y checksums compuestos SHA-256.
- Resultado de cada regla en CSV y informe corregido v1.0.2.
- Guía de interpretación y secuencia de correcciones.
Qué debe comprobarse en el prototipo
| Área | Comprobación mínima | Evidencia necesaria |
|---|---|---|
| Función | Búsqueda, filtros, estado vacío y navegación por teclado | Pruebas ejecutables y registro de resultados |
| Responsive | Reflujo, desbordamiento y legibilidad en varios anchos | Capturas o mediciones del navegador |
| Accesibilidad | Semántica, foco, teclado, zoom, contraste y objetivos táctiles | Herramienta automática más revisión manual |
| Seguridad | Tratamiento de entrada, dependencias y ausencia de secretos | Revisión del código y pruebas específicas |
| Rendimiento | Peso, carga e interacción | Mediciones fechadas en un entorno identificado |
Una búsqueda literal en CSS no demuestra conformidad y una medición aislada no sustituye las excepciones del criterio aplicable. La rúbrica, el código y los resultados de este prototipo pueden auditarse en el registro público de Zenodo enlazado a continuación.
Resultados observados en tres ejecuciones independientes
Las tres solicitudes terminaron con estado completed y devolvieron candidatos evaluables. La tabla muestra los resultados de la reevaluación corregida v1.0.2, no la salida histórica inválida del evaluador v1.0.0.
| Ejecución | Reglas | Latencia | Tokens entrada / salida / razonamiento | Coste estimado |
|---|---|---|---|---|
| r1 | 36/36 | 32.998 ms | 2.079 / 3.325 / 179 | 0,112740 USD |
| r2 | 36/36 | 34.061 ms | 2.079 / 3.311 / 260 | 0,100383 USD |
| r3 | 36/36 | 34.908 ms | 2.079 / 3.252 / 239 | 0,098613 USD |
| Total | 108/108 | p50: 34.061 ms; p95 por rango más cercano: 34.908 ms | 6.237 / 9.888 / 678 | 0,311736 USD |
Las 36 reglas por candidato cubrieron el contrato del contenido y del DOM, búsqueda y filtros, estados, teclado y foco observable, una comprobación axe limitada, ausencia de solicitudes externas y errores de consola, tratamiento como texto de un fixture similar a XSS, JavaScript deshabilitado y diseño a 320, 768 y 1280 píxeles. Aprobar una regla significa superar ese fixture, no demostrar una propiedad universal.
El coste total es una estimación calculada con el uso devuelto y el precio oficial archivado el 17 de agosto de 2026; no es una factura ni una promesa de coste futuro. La latencia también depende de la carga, la ruta, el contexto y la infraestructura.
Fe de erratas del evaluador
El evaluador congelado v1.0.0 rechazó inicialmente las tres salidas, aprobó 3 reglas, marcó 3 como fallidas y dejó 102 sin ejecutar. La causa fue un falso positivo: una expresión regular sin distinguir mayúsculas y minúsculas confundió callbacks ordinarios escritos con function () con el constructor dinámico Function(...). Ningún candidato contenía eval(...), Function(...) ni new Function(...). Por tanto, el 0/3 original es una salida histórica inválida del evaluador, no un fallo observado del modelo.
La corrección v1.0.1 arregló ese patrón. Una auditoría posterior detectó además dos supuestos del evaluador que el prompt no exigía: tratar el primer párrafo de cada tarjeta como descripción y exigir un texto literal para la etiqueta del buscador cuando el brief solo pedía una etiqueta accesible no vacía. La v1.0.2 corrigió esos dos supuestos y volvió a ejecutar las 108 reglas.
Estas correcciones fueron posteriores a la ejecución y no estaban preregistradas. No se hicieron nuevas llamadas a la API, no se editaron respuestas ni candidatos y no se eligió una salida ganadora. El registro de Zenodo conserva las capas v1.0.0, v1.0.1 y v1.0.2, sus parches, pruebas de regresión, límites de integridad y checksums. Consulta la secuencia completa de correcciones antes de interpretar el resultado.
Qué sigue pendiente de verificar
La rúbrica congelada no dejó reglas automáticas sin ejecutar en la reevaluación v1.0.2. Aun así, una suite corta no cubre todo lo necesario para una aplicación real. Queda pendiente, como mínimo:
- pruebas con lectores de pantalla, tecnologías de asistencia, personas usuarias y tareas reales;
- zoom al 200 %, alto contraste del sistema, dispositivos físicos y una matriz de navegadores distinta de Chromium;
- backend, autenticación, autorización, base de datos, carga de archivos, dependencias y tratamiento de datos reales;
- modelo de amenazas, revisión de seguridad de producción, pruebas de carga y observación de red en un despliegue real;
- mantenibilidad, internacionalización, contenido extremo, calidad visual con criterios humanos y ciclos de reparación.
La activación por teclado, el foco observable, axe, el modo sin JavaScript, la red y la consola sí se comprobaron dentro de los fixtures publicados. Esos aprobados no sustituyen las revisiones manuales anteriores.
Flujo práctico para usar ChatGPT en desarrollo web
La parte valiosa no es pedir “crea una web” y copiar la respuesta. Un flujo útil separa especificación, generación, verificación y decisión humana.
- Define un problema pequeño. Describe usuarios, tarea, contenido, estados vacíos, errores y datos permitidos.
- Convierte requisitos en criterios observables. Por ejemplo: “a 320 px no existe overflow” es comprobable; “diseño perfecto” no lo es.
- Fija el contrato técnico. Indica archivos, framework o ausencia de él, navegadores, restricciones de red, API y estructura del DOM cuando sea necesaria.
- Proporciona una referencia autorizada. Usa un mockup propio y explica qué parte es orientación visual y qué parte es requisito exacto.
- Guarda la primera salida sin editar. Así puedes medir qué produjo el modelo y no confundir una reparación humana con capacidad original.
- Ejecuta pruebas antes de reparar. HTML válido, funciones, responsive, accesibilidad automatizable, consola, red, seguridad y pruebas del backend.
- Entrega al modelo solo fallos reproducibles. Incluye el criterio, el comportamiento observado y un caso mínimo; vuelve a ejecutar toda la suite tras cada cambio.
- Haz revisión humana. Comprueba lenguaje, experiencia, teclado, lector de pantalla, datos, amenazas y mantenimiento.
- Decide si se integra. Reescribe o descarta el código cuando sea más seguro que seguir reparando una propuesta frágil.
Plantilla de prompt para un componente verificable
Esta estructura ayuda a reducir ambigüedad. Debe adaptarse al proyecto y no contiene una promesa de que el resultado superará las pruebas.
Objetivo:
Construye [componente] para [usuario y tarea].
Entregables:
- [archivos exactos]
- [framework o HTML/CSS/JS nativos]
Contenido y estados:
- [texto exacto]
- carga, vacío, error y éxito
Comportamiento verificable:
- [acción] debe producir [resultado]
- a 320, 768 y 1280 px debe [criterio]
Accesibilidad:
- HTML semántico, teclado, foco visible y nombres accesibles
- no afirmar cumplimiento hasta completar pruebas automáticas y manuales
Privacidad y seguridad:
- no enviar datos ni cargar recursos remotos salvo los autorizados
- tratar toda entrada como no confiable
Límites:
- no inventar APIs ni dependencias
- señalar decisiones ambiguas y aspectos que requieren validaciónCómo revisar código generado antes de producción
Función y regresión
Prueba el camino esperado, entradas vacías, texto largo, acentos, caracteres especiales, errores de red y estados combinados. Cada reparación debe ejecutar toda la suite, no solo el caso que falló.
Accesibilidad
Usa semántica nativa antes de añadir ARIA. Revisa el orden de encabezados, etiquetas, mensajes de error, foco, teclado, reflow, zoom y lector de pantalla. La explicación oficial de WCAG 2.2 sobre tamaño de objetivos también detalla excepciones: medir 44 píxeles en un experimento no demuestra conformidad completa.
Seguridad
La guía de seguridad de OpenAI recomienda revisión humana cuando sea posible, especialmente para código y ámbitos de alto impacto. Además, aplica prácticas de seguridad web independientes: validación en servidor, salida codificada según contexto, políticas de contenido, gestión de secretos, autorización, límites y pruebas específicas de amenazas. Nunca pongas una clave de API en JavaScript del navegador.
Datos y privacidad
Antes de enviar código, registros o contenido a una API, elimina secretos y datos personales innecesarios. En nuestro experimento usamos datos ficticios y store: false. Este parámetro no significa ausencia total de retención ni activa por sí mismo Zero Data Retention; consulta los controles oficiales de datos de la API para el tratamiento aplicable.
Rendimiento y mantenimiento
Mide recursos, JavaScript, interacción, estabilidad visual y comportamiento en la red real. Revisa también si el equipo puede mantener el código. Un prototipo corto puede pasar una prueba y seguir siendo una mala base para una aplicación grande.
Si el componente va a enviar mensajes al chat de este sitio, revisa también la política de privacidad: el código de interfaz es solo una parte del tratamiento de datos y no sustituye los avisos, controles y límites del servicio.
Limitaciones de nuestro experimento
- Un componente ficticio, pequeño y sin backend.
- Tres repeticiones de un único modelo, prompt, imagen, configuración y fecha; no estiman una tasa general de éxito.
- Una sola versión y entorno de Chromium; no hubo matriz de navegadores, sistemas ni dispositivos.
- Los fixtures automáticos cubren casos concretos. Cero incidencias graves o críticas de axe no demuestra conformidad WCAG.
- La cadena similar a XSS, el análisis estático y el aislamiento local no constituyen una auditoría de seguridad de producción.
- No hubo lector de pantalla, pruebas con usuarios, alto contraste, backend, datos reales ni revisión de un despliegue.
- Las capturas documentan estados ejecutados; no asignan una puntuación humana a la calidad visual.
- La reevaluación v1.0.2 fue una corrección posterior, no un análisis preregistrado.
Por ello, esta página responde a una pregunta limitada: qué devolvió una configuración concreta ante un brief concreto y qué superó dentro de una rúbrica publicada. No demuestra que el producto cree sitios completos de forma autónoma, que el mismo identificador mantenga el comportamiento en el futuro ni que otro prompt obtenga el mismo resultado.
Preguntas frecuentes
¿ChatGPT puede crear una página web completa?
Puede proponer archivos, componentes y explicaciones, pero la amplitud de una “página completa” varía. Integraciones, seguridad, accesibilidad, contenido, rendimiento, despliegue y mantenimiento necesitan pruebas y decisiones humanas.
¿El código de ChatGPT está listo para copiar y publicar?
No debe asumirse. Incluso una salida que funciona en una demo puede contener errores, incompatibilidades, vulnerabilidades o problemas de accesibilidad. Ejecútala en un entorno aislado, revisa los cambios y aplica la misma puerta de calidad que al código escrito por una persona.
¿ChatGPT puede convertir una imagen en HTML y CSS?
Los modelos y endpoints compatibles pueden aceptar entradas visuales según su documentación y configuración. En esta prueba, cada solicitud incluyó la misma referencia visual original con detalle high y requisitos textuales dominantes. Evaluamos contenido, estructura, comportamiento y estados en viewports definidos; no calculamos fidelidad píxel a píxel ni demostramos que cualquier imagen pueda convertirse correctamente en código.
¿Qué lenguaje es mejor para empezar?
Para una interfaz pequeña, HTML, CSS y JavaScript nativos reducen dependencias y facilitan observar el resultado. Un proyecto existente debe respetar su arquitectura y estándares; cambiar de framework solo porque el modelo lo sugiera suele aumentar el riesgo.
¿Pasar las pruebas garantiza seguridad y accesibilidad?
No. Las pruebas cubren casos definidos. La seguridad requiere un modelo de amenazas y la accesibilidad combina automatización, revisión humana y pruebas con tecnologías de asistencia y usuarios cuando sea posible.
¿Qué modelo conviene para desarrollo web con ChatGPT?
No hay un ganador universal. Evalúa modelos disponibles con tareas representativas, el mismo brief y la misma rúbrica. Mide corrección, reparaciones, latencia y coste por salida aceptable, y vuelve a probar cuando cambie el modelo o el prompt.
Fuentes y evidencia
Documentación oficial consultada y archivada el 17 de agosto de 2026:
- OpenAI: ficha del modelo GPT-5.6 Sol.
- OpenAI: Responses API.
- OpenAI: Structured Outputs.
- OpenAI: imágenes y visión.
- OpenAI: prácticas de seguridad.
- OpenAI: controles de datos de la API.
- W3C: Web Content Accessibility Guidelines 2.2.
- W3C: comprensión de Target Size (Minimum).
Evidencia propia depositada en Zenodo:
- Registro público de la prueba y DOI 10.5281/zenodo.21983885.
- Guía inicial y secuencia de correcciones, protocolo y manifiesto previo a la ejecución.
- ZIP versionado y checksums compuestos.
- Resultados por regla, informe corregido y resumen JSON v1.0.2.
Política editorial: las fuentes oficiales documentan el producto, la API y los estándares; no prueban nuestros resultados. Los resultados propios se sustentan en peticiones, respuestas, candidatos, logs, reglas, capturas y checksums publicados. Distinguimos el registro original inválido del evaluador y la reevaluación corregida, e indicamos qué no se probó.
