La IA no construye productos que funcionen por ti; eso sigue siendo tu trabajo

• La IA puede crear en minutos un prototipo con UI y base de datos, pero no acorta la distancia entre una primera versión funcional y un producto listo para producción
• En un producto real siguen existiendo problemas que requieren criterio de ingeniería más que escribir sintaxis, como escalabilidad, manejo de errores, observabilidad, seguridad, autenticación y estructuras de datos
• El valor de las ciencias de la computación está menos en producir código y más en los modelos mentales para entender cómo se comportan los sistemas y por qué fallan; eso permite detectar consultas ineficientes o condiciones de carrera
• La demanda de trasladar requisitos a código de forma mecánica disminuirá, pero los ingenieros experimentados pueden delegar tareas repetitivas a la IA y enfocarse en problemas que requieren experiencia, trabajando mucho más rápido
• Si se usa la IA como sustituto del entendimiento, será difícil corregir, ampliar o transferir sistemas rotos; por eso hay que aprender primero los fundamentos y luego aprovechar las herramientas de IA

---

La brecha entre prototipo y producto

• Si describes una idea en lenguaje natural, en pocos minutos puedes obtener un prototipo funcional con UI y base de datos que realiza la función prevista
• Pero un prototipo que corre en una laptop puede revelar muchos problemas en un entorno real
  • No soporta carga y no cuenta con manejo de errores
  • Los tokens de API pueden filtrarse
  • El modelo de datos de demostración puede venirse abajo en cuanto se agrega un segundo usuario
  • La autenticación depende de supuestos no verificados y la seguridad también es incierta
• Al llegar a la etapa de despliegue aparece una gran brecha de producción entre “funciona” y “está listo”

Lo difícil venía después de escribir el código

• Los ingenieros de software ya podían poner algo en marcha rápidamente antes, y la parte que realmente tomaba tiempo venía después
  • Diseñar sistemas que resistan al crecer en escala
  • Manejar excepciones cuando los usuarios entran por rutas inesperadas
  • Construir observabilidad para saber cuándo ocurre una falla
  • Tomar decisiones de arquitectura de datos que reduzcan los arrepentimientos dentro de 3 años
• La IA ha reducido mucho el tiempo para llegar a la primera versión funcional, pero no ha reducido la distancia desde esa versión hasta un sistema listo para producción
• El ciclo rápido de pedir, responder y ver resultados da la impresión de que el resto del proceso de desarrollo también se comprimió, pero los problemas difíciles del software nunca fueron, en primer lugar, escribir sintaxis
• El criterio para decidir qué construir y cómo estructurarlo, qué posponer y cuándo decir que no, es lo que separa un prototipo de un sistema de producción

Por qué las ciencias de la computación siguen siendo necesarias

• Con el acceso fácil al código generado por IA, cada vez más recién llegados se preguntan si todavía hace falta estudiar durante años algoritmos, estructuras de datos, sistemas operativos y teoría
• El valor de la formación en ciencias de la computación no está solo en la capacidad de escribir código, sino en formar modelos mentales para entender cómo funcionan y fallan los sistemas, y por qué se producen esos resultados
• Esa base es necesaria para identificar posibles fallas en el código generado por IA
  • Una consulta que provoca un escaneo completo de tabla en una tabla de 50 millones de filas
  • Una estrategia de caché que crea una condición de carrera bajo carga concurrente
  • Una arquitectura que resuelve los requisitos actuales, pero hace que el siguiente problema sea mucho más difícil
• Sin conocimientos básicos, terminas dependiendo por completo del criterio del modelo
  • El modelo no se basa en criterio, sino en reconocimiento de patrones, y genera con confianza código que considera alineado con la intención
  • El código generado puede verse correcto y convencional, pero fallar en producción
  • Si no tienes el conocimiento para reconocer el problema, diagnosticarlo puede tomar días
• Ahora que se redujo la distancia entre entendimiento y resultado, es un buen momento para aprender ciencias de la computación; un estudiante que entienda bien los sistemas distribuidos puede construirlos en mucho menos tiempo que hace 10 años

