Cómo convertirse en un ingeniero de IA 30 veces mejor con criterio

• En la era en que la IA genera código en grandes volúmenes, la capacidad clave que distingue el valor de un ingeniero no es la velocidad, el conocimiento ni la experiencia, sino el "criterio" (taste), es decir, la capacidad de evaluar qué vale la pena construir
• Integrantes del equipo de OpenAI Codex llegaron de forma independiente a la misma conclusión: cualquiera puede convertirse en un ingeniero 10 veces mejor si tiene buen criterio de software
• El criterio se divide en tres formas: reconocimiento (recognition), brújula (compass) y visión (vision), y todas convergen en un solo mecanismo: la calidad de una función interna de evaluación
• El valor se concentra en cinco áreas: selección del problema, arquitectura de sistemas, juicio de calidad, empatía con el usuario y comunicación
• Ahora que escribir código se ha comoditizado, la capacidad de juzgar y pensar es la verdadera habilidad central, y debe cultivarse de forma intencional

---

El mundo cambió, pero la mayoría de los ingenieros no se ha dado cuenta

• En marzo de 2025, Dario Amodei, CEO de Anthropic, predijo que la IA escribiría el 90% del código en cuestión de meses; en ese momento sonaba absurdo
• Boris Cherny, creador de Claude Code, contó que en diciembre el 100% del código que había hecho commit fue escrito por IA y que no abrió el IDE ni una sola vez
• Andrej Karpathy, que había llamado “slop” a las herramientas de coding con IA, cambió completamente de postura en diciembre
  • “Nunca me había sentido tan rezagado como programador, y la profesión se está reconfigurando de forma drástica”
  • DHH, creador de Ruby on Rails, reconoció que su resistencia se debía a que “los modelos no eran lo suficientemente buenos”, pero que ahora la situación se invirtió
  • Malte Ubl, CTO de Vercel, comentó que “el costo de producir software está convergiendo a cero”
• Entre noviembre y diciembre de 2025, Opus 4.5, GPT-5.2 y Gemini 3 cruzaron un umbral de capacidad antes invisible, llevando el código generado por IA al nivel de un ingeniero experimentado en una amplia gama de tareas, y reduciendo los tiempos de horas a minutos
• Cuando generar código se vuelve una commodity, lo que queda es la ingeniería de software: descomponer problemas, decidir qué construir, diseñar pruebas, confiabilidad y escalabilidad, y juzgar trade-offs; en otras palabras, criterio

Qué es realmente el criterio

• En los mejores equipos de ingeniería existen tres definiciones de criterio, pero en realidad son la misma capacidad vista desde distintos ángulos

• El criterio como reconocimiento

  • La capacidad de sentir cuál de dos implementaciones es mejor incluso antes de poder explicar por qué
  • Emma Tang: si un sistema es realmente limpio, escalable, libre de redundancias y simple de entender, eso es una cuestión de criterio
  • Como un chef que prueba una salsa y sabe que le falta acidez antes de identificarlo conscientemente, el pattern matching opera más rápido que el razonamiento consciente
  • El caso del equipo de Codex al elegir Rust en lugar de TypeScript para su CLI
    • Ambos funcionaban, pero reconocieron que las restricciones de Rust —tipado fuerte, manejo explícito de memoria y dependencias mínimas— generaban un efecto en la cultura de ingeniería que iba más allá de sus ventajas técnicas
    • No fue una decisión de “lenguaje técnicamente superior”, sino de “lenguaje que moldea los comportamientos que el equipo quiere”
  • Mal criterio: elegir Rust porque está de moda o porque un blog dice que es más rápido, sin entender sus efectos de segundo orden

• El criterio como brújula

  • Es la forma que Tibo describió al decir que un ingeniero debe tener “su propia brújula”: no se trata de evaluar lo que ya existe, sino de saber qué construir después
  • El ingeniero que, antes de escribir una sola línea de código, dice: “esta no es la funcionalidad correcta”
  • El caso de Boris Cherny, que desarrolló la función de lista de tareas de Claude Code en dos días con cerca de 20 prototipos
    • Probó tareas inline, interfaz tipo drawer, pills interactivos, visualización en la parte inferior de la pantalla y más, hasta converger en una forma que no se sentía arbitraria, sino inevitable
    • Después pudo explicar por qué la versión final era mejor, pero esa insatisfacción inicial con las versiones intermedias fue el criterio funcionando como brújula
  • El criterio-brújula es más escaso que el criterio como reconocimiento, porque opera más arriba en la cadena que la mera ejecución

