Ingeniería del vibe

• "Vibe Engineering" es un nuevo nombre para una forma profesional de desarrollo que utiliza herramientas de programación con IA. A diferencia del "vibe coding", que es rápido e irresponsable, se refiere a un enfoque en el que ingenieros con experiencia usan LLM sin perder calidad de código ni responsabilidad
• Con la aparición de agentes de programación como Claude Code, OpenAI Codex CLI y Gemini CLI, el uso de LLM en proyectos reales se disparó, y algunos ingenieros incluso ejecutan varios agentes al mismo tiempo para trabajar en paralelo
• Para aprovechar bien los LLM, se necesitan prácticas de ingeniería de software de primer nivel ya establecidas, como pruebas automatizadas, planeación previa, documentación integral, control de versiones y cultura de revisión de código
• Las herramientas de IA amplifican la experiencia existente, y mientras más habilidades y experiencia tenga un ingeniero senior, más rápido y mejores resultados podrá obtener al usar LLM
• El término marca una diferencia clara frente al "vibe coding" y enfatiza una forma más difícil y sofisticada de usar IA para desarrollar software de producción; además, la combinación contradictoria entre "engineering" y "vibe" termina siendo fácil de recordar (destacando los cambios en el proceso de desarrollo y la importancia de la experiencia ante el avance de las herramientas de IA)

---

Diferencia entre vibe coding y vibe engineering

• El vibe coding es una forma rápida, relajada e irresponsable de desarrollar software con IA, totalmente guiada por prompts y con poca o ninguna atención a cómo funciona realmente el código
• En el extremo opuesto del espectro existe una forma en la que profesionales experimentados aceleran su trabajo con LLM, pero siguen sintiéndose orgullosos del software que producen y asumen responsabilidad por él con total seguridad; a eso se le da el nombre de vibe engineering
• Una verdad menos conocida es que trabajar productivamente con LLM como ingeniero de software en proyectos reales, y no solo en proyectos de juguete, es difícil; hace falta mucha profundidad para entender cómo usar estas herramientas y hay muchas trampas que evitar

Aparición e impacto de los agentes de programación

• Con la llegada de herramientas de agentes de programación como Claude Code, lanzado en febrero de 2025, Codex CLI de OpenAI en abril y Gemini CLI en junio, la utilidad de los LLM para problemas reales de programación aumentó de forma drástica
  • Estas herramientas modifican código de forma iterativa y lo prueban activamente hasta cumplir el objetivo indicado
• Ingenieros de software experimentados y confiables están ejecutando varios agentes al mismo tiempo para resolver múltiples problemas en paralelo y ampliar el alcance de su trabajo
  • El autor al principio era escéptico, pero después de probar agentes de programación en paralelo confirmó que agotan mentalmente, pero son sorprendentemente efectivos
• Gran parte de la colección de tools.simonwillison.net se construyó con un enfoque clásico de vibe coding, pero iterar con agentes de programación para producir código de calidad de producción que pueda mantenerse en el futuro se siente como un proceso completamente distinto

Prácticas de ingeniería de software existentes que los LLM potencian

• Pruebas automatizadas: si hay una suite de pruebas sólida, integral y estable, las herramientas de programación con agentes pueden trabajar rápido; sin pruebas, el agente puede afirmar que algo funciona sin realmente probarlo, o los cambios nuevos pueden romper funciones no relacionadas
  • El desarrollo guiado por pruebas resulta especialmente efectivo con agentes que pueden iterar en bucle
• Planeación previa: cuando uno se sienta a construir algo improvisando, empezar con un plan de alto nivel hace que todo salga mucho mejor, y esto se vuelve aún más importante al trabajar con agentes
  • Primero se puede iterar sobre el plan y luego pasárselo al agente para que escriba el código
