CEO de GitHub: incluso en pleno boom de la IA, la codificación manual sigue siendo clave
(techinasia.com)- El CEO de GitHub, Thomas Dohmke, enfatizó la importancia de mantener la capacidad de programar manualmente a pesar de la expansión de las herramientas de IA
- Sostuvo que, aunque la IA genere código, es más eficiente que los desarrolladores lo corrijan y revisen directamente
- Advirtió que depender solo de la automatización puede generar ineficiencias reales y perjudicar la productividad, y que el abuso del código generado por IA, como en el "vibe coding", incrementa los riesgos de calidad y seguridad
- Explicó, apoyándose en tendencias y casos de la industria, que el enfoque más efectivo es un método híbrido entre IA y desarrolladores humanos
- El rol del desarrollador no está desapareciendo, sino evolucionando hacia uno que exige colaboración con la IA, resolución estratégica de problemas y capacidad de diseño
CEO de GitHub destaca la importancia de la codificación manual incluso en la era de la IA
El CEO de GitHub, Thomas Dohmke, enfatizó la importancia de mantener la capacidad de programar manualmente incluso cuando el uso de herramientas de IA se expande en el desarrollo de software
- En su participación en “The MAD Podcast with Matt Turck”, explicó que los desarrolladores deben tener la capacidad de corregir directamente el código generado por IA para evitar una caída de productividad
- Como flujo de trabajo efectivo, planteó un enfoque en el que la herramienta de IA genera código y envía un Pull Request, y luego el desarrollador lo ajusta de inmediato usando sus habilidades
- Señaló que, si se depende exclusivamente de agentes de automatización, se puede terminar perdiendo tiempo innecesario al describir cambios simples en lenguaje natural, lo que genera ineficiencias
- Dohmke indicó que “tratar de explicar en lenguaje natural algo que ya sabes hacer directamente en un lenguaje de programación es la opción más ineficiente”
- El término “vibe coding”, mencionado por el cofundador de OpenAI Andrej Karpathy, se refiere a una dependencia excesiva del código generado por IA, y Dohmke también llamó a tener cuidado con ello
Insights y tendencias de la industria
1. La mejor respuesta para programar con IA es una estrategia híbrida
- La visión de Dohmke coincide con el consenso de la industria de que la mejor opción es combinar la automatización con IA y las habilidades humanas de programación
- Según una investigación de Deloitte, los desarrolladores usan herramientas de IA principalmente para escribir código boilerplate, pero al mantener la revisión final humana logran una mejora de productividad de 10 a 20 minutos
- Dado que aproximadamente la mitad del código generado por IA contiene errores parciales, la estrategia de “confiar, pero verificar” se está consolidando como estándar en la industria
- En Google, más del 25% del código total es generado por IA, pero la experiencia sigue mostrando que la revisión y mejora activa por parte de desarrolladores humanos es indispensable
- Este enfoque equilibrado refleja que, junto con un mayor reconocimiento de los límites de la IA, la industria está madurando hacia un modelo en el que la experiencia del desarrollador se potencia en lugar de ser reemplazada
2. El rol del desarrollador está cambiando, no desapareciendo
- Más que hacer desaparecer los trabajos de programación, la IA está transformando el rol del desarrollador de un codificador puro a un gestor de procesos de desarrollo basados en IA
- Los expertos prevén que los perfiles de desarrollo se dividirán entre ingenieros de producto que aprovechan la IA y arquitectos avanzados enfocados en garantizar calidad y seguridad de sistemas
- Este cambio implica la necesidad de nuevas capacidades como el uso efectivo de la IA, la resolución estratégica de problemas y la capacidad de diseño de alto nivel
- Junto con la escasez de ingenieros de software, ya se ha demostrado que las herramientas de IA ayudan a los desarrolladores junior, y también abren nuevas oportunidades de crecimiento para perfiles más experimentados
- Esto sugiere que, al igual que ocurrió con herramientas y abstracciones del pasado, la creatividad humana sigue siendo necesaria
3. El dilema productividad-calidad del “vibe coding”
- El fenómeno del “vibe coding” muestra la ventaja de productividad del código generado por IA, pero también sus límites en calidad y seguridad
- Las herramientas de IA ayudan con el prototipado rápido y el desarrollo iterativo, pero también aumentan la preocupación por el deterioro de la calidad del código y los riesgos de seguridad
- En casos reales, se han producido vulnerabilidades de seguridad por el uso de código de IA sin validación
- En entornos como startups lideradas por fundadores no técnicos, el abuso del código generado por IA puede acumular deuda técnica y terminar frenando el crecimiento a largo plazo
- La experiencia de grandes empresas tecnológicas muestra que la clave para adoptar IA está en equilibrar automatización y control estricto de calidad, una lección que también es importante para las startups
1 comentarios
Opiniones de Hacker News
Me pregunto muchísimo por qué la gente ya no habla de la complejidad esencial de los sistemas
En No Silver Bullet de Fred Brooks se señala que la verdadera dificultad de la ingeniería de software viene de entender, aclarar y modelar el espacio del problema central. La complejidad accidental, como las limitaciones de las herramientas, es secundaria
Últimamente se habla mucho de agentes de IA que crean bases de código completas a partir de prompts en lenguaje natural en lugar de ingenieros. Pero esa idea parte de la ilusión de que el problema de la especificación ya está resuelto. En la práctica, convertir ideas ambiguas en sistemas detallados y sólidos sigue siendo el rol central del ingeniero
Si alguien proporciona especificaciones detalladas y trabaja iterativamente con una IA para construir software, en realidad lo que hace es eliminar complejidad accidental con IA. Eso se parece a cuando los desarrolladores pasaron de ensamblador a lenguajes de alto nivel. No reemplaza al ingeniero; solo aumenta la productividad. También reduce el costo del trabajo repetitivo y abre la posibilidad de ampliar el impacto
Si un agente puede crear un producto solo con prompts, es porque alguien ya definió claramente el sistema. Y si con IA solo se copian productos existentes, entonces eso no va de resolver problemas técnicos, sino de distribución o competencia por costos; no es innovación de ingeniería, sino innovación de negocio
Me pregunto si se me está escapando algo
La clave es por qué el trabajo de especificación ya se trataba con descuido mucho antes de la llegada de la IA
Las partes interesadas (clientes, managers) desde hace tiempo piden que se programe “más o menos a ojo”. Dan una explicación vaga y esperan que alguien produzca milagrosamente una solución acorde. Nadie sabe si la solución realmente funciona por completo. Muchas veces simplemente parece que funciona más o menos y con eso siguen adelante
En la mayoría de los casos, es el programador quien concreta las cosas basándose en su conocimiento del dominio (por ejemplo, porque sabe intuitivamente cómo debería verse una página correcta de envío de formularios)
Ahora solo cambió la contraparte y pasó a ser la IA; queda por ver si esta forma de trabajar realmente puede repetirse igual
La distinción entre complejidad esencial/accidental es una idea muy importante para pensar hasta dónde la IA puede hacerse cargo del desarrollo de software
Muchos desarrolladores no pueden explicarlo con palabras, pero eso es lo que sienten intuitivamente cuando dicen por qué no serán reemplazados por la IA
De hecho, yo también intenté que agentes como Claude resolvieran problemas en bases de código enormes y muy complejas, atravesadas por lógica de negocio externa. Pero la IA no capta bien los requisitos de negocio ni el contexto, así que no puede hacer cambios de código orientados al negocio. Solo puede ayudar con cambios de código más simples y de contexto acotado. O sea, solo puede encargarse de la complejidad accidental, y tiene límites cuando se trata de traducir requisitos reales a un sistema, que es el verdadero rol del desarrollador
Además, muchas veces lo que resuelven los desarrolladores no son problemas técnicos sino problemas de distribución/mercado. Reemplazar juniors con IA todavía da poca confianza. El mayor problema es que la IA no puede autocorregirse por sí sola. Aun así, seguirán apareciendo negocios basados en IA que intenten bajar los costos de empresas existentes. Que ese cambio sea bueno o malo no significa mucho para quien pierde su trabajo
Sí hay una respuesta a “¿me estoy perdiendo algo?”
En realidad hay muchísimos desarrolladores que no saben usar software. A esos la IA los va a reemplazar fácilmente
En un trabajo anterior trabajaba con JavaScript, y la gente que hacía cosas realmente sorprendentes era solo la que programaba como hobby. En la empresa, a la mayoría le costaba incluso mostrar texto en pantalla. No es broma
Mucha gente intentaba meterse con frameworks enormes, pero al final se quedaba en copiar y pegar hasta que algo medio funcionara. Fingen resolver complejidad avanzada, pero casi todo es trabajo innecesario o código para presumir
Casi no tienen capacidad de crear apps originales, escribir documentación o medir la usabilidad real
¿Cómo se arregla esto? Como con los abogados, introduciendo estándares altos como un examen tipo barra, excluyendo sin miedo a quienes no los superen, y contratando a los demás solo como juniors o aprendices para que una nueva generación de desarrolladores pueda crecer de verdad
La respuesta fácil sobre lo “que se están perdiendo” es que en la industria nadie ha leído "No Silver Bullet"
Quienes escriben sobre deuda técnica o arquitectura de sistemas en realidad no son los responsables de tomar decisiones que afectan al equipo o al negocio, y esos libros también son opcionales para los ingenieros
Quienes impulsan el discurso de reemplazar programación con IA muchas veces no distinguen entre construir un MVP y escalar una base de código durante 10 años mientras se mejora el legado
Por ejemplo, una vez un manager propuso la típica mala idea de repartir 33% del tiempo a 3 proyectos por día. La asignación de personal o la estructuración del tiempo debería ser capacidad de gestión, pero al final quien lo resuelve bien termina siendo el ingeniero
Ahora esos managers proponen “hacer que la IA resuelva toda la deuda técnica y las pruebas”, y cuando no sale bien, otra vez es el ingeniero quien tiene que explicarlo
Hablar de complejidad es, en la práctica, otra repetición del problema de la mala gestión. La gran mayoría de los ingenieros con experiencia ya no cree que su trabajo pueda reemplazarse con un prompt sencillo
El tema del que realmente deberíamos hablar es este: “la ingeniería de software tiene un grave problema de gestión, y la IA lo hace aún más visible”
Muchos no desarrolladores o estudiantes sienten que para desarrollar software hay que aprender a usar herramientas complejas, y les atrae la promesa de que “si haces buenas especificaciones, cualquiera puede crear software” (omitiendo por completo que la propia capacidad de especificar es muy difícil y necesita tecnología de apoyo)
Antes el no-code iba por la misma línea, y en la práctica sus herramientas son limitadas; mientras más potentes son, más aprendizaje complejo y especializado requieren
La idea de reemplazar SWE con LLM al final es otra versión de “en vez de aprender el sistema, le das prompts en lenguaje natural y el modelo usa las herramientas por ti”
Visto así, lo que hoy llaman vibe coding es prácticamente la culminación de ese objetivo (aunque con debilidades reales como la mantenibilidad)
A mí me parece que una de las razones por las que los managers quieren eliminar a los SWE es que no saben comunicarse bien con ellos
Con un LLM creen que pueden comunicarse con la máquina sin necesitar a los “nerds” y que así resuelven ese problema
Los lenguajes de programación son un medio adecuado para una especificación precisa del programa deseado. El lenguaje natural nunca tendrá ese nivel de claridad
Por eso es normal revisar y editar lo que genera la IA. A veces incluso es más fácil corregir uno mismo que explicar el cambio
Me pregunto si los estudios independientes que muestran que Copilot aumenta la tasa de errores no habrán contribuido naturalmente a una actitud más cautelosa
Quienes venden IA muchas veces afirman que pronto ya no hará falta un autor humano
Los Transformer pueden aplicarse a muchas tareas: testing automatizado, expansión de especificaciones, acelerar proyectos nuevos, explorar APIs desconocidas, construir funcionalidades iniciales, revisión de código, etc.
Incluso si aceptamos que el código es el medio correcto para la especificación, los Transformer cumplen el papel de interfaz automatizada entre el lenguaje natural y ese medio (el código)
Últimamente, gracias a la enorme cantidad de conocimiento que tienen, los Transformer no tienen problema en generar código
Así como los humanos buscan la automatización en la programación, los Transformer representan un salto enorme
En algún momento del futuro, el reemplazo de programadores por IA podría volverse realidad (como pasó cuando el telar automático, la imprenta o las calculadoras electrónicas reemplazaron trabajo humano)
Pero puede que eso no ocurra ahora mismo, ni siquiera en los próximos 10 años, y siguen quedando retos como las alucinaciones, la precisión, el uso de herramientas y la construcción de infraestructura
La existencia o no de trabajos de programación puede variar según el dominio, la habilidad y las expectativas salariales
Es importante tomarse en serio las herramientas de IA y adaptarse. Si no, existe el riesgo de quedarse atrás, como ocurrió en la adopción de la computación personal o de internet
Creo que la seudocreatividad de la IA tiene límites
Si todos los resultados del entrenamiento de los LLM vuelven a circular solo como entrada para LLM, el rango de ideas nuevas nunca se ampliará
Los humanos siguen mostrando creatividad que va más allá de ese rango
Tal vez en el futuro los LLM crucen esa barrera, pero por ahora no son tan distintos del “mono con máquina de escribir”
En mi experiencia, los LLM son más efectivos cuando se usan como scaffolding (herramienta de apoyo)
Les paso una descarga mental de la funcionalidad que quiero crear y les pido que generen el modelo y el controlador básico que necesita
Así, lo único que me queda es concentrarme en la vista y en la lógica de negocio real, y el reparto del trabajo queda claro
Tengo entendido que cuando aparecieron por primera vez los lenguajes de alto nivel, al principio hubo críticas parecidas a las que hoy se hacen a los LLM o al código en lenguaje natural, algo como “no tienen suficiente precisión porque es difícil controlar la memoria directamente”
El problema no es que el lenguaje natural no pueda ser preciso, sino que la mayoría de la gente explica sus necesidades de forma imprecisa, o tiene claro solo lo que quiere pero no logra describir bien lo que realmente debe hacer la computadora
Como resultado, el ingeniero tiene que adivinar muchísimo al traducir requisitos de negocio, o el LLM asume ese papel entendiendo todavía menos contexto
El mejor uso de la IA es ayudarme a no perder el estado de flujo cuando me trabo con una API nueva o con una funcionalidad tediosa que no quiero hacer
La IA puede aplicar patrones comunes a lo largo del código de forma rápida y eficiente, pero esencialmente 'no sabe por sí sola qué está haciendo'
Para compartir una experiencia reciente, intenté hacer que un LLM refactorizara código relacionado con el cálculo del tamaño y la posición de popups
Una parte estaba escrita con
ify otra conswitch, pero el LLM no reaccionó con ninguna flexibilidad ante esa diferencia y, aunque se lo expliqué claramente, terminó unificando ambas partes enifo enswitchLos LLM tienden a mantener el patrón de los tokens anteriores
Aquí no fue un gran problema, pero en situaciones apenas un poco más complejas ignoran los matices y producen código superficialmente convincente
En cambio, si se divide en unidades pequeñas y se dan instrucciones claras, el LLM puede ser bastante eficiente. Por ejemplo, puede ejecutar fácilmente algo como “guarda el tamaño en
m_StateStoragey aplícalo en la etapa de renderizado”Sobre todo con modelos como Cerebras, que pueden procesar rápido incluso varios kilobytes de código, eso es mucho más veloz que escribir directamente mis ideas como código
Al final, lo que hoy se evalúa es una crítica limitada al rendimiento actual de los modelos Transformer
Esta industria cambia tan rápido que una limitación de hoy puede dejar de importar en un mes
Incluso “LLM” es, estrictamente hablando, una expresión ambigua. Los modelos Transformer más recientes son multimodales y manejan no solo texto, sino varias formas de datos
Por eso, si se va a criticar, conviene señalar concretamente qué modelo, herramienta o paradigma se está cuestionando para que la discusión sea útil
Sobre la “falta de ingenieros de software” y los estudios que dicen que “la IA ayuda especialmente a los desarrolladores junior”
En la realidad en la que vivo, el mercado laboral tech está en su peor momento, y la IA más bien perjudica a los juniors al quitarles experiencia justo donde deberían crecer
Hace poco tuve una experiencia curiosa con Claude. En Zed le dije “arréglame el error de la línea 71” y terminó cambiando formato innecesariamente en la línea 91
Fue como jugar al teléfono descompuesto con un LLM
Incluso una corrección tan simple es más rápida hacerla uno mismo. Esa experiencia me volvió a confirmar la sensación de que “los LLM en realidad no piensan”
Los LLM son pésimos para reconocer números de línea
De esa experiencia saqué la lección de que “los LLM no saben contar números de línea”
La próxima vez sería mejor decirle “corrige el error en la función XYZ” o pegar directamente esa línea al darle la instrucción
Y, claro, los LLM no piensan. Son solo una enorme ecuación
En este hilo parece haber mucha gente usando IA para programar por primera vez
También pudo haber sido error del operador
Hay que darle al LLM el contexto correcto. Un número de línea no es un contexto adecuado
Para mí, el rol del ingeniero de software es convertir requisitos en software
El software no es simplemente código, y los requisitos tampoco se entregan solo en lenguaje natural
Hoy por hoy, incluso trabajando con IA, no voy más rápido que la IA (salvo en tareas simples o software pequeño)
Para mis estándares, la IA actual está al nivel de un desarrollador junior/intermedio
En los últimos 2 años no he sentido que la IA haya mejorado de forma revolucionaria
La mayoría de los requisitos no llegan claramente documentados
Casi nadie sabe realmente cuál es la lógica de negocio
Por eso, muchas veces el ingeniero de software tiene que ir a preguntar directamente
También se necesita experiencia e intuición para pensar en hacia dónde debe crecer el software y cómo diseñarlo para soportar esa expansión
No me imagino que un LLM pueda cumplir ese rol, ni siquiera parcialmente
Nunca he visto un proyecto de software con requisitos claros
La mitad del proyecto consiste en “descubrir qué es lo que realmente quieren”
Los LLM todavía ni siquiera llegan a nivel junior
Si la IA actual en verdad estuviera al nivel de un desarrollador intermedio en tu empresa, entonces el problema sería de contratación en esa empresa
Una de las mayores ventajas de las computadoras es la automatización confiable y reproducible
Los lenguajes formales como los lenguajes de programación permiten comunicar con claridad, sin ambigüedad, los requisitos de la automatización deseada
El lenguaje natural no tiene ese nivel de precisión
La verdadera base de verdad (ground truth) de un programa sigue siendo el código
Si un humano quiere controlar con precisión el comportamiento de un programa, la capacidad más importante es entender y modificar código
La palabra “manual” tiene una connotación negativa
Lo que ese artículo quería decir es “la programación humana sigue siendo clave”
No está claro si el CEO de GitHub realmente usó la palabra “manual”. Sería bueno contar con una fuente del artículo con una elección de palabras más neutral o más precisa
No es deseable menospreciar la programación humana llamándola “manual”. Los desarrolladores humanos también usan muchos toolkits de automatización además de la IA
Puede ser tan negativo como hablar de “pensamiento manual”
Recién me entero de la connotación negativa de “manual”
Me pregunto si hoy en día realmente se le tiene tanta aversión al trabajo manual
Me pregunto cuál sería la diferencia entre “manual coding” y “human coding”
“Depender solo de agentes de IA puede ser ineficiente”
Por ejemplo, muchas veces editar directamente el código es mucho más rápido que explicar largamente en lenguaje natural un cambio simple
Por lo tanto, la interacción activa con agentes de IA probablemente será el flujo de trabajo óptimo
Muchas veces, mientras empiezo a pensar el cambio en lenguaje natural, antes incluso de escribirlo ya se me ocurre directamente la modificación que necesito
Cuanto más contexto tiene el cambio, más siento que yo mismo lo corrijo más rápido que un agente
Me pregunto cuánta interacción activa es razonable
Hace poco me sumé a una startup de tooling para agentes, y hablamos mucho de esto internamente
Me parece bien darle feedback continuo al agente, tipo “¡la verdad, esto lo estás haciendo mal!”, pero hay partes que podrían volverse agotadoras
Me interesa saber qué piensan y si tienen más ideas o feedback sobre el flujo de trabajo
La IA todavía no ha llegado a donde muchos esperaban
Por ejemplo, a menudo sufro por referencias o especificaciones incorrectas. Parece deberse a que la IA fue entrenada con datos desactualizados y tiene poca capacidad de actualización en tiempo real
Las soluciones actuales de LLM y GI intentan resolver de una sola vez todos los pasos n, y por eso terminan siendo menos útiles
Si al menos resolvieran bien solo del paso 1 al paso i, ya serían mucho más útiles para los humanos
Todavía no he visto una solución de IA completamente modular como la que quiero (por ejemplo: que refleje mi estilo de GitHub y resuelva el problema x consultando solo los recursos a, b y c)
Y espero que aparezca una IA para programar que explore el problema secuencialmente, haciendo más preguntas e interactuando durante el proceso
Me llamó la atención ver a un CEO opinando sobre IA y programación desde un ángulo algo distinto
Normalmente los CEOs o inversionistas predicen una reducción del rol del desarrollador diciendo que “más del 30% de todo el código lo escribe la IA”, pero aquí el diagnóstico es que en realidad solo son las mismas personas desarrolladoras usando herramientas para escribir código más rápido
También subraya que escribir código es solo una parte del trabajo de desarrollo de software