Conoces esa sensación cuando estás sentado con tu computadora portátil abierta, mirando el código que parece jeroglíficos, preguntándome: “¿Qué estoy haciendo aquí?” Ese fui yo durante los últimos ocho meses.

He pasado años diciéndome a mí mismo y a los demás: “No soy un desarrollador”, mientras que simultáneamente escribo suficiente código para sobrevivir.

Pero algo cambió recientemente. Dejé de preocuparme por si era un “desarrollador real” y abrazé la “codificación de ambientes”: construir por la sensación, usar la IA como mi compañero de codificación y aprender lo suficiente como para hacer algo útil. El resultado? Después de ocho meses, una aplicación completamente funcional que se ha transformado en la forma en que ejecuto mi negocio de reventa de LEGO.

No se trata de cortar esquinas. Se trata de encontrar una nueva ruta en la codificación que no requiere un título en informática o años de estudio de marcos. Se trata de construir algo real, resolver problemas reales y aprender en el camino.

Así es como AI me ayudó a pasar de los scripts de PowerShell a una aplicación completa de React/Express sin nunca “aprender a codificar” formalmente.

¿Qué es la “codificación de ambientes”?

Vibe Coding es un término acuñado por Andrej Karpathy, un miembro fundador de OpenAI, en febrero de 2025. Describe un nuevo enfoque para el desarrollo de software en el que permite que la IA realice la mayor parte de la codificación real mientras lo guía con instrucciones de lenguaje natural en lugar de escribir manualmente el código usted mismo.

La filosofía central se trata de “ceder completamente a las vibraciones” y casi “olvidar que el código existe”, centrarse en lo que desea crear en lugar de cómo codificarlo. Cuando encuentra errores, los pega a la IA sin comentarios, y generalmente soluciona los problemas.

Como lo describió Karpathy, “solo veo cosas, digo cosas, corre cosas y copia de cosas, y en su mayoría funciona”. Es particularmente adecuado para proyectos y prototipos de bajo riesgo donde la velocidad de desarrollo importa más que una comprensión perfecta de cada línea de código.

Para la codificación de VIBE no desarrolladores abre la creación de aplicaciones al permitirle concentrarse en aspectos creativos en lugar de quedarse atrapado en detalles técnicos.

¿Es una codificación “real”? Los puristas dirían que no. Pero esto es lo que importa: tengo una aplicación de trabajo que resuelve problemas reales en mi negocio, construidos principalmente a través de conversaciones con IA. Eso me parece bastante real.

Y no estoy solo, hay todo un movimiento de “codificadores de vibos” que surgen. Las personas que construyen software sin antecedentes tradicionales de codificación, aprovechando la IA para cerrar la brecha entre lo que pueden imaginar y lo que pueden crear. Está democratizando el desarrollo de software de una manera que las plataformas de bajo código prometieron pero nunca se entregaron por completo.

La belleza de la codificación de ambientes no es que reemplace el aprendizaje: es que le permite construir primero y aprender a medida que avanza, en contexto, resolver problemas reales en lugar de trabajar a través de tutoriales abstractos.

Conoce a Brickbuddy

Mi negocio de pasatiempos es vender LEGO usado en Bricklink. Lo disfruto; Bajo estrés y trabajo satisfactorio que paga algunas facturas cada mes. Pero cuando se trata de millones de pequeñas piezas que procesan, todo es una pesadilla absoluta.

Así que decidí crear una aplicación. Primero, era un módulo de PowerShell (sí, ¿una aplicación “real” en PowerShell?). Funcionó … Sorta … pero este escenario necesitaba una aplicación web, por lo que nació Brickbuddy.

BrickBuddy es una aplicación web con un frontend reactjs y una aplicación expresa que aloja una API en el backend. Puedes ver la página de destino que arrojé en Brickbuddy.io.

Mi objetivo era crear una aplicación para mí para administrar mi negocio de LEGO usado y tal vez En algún momento, venda suscripciones.

Porque Claude puede describir la aplicación mucho mejor de lo que puedo, aquí está su opinión:

Descripción general

Brickbuddy es una aplicación completa diseñada para administrar el inventario de ladrillo LEGO, con características para rastrear, organizar y administrar lotes de artículos de ladrillo. La aplicación sigue una arquitectura moderna de cliente cliente con una clara separación de preocupaciones.

Pila de tecnología

Frontend (ui)

• Marco central: React 18 con el enrutador react 6
• Gestión estatal: Gestión estatal personalizada basada en el contexto con AppStateProvider
• Componentes de la interfaz de usuario:
  • CSS de viento de cola para el estilo
  • UI sin cabeza y interfaz de usuario de Radix para componentes accesibles
  • Reaccionar iconos e iconos de héroes para la iconografía
  • Tabla de reacción de TanStack para tablas de datos
  • Reaccionar toastify para notificaciones
  • Chart.js/Recharts para la visualización de datos