• El criterio como visión

  • Se expresa en la frase de SQ Mah: “los humanos definen la evolución”, y es la forma más difícil: saber no qué es bueno hoy, sino qué será importante dentro de dos años
  • Peter Steinberger, creador de OpenClaw, ejecuta de 5 a 10 agentes al mismo tiempo y dedica la mayor parte de su tiempo a arquitectura y diseño de sistemas
    • Mencionó que “la mayor parte del código es una aburrida transformación de datos” y que la energía debe concentrarse en el diseño del sistema
  • La siguiente prioridad del equipo de Codex es la planificación basada en contexto rico, que requiere información fuera del codebase, como objetivos de negocio, dinámica del mercado y prioridades del equipo
    • No es la visión aplicada a un generador de código mejor, sino a una estrategia de producto orientada a un futuro donde el modelo entienda por qué existe el software

• Definición integrada

  • Las tres formas convergen en un solo mecanismo: el criterio es la calidad de una función interna de evaluación
  • En el reconocimiento, la función de evaluación actúa sobre el resultado terminado; en la brújula, sobre las posibilidades y la dirección; en la visión, sobre el futuro y la trayectoria
  • En un mundo donde la IA genera código, el trabajo humano es evaluar: decidir qué construir, juzgar si el resultado es suficiente y detectar cuándo cambiar la arquitectura; la evaluación pasa a ser el trabajo mismo

Por qué algunos ingenieros ganan muchísimo más

• Antes de la IA, la brecha de compensación se explicaba por tres factores: empresa, antigüedad y especialidad; pero la IA está mezclando por completo esas tres variables
• La diferencia entre un ingeniero sobresaliente y uno promedio en una startup se amplió de 3x a 10x, porque el primero puede usar IA para producir lo que antes requería un equipo pequeño
• El eje de la experiencia se está desplazando: importa menos la experiencia escribiendo código y más la experiencia tomando buenas decisiones
  • Saber “React” vale menos; saber “diseñar sistemas confiables bajo carga” vale más
• Lo que tienen en común los ingenieros con mayor diferencia de impacto es que toman decisiones que se acumulan de forma compuesta
  • Una sola buena decisión de arquitectura puede ahorrar meses de trabajo a lo largo de un año
  • Una sola buena decisión de producto puede determinar si una funcionalidad se adopta de verdad o no
• Incluso trabajando más duro, alguien puede generar solo la mitad del valor que una persona con mejor criterio; hacer correr 2 agentes sobre el problema correcto produce más valor que correr 8 sobre el problema equivocado
• En el caso de OpenAI, los ingenieros más productivos no fueron quienes generaron más código, sino quienes cambiaron su foco para dedicar más tiempo a conversaciones con usuarios, dirección de producto y empatía
  • Algunos volvieron al autocompletado por tabs porque sentían que “perdían la intuición del codebase”, y ambas respuestas son válidas

Dónde se genera realmente el valor

• Existen cinco áreas donde el criterio crea valor desproporcionado; la mayoría de los ingenieros compite solo en una o dos

• Zone 1: elección de problemas

  • Decidir qué hacer es la decisión de criterio con mayor apalancamiento, pero la mayoría casi no lo piensa
  • Un ingeniero con criterio se pregunta: “si resuelvo bien esto, ¿desaparecen otros cinco problemas?”
  • Peter Steinberger intercambia con el agente durante mucho tiempo para pulir el plan, desafiarlo y rebatirlo, y solo ejecuta al agente cuando queda satisfecho; el plan es el trabajo y la ejecución se delega
  • En el sistema de permisos de Claude Code, en lugar de elegir RBAC complejo y políticas detalladas, se optó por el enfoque más simple posible (pedir permiso y recordar la respuesta) para lanzar algo rápido e intuitivo

• Zone 2: arquitectura de sistemas

  • Es la forma en que encajan las piezas, y el área donde el criterio tiene la vida útil más larga; una buena decisión sigue pagando dividendos dos años después, una mala se acumula como deuda técnica que exige reescritura
  • La decisión de convertir el loop del agente de Codex en una máquina de estados, la decisión de Claude Code de escribir “la menor cantidad posible de lógica de negocio” y la obsesión de OpenClaw por la extensibilidad modular son todas decisiones de criterio arquitectónico
  • Boris Cherny: “Cada vez que sale un nuevo modelo, borramos un montón de código y dejamos la menor cantidad de código posible alrededor del modelo”
    • La mayoría de los equipos agrega código en cada release, pero el equipo de Claude Code lo elimina; el modelo es el producto y todo alrededor debe ser lo más delgado posible

• Zone 3: juicio de calidad

  • Es saber si algo ya está suficientemente listo para lanzarse o si necesita más trabajo; es un área donde la IA no puede ayudar (porque no conoce qué significa “suficiente” en un contexto específico)
  • La revisión jerárquica de código de Codex: el código no central recibe solo revisión de IA, mientras que el código central del agente exige revisión humana
    • El criterio está en saber qué código importa; el sistema de permisos necesita ojos humanos, actualizar el README no
  • El equipo de Codex escribe casi todo el código con prompts, pero otras áreas internas están más cerca del 70%; el 30% escrito a mano es la parte donde más importa el juicio de calidad (“regla 30/70”)

• Zone 4: empatía con el usuario

  • Es entender qué necesita realmente la otra persona, un área donde la IA es más débil
  • Los mensajes de carga contextuales de Claude Code que hizo Boris (mostrar lo que el modelo está haciendo en vez de solo un spinner) no los pidió nadie, pero se hicieron por la diferencia entre esperar sin información y esperar con información
  • Los valores predeterminados del sandbox de Codex también son una decisión de empatía con el usuario; Tibo: “aunque perjudique la adopción, no recomendamos por defecto algo que podría no ser seguro”
    • Esto parte de entender que muchos usuarios “no son tan técnicos” y podrían hacer por error cosas irreversibles; se eligió seguridad por encima de comodidad

• Zone 5: comunicación y storytelling

  • Es cómo se enmarca lo que se construyó, un terreno que los ingenieros subestiman de forma consistente pero que el mercado recompensa
  • OpenClaw de Peter Steinberger registró más búsquedas en Google durante su semana viral que Claude Code y Codex combinados
    • Un nombre claro, una demo convincente y la narrativa de “una persona produce como un equipo entero” impulsaron su difusión
  • El archivo AGENTS.md de Codex (un README para agentes de IA, no para humanos) reconoce que cambió el lector de la documentación y adapta el formato a eso

Ejemplos de criterio (y de su ausencia)

• Elección del stack tecnológico

  • Sin criterio: “TypeScript porque es lo más popular y todos lo conocen”, justificado por costumbre
  • Con criterio: Boris elige TypeScript porque para los modelos Claude está “on distribution” (algo que el modelo ya maneja bien), optimizando para las fortalezas del modelo y no para la comodidad del equipo
    • Codex eligió Rust porque quería dependencias mínimas que “te obligaran a pensar en los estándares de ingeniería que fijaste” y que pudieran inspeccionarse directamente; es la misma clase de decisión, pero en ambos casos basada en restricciones concretas y no en una preferencia general

• Cómo tratar código que no se entiende por completo

  • Sin criterio: “Lo generó la IA y pasó los tests, así que se lanza”, sin considerar si los tests son suficientes ni la mantenibilidad
  • Con criterio: Peter lanza código que no leyó, pero no de forma descuidada; “conozco la ubicación y la estructura de los componentes, y el diseño completo del sistema; normalmente eso basta”
    • Tests, linting y CI local funcionan como capas de verificación; una postura es apostar y la otra es un sistema que garantiza la corrección de manera estructural

• Respuesta a solicitudes de funcionalidades

  • Sin criterio: implementar según el ticket y pasar al siguiente después del lanzamiento
  • Con criterio: Boris crea 20 prototipos en los dos días previos al lanzamiento; no es lentitud, sino experimentación rápida para navegar hacia la solución correcta; la inevitabilidad es la huella del criterio

• Diseño para agentes de IA

  • Sin criterio: un README normal con instrucciones de configuración y endpoints de API
  • Con criterio: Codex escribe AGENTS.md para decirle a la IA cómo navegar el codebase, qué comandos de prueba usar y cómo respetar los estándares, estructurando el codebase de forma que inevitablemente permita que el modelo tenga éxito

• Cómo manejar una avalancha de PRs

  • Sin criterio: llegan PRs generados por IA pero se mantiene el mismo proceso de revisión, saturando a los revisores y bajando la calidad
  • Con criterio: el equipo de Emma Tang exige adjuntar el prompt al PR; si no está, preguntan por Slack “¿cuál fue el prompt?”
    • En el mundo de la IA, revisar la intención es más útil que revisar el código; Peter llama a los PR “prompt requests” y le interesa más el prompt de generación que el código, porque cambió la unidad de generación y también debe cambiar la unidad de revisión

Un plan para cultivar el criterio (no solo apreciarlo)

• El consejo de “acumula más experiencia” es tan inútil como “haz más ejercicio”; abajo va un plan de 90 días dividido en tres formas

• Mes 1: construir criterio de percepción mediante exposición estructurada

  • El mecanismo es exposición masiva a variaciones de calidad, seguida de reflexión deliberada
  • Semanas 1-2: estudiar 10 herramientas de desarrollo que admires
    • Instala Codex CLI, Claude Code, Linear, Supabase, el dashboard de Stripe, Vercel, Tailwind, Railway, Resend y 1 producto no software (una exhibición de museo bien diseñada o el menú de un restaurante)
    • Dedica 15 minutos a cada una y escribe: ¿qué notaste en los primeros 60 segundos?, ¿qué te dio gusto?, ¿qué te confundió?, ¿qué decisión te robarías?
    • Las buenas herramientas muestran el resultado en los primeros 30 segundos antes de explicar el proceso; las malas explican la arquitectura antes de mostrar por qué debería importarte
  • Semanas 3-4: estudiar 10 papers por su metodología, no por sus hallazgos
    • El paper original de BLEU score, el paper de Constitutional AI de Anthropic, el paper de PageRank de Google, el registro del Netflix Prize y los papers de Scaling Laws
    • Escribe: qué hace elegante a la metodología, cuál es la única intuición que la hace funcionar y cómo aplicarla a mi dominio
    • Descubrirás que principios estructurales como criterios de evaluación claros, divulgación honesta de limitaciones y formulaciones simples en vez de complejidad se repiten entre disciplinas

• Mes 2: construir criterio de brújula mediante discernimiento activo

  • Ejercicio semanal “Side-by-Side”: busca dos ejemplos del mismo tipo y escribe 500 palabras sobre por qué uno es mejor que el otro (dos documentaciones de API, dos blogs técnicos, dos diagramas de arquitectura, dos frameworks de evaluación)
    • Prohibido decir “lo prefiero”; siempre especifica el mecanismo concreto con “esto es mejor porque…”
    • Ejemplo: la documentación de Stripe es mejor porque está organizada alrededor de lo que el desarrollador quiere hacer (enviar un pago, manejar errores) y no de la arquitectura interna
  • Ejercicio diario “Practice Noticing”: cada vez que veas una herramienta, paper o código, elige una decisión del creador y anota en una oración “¿por qué esto y no la alternativa obvia?”; después de 30 días, el patrón de esas 30 observaciones será un criterio en desarrollo

• Mes 3: construir criterio de visión mediante aplicación generativa

  • Semana 9: rediseña algo que te pertenezca (el flujo de onboarding del equipo, el README de un proyecto, la experiencia de desarrollador de un pipeline de evaluación) usando lo aprendido
  • Semana 10: escribe el texto más preciso que hayas hecho hasta ahora; no el más largo ni el más completo, sino uno donde cada párrafo cumpla su función y cambie la forma de pensar del lector
  • Semana 11: diseña un sistema desde cero y explica cada decisión desde primeros principios, no desde la convención (“microservicios porque es una buena práctica” no, sino “somos un equipo de 4, el tráfico es predecible y la simplicidad de despliegue pesa más que las ventajas de escalado que no necesitaremos en 18 meses, así que monolito”)
  • Semana 12: comparte tu criterio, enseña la diferencia entre dos enfoques y escribe un AGENTS.md para tu propio codebase; la capacidad de codificar criterio en sistemas y documentación es lo que separa la habilidad individual de la capacidad organizacional

Cinco proyectos para desarrollar criterio rápidamente

• 1. Construir un framework de evaluación para código generado por IA

  • No un linter o un test runner, sino un framework que responda: “¿este código de IA es lo bastante bueno para producción?”, definiendo una rúbrica propia (corrección, mantenibilidad, eficiencia, seguridad, estilo)
  • Aplicarlo y puntuar 50 PR reales generados por IA, ajustar la rúbrica con base en las puntuaciones sorprendentes, publicar los resultados y desarrollar el criterio de la Zona 3 (juicio de calidad)

• 2. Rediseñar el onboarding de un proyecto open source

  • Hacer un fork de una herramienta cuya tecnología respetas pero cuyo onboarding resulta frustrante, rediseñar los primeros 5 minutos de la experiencia del desarrollador, escribir el README y la guía de inicio, y estructurarlo para que un nuevo contribuidor pueda abrir un PR en su primer día
  • Desarrollar al mismo tiempo la Zona 4 (empatía con el usuario) y la Zona 5 (comunicación)

• 3. Crear una “prueba de criterio” para el equipo

  • Redactar 10 pares de enfoques de implementación; en cada par, uno refleja un mejor criterio, y preguntar a 5 ingenieros cuál es mejor y por qué
  • El resultado interesante no es la respuesta correcta, sino el desacuerdo de opiniones; donde los estándares no están alineados nace el origen de bugs, deuda técnica y retrabajo, y ahí se construye el criterio organizacional de mayor apalancamiento

• 4. Lanzar un producto con una restricción de 48 horas

  • No un prototipo, sino un producto funcional que otras personas usarían; la limitación de tiempo obliga constantemente a tomar decisiones de criterio (qué incluir y qué recortar)
  • Si gastas 6 horas en una función equivocada, quemas una cuarta parte del tiempo, así que las consecuencias de una mala decisión son inmediatas

• 5. Escribir un blog técnico que cambie la forma de pensar

  • No un tutorial o un how-to, sino un texto que reconfigure un concepto familiar para que el lector lo vea de otra manera después (darse cuenta de que el criterio es evaluación, reconocer que borrar código con cada lanzamiento de modelo no es una costumbre sino una filosofía arquitectónica)
  • Desarrollar la Zona 5 (comunicación y storytelling); una perspectiva genuina es la base de todo criterio

Optimizar la carrera con enfoque en el criterio

• Dejar de competir por velocidad

  • Si la IA escribe código a velocidad de máquina, competir por velocidad de programación es un juego perdido; vale más quien dedica 30 minutos a pensar cuáles 50 líneas realmente hacen falta que quien genera 500 líneas por hora
  • La velocidad de implementación ya se volvió un commodity, y lo que no se ha comoditizado es el juicio sobre qué implementar y cómo hacerlo

• Invertir en las “habilidades adyacentes” que el criterio necesita

  • Lo que tienen en común los mejores ingenieros es que no son simples coders: Boris es fundador de startup, Emma lideró infraestructura de datos durante 4 años en Stripe, Peter hizo crecer PSPDFKit hasta convertirlo en un negocio global
  • El criterio necesita materia prima: pensamiento de producto, sensibilidad de diseño, comprensión del negocio y habilidades de comunicación son los materiales que hacen posible el criterio

• Elegir roles donde el criterio sea recompensado

  • Los roles que implementan especificaciones bien definidas recompensan la velocidad; los roles que deciden qué construir, cómo construirlo y qué es suficiente recompensan directamente el criterio
  • Roles donde el criterio se recompensa especialmente: ingeniero fundador en startups tempranas, tech lead en empresas de producto, ingeniero de plataforma o infraestructura que diseña sistemas sobre los que otros ingenieros construyen, ingeniero de developer experience, ingeniero staff+ que maneja decisiones arquitectónicas entre equipos

• Construir trabajo público que refleje criterio

  • En la era de la IA, el portafolio importa más que el CV; la evidencia está en los entregables (open source bien diseñado, blog técnico con una perspectiva consistente, productos que la gente realmente usa)
  • OpenClaw de Peter dice más que cualquier currículum, y el prototipo de Claude Code de Boris demuestra mejor su criterio que cualquier respuesta en una entrevista conductual

La verdad incómoda

• El criterio está distribuido de manera desigual y seguirá siéndolo; algunas personas han cultivado durante 15 años miles de decisiones, con una ventaja de partida imposible de alcanzar con un plan de 90 días
  • El equipo de Codex trabaja en una empresa que crea modelos con acceso ilimitado a tokens, y Peter parte de una trayectoria atípica con 20 años de experiencia y una empresa que logró exit
• Aun así, la brecha entre “no tener criterio” y “tener algo de criterio” tiene un impacto enorme en la carrera y se puede cerrar; dar el salto de recibir tickets para implementar a proponer qué construir mediante investigación con usuarios, y luego implementarlo con IA hasta las pruebas y la arquitectura, eso es precisamente criterio
• La confesión honesta de Gergely Orosz: “se siente como si de repente te quitaran algo valioso; me costó mucho esfuerzo volverme bueno programando, y uno de mis mejores recuerdos es estar totalmente inmerso tecleando ideas”
  • La sensación de pérdida porque la habilidad de programar a mano se vuelve menos central es real, pero la capacidad de saber qué código debe existir, cómo debe estructurarse y qué es suficiente siempre fue la verdadera capacidad
• Los ingenieros que van a prosperar después son quienes entiendan esto: el criterio siempre fue el trabajo; solo que estaba escondido dentro del código, y la IA, al quedarse con el tipeo, lo deja al descubierto

[clastneo]

Vaya, ahora ni 10x basta y ya hay que pensar en ser 30x jajaja

[channprj]

Yo también quisiera dejar de ver expresiones algo exageradas como lo de ingeniero x veces mejor.. T_T
Aunque pretenden ser cuantitativas, en realidad también son expresiones cualitativas.