• Documentación integral: al igual que los programadores humanos, los LLM solo pueden mantener en contexto una parte de la base de código a la vez; si se les da documentación relevante, pueden usar APIs de otras áreas sin tener que leer primero ese código
  • Si primero se escribe una buena documentación, el modelo puede construir una implementación alineada usando solo esa entrada
• Buenos hábitos de control de versiones: si un agente de programación pudo haber hecho cambios, se vuelve aún más importante deshacer errores y entender cuándo y cómo cambió algo
  • Los LLM son muy buenos con Git: pueden explorar el historial por su cuenta para rastrear el origen de un bug y suelen usar git bisect mejor que la mayoría de los desarrolladores
• Automatización efectiva: integración continua, formateo y linting automatizados, y despliegue continuo a entornos de vista previa también ayudan a las herramientas de programación con agentes
  • Los LLM facilitan escribir scripts rápidos de automatización para que la próxima vez una tarea pueda repetirse de forma exacta y consistente
• Cultura de revisión de código: si eres rápido y productivo revisando código, la experiencia de trabajar con LLM será mucho mejor
  • Si prefieres escribir tú mismo el código antes que revisar lo que escribió otra persona (o algo), entonces esto será difícil
• Una forma muy extraña de técnica de gestión: obtener buenos resultados de un agente de programación se parece de manera incómoda a obtener buenos resultados de un colaborador humano
  • Hay que dar instrucciones claras, asegurar el contexto necesario y proporcionar retroalimentación accionable sobre el resultado
  • Es mucho más fácil que trabajar con personas reales porque no hace falta preocuparse por insultarlas o desanimarlas, pero la experiencia previa de gestión resulta sorprendentemente útil
• QA manual realmente bueno: además de las pruebas automatizadas, también hay que ser realmente bueno probando software manualmente, incluyendo anticipar y explorar casos límite
• Habilidades sólidas de investigación: suele haber decenas de maneras de resolver un problema de programación dado, y siempre ha sido importante identificar la mejor opción y justificar el enfoque; eso sigue siendo un obstáculo antes de soltar a un agente para que escriba código real
• Capacidad de desplegar en entornos de vista previa: cuando un agente construye una funcionalidad, tener una forma segura de previsualizarla —sin desplegarla directo a producción— hace que la revisión sea mucho más productiva y reduce mucho el riesgo de publicar algo roto
• Instinto para distinguir qué se puede subcontratar a la IA y qué debe hacerse manualmente: esto sigue evolucionando a medida que los modelos y herramientas se vuelven más eficaces
  • Una gran parte de trabajar bien con LLM es mantener una intuición fuerte sobre cuándo se aplican mejor
• Un sentido de estimación actualizado: estimar cuánto va a tardar un proyecto siempre ha sido una de las partes más difíciles, pero también más importantes, de ser ingeniero senior, especialmente en organizaciones donde las decisiones de presupuesto y estrategia dependen de esas estimaciones
  • La programación asistida por IA hace esto todavía más difícil: cosas que antes tomaban mucho tiempo ahora son mucho más rápidas, pero las estimaciones dependen de factores nuevos que todos seguimos intentando entender

Naturaleza y sentido de la vibe engineering

• Para realmente aprovechar las capacidades de estas herramientas nuevas hay que operar al nivel más alto del juego, y eso incluye:
  • no solo hacerse responsable de escribir código, sino también de
  • investigar enfoques,
  • tomar decisiones de arquitectura de alto nivel,
  • redactar especificaciones,
  • definir criterios de éxito,
  • diseñar bucles de agentes,
  • planear QA,
  • gestionar una tropa cada vez mayor de extraños pasantes digitales que intentan engañarte cuando tienen oportunidad,
  • y pasar mucho tiempo revisando código
• Casi todo lo anterior ya forma parte de lo que caracteriza a un ingeniero de software senior
• Las herramientas de IA amplifican la experiencia existente: mientras más habilidades y experiencia tengas como ingeniero de software, más rápido y mejores resultados podrás obtener trabajando con LLM y agentes de programación