• Cliente HTTP: Axios
• Manejo de forma: React Select
• Pruebas: Broma, biblioteca de prueba, dramaturgo

Backend (API)

• Marco central: Express.js
• Base de datos: Microsoft SQL Server (a través de SECLELIZE ORM)
• Autenticación: Jwt (jsonwebtoken)
• Validación: Joi, validador expreso
• Seguridad: Casco, bcrypt para hashing de contraseña
• Manejo de errores: Tipos de errores personalizados (ServiceError, ControllerError)
• Explotación florestal: Implementación del registrador personalizado

DevOps/infraestructura

• Construir herramientas: CRACO (Crear la anulación de configuración de la aplicación React)
• Pruebas: Broma, dramaturgo
• CI/CD: Acciones de Github
• Contenedores: Scripts para entornos de desarrollo/producción
• Gestión del medio ambiente: dotenv, env-cmd

Arquitectura

Arquitectura frontend

La interfaz de usuario sigue una arquitectura en capas bien estructurada:

1. Capa de contenedor de página:
   • Componentes de página de nivel superior (por ejemplo, UserInventory, catálogo, lotes)
   • Administra la presentación de enrutamiento y a nivel de página
2. Capa componente:
   • Componentes de presentación centrados en representar elementos de la interfaz de usuario
   • Sigue una convención de nomenclatura clara (por ejemplo, BatchSelector, LoadingButton)
   • Organizado por característica en lugar de tipo
3. Capa del manejador de acción:
   • Ganchos personalizados con patrón de nombres use[Component]Handler
   • Administra las interacciones del usuario y los eventos de la interfaz de usuario
   • Mapea eventos de interfaz de usuario a operaciones de lógica empresarial
   • Maneja errores y estado de la interfaz de usuario
4. Capa de lógica de negocios:
   • Ganchos personalizados con patrón de nombres use[Feature]Logic
   • Contiene operaciones complejas independientemente de la interfaz de usuario
   • Se comunica con los servicios de backend
   • Maneja las transformaciones de datos
5. Capa de servicio:
   • Comunicación API a través de ganchos de servicio
   • Resumen solicitudes HTTP y manejo de respuesta
6. Capa de gestión estatal:
   • AppStateProvider centralizado utilizando el contexto React
   • Validación de estado a través de StateActionValidator
   • Persistencia con LocalStorage a través de la utilidad de Localsettings
   • Organización estatal basada en esquemas con esquemas específicos de página

Arquitectura de backend

1. Capa del controlador:
   • Handlers de ruta organizados por dominio (p. Ej., BatchController, UserController)
   • Valida los datos de solicitud
   • Transforma entre contratos de API e interfaces de servicio
   • Maneja el formato de respuesta HTTP
2. Capa de servicio:
   • Contiene la lógica de negocios (por ejemplo, BatchService, UserInventoryItemService)
   • Implementa operaciones de dominio
   • Servicio base común (_brickbuddyservice) para la funcionalidad compartida
   • Manejo de errores con tipos de servicio de servicio personalizados
3. Capa modelo:
   • SECULAR MODELOS REPRESENTANDO Tablas de bases de datos
   • Define el esquema, las relaciones y las validaciones
   • Organizado por entidad (p. Ej., Usermodel, BatchModel)
4. Capa de middleware:
   • Procesamiento de solicitud/respuesta
   • Autenticación y autorización
   • Manejo de errores y registro
5. Utilidades:
   • Funciones de ayudantes compartidos
   • Infraestructura de registro
   • Tipos de error y formatúas

Flujo de datos

1. El usuario interactúa con un componente
2. El controlador de acción procesa la interacción
3. Se invoca la lógica de negocios si es necesario
4. Llamada API realizada a través de la capa de servicio
5. El controlador API recibe solicitud
6. El controlador valida y delegados al servicio
7. El servicio realiza operaciones de bases de datos y lógica de negocios
8. La respuesta fluye hacia atrás a través de las capas

Características clave

• Gestión de lotes para inventario de ladrillo
• Seguimiento de inventario de usuarios
• Integración con servicios externos (Bricklink)
• Gestión de establecidos
• Seguimiento de ubicación del artículo
• Autenticación de usuario y gestión de perfil
• Capacidades de informes

Esta arquitectura demuestra una aplicación bien estructurada con una clara separación de las preocupaciones, siguiendo las mejores prácticas de React y Node.js modernas, con un enfoque en la mantenibilidad, la prueba y la escalabilidad.

Como puede ver, esta no es una de esas aplicaciones que los influencers de IA giran en cinco minutos y todo es un clon de Netflix. ¡Es una pila tecnológica completa que incluye la automatización de implementación con acciones de GitHub, Terraform, un entorno de desarrollo y prod!

