en LinkedIn hace unos días diciendo que muchos de los mejores ingenieros ahora solo usan IA para codificar.
Llegó a miles y obtuvo bastantes opiniones acaloradas. El espacio está claramente dividido en esto, y la gente en contra en su mayoría piensa que se trata de subcontratar un proyecto completo a un sistema que no puede construir software confiable.
No tuve tiempo de responder a todos los comentarios, pero creo que hoy en día existe un malentendido fundamental sobre cómo se puede utilizar la IA para construir. Puede que le sorprenda saber que gran parte de esto sigue siendo ingeniería, sólo que en un nivel diferente al anterior.
Así que veamos cómo ha evolucionado este espacio, cómo planificar antes de usar la IA, por qué el juicio y el gusto siguen siendo importantes, qué herramientas de codificación de IA están ganando y dónde siguen estando los cuellos de botella.
Porque la ingeniería de software puede estar cambiando, pero no parece estar desapareciendo.
El espacio se mueve rápido
Antes de ver cómo construir con estas herramientas, vale la pena comprender qué tan rápido han cambiado las cosas.
Cursor se convirtió en el primer IDE real asistido por IA en 2024, a pesar de que se lanzó en 2023, pero lograr que produjera algo bueno sin dejar un rastro de errores no fue fácil.
Luché mucho incluso el verano pasado al usarlo.
Muchos de nosotros también recordamos el fiasco de Devin, el llamado "ingeniero junior en IA" que realmente no podía terminar nada por sí solo (aunque de esto fue hace algún tiempo).
Los últimos meses han sido diferentes y también lo hemos visto en las redes sociales.
Spotify afirmó públicamente que sus principales desarrolladores no han escrito ni una sola línea de código manualmente desde diciembre. Según se informa, el propio equipo interno de Anthropic tiene más del 80% de todo el código implementado escrito con asistencia de IA.
Y Andrej Karpathy dijo que la programación cambió más en los últimos dos meses que en años.
Anthropic también descubrió que Claude Opus 4.6 descubrió 22 vulnerabilidades novedosas en Firefox en dos semanas, 14 de ellas de alta gravedad, aproximadamente una quinta parte del recuento total de correcciones de alta gravedad de Mozilla en 2025.
Las personas que utilizan estas herramientas a diario ya saben que están mejorando. Pero "mejorar" no significa que el trabajo de ingeniería haya desaparecido.
Tú planificas, códigos AI
Entonces, si las herramientas son tan capaces, ¿por qué no puedes simplemente decir lo que quieres y construirlo? Porque la planificación, la arquitectura y el pensamiento sistémico siguen siendo la parte difícil.
Piense en la IA como un asistente, no como un arquitecto. Usted sigue siendo quien dirige el proyecto y debe pensarlo detenidamente antes de comenzar a delegar cómo se debe construir.
Cuanto mejor sea su descripción general de las diferentes capas (es decir, frontend, backend, seguridad, infraestructura), más fácil será instruirlo correctamente.
Si no mencionas lo que quieres, normalmente no lo consigues.
Esto podría significar usar un agente para investigar primero diferentes enfoques: opciones de pila tecnológica, compensaciones de costo y rendimiento, o por qué elegiría un lenguaje o marco en lugar de otro.
Si está creando autenticación, investigue. Obtenga una breve revisión de cualquier herramienta que esté considerando, ya sea Cognito, Auth0 u otra, y verifique si realmente admite lo que necesita.
Esto significa que tienes que aprender algo por tu cuenta.
Si está almacenando datos de usuario, es posible que necesite una API CRUD para ello. Un agente puede crearlo, documentarlo adecuadamente y luego otro agente puede usar esa documentación dentro de otra aplicación.
Esto funciona mucho mejor si ya sabe cómo se deben estructurar las API, cómo funcionan los CDK en la nube o cómo encajan los canales de implementación.
Cuanto menos especifiques por adelantado, más doloroso será después cuando intentes que el agente haga cosas como "no es así" y "esto no funciona como pensé". (Soy culpable de ser tan vago).
Ahora bien, podrías mirar esto y pensar que todavía parece mucho trabajo.
Y, sinceramente, sí, todavía es trabajo. Muchas de estas piezas se pueden subcontratar, y eso hace que las cosas sean mucho más rápidas, pero sigue siendo algún tipo de ingeniería.
Boris Cherny, que trabaja en Claude Code, habló sobre su enfoque: primero el modo de planificación, iterar hasta que el plan sea correcto y luego aceptar automáticamente la ejecución.
Su idea que sigue siendo citada en la comunidad tecnológica es: "Una vez que el plan es bueno, el código es bueno".
Entonces, piensas. El agente de IA construye.
Entonces tal vez lo evalúes, lo redirijas y lo pruebes también.
Quizás eventualmente veamos mejores agentes orquestadores que puedan ayudar con el diseño, la evaluación y la estructuración de sistemas, y estoy seguro de que la gente ya está trabajando en esto.
Pero por ahora, esta parte todavía necesita un humano.
Sobre el juicio y el gusto
La gente habla mucho sobre el juicio, y también sobre el gusto, y sobre cómo esto simplemente no se puede delegar en un agente de IA. Básicamente, se trata de saber qué preguntar, cuándo rechazar, qué parece riesgoso y tener la capacidad de saber si el resultado es realmente bueno.
El juicio es básicamente un reconocimiento que se construye al haber estado cerca del trabajo y, por lo general, viene con algún tipo de experiencia.
Las personas que han trabajado cerca del software tienden a saber dónde fallan las cosas. Saben qué probar, qué suposiciones cuestionar y, a menudo, pueden darse cuenta cuando algo se está construyendo mal.
Esta es también la razón por la que la gente dice que es irónico que muchas de las personas que están en contra de la IA sean ingenieros de software. Son los que más pueden ganar con estas herramientas precisamente porque ya tienen ese criterio.
Pero también creo que personas de otros espacios, ya sea desarrollo de productos, diseño técnico o UX, han desarrollado su propio criterio que puede trasladarse a la construcción con IA.
Creo que las personas que tienen afinidad por el pensamiento a nivel de sistema y que pueden pensar en modos de falla también tienen algún tipo de ventaja.
Por lo tanto, no es necesario haber sido desarrollador, pero sí saber qué aspecto tiene lo que estás intentando construir.
Pero si todo es nuevo, aprende a hacer muchas preguntas.
Si está creando una aplicación, pídale a un agente que realice una auditoría preliminar de la seguridad de la aplicación, califique cada área, le dé una breve explicación de lo que hace cada una y le explique qué tipo de violación de seguridad podría ocurrir.
Si trabajo en un espacio nuevo, me aseguro de enfrentar a varios agentes entre sí para no quedar completamente ciego.
Por lo tanto, el punto es trabajar con los agentes en lugar de subcontratarles ciegamente todo el proceso de pensamiento.
Si el criterio es saber qué cuestionar, qué priorizar, qué es riesgoso y qué es lo suficientemente bueno, el gusto es más bien el estándar de calidad. Es detectar cuando la UX, la arquitectura o la calidad de salida se sienten mal, incluso si técnicamente funciona.
Pero nada de esto tiene solución. El juicio es algo que se construye, no algo con lo que se nace. El gusto puede ser un poco más innato, pero también debería mejorar con el tiempo.
Como soy autodidacta, soy bastante optimista de que las personas puedan saltar a este espacio desde otras áreas y aprender rápido si tienen afinidad por ello.
También pueden estar motivados por otras cosas que pueden resultar útiles.
¿Qué herramientas asistidas por IA están ganando?
Ahora los he sobrecargado con todo antes de llegar a las herramientas de IA reales, así que repasémoslas y veamos cuál parece estar ganando.
Cursor se lanzó en 2023 y se mantuvo en escena durante mucho tiempo. Luego, OpenAI, Anthropic y Google comenzaron a impulsar sus propias herramientas.
Observe a continuación la cantidad de menciones de Claude Code, Cursor y Codex en las comunidades tecnológicas durante el último año. Esto resume bastante bien cómo ha cambiado la narrativa durante el año pasado.
Si va a Google Trends e investiga un poco, mostrará tendencias similares, aunque no muestra que la tendencia del Cursor haya disminuido a mediados del verano pasado.
El destacado es, obviamente, Claude Code. Pasó de ser un proyecto paralelo dentro de Anthropic a la herramienta de desarrollo más discutida en menos de un año.
El volumen de conversación a su alrededor eclipsa a Cursor, Copilot y Codex combinados en las comunidades que este rastrea.
Es fascinante cómo estas plataformas propietarias de LLM pueden simplemente apoderarse de un espacio en el que quieren tener éxito y prácticamente aplastar a sus competidores (por supuesto, todavía subsidiando su propia herramienta a un ritmo que ningún IDE de terceros puede igualar).
Pero además de la economía simbólica subsidiada de estas herramientas, la gente pasó de escribir bloques de código y parte de su código base a simplemente decir "Dejé de abrir mi IDE".
Entonces, estas herramientas ahora nos permiten pasar de la codificación asistida a la codificación delegada.
La diferencia fundamental que la gente sigue señalando con respecto a otras herramientas (como Cursor) es que Claude Code funciona en su base de código como un colega al que le entrega el trabajo en lugar de dentro de su editor sugiriendo código.
La gente también sigue descubriendo que Claude Code es útil para cosas que no son programación.
Tengo un amigo que trabaja en la organización de todo su equipo de 15 personas dentro de VS Code con Claude Code. En realidad, nada de esto es código y solo usa el IDE para la organización.
Ahora los límites de tarifas son una cosa constante, siendo Claude Code el más rápido que te agotarás semana tras semana. Normalmente se me acaba el jueves y tengo que esperar hasta el lunes.
Por eso tenemos varias suscripciones, como también Codex.
Ahora bien, tal vez sea una cuestión de gustos, pero la mayoría de las personas con las que hablo recurren a Claude Code para la mayor parte de su trabajo, siendo Codex su compañero.
Habilidades del código Claude
Mencionemos brevemente las Habilidades también aquí junto con Claude Code.
Creo que fue hecho para que la gente escribiera instrucciones internas basadas en proyectos, donde codificas las lecciones en un archivo de habilidades y se lo entregas a Claude antes de que comience a funcionar.
Estos son archivos de rebajas (junto con scripts, activos y datos) que se encuentran en su proyecto y deben cubrir todo, desde cómo estructurar las API hasta lo que espera su canal de implementación y cómo manejar casos extremos en un marco particular.
Pero lo he encontrado como una forma interesante de transferir conocimientos. Digamos que es un desarrollador que necesita crear una aplicación móvil y nunca ha tocado React Native.
Si puede encontrar una habilidad con mejores prácticas creada por alguien que realmente sepa lo que está haciendo, le resultará más fácil desarrollar ese proyecto. Es como si estuvieras tomando prestada la experiencia de otra persona y la inyectaras en tu flujo de trabajo.
Lo mismo ocurre con el diseño de interfaz, los estándares de accesibilidad, la arquitectura del sistema, el SEO, el wire framing de UX, etc.
Ahora he intentado construir algunos de estos con IA (sin ser un experto en el campo) con más o menos éxito.
Tal vez este patrón crezca y podamos instruir mejor a los agentes de antemano, tal vez vendiendo habilidades entre nosotros, para que no tengamos que aprender tanto, quién sabe.
Cubrimos también los cuellos de botella
Debería cubrir los temas también. No todo esto es arcoíris y sol.
Los LLM pueden ser poco confiables y causar daños reales, no tenemos el control de la deriva del modelo y luego está la cuestión de cómo se construye el juicio si ya no estamos codificando.
El otro día me estaba tirando de los pelos porque una integración no funcionaba. Le pedí a Codex que documentara cómo usar una API desde otra aplicación y luego envié esa documentación a Claude Code.
Me tomó unos minutos construir la integración y luego una hora depurarla, pensando que era algo completamente distinto. Pero, esencialmente, Claude Code había creado la URL base para el punto final, que debería haber sido lo único que verifiqué pero no lo hice.
Seguí preguntándole de dónde sacaste este y decía: "Realmente no puedo decirlo".
Ya conoces el trato.
Así que tiene sentido que las cosas se pongan bastante mal cuando se les da a estos agentes poder real. Ya hemos escuchado las historias.
En diciembre, Kiro, el agente de codificación de inteligencia artificial de Amazon, heredó los permisos elevados de un ingeniero, evitó la aprobación de dos personas y eliminó un entorno de producción de AWS en vivo. Esto provocó un apagón de 13 horas.
Sé que ahora hicieron obligatorio aprobar el código generado por IA.
Pero dudo que la revisión manual pueda ser la principal capa de control si la IA escribe tanto código. Entonces me pregunto si la respuesta es mejores restricciones, un radio de explosión más estrecho, pruebas más sólidas y mejores comprobaciones del nivel del sistema de alguna manera.
Será interesante ver qué nos depara el futuro aquí.
Hay más historias como esta, por supuesto.
Por ejemplo, Claude Code borró la base de datos de producción de un desarrollador mediante un comando Terraform, destruyendo 2,5 años de registros (aunque Claude le advirtió antes). El Codex de OpenAI borró toda la unidad F: de un usuario debido a un error de escape de caracteres.
También hay una deriva del modelo sobre la que simplemente no tenemos control como usuarios. Esto significa que las herramientas pueden degradarse, tal vez debido a nuevas versiones, correcciones de reducción de costos, etc.
Que el modelo simplemente no funcione como antes es más que una molestia.
Esto no es nuevo y la gente ha creado sus propias herramientas de seguimiento para ello.
Marginlab.ai ejecuta diariamente pruebas comparativas de SWE-bench contra Claude Code específicamente para rastrear la degradación. Sniffly de código abierto de Chip Huyen para rastrear patrones de uso y tasas de error.
El hecho de que la comunidad sintiera la necesidad de construir todo esto dice algo. Confiamos en estas herramientas para trabajos serios, pero no estamos a cargo de su rendimiento.
Luego está todo el asunto del juicio.
Anthropic realizó una prueba controlada con 52 ingenieros de software, en su mayoría jóvenes, y descubrió que el grupo que utilizó IA obtuvo una puntuación un 17% más baja en pruebas de comprensión, aproximadamente dos calificaciones peores que el grupo que codificó a mano.
Cuando subcontratas la parte de escritura del código, comienzas a perder la intuición que surge al trabajar cerca del código, la pregunta es qué tan problemático será esto.
Esta lista no es exhaustiva, también está la cuestión de cuánto cuestan realmente estas herramientas una vez que desaparezcan los subsidios.
Redondeando
Esta conversación no se trata de no necesitar experiencia en ingeniería de software ni de que la IA sea inútil.
Lo que creo que realmente está sucediendo es que la ingeniería en este espacio está cambiando. El pensamiento sistémico, la experiencia en ingeniería, la curiosidad, la amplitud de dominios y el pensamiento analítico importarán más que la capacidad de escribir el código a mano.
Quizás esto signifique que la ingeniería está ascendiendo a un nivel de abstracción, con la IA alejando el valor de la codificación manual hacia el juicio del sistema.
Pero no creo que la IA elimine la necesidad de la ingeniería en sí. En este momento, esta es una nueva forma de diseñar software, obviamente mucho más rápida, pero no exenta de muchos riesgos.
Hemos visto que el progreso supera todo lo que esperábamos, por lo que es difícil decir hasta dónde llega.
Pero por ahora, un ser humano todavía tiene que impulsar el proyecto, asumir la responsabilidad y decidir qué es bueno y qué no.
Este es mi primer artículo de opinión, ya que suelo escribir sobre la construcción en el espacio de la ingeniería de IA.
Pero como hemos estado creando software usando IA con Claude Code, parecía apropiado escribir un poco sobre este tema.
Estos siguen siendo los conceptos básicos de la ingeniería de vibraciones, sé que la gente ha ido más lejos que yo, por lo que probablemente habrá otro en el futuro hablando de lo ingenuo que fui aquí y cómo las cosas han cambiado desde entonces.
Por desgracia, así son las cosas y si escribes debes tragarte el orgullo y aceptar sentirte estúpido.
Conéctese conmigo en LinkedIn para escribir sus pensamientos, consulte mis otros artículos aquí, en Medium o en mi sitio web.
❤