“Vibe engineering”, ¿en serio?: reflexión sobre la elección del término

• Sobre si el nombre "vibe engineering" es tonto: probablemente sí; a estas alturas la idea de "vibe" en IA ya se siente algo gastada, y el propio "vibe coding" suele usarse de forma despectiva por muchos desarrolladores
  • Pero el autor está listo para recuperar el vibe para algo más constructivo
• Nunca le gustó la distinción artificial entre "coder" e "engineer", porque siempre se sintió un poco como una barrera de entrada, pero en este caso una pequeña barrera de entrada es exactamente lo que hace falta
  • Vibe engineering establece una separación clara frente al vibe coding y señala que esta es otra forma, más difícil y más sofisticada, de trabajar con herramientas de IA para construir software de producción
• Le gusta que pueda sonar arrogante y polémico, porque todo este espacio sigue siendo absurdo de muchas maneras
  • Mientras descubrimos la forma más productiva de aplicar estas herramientas nuevas, no deberíamos tomarnos demasiado en serio a nosotros mismos
• En el pasado intentó posicionar términos como programación asistida por IA, pero con un éxito casi nulo; esta vez tampoco suena mal frotar un poco el vibe y ver qué pasa
• Le gusta mucho la clara discordancia entre "vibe" y "engineering", porque hace que el término combinado sea juguetón y (ojalá) fácil de recordar precisamente por su auto-contradicción

[m00nlygreat]

Creo que hace no mucho también intentaron ponerle un nombre como "¿qué era eso de coding?" y, según entiendo, fracasó, así que "programación en pareja con IA" me parece la expresión más adecuada.

Ponerle nombre solo para poder decir: "Ese nombre lo inventé yo."

[m00nlygreat]

Parece que alguien lo llamó codificación aumentada (Augmented Coding) y luego desapareció rápidamente.

[GN⁺]

Comentarios en Hacker News

• Últimamente, cuando leo temas así, me entra una especie de tristeza. Antes sentía que tenía una habilidad de programación difícil de conseguir, con mucha demanda y buena paga, y que aunque los lenguajes o frameworks cambiaran rápido, era lo bastante listo como para seguirles el ritmo. Pero cuando gente como Simon Willison dice que este nuevo estilo de programación basada en agentes y flujos de trabajo simultáneos es el futuro, siento que va a requerir un esfuerzo enorme y me deprime. He probado agentes de código, pero termino esperando más tiempo, y gestionar varias tareas al mismo tiempo me dificulta entrar en ritmo, así que lo disfruto menos. Por eso hasta me dan ganas de cambiarme a algo completamente distinto, como ventas.

  • Yo también empatizo sinceramente con ese sentimiento. De hecho, una de mis metas era refutar la idea de que "las habilidades de programación dejarán de servir y cualquiera podrá escribir código con un LLM". En realidad, creo que alguien con experiencia previa en desarrollo se vuelve mucho más valioso al trabajar con agentes de código o con LLM. Puedes aprovechar todo lo que ya aprendiste para generar un impacto mayor con herramientas nuevas. Como también se menciona en el post, las herramientas de IA amplifican la capacidad de los expertos que ya existían. Un principiante puede hacer una UI llamativa con ChatGPT, pero no puede encargarse de diseño de arquitectura, pruebas automatizadas, CI/CD, despliegues en Kubernetes ni de operar múltiples agentes al mismo tiempo, así que el rol de un ingeniero con experiencia se vuelve mucho más importante.
  • A mí también me pesa la idea de "gestionar varios agentes masivamente paralelizados". Por fuera se ve muy potente y entiendo por qué a tantos desarrolladores les interesa, pero en realidad me parece una enorme fuente de estrés y trabajo administrativo. Cuando me enamoré del desarrollo por primera vez, lo divertido era programar en sí; pasaba todo el día escribiendo código y aprendía muchísimo. Ahora, después de más de 10 años de carrera, mi forma de pensar cambió hacia algo más de negocio: "¿para qué deberíamos programar esto en primer lugar?". En las reuniones, si otro equipo pregunta "¿se puede hacer esto?", la respuesta casi siempre es "SÍ". Técnicamente, casi todo se puede. Pero la pregunta de verdad importante es "¿qué tan difícil es?" o "¿por qué deberíamos hacerlo?". Sigo pensando que lo importante no es la capacidad de iterar o lanzar muchas cosas, sino mirar la esencia del problema.
  • Esto expresa exactamente cómo me siento. A mí tampoco me gusta nada el trabajo de vigilar y administrar IA. Además, me asusta que esta programación basada en IA esté normalizando una realidad en la que dependes de cuentas opacas de grandes corporaciones sin ninguna validación real.
  • No hace falta preocuparse tanto. Yo también estoy mentoreando a un ingeniero junior en mi equipo. A esta persona le cuesta muchísimo mejorar el código, porque si funciona, ya se da por satisfecha. La estructura no es buena y hay pequeños problemas e issues de seguridad escondidos por todas partes. Todo eso pasa incluso con apenas 3 archivos de Python. En nuestro equipo hay 10 desarrolladores, y si usamos LLM, la diferencia en calidad de código se amplía aún más según la experiencia de cada quien. En los 6 meses antes de que se adoptara oficialmente el uso de LLM, lo que sentí fue justamente eso: en la práctica, la brecha entre junior y senior, y entre gente más o menos experimentada, se hace más grande. Coincido bastante con Simon.
  • En esencia, solo hay que recordar que cuanto más conocimiento tiene una persona, más poder le da la herramienta, no menos.