La construcción de aplicaciones de producción reales es posible con la codificación de ambas; Pero requiere un proceso de pensamiento completamente diferente y la voluntad de dejar de lado algunos detalles.

¡En general, Brickbuddy está actualmente en más de 120,000 líneas de código!

De acuerdo, 1/4 de eso podría recortarse y simplificar, pero eso es para otra publicación de blog.

Comenzando como un codificador de vibra junior

Sabía cómo codificar. Conocía estructuras de control, arquitectura básica y algunos scripting. Pero nunca había tocado un marco frontend. No tenía idea de qué era un componente, cómo funcionaban los accesorios o cómo se administró Frontend State.

Así que hice lo que cualquier curioso constructor haría: abrí IDE cursoreligió una función que necesitaba y escribió algo como:

“Cree una página con una barra lateral y una tabla que muestre todo mi inventario”.

Y la IA lo hizo.

Al principio, esto se sintió como hacer trampa. Pero luego me di cuenta: todavía tenía que probarlo, comprender cómo funcionaba y modificar las cosas. No entendí la sintaxis, pero comencé a ver patrones. Y finalmente, comencé a preocuparme por qué Algo funcionó, no solo eso lo hizo.

Ai como conductor, yo como pasajero

Al principio, la IA tenía el control. Yo solo era el pasajero.

Le dije lo que quería, me dio código y lo pegé. No cuestioné el resultado. No sabía cómo. No sabía qué era un reductor, o qué significaba JSX. Estaba construyendo a ciegas, confiando en la IA para verme.

Pero con el tiempo, las cosas comenzaron a romperse. Y cuando lo hicieron, no pude pedirle que lo arregle. Tuve que entender el contexto.

Fue entonces cuando las cosas comenzaron a cambiar.

Romper cosas me enseñó el marco

En el momento en que algo se rompió y la IA no pudo parchearlo limpiamente, tuve que aprender. Tuve que depurar. Tuve que rastrear dónde comenzó el error, por qué un estado no se actualizó, o por qué una función estaba obteniendo el valor incorrecto.

Ese dolor fue el mejor maestro.

Me enseñó el idioma sin tutoriales. Me enseñó arquitectura sin cursos. Me obligó a ser más inteligente porque la IA sola no era suficiente.

Finalmente, dejé de decirle a la IA qué hacer.

Yo empecé Haciendo preguntas.

• “¿Qué significa esta advertencia?”
• “¿Por qué este componente se vuelve a repasar?”
• “¿Es esta una buena forma de administrar el estado en múltiples componentes?”

Y la IA respondió. Y aprendí.

Construyendo algo real

Una de las cosas más importantes que aprendí a través de esto es que construir algo real es la forma más rápida de aprender.

No estaba construyendo una aplicación falsa o siguiendo un tutorial. Estaba resolviendo problemas reales que tenía con mi tienda Lego. Estaba enviando características que me importaban. Y debido a eso, me importaba arreglar errores, refactorizar el código y aprender la forma correcta de hacer las cosas.

Ai hizo esto posible. Me dejó construir antes de saber cómo construir.

No fue fácil (a pesar de lo que los influyentes pueden decir)

Este no fue un proceso perfecto. Me encontré con obstáculos, alucinaciones y toneladas de indicaciones desperdiciadas. He pasado más de una hora en un soltero Problema, yendo y viniendo con la IA, tratando de descubrir por qué algo que debería funcionar … simplemente no lo hizo.

Sí, la interfaz de usuario se unió rápidamente al principio. Esa parte fue fácil, honestamente, es tal vez el 5% de una aplicación real. Lo que tomó el tiempo fue todo lo demás:

• Administrar el estado correctamente
• Manejo de casos de borde
• Arreglando errores que rompieron otras características
• Aprender la forma correcta de organizar la lógica en los componentes

No solo escribía código: estaba aprendiendo arquitectura, flujos de trabajo de depuración, convenciones de nombres y patrones de reacción específicos. Y lo estaba haciendo mientras intentaba construir algo real que realmente funcionara.

Fue frustrante. Fue lento. Fue confuso.

Pero aún era más rápido que si hubiera intentado aprender reaccionar de publicaciones de blog o videos de YouTube. Porque estaba aprendiendo construyendo, no estudiando.

No necesitas dominar el idioma para comenzar. Pero necesitas tener curiosidad. Necesitas estar dispuesto a romper las cosas. Y lo más importante, debe seguir adelante incluso cuando no comprenda completamente lo que está construyendo.

Porque eventualmente lo harás.

Brickbuddy existe porque no esperé hasta que estuve “listo”. Comencé a construir, y Ai me conoció donde estaba.

Y 8 meses después, tengo una aplicación real que funciona.

Ese es el poder de codificar con IA.

¡Estén atentos para más publicaciones sobre mi experiencia en el último año más o menos, construyendo Brickbuddy!