Habr: autor explicó por qué AI no debe reducirse solo a vibe coding

Una columna en Habr hizo un punto sorprendentemente sobrio: el problema no es con el vibe coding en sí, sino con el hábito de reducir el trabajo con IA solo a la escritura de código. El autor sugiere pensar más ampliamente y elegir no el camino más "tecnológico", sino el más corto y sostenible hacia el resultado.

No Código por Código

El texto comienza con una crítica no a los modelos, sino al término "vibe coding" como un marco demasiado estrecho. Si constantemente piensas en términos de "vamos a generar una aplicación", es fácil perder soluciones más prácticas. Para un informe de datos, a veces es suficiente pedir a la IA que arme un archivo Excel con fórmulas y una estructura clara. Para un proyecto de contenido—selecciona una combinación de un CMS listo, plantilla y complementos, en lugar de perder tiempo en frontend, deployment y depuración de tu propio stack.

"La IA en tus manos es una gran multiherramienta, no un martillo."

Este es el pivote principal del artículo: el código no debe ser el objetivo en sí. Si una tarea ya ha sido resuelta por el mercado hace mucho tiempo, la IA es más útil como un acelerador para la configuración, personalización e implementación, en lugar de como una fábrica de nueva deuda técnica. Este enfoque es especialmente importante para equipos pequeños, donde después del lanzamiento el sistema aún necesita ser mantenido, entregado a otras personas, y no ser enterrado bajo preguntas sobre acceso, seguridad y compatibilidad.

Blog en Lugar de Tu Propio CMS

El autor ilustra esto con un caso específico: había la necesidad de lanzar rápidamente una revista especializada en educación para una pequeña escuela privada. La tentación era típica de 2026—tomar Claude Code u otro agente y "vibe code" tu propio CMS en un stack moderno. Pero después de una verificación rápida de la realidad, la solución resultó ser obvia: un blog con secciones, SEO, imágenes, búsqueda y RSS—este es un problema ya resuelto que WordPress ha cubierto durante años.

En lugar de una aplicación personalizada, se eligió un stack pragmático: VPS en Ubuntu, nginx, PHP 8.3, MySQL 8.0, WordPress con tema GeneratePress.

La IA no desapareció—fue usada como ejecutora vía SSH, escribiendo PHP, editando configs, ajustando el tema, y ensamblando personalizaciones a través de mu-plugins.

• servidor con nginx, PHP-FPM, MySQL, SSL, firewall y fail2ban
• página de inicio de revista con bloque hero, tarjetas de artículos y cuadrícula de secciones
• SEO básico, sitemap y URLs legibles
• 12 mu-plugins para personalización dirigida
• alrededor de 600 líneas de CSS y varios scripts Python auxiliares

Esencialmente, el autor no abandonó la IA—dejó de forzar a la IA a construir lo que ya existe. Este es el argumento central del artículo: en muchos proyectos, la victoria viene no de maximizar la cantidad de código generado, sino de la capacidad de confiar en una plataforma lista y pulir solo los puntos estrechos.

Dónde la IA Es Realmente Útil

La parte más fuerte del texto es la descripción del proceso real, sin magia y sin bombo promocional. La IA no hizo todo "con un comando". El trabajo procedió en iteraciones: una persona formula una tarea, el modelo hace aproximadamente el 80% de lo necesario, luego comienza un ciclo de verificación, búsqueda de problemas visuales y correcciones dirigidas.

Para un stack desconocido, esto aún da enormes ahorros de tiempo, porque no necesitas pasar semanas aprendiendo API de WordPress, hooks, filtros y peculiaridades de cascada CSS. Pero el artículo honestamente enumera las limitaciones también. Un agente de consola no ve el resultado en un navegador, no sabe sobre cambios manuales en el panel de administración, y puede fácilmente romper un bloque adyacente mientras arregla el actual.

En un caso, la IA hizo el bloque de categorías HTML estático, y después de renombrar las secciones en la página de inicio, nada se actualizaba. La corrección llegó solo después de varias iteraciones: primero a través del filtro the_content, luego abandonando slugs hardcodeados en favor de get_terms(). En otro caso, tuvieron que separadamente descubrir por qué los estilos core de WordPress estaban rompiendo la cuadrícula de tres columnas, y elevar la prioridad de los estilos personalizados a 999.

De esto viene la segunda conclusión importante: la IA no reemplaza el pensamiento arquitectónico y la competencia técnica básica. Acelera infraestructura, personalización y CSS rutinario, pero no toma decisiones de producto maduras por sí sola. Si una persona no entiende el dominio, no nota errores de seguridad, y no puede evaluar la calidad del resultado, el modelo simplemente producirá respuestas plausibles que se desmoronarán en un proyecto real.

Qué Significa Esto

La columna de Habr golpea bien el nervio del mercado: es demasiado fácil comenzar a medir el éxito de la IA por la cantidad de código escrito a su alrededor. En la práctica, el negocio más a menudo necesita no un nuevo framework, sino una solución rápida, barata y sostenible. Por lo tanto, el escenario más útil para la IA hoy no es el vibe coding ciego, sino elegir la ruta más corta: en algunos lugares será un servicio personalizado, y en otros lugar Excel, WordPress u otro producto listo que puedas lanzar y entregar sin dolor extra.