- En contra de la idea común de que la inteligencia artificial convertirá a los desarrolladores en “managers” o “editores”, el autor propone un enfoque de “programar como un cirujano” y enfatiza una forma de trabajar enfocada en las tareas centrales
- Así como un cirujano se concentra solo en la parte clave de la operación con el apoyo de personal auxiliar, los desarrolladores pueden delegar tareas secundarias mediante herramientas de IA y dedicarse a resolver los problemas esenciales
- Las tareas principales (por ejemplo, el prototipado de UI) siguen siendo realizadas directamente por personas, pero las tareas repetitivas como documentación, corrección de bugs y exploración de código pueden quedar a cargo de agentes de IA
- Al dejarle a la IA las tareas simples y repetitivas, es posible delegar el grunt work sin problemas de jerarquía de estatus, y gracias a su disponibilidad 24/7 se le puede asignar trabajo incluso de madrugada o a la hora del almuerzo
- Este enfoque se conecta con el concepto de “autonomy slider” de Andrej Karpathy, lo que sugiere que la estrategia de uso de IA debe cambiar según el nivel de autonomía de cada tarea
Programar como un cirujano: concepto central
- Se opone a la predicción general de que la IA convertirá a los desarrolladores en managers o editores, y propone en cambio una forma de trabajar como un cirujano (Surgeon)
- El cirujano opera directamente, pero recibe apoyo de un equipo para las tareas de preparación y el trabajo secundario, de modo que puede concentrarse solo en el trabajo central que requiere su especialización única
- De la misma manera, los desarrolladores pueden usar la IA como personal de apoyo para concentrarse en el trabajo creativo central
- Como prototipador de UI, el autor busca usar herramientas de IA para invertir el 100% de su tiempo en trabajo significativo
- Delegar las tareas secundarias que la IA puede resolver permite maximizar la productividad
Tareas secundarias que se pueden delegar a la IA
- Lista de tareas de apoyo que la IA puede realizar suficientemente bien
- Redactar guías sobre el codebase antes de hacer cambios grandes
- Generar borradores de código tipo “spike” para intentar cambios importantes
- Corregir errores de TypeScript o bugs con especificaciones claras
- Escribir documentación sobre funcionalidades en desarrollo
- Estas tareas pueden ejecutarse en segundo plano de forma asíncrona
- La IA puede avanzar durante la hora del almuerzo o por la noche, para que al día siguiente se pueda revisar de inmediato
- Esto permite, como “un cirujano que entra a un quirófano ya preparado”, concentrarse en la programación central con toda la preparación ya hecha
El slider de autonomía (Mind the autonomy slider)
- Hay una gran diferencia entre cómo se usa la IA para tareas centrales y para tareas de apoyo
- El diseño central y el prototipado siguen siendo realizados directamente por personas, donde son importantes los ciclos rápidos de retroalimentación y una alta visibilidad
- En cambio, para las tareas secundarias es más eficiente dejar a la IA trabajar de forma autónoma durante largos periodos
- Para sesiones largas sin supervisión, prefiere Claude Code y, recientemente, Codex CLI
- Esta diferencia es similar al concepto de “autonomy slider” de Andrej Karpathy
- Según el nivel de autonomía, cambian las herramientas y la forma de pensar necesarias, y confundirlas puede ser riesgoso
La IA y el concepto del “equipo de cirujano de software”
- El concepto de “cirujano de software” es una idea antigua propuesta por Harlan Mills en 1975 en "The Mythical Man-Month" de Fred Brooks
- La estructura gira en torno a un “chief programmer”, con apoyo de un “copilot” y personal administrativo
- Antes, esos roles de apoyo los cumplían personas, pero la IA los reemplaza de una forma económicamente viable
- El autor señala que este cambio significa más que una simple reducción de costos
- Reduce los problemas de jerarquía de estatus
- Al delegar a la IA el ‘grunt work’ repetitivo y aburrido, se alivian los problemas de distribución desigual del trabajo dentro del equipo
- Como la IA está disponible 24/7, también puede realizar investigación nocturna o análisis de código que no se le podría pedir a un becario humano
Notion y la expansión de “trabajar como un cirujano”
- El autor explica que este enfoque ya se está implementando en Notion, donde trabaja
- A nivel de empresa, se impulsa activamente el uso de herramientas de programación con IA, y el codebase también está diseñado con eso en mente
- En especial, esto mejora mucho la productividad de los desarrolladores que recién se integran a un codebase grande
- Desde la perspectiva del producto, Notion busca extender esta forma de “trabajar como un cirujano” más allá de los programadores, hacia todos los trabajadores del conocimiento
- El objetivo central no es delegar el trabajo importante, sino identificar y delegar las tareas secundarias y repetitivas que no son importantes, para ayudar a las personas a concentrarse en lo que realmente importa
7 comentarios
Parece que la idea es enfocarse en el trabajo del núcleo y dejarle a la IA las tareas periféricas. En eso estoy bastante de acuerdo, y parece posible reemplazar con IA algunas tareas que no pertenecen al dominio central, sino que son sustituidas por ciertos SaaS, así como tareas administrativas.
Lo que probablemente genere más debate será si es posible reemplazar con IA el trabajo del núcleo. Al final, la tendencia seguirá hacia el lado que dé mejores resultados. Si vemos cómo resuelve problemas de la IOI o de LeetCode, a veces la IA muestra una capacidad de programación muy superior a la humana. Hacer predicciones apresuradas parece ir más allá de mis capacidades, así que creo que habrá que observar cómo evoluciona.
Esta analogía es una comparación completamente equivocada que no logra captar la esencia.
La cirugía es una tarea irreversible, y la programación es una tarea reversible (o sea, donde se puede hacer
save and load).Si la cirugía también pudiera revertirse, los cirujanos igual se la encargarían a subordinados que sepan operar, y sería más eficiente que detrás se dedicaran al diseño, la revisión y la gestión. Total, si algo sale mal, solo habría que revertirlo.
Estoy de acuerdo. De forma similar, creo que a menudo también se confunde la ingeniería de software con la ingeniería de la construcción.
Si de verdad quieres programar como un cirujano, ¿no habría que hacer que solo puedan programar quienes se graduaron de Ciencias de la Computación? Si aumentan los cupos de esa carrera, entonces los programadores deberían unirse y hasta hacer huelga también......
¿Por qué no existe un asistente de codificación!?
jajajajajajajajajajajajajajajajajajajaja
Opiniones de Hacker News
Si un cirujano principiante empieza una operación creyendo que la enfermera o el anestesiólogo evitarán sus errores, puede matar al paciente muy rápido.
Que haga falta un equipo quirúrgico no significa que la formación de un cirujano senior sea innecesaria.
El problema es que un cirujano sin experiencia piense: “como la enfermera me pasa el bisturí, no necesito aprender”.
Si al final no queda otra que aprender sacrificando pacientes, entonces así será, pero si no, primero hay que ir a la facultad de medicina.
Por eso, en todo el texto se siente el efecto Dunning-Kruger (un sesgo cognitivo en el que alguien con poca capacidad sobrestima mucho sus habilidades reales).
Llevo mucho tiempo diciendo que cualquier ingeniero de software debería leer The Mythical Man-Month.
En los últimos 25 años, la forma de desarrollar cambió de manera drástica, como la transición de waterfall a agile.
Pero cuando uno desarrolla con LLMs (Codex, Claude Code, etc.), da la impresión de que estamos regresando a patrones de desarrollo de los años 70 y 80.
Ahora es como si pudiéramos pensar la estructura como quien diseña una catedral, y delegar la implementación de los detalles.
En una cirugía solo una persona trabaja a la vez, pero en software varias personas pueden meter mano al mismo tiempo.
En realidad se parece más a un equipo deportivo, y nos falta práctica o coaching, así que la calidad tarda en llegar.
Se ha vuelto posible concentrarse más en el diseño que en escribir código.
Si de verdad fueras a construir un edificio alto, tendrías que preocuparte hasta por la calidad del acero y el origen de los pernos.
Ignorar eso es peligroso.
Esta analogía está mal tanto en sentido literal como metafórico.
El cirujano no es simplemente un trabajador, sino un gerente que administra toda la cirugía, y en la práctica el anestesiólogo es la persona más importante.
Además, la idea misma de “trabajo pesado” (grunt work) es una forma equivocada de ver las cosas.
Verse a uno mismo como el cirujano y a los demás como personal de apoyo es una perspectiva egocéntrica.
Igual que en el concepto de Brooks del Chief Programmer, el desarrollador principal puede trabajar gracias al apoyo del equipo.
El autor no ve a los juniors como simple mano de obra inferior, sino como mentees.
No es una analogía perfecta, pero el mensaje sobre las herramientas de programación con IA merece respeto.
Incluso puso como ejemplo que históricamente se podía operar sin anestesia.
Por ejemplo, como en ciertas explicaciones de frameworks que comparan a los programadores con carpinteros, en la práctica los artesanos reales no pulen cada parte a la perfección.
Me gustó esta analogía y pienso usarla de ahora en adelante.
Otra analogía posible sería la del taller de un pintor clásico.
Rembrandt o Rubens hacían que sus alumnos prepararan el lienzo y pintaran algunas partes, mientras el maestro solo pintaba directamente las secciones clave.
En cambio, después del romanticismo apareció el ideal del artista que completa todo por sí solo.
Algunos programadores quieren crear solos como Turner, pero yo prefiero dibujar el panorama general como Rembrandt y dejar los detalles a la IA o a juniors.
La calidad del código tiene que ser buena para poder responder rápido al feedback de los usuarios.
No se trata solo de “programar rápido y ya”, sino de una estructura que reduzca el costo de los cambios.
Si el enfoque tipo Rembrandt lleva a buen código, está bien, pero todavía falta evidencia.
Yo también usé Claude durante unos meses, pero sentí que programar directamente era más eficiente.
Sin embargo, esta vez, al actualizar una base de datos grande de MySQL 8→9, le pedí a Claude que encontrara consultas con posibles problemas, y sorprendentemente acertó en la mayoría.
No fue perfecto, pero redujo muchísimo el tiempo de depuración.
Siento que los LLM aportan mucho más encontrando puntos de riesgo que escribiendo el código directamente.
Si pegas un stack trace de una base de código vieja, el LLM te sugiere una dirección inicial para depurar.
Incluso al corregir problemas de rendimiento, puedes pedirle que verifique si distintas rutas de código producen el mismo resultado.
Todavía está al nivel de autocompletado para escribir código, pero la eficiencia sí mejora claramente.
Me recordó la charla Software Faster de Dan North.
Me impresionó la idea de que “el software es como la cirugía: haz solo lo mínimo necesario para resolver el problema”.
Pero este texto está bastante lejos de esa filosofía.
Por eso ahora siento que soy un cirujano que hace amputaciones todo el tiempo.
Parece que la estructura de Chief Programmer Team está volviendo a ponerse de moda.
Esta vez, en una forma donde el equipo incluye agentes de IA en lugar de humanos.
Las ideas de Fred Brooks están volviendo a llamar la atención.
Si a un desarrollador con productividad 10x (10x-er) le pones un equipo competente, puedes reducir el tiempo que se desperdicia en reuniones o administrando Jira.
Si se les paga un salario alto, hay que usar su tiempo de la manera más valiosa posible.
Entender el espectro de autonomía, o el espectro de delegación, es la clave para usar bien las herramientas de programación con IA.
Los ingenieros no están tan acostumbrados a delegar, pero los fundadores tienden a aprender esto más rápido.
Sobre la expresión “el cirujano se concentra en lo importante”, alguien señaló que en realidad todas las tareas de apoyo son igual de importantes.
Hay que ser humilde, respetar el apoyo de quienes te rodean y apoyarlos del mismo modo.