• A inicios de 2023, más o menos cuando salió GPT-4, pasó algo parecido en la industria de la traducción. En traducción inglés-japonés, que es el campo en el que trabajé, la traducción automática por primera vez se acercó al nivel humano. En ese momento tuve muchas discusiones con traductores profesionales, y como aquí, muchos expresaban desilusión por miedo a que sus habilidades difíciles dejaran de tener sentido. Mucha gente decía también que, si ahora usabas LLM como asistente, incluso desaparecía la parte desafiante y entretenida del proceso. La mayoría de los traductores que conocí trabajaban como freelancers y eran del tipo que traduce cada oración con mucho cuidado. La idea de convertirse en gestores de grandes proyectos de traducción no les atraía mucho, y aunque pudieran aprovechar habilidades de comunicación cultural y contextual muy avanzadas, tenían poca motivación para ello. Hoy no hago tanta traducción, pero sigo de cerca los avances de la IA y a veces comparo modelos con trabajos de traducción. Últimamente he estado probando sistemas de traducción basados en múltiples LLM superpuestos, donde se revisan y mejoran mutuamente. En algunos documentos, los resultados son realmente casi indistinguibles de una traducción humana de altísimo nivel. El costo de la API no era barato, pero para traducciones importantes valía completamente la pena. Y al diseñar ese tipo de sistema de "vibe translation", mi experiencia como traductor claramente me ayudó. Se parece mucho a lo que Simon llama vibe engineering. A mi edad actual (68 años), eso me parece bien, pero si los LLM y demás hubieran aparecido al principio de mi carrera, en mis años 5 a 10, creo que probablemente habría dejado la traducción.

  • El tema de la traducción es excelente para hablar de LLM, gracias por compartir la experiencia. Por otro lado, la mayoría de la gente no atribuye un valor profundo al trabajo de los traductores. Por ejemplo, casi nadie recuerda quién tradujo un libro, y como hoy la gente ya no lee tanto como antes, eso puede ser aún más cierto. Además, por esa misma razón, tradicionalmente la traducción siempre se ha contratado y pagado por cantidad de palabras o de líneas. Se la trata como un chequeo final, como pasa con la seguridad de software. Las áreas de traducción que de verdad podrían conservar una ventaja competitiva futura serían el ámbito legal, porque ahí una persona tiene que asumir litigios o responsabilidad, o la interpretación simultánea o presencial, porque requieren trato cara a cara y encuentros reales.

• Últimamente me parece un poco ridículo cómo en la comunidad tecnológica se empuja demasiado la idea de que "programar es más rápido y la productividad sube". Hay un ambiente donde solo importa sacar resultados rápidos. En mi experiencia, muchas veces los LLM producen código verboso y desordenado. Claro, pueden ser más rápidos que yo, pero aun así siento que el código que yo hago despacio termina siendo mucho mejor. Esta cultura de chatear todo rápido, sacar algo rápido y llevarlo rápido a producción ya fue parte de lo que causó la avalancha de productos web mal hechos de antes. Más allá de palabras de moda como vibe coding o vibe engineering, deberíamos discutir seriamente por qué necesitamos tanta velocidad aunque sea de baja calidad, y por qué no podemos mejorar más la automatización y los procesos en sí. Por ejemplo, puedes generar pruebas unitarias rapidísimo, pero también deberíamos preguntar por qué necesitamos tantas pruebas unitarias en primer lugar. Claro que son necesarias, pero siento que la abstracción, la visión de más alto nivel, sí está avanzando, mientras que las herramientas de nivel inferior, las más detalladas, avanzan mucho más lento.

  • El problema esencial en estos debates sobre ingeniería de software es que, aunque las herramientas y los lenguajes parezcan los mismos, en la práctica hay diferencias enormes en tolerancias, seguridad, compliance y estándares de mantenimiento. Hay quien solo quiere hacer un prototipo simple rápido, y hay quien trabaja con hojas de ruta a 10 años o con datos sensibles. Como esas dos perspectivas se mezclan, conviven tanto la idea de que sacar cosas rápido es una capacidad clave como la preocupación de que eso puede terminar en resultados espantosos. Ninguna de las dos posturas está necesariamente equivocada, pero da la impresión de que casi siempre se discute ignorando el contexto real del trabajo y el nivel de riesgo.
  • Realmente los LLM sí ayudan muchísimo a la velocidad de desarrollo. Yo programo desde quinto de primaria, llevo más de 20 años haciéndolo, y la gente a mi alrededor reconoce que soy rápido, pero después de adoptar LLM mi escala creció una barbaridad. El tablero ya cambió por completo y ahora la cuestión es si te adaptas o no. También tengo muchas quejas sobre la incertidumbre del futuro, pero si eres un ingeniero en una situación parecida, lo entiendo totalmente.
  • Voy a intentar desarrollar el argumento de por qué la velocidad es tan importante en desarrollo de software. No digo que mi postura sea necesariamente correcta ni que tenga datos reales que la respalden. Incluso puede que las definiciones sean imprecisas. Para empezar, podríamos llamar "software trivial" al caso donde todo el mundo entiende claramente su valor y su solución, donde la verificación automática es posible, o donde solo existe una forma de implementarlo. Pero la mayor parte del software real no es trivial. Siempre aparecen bugs, requisitos faltantes, abstracciones que hacen agua, funcionalidades inútiles, problemas de integración, de rendimiento, de seguridad, complejidad y dolores de cabeza de mantenimiento. No importa qué tan brillante sea el desarrollador ni qué tan bien esté escrito el código: esos problemas son inevitables. Solo se revelan y se van corrigiendo poco a poco mediante feedback repetido, uso real, mantenimiento y muchísimos experimentos. Es decir, no puedes hacer el código perfecto de una sola vez; la calidad mejora a través de múltiples iteraciones. La calidad total del software está dominada por la cantidad de estos "bucles de retroalimentación". Y el tiempo que toma completar cada vuelta limita también cuántas iteraciones puedes hacer. Al final, cuanto mayor sea la velocidad de producción, más bucles de retroalimentación puedes recorrer, y por tanto el software puede evolucionar hacia algo mejor. El código lento pero de alta calidad también tiene un límite si solo permite una sola iteración; en cambio, incluso algo de baja calidad, si puede iterarse infinitamente, podría terminar llegando a un mejor resultado.
  • En cinco años esto va a parecer uno de los mejores ejemplos de falacia del costo hundido del mundo.

• Creo que un nombre mejor que "vibe coding" sería "agentic coding" o incluso "agentic software engineering". Mi flujo de trabajo empieza con el code plan de Claude, y el primer paso siempre es crear una especificación clara. Uso TDD y además fuerzo mediante automatización ciertas reglas ocultas de calidad de código que yo defino. Por ejemplo, si algo rompe el design system, no se puede hacer commit del código; y también automatizo revisiones para asegurar separación por capas, como obligar a que los handlers HTTP pasen por la capa de servicios. Le recuerdo periódicamente al modelo que siga bien TDD, y Claude 4.5 lo recuerda mucho mejor que 4.1. Gracias a esta base de TDD, las code reviews de los PR se vuelven facilísimas. También hice una herramienta simple que le pasa el PR y la especificación a Gemini para que marque automáticamente inconsistencias, omisiones y errores. Es una muy buena herramienta de respaldo. Pero al final, lo importante es tener la capacidad de juzgar por ti mismo cuál es el resultado que quieres y en qué momento el agente se está desviando. En definitiva, "entrada basura, salida basura; entrada de calidad, salida de calidad".

  • Mencionaste que le recuerdas TDD al modelo, pero en vibe coding, ¿el agente realmente recorre repetidamente el loop red-green-refactor de TDD? ¿O más bien genera todo el resultado de una sola vez?
  • En vez de decirle vibe based, me parece que "slop-coding" le queda mejor.

• Tengo dudas de que el nombre "vibe engineering" sea realmente correcto. En la práctica, se trata de ponerle al agente toda clase de restricciones: pruebas automáticas, planificación previa, documentación detallada, formateo/lint de código, QA manual, etc. Yo también empecé con vibe coding después de leer a Karpathy, y al principio viví ese flujo de reenviar varias veces incluso cuando el código se atora, confiando en el proceso completo. Pero conforme gané experiencia, me di cuenta de que al final tienes que controlar el modelo. Operar agentes se parece al karting: necesitas muchas restricciones alrededor, como las llantas que bordean la pista. El Constraint Harness es lo esencial, y el código en sí se vuelve fácil de generar y regenerar. En adelante, lo importante será construir buenas pruebas y restricciones para el trabajo producido por IA.

  • El término "vibe engineering" suena demasiado ligero y poco serio. ¿No sería mejor un nombre más neutral y que describa la función real, como "LLM-assisted programming"? Claro, tiene menos impacto.

• "Planificación previa" también podría llamarse spec-driven development. En realidad, quizá todo desarrollo, dicho de forma simple, siempre se basó en especificaciones previas. Pero la verdadera esencia está en esa "forma muy extraña de gestión": dar instrucciones claras, suficiente contexto y retroalimentación accionable. Viéndolo solo en texto, se parece más a waterfall que a agile.

• Parece que ahora el término vibe-coding ya se extendió para abarcar toda la programación basada en IA. De hecho, cuando yo trabajo con IA, se siente más como pair programming, y sí pienso "de verdad estoy vibe-ing". Aun así, creo que esa forma original de vibe-coding de simplemente soltarle el volante, tipo "Take the wheel, LLama of God", va a seguir usándose bastante, así que haría falta una palabra nueva para diferenciarla. Me gustaría proponer “Yolo-Coding”. Además encaja bien con la línea no-code, low-code, yolo-code.

  • A mí me parece mejor que vibe coder conserve una imagen negativa, parecida a no-code. No me encanta el término vibe engineer, pero de todos modos creo que en el futuro el nombre mismo de ingeniero o desarrollador ya va a asumir por defecto el uso de agentes, y el desarrollo "manual" podría volverse más bien la excepción.
  • En $enterprise, tratando de encontrar una forma de distinguir entre "responsible vibing" y "YOLO vibe coding", terminamos llegando al término "agent assisted coding", porque hacía falta sí o sí un acrónimo de tres letras.
  • El significado original de "vibe coding", como lo publicó Ilya Sutskever en Twitter, era básicamente meter un prompt y luego copiar, pegar y ejecutar el resultado sin siquiera revisarlo, sin análisis ni validación.
  • Personalmente, veo AI-assisted coding como algo al nivel de autocompletado o de ayuda para leer documentación poco amigable. Vibe coding sería:
  • el desarrollador no entiende en absoluto el código que escribió el LLM
  • se genera deuda técnica al instante sin ninguna revisión de código
  • legalmente queda totalmente vulnerable en la UE/EE. UU. por problemas de protección de copyright

  Creo que la falla más crítica de vibe coding es que el código producido por un LLM, en esencia, no puede protegerse ni registrarse por copyright. Hay algunas excepciones, como Reino Unido, pero en la mayoría de los países lo veo muy mal.

  • Yo también le hice a claude un comando tipo /yolo para que simplemente ejecute sin mucha guía.

• Hay un experimento donde unas palomas interactúan con un dispositivo que entrega comida al azar, y como creen que la recompensa se debe a su conducta, empiezan a repetir toda clase de bailes y movimientos graciosos.

  • Puede que esos bailes graciosos no sean otra cosa que "escribir pruebas" o "hacer planificación".
  • ¿Tienes por casualidad algún paper o referencia? Si busco "palomas haciendo monerías" solo me salen videos de redes sociales y cuesta encontrarlo.

• "Augmented Engineering" (AE) suena mejor. Amplías tus capacidades con el poder de la IA y puedes lograr los mejores resultados, así que sería "ingeniería aumentada". AE también puede entenderse como "Advanced Engineering". Como la IA te permite acceder al instante a conocimiento técnico de última generación, naturalmente sería una ingeniería más avanzada. En cambio, vibe no me convence.

  • No hace falta preocuparse tanto por la terminología; si le pones un nombre aparte, hasta puede dar la impresión de que la programación con IA es algo que solo aplica a ciertos desarrolladores. En el futuro, la programación tradicional será el caso excepcional, y la palabra vibe probablemente también desaparezca pronto.
  • Tengo una objeción con la última frase: la IA no solo puede hacerte absorber "al instante" conocimiento de ingeniería reciente, sino también errores repetidos, fallas, malentendidos y defectos de diseño acumulados en los últimos 1 a 10 años. O sea, nunca deberías confiar de forma acrítica en la información que te da la IA; siempre hay que verificar las fuentes, y hasta confirmar que esas fuentes no hayan sido generadas también por IA. Como los datasets se siguen contaminando, hay que ser todavía más cuidadosos.
  • Quisiera preguntar si "Augmented Engineering" realmente necesita ser un nombre aparte. Al final eso sigue siendo simplemente "ingeniería"; así como no decimos "book-assisted engineering" solo porque alguien trabaja consultando libros, aquí pasaría lo mismo con vibe. Si acaso, podríamos llamarlo "Yolo engineering", o incluso "Machine Outsourced Irresponsible LMAO Engineering". Y lo de "Advanced Engineering" también me parece inflado.

• Simon siempre da exactamente en el clavo, pero el verdadero problema no es tanto "coding" como la palabra "vibe". Incluso si lo cambias por vibe engineering, sigue transmitiendo el matiz de "seguir adelante sin tener idea de lo que estás haciendo". En ese sentido, me parece mejor un término como "AI-assisted software engineering", porque permite distinguir con más claridad ambos extremos.

[kimjoin2]

Inventar nombres sin sentido;