Trabajo que se automatiza y productividad que se expande

• La demanda de trabajo de codificación mecánica, que consiste en convertir requisitos línea por línea en implementación, está disminuyendo de verdad, y esa área se está automatizando
• Mientras la parte baja de la distribución de productividad se comprime, el límite superior se expande
  • Un ingeniero experimentado que usa herramientas modernas de IA puede trabajar a una velocidad difícil de imaginar hace 5 años
  • No es que los problemas difíciles hayan desaparecido, sino que se resuelven muchas de las tareas mecánicas que consumían tiempo y atención
  • Ese tiempo liberado puede dedicarse a trabajos que sí requieren experiencia real
• El ingeniero que se quedará atrás no es quien no sabe usar IA, sino quien usa la IA como sustituto del entendimiento
  • Construye con vibe coding sistemas sobre los que no puede razonar
  • No puede corregir fallas ni ampliar un sistema que creció
  • No puede explicar a los responsables de mantenimiento lo que construyó

Trabajar en un nivel de abstracción más alto

• El cambio necesario no se limita a adoptar una nueva herramienta, sino a trabajar en un nivel de abstracción más alto sin dejar de estar arraigado en los fundamentos
• El ingeniero que usa la IA como amplificador, no como sustituto del conocimiento profundo, puede adelantarse rápidamente a sus colegas
  • Entiende qué le está pidiendo generar al modelo
  • Revisa críticamente el código generado como revisaría el pull request de un ingeniero junior
  • Conversa desde una perspectiva de arquitectura, no solo transmitiendo descripciones de funcionalidades
  • Sabe cuándo oponerse a las sugerencias del modelo
• Esto no consiste en reemplazar habilidades existentes por una capacidad nueva, sino en aplicar las habilidades existentes a un nuevo entorno para obtener mucho más apalancamiento
• Incluso después del prototipo sigue siendo necesario el criterio real de ingeniería, y esa capacidad es lo que separa a quienes lanzan software confiable de quienes solo lanzan demos
• El orden de aprendizaje debe ser primero los fundamentos y luego las herramientas de IA

[GN⁺]

Opiniones en Hacker News

• Estoy por tirar a la basura varios meses de código generado con LLM en un proyecto paralelo. Aunque escribí especificaciones de diseño detalladas y trabajé sobre una base de código existente, cada cambio individual parecía lógico, pero en conjunto terminó siendo una masa compleja donde muchas partes no encajaban del todo
  Con los informes o papers pasa algo parecido: cada sección parece convincente, pero el documento completo se siente raro. Aunque los humanos sean más lentos en las tareas de detalle, parecen hacer un razonamiento de alto nivel que los LLM todavía no pueden. Si les señalas un defecto, dicen “totalmente de acuerdo”, pero cuando se revisan a sí mismos no logran detectarlo
  Crear una app CRUD simple con un framework JS común, Tailwind y un ORM probablemente sea perfectamente posible, pero antes también se podían comprar plantillas SaaS, y es muy probable que un boilerplate comercial bien hecho a mano sea mejor que el resultado de programar por vibe coding

  • Cada vez uso más programación asistida por LLM en lugar de programación totalmente autónoma. Modelos como Opus, más que entender un buen diseño, tienden a hacer cambios hasta alcanzar el objetivo, dejando código que una persona debe ordenar y un exceso de trabajo de investigación
    En PR de otras personas también veo con frecuencia implementaciones que resuelven superficialmente el problema del prompt, pero que son difíciles de mantener a largo plazo. Por eso decido yo mismo el procedimiento de implementación y el diseño, y trabajo paso a paso con modelos open source pequeños o con Claude 4.5/4.6. Explorar APIs y escribir boilerplate se vuelve más rápido, varias veces más que hacerlo a mano, sin que se deteriore mi conocimiento ni se arruine la base de código
  • Muchas veces me quedé atrapado en soluciones complejas y sobrediseñadas, y después de salir a caminar o hacer otra cosa me di cuenta de una solución simple. Los LLM procesan todo de inmediato, quitándote el tiempo para reflexionar, darte cuenta de que estás en un callejón sin salida y pensar en conflictos con las siguientes tareas
  • Mi proyecto paralelo también llegó a un punto en el que ya es difícil entender por completo el código y modificarlo de forma segura por mi cuenta, pero creo que ya no necesito hacerlo. Escribí código hermoso durante casi 20 años, así que ahora quiero concentrarme en la productividad y en el resultado; mientras Codex entienda el código espagueti, para proyectos personales o estudios independientes pequeños está bien
    La IA es una nueva capa añadida sobre el stack tecnológico, del mismo modo que los lenguajes de alto nivel se colocaron sobre el lenguaje de máquina, así que hay que aprender a soltar
  • El verdadero valor estaba menos en el código y más en el aprendizaje obtenido al llegar hasta ahí. En el proceso de batallar, uno descubre una y otra vez los requisitos reales y los desafíos técnicos, pero la IA se salta ese proceso y hace que parezca que se alcanzó el objetivo de forma superficial
    Eso no significa que la IA sea inútil; más bien hay que pensar más a fondo en los requisitos y en la validación final, y confiar menos en que el proceso por sí solo garantice un resultado valioso
  • En un nuevo proyecto de calendario familiar estoy aprovechando la velocidad de la IA para pulir problemas de experiencia de usuario. Hago una funcionalidad, la uso personalmente durante unos días y luego corrijo lo que no me gusta, repitiendo el ciclo con el objetivo de completar las funciones de la v1
    No me gustan los colores ni la lógica de negocio verbosa, innecesariamente vistosa, pero lo importante ahora es si realmente nos resulta útil a mi pareja y a mí, y el resultado es positivo. Después rediseñaré la UI a mi gusto, cerraré los requisitos del backend y luego lo reescribiré desde cero para que sea fácil de mantener y escalar
    La familia Claude es excelente para prototipado y descubrimiento de requisitos, y facilita el proceso de reconstruirlo bien después

• Un criterio simple de validación es si en los últimos 12, 24 o 36 meses vimos de verdad grandes productos nuevos o mejoras importantes en productos existentes. El único producto nuevo excelente que he usado es mi LLM preferido, y esos laboratorios, de hecho, están contratando a más gente
  Si dentro de 12 meses no hay mejoras, creo que se repetirá el argumento de que “recién en febrero de 2027 los LLM se volvieron lo suficientemente buenos, así que todavía no se puede evaluar”

  • Que las versiones web y para VS Code de Claude Code sigan llenas de bugs también es un buen criterio. Casi todas las ejecuciones iterativas de agentes se rompen y requieren recargar a la fuerza, y a veces ni siquiera eso lo soluciona. Anthropic tiene en la práctica un presupuesto ilimitado de LLM y también modelos no publicados
  • No soy de los que creen que los LLM sirven para todo, y los uso de manera controlada, pero el reciente avance en descubrimiento automático de vulnerabilidades es interesante. Chrome corrigió en junio más bugs que en los dos años anteriores
    https://news.ycombinator.com/item?id=49120097
    Las últimas actualizaciones de seguridad de Apple y el boletín de seguridad de Android de junio también corrigieron una cantidad enorme de vulnerabilidades. Muchas surgieron en lenguajes inseguros como C/C++, pero como los LLM son fuertes en tareas de transformación claramente definidas y con poco margen para desviarse, también son útiles para portar a lenguajes seguros como Rust
  • La velocidad de lanzamiento de proyectos es parecida a la de antes, pero gracias a las herramientas de IA los resultados son mucho más pulidos y ricos en funciones. Antes lanzaba algo que solo funcionaba en el camino feliz, pero ahora puedo ofrecer cancelación, exportación de cuenta, política de privacidad y hasta apps móviles y web completas sin un gran esfuerzo
  • Basta mirar algunas comunidades de desarrollo para ver que, desde la aparición de estas herramientas, la cantidad de productos nuevos se triplicó. No existe una lista que rastree todo el software lanzado y si usó IA o no, así que es extraño asumir que no existe solo porque uno no vio mejoras directamente
    También en el sector salud la cantidad de productos se disparó; la calidad varía, pero decir que no hubo ningún resultado es objetivamente falso
  • Creo que la puesta en práctica real empezó a fines del año pasado, pero sí es cierto que recientemente hubo un aumento notable de software de hobby. Qué tan bien se mantenga es otro tema

• Cuando el producto funcione, recomiendo pedirle: “revisa si la base de código está lista para producción y si cumple el estándar para venderse por 1 millón de dólares”. Entonces la IA revelará que no está ni cerca del nivel que afirmaba antes, y se convertirá en el “prompt del millón de dólares” que te muestra cuánto te estaba engañando

  • Vi dos publicaciones en Hacker News y en ambas el comentario principal decía que “la IA no puede escribir código y pronto se vendrá abajo”. Me cuesta entender que sigan diciéndoles que es un espejismo a personas que llevan años usando estas herramientas con éxito todos los días
  • Muchas bases de código pésimas se han vendido por más de 1 millón de dólares
  • Entonces me pregunto por cuántos millones debería venderse Oracle Database
    https://news.ycombinator.com/item?id=18442941
  • Si le pides que corrija los problemas y luego haces la misma pregunta otra vez, después de corregirlos volverá a darte críticas parecidas
  • Vale la pena pensar en cuánto se vendió OpenClaw

• Probé usar LLM de dos maneras. Primero, hice vibe coding con Opus 4.6 y un backend en Node para un plugin que envía notificaciones a un canal de Slack según el turno de cada persona, y un temporizador de intervenciones por participante en Google Meet. Como es una herramienta interna, aunque no entienda bien la implementación, funciona sin problemas en GCP, y redujo el costo de una herramienta de Slack que salía 20 dólares al mes por persona a un costo de infraestructura de 0.07 dólares al mes en total.
  No salió de una sola vez: pasó por un plan detallado, ejecución paso a paso y agregado de pruebas. Segundo, en productos de largo plazo, el equipo diseña y revisa la arquitectura, crea tickets detallados en JIRA y luego se los pasa a Opus. El modelo arma un plan de implementación y solo se le permite programar después de que un ingeniero lo aprueba.
  Para un MVP rápido o una prueba de concepto, el primer enfoque sirve, pero si es un producto de largo plazo, hay que desechar el MVP, planear desde el principio la escalabilidad y una arquitectura limpia, y usar el LLM como trabajador de coding. Los LLM todavía son débiles para juzgar arquitecturas que los humanos puedan mantener durante mucho tiempo y código limpio.

  • Para hacer vibe coding de apps desechables y de bajo riesgo fue excelente, pero implementar funcionalidades de la misma forma en una enorme base de código legacy fue una pesadilla total.

• El criterio para distinguirlo es si disfrutar el resultado generado por IA resulta placentero. Textos, videos, voces, menús de restaurantes, fotos de ropa, documentos, control aéreo, anuncios: nada de eso resulta agradable, aunque los LLM sí tienen valor como motores de búsqueda mejorados o herramientas de preguntas y respuestas.

  • A muchos consumidores no les importa la baja calidad si cumple un mínimo y funciona. Lo mismo pasó con electrodomésticos, software y comida rápida.
    Si la IA finalmente alcanza ese estándar, los productos generados dominarán a los hechos a mano, y es muy probable que los productos y servicios hechos directamente por personas solo puedan comprarse a precios mucho más altos, como ocurre hoy con la artesanía.
  • Puede que ya estemos disfrutando todo el tiempo de buenos resultados de IA sin darnos cuenta. A nadie le gustan los generados puntuales y pésimos.
  • Si la gente gasta en conjunto decenas de miles de millones de dólares cada mes, se puede decir que en realidad sí les gusta.
  • Trato los resultados generados por IA solo como materia prima, no como productos terminados para ofrecer directamente al público masivo.
  • El problema no es que sea IA, sino la baja calidad. Aunque sea claramente IA, a la gente le gusta un resultado bien hecho.

• Habrá mucho trabajo en ordenar los resultados de vibe coding de otras empresas y convertirlos en sistemas realistas. Aunque el valor de cada proyecto individual baje, aumentará la cantidad, y es probable que no funcionen bien sin ayuda.
  Una empresa sin ingenieros de software dijo que usa Claude Code para tareas ajenas a su negocio principal, pero que aun así quiere que sus empleados hagan el trabajo para el que fueron contratados, en vez de andar toqueteando código.
  A medida que se vuelve más fácil hacer desarrollos a medida, los productos genéricos y uniformes serán más difíciles de vender, pero entregar resultados realmente personalizados sigue requiriendo mucho trabajo. Esto favorece el doble a quienes tienen experiencia construyendo directamente y conocimiento del área de negocio correspondiente.
  La gente, por lo general, no sabe qué necesita, así que la esencia de la consultoría —descubrir y entregar esos requisitos— sigue igual; y como el software se vuelve más barato, se puede atender a más clientes.

  • No queda claro quién es ese empleado que no debería tocar código.

• La lógica de base del texto tiene fallas. Si después de hacer un prototipo todavía queda trabajo por hacer, basta con seguir haciendo ese trabajo. Parece equiparar el uso de IA con generar todo de una vez a partir de un prompt de cuatro líneas, y se siente más como una autojustificación acrítica que como una idea fundamental.

  • Coincide exactamente con mi experiencia usando LLM en bases de código con cobertura de pruebas insuficiente, requisitos inciertos y métodos de despliegue no estándar. Cuando se sale del camino feliz, empieza a hacer malas suposiciones que rompen producción, y ni siquiera los modelos más inteligentes están a la altura de la arquitectura adecuada para ese entorno.

• Aunque no tengo formación en ingeniería, me pareció intuitivamente correcto, y lo viví varias veces al crear un juego de cartas. Al principio lo hacía bien, pero como tomó una librería estándar de 52 cartas, después no se podían agregar cartas de evento especiales, y hacía falta un modelo de datos flexible basado en objetos de carta.
  Si se le dice desde el principio, probablemente pueda resolverlo, pero si uno trata el software como algo desechable y no piensa profundamente en la implementación como lo haría un ingeniero experimentado, no se le ocurren esos requisitos. El problema de los textos y el código generados por IA es que te quitan el pensamiento que estaba incorporado en el proceso de creación.
  Dicho eso, no todo software necesita escalabilidad, velocidad y mantenibilidad. Eso sí hace falta en infraestructura y apps que usarán millones de personas, pero una app familiar para planificar comidas no necesita soportar configuraciones de alergias para decenas de miles de empleados de Google.
  La IA puede convertir el software en una herramienta casera, como comida hecha en casa. La comida casera no tiene que ser una receta perfecta: alcanza con alimentar a la familia y ser un regalo de esfuerzo para alguien.

• Si un producto pudiera crearse con una sola petición, hace mucho que las empresas de outsourcing habrían dominado a las empresas de producto. Una parte considerable del desarrollo de producto ocurre en el trabajo iterativo después del prototipo/MVP inicial.
  No se trata solo de tecnología: hay que profundizar durante mucho tiempo en el problema, entender la causa raíz del dolor y resolverlo tanto desde la experiencia de usuario como desde la tecnología. Antes también se podía “promptear” un producto a una empresa de outsourcing, pero esta es la razón por la que se pagaba a empresas de producto que habían acumulado experiencia hablando durante años con los clientes.

• Un título que resume mejor la discusión sería The Prototype Isn't the Product. Con IA se pueden crear sorprendentemente rápido prototipos desechables y apps personales donde basta con que “más o menos funcionen”, pero la ingeniería de software donde importan la calidad y el mantenimiento sigue siendo difícil y lenta.
  Hay muchas demos vistosas de vibe coding, pero poca discusión sobre qué tan útil fue la IA en bases de código legacy a gran escala o en el trabajo profesional cotidiano y poco glamoroso.
  No te van a llamar un domingo a las 6 de la mañana porque se detuvo un prototipo de juego 3D hecho con vibe coding, pero si aparece un bug en el sistema operativo 24/7 que acabas de actualizar, seguro que sí te van a llamar.