Los LLM están erosionando mi carrera en ingeniería de software y no sé qué hacer
(human-in-the-loop.bearblog.dev)- Las herramientas de desarrollo basadas en LLM ya intervienen en la redacción de documentos de diseño, planes de implementación, escritura de código y depuración, debilitando la diferenciación de una especialización de 10 años en backend de pagos y finanzas
- El conocimiento de dominio en finanzas y pagos era una ventaja competitiva basada en experiencia con cumplimiento PCI, libros contables de doble entrada, escrow, conciliación, ciclos de vida de pagos e idempotencia en transferencias bancarias, pero el modelo logró captar los vínculos de la estructura del sistema y eso provocó el primer golpe
- Con Claude Code, Codex, MCP y DataDog MCP, la automatización de la depuración se ha expandido: algunos bugs se resuelven solo con un stack trace y el contexto de Sentry, y luego el 90% de los bugs en sistemas distribuidos empezó a resolverse de un solo intento
- Incluso los pilares restantes, la calidad del código y la arquitectura, se están reduciendo a una cuestión de “taste”, y la tendencia va hacia aceptar codebases de nivel
CoDque los LLM pueden manejar, en lugar de codebases de nivelAoBlegibles para humanos - Para preservar la empleabilidad a largo plazo, habría que mover la especialización hacia áreas donde a los LLM no se les dé fácil sobresalir, pero la transición a investigación está limitada por el país de residencia, la competencia en postulaciones, la situación familiar y la posibilidad de RSI
Trasfondo de carrera
- Soy un ingeniero de software con 10 años de experiencia profesional; empecé en frontend web porque depurar era más fácil ahí, pero luego me pasé al backend
- Por casualidad terminé en roles de desarrollo de software en los dominios de finanzas, bookkeeping y procesamiento de pagos, con una alta autonomía gracias a relaciones cercanas y francas con Product Managers y stakeholders
- Acumulé conocimiento de dominio sobre cumplimiento PCI (PCI compliance), libros contables de doble entrada (double-entry ledgers), escrow, conciliación (reconciliation), ciclos de vida de pagos (payment lifecycles) e idempotencia en transferencias bancarias (bank transfer idempotency)
- La estrategia de carrera de convertirme en especialista de dominio fue una decisión clara para diferenciar mi experiencia en un área donde se veía venir un aumento en la demanda por expertos de dominio
El primer pilar que empezó a derrumbarse: conocimiento específico de dominio
- El año pasado cambié a una empresa del sector financiero; mis empresas anteriores tenían un fuerte componente de pagos y finanzas, pero no estaban centradas exclusivamente en finanzas
- La nueva empresa adoptó la IA de lleno y me dio cuentas de ChatGPT y Claude Enterprise desde el primer día, además de incentivar el uso de IA para investigar, explorar y programar
- Eso sí, con la condición de que cada línea de código que llegue a producción debe revisarse personalmente y asumirse bajo responsabilidad propia
- Mi primer proyecto fue rehacer un sistema heredado desastroso de pagos en línea, trabajo que me asignaron por mi experiencia previa construyéndolos
- Los Design Docs que escribíamos antes de programar debían ser legibles tanto para ingenieros como para Product Managers, y requerían más una perspectiva de arquitectura que análisis técnico profundo
- El primer Design Doc lo escribí con ayuda mínima de IA; en ese entonces llamaba a los LLM “stochastic parrots”, una postura que ya no sostengo
- El feedback de mi manager fue que entregaba código a buen ritmo, pero tardaba demasiado escribiendo Design Docs y debía usar más IA
- Los modelos de entonces no eran tan buenos como ahora, pero ya eran suficientemente útiles para acelerar la escritura y la toma de decisiones
- Fue el momento en que empezó a perder valor todo el conocimiento acumulado durante años sobre trade-offs de implementación, cómo funciona el acquiring y cómo estructurar la idempotencia para evitar cobros duplicados
- El modelo todavía requería ajuste, pero podía captar los vínculos sobre cómo estructurar un sistema, que es precisamente la parte más difícil y la que normalmente solo se forma en la cabeza tras años de experiencia real
- Como en la web hay muchos textos explicativos, documentación técnica y blogs sobre cómo aplicar herramientas técnicas a un dominio, concluí que el modelo podía absorber todo eso como datos de entrenamiento
- Aun así me quedaba la esperanza de que el área donde los humanos seguirían destacando sería la depuración, y que mi experiencia con race conditions en producción y debugging de sistemas distribuidos sostendría mi empleabilidad a largo plazo
El segundo pilar que empezó a derrumbarse: depuración y sistemas distribuidos
- Después de volverse buenos para redactar documentos y apoyar planes de implementación, los LLM también empezaron a escribir código bien, y esa tendencia se amplió con el hype de Claude Code en la segunda mitad de 2025 y la llegada de Codex
- Incluso antes de eso ya usaba LLM a diario para escribir pruebas unitarias, pero todavía no confiaba lo suficiente como para delegarles implementaciones completas
- Introducir más IA en la escritura de código fue el siguiente paso natural, y como me gustaban tanto los despliegues a producción y la satisfacción del usuario como programar, era un intercambio aceptable
- Los LLM se volvieron hábiles escribiendo código, pero no podían depurar el desorden dejado por el modelo o por humanos, así que seguía sintiendo que mi papel era más grande que simplemente orquestar robots
- Con MCP, los flujos de trabajo agénticos y la llegada de Claude 4.5, incluso ese eje de la depuración empezó a tambalear
- Claude 4.5 resolvía alrededor del 60% de los bugs solo con un stack trace y algo de contexto; en la mayoría de los casos bastaba un enlace de Sentry con Sentry MCP habilitado
- A veces generaba una solución plausible pero completamente incorrecta
- En ese punto dejé de dudar de la máquina y vi a Claude Code resolver de un solo intento bugs que antes me habrían tomado todo un día de depuración
- Después llegaron 4.6, 4.7, GPT 5.5, Opus 4.8 y DataDog MCP, y el CLI empezó a resolver de un solo intento bugs de sistemas distribuidos
- Incluyendo bugs que antes no había podido resolver, bugs que me habrían exigido dos días completos de depuración y bugs en sistemas distribuidos con observabilidad distribuida deficiente
- Resolve de un solo intento el 90% de bugs como race conditions extrañas, corner cases inesperados, problemas con integraciones de terceros y edge cases no documentados de APIs
- Todavía hace falta alguien que revise el código y orqueste a los robots, así que sigo empleado, pero me convertí en un ingeniero commodity
- Mi especialización en finanzas y pagos, mi intuición para depurar y mi conocimiento de sistemas distribuidos se transformaron en conocimiento promptable que cualquier otro ingeniero senior puede ajustar con LLM
- A diferencia de la idea que me enseñaron, de que había espacio tanto para generalistas como para especialistas, el mercado se está moviendo hacia volver generalistas a todos
- Si todos se vuelven generalistas y la demanda no acompaña, el precio de los generalistas cae, y la demanda además viene bajando
El tercer pilar que aún no se ha derrumbado: calidad de código y arquitectura
- El pilar que aún queda es la calidad del código y la arquitectura de software, un área que hoy se reduce con frecuencia a la palabra “taste”
- Durante toda mi carrera me gustó refactorizar, me importó el buen código y negocié dentro de los sprints tiempo para eso
- También disfruté discutir trade-offs y estructura de codebases en temas como DDD, Hexagonal y Clean Architecture
- Los agentes son herramientas muy débiles para mantener una codebase ordenada
- Si no se los orquesta, los problemas de dependencias circulares aparecen rápido
- Agregan código duplicado, insertan comentarios innecesarios, mezclan funciones puras con side effects e ignoran principios SOLID
- Esta capacidad debería ser el área que preserve la empleabilidad humana, pero la industria la está reduciendo a la palabra “taste” y moviéndose hacia un mundo donde la importancia de organizar bien el código es menor
- Los humanos todavía deben orquestar agentes para evitar codebases espagueti con grafos de dependencias circulares
- No quiero codebases de nivel
Fque se rompan al intentar arreglar cualquier cosa, pero los nivelesCoDahora parecen suficientemente aceptables - Ya no se necesitan codebases de nivel
AoBporque las codebases están pasando a hacerse para que las manipulen LLM, no para que las lean humanos - Si el código fuente ahora se escribe para que lo lean máquinas y no personas, también es posible elegir orientarse hacia las máquinas
- Incluso el conocimiento sobre calidad de código y arquitectura está perdiendo valor, y el tiempo invertido en leer libros, practicar, debatir con otros ingenieros y escribir ADRs se está volviendo inútil
Entonces, ¿qué se supone que debo hacer ahora?
- Por ahora creo que seguiré empleado, al menos en mi empresa actual, pero la perspectiva a largo plazo es incierta
- A largo plazo, las cosas que me tomaron 10 años aprender —o más si cuento la experiencia no especializada— están perdiendo valor de manera gradual
- Hasta el último pilar de especialización quedó reducido a “taste”
- Hace unos 8 meses hubo despidos en mi empresa actual —según la explicación de la compañía, no relacionados con IA— y varios excolegas brillantes que fueron despedidos siguen buscando trabajo
- Muchos de ellos enfrentan el mismo problema: la especialización de dominio ya no alcanza para diferenciarse
- La empresa está contratando otra vez para algunos roles, pero la familiaridad con el dominio ya no es un factor fuerte de diferenciación
- Antes las vacantes se publicaban como “Software Engineer - Area”, pero ahora solo dicen “Software Engineer” y la asignación al equipo ocurre después de aceptar la oferta
- Para ingenieros brillantes que no habían tenido oportunidad de acumular experiencia profunda en un dominio, este cambio abrió mejores oportunidades laborales
- Pero también hizo que ingenieros brillantes que pasaron toda la vida acumulando conocimiento de dominio compitan en el mismo carril
- La única opción para preservar la empleabilidad a largo plazo parece ser mover la especialización hacia áreas donde a los LLM no se les dé bien destacar con facilidad
- También he considerado volver a la universidad para estudiar matemáticas, estadística y Machine Learning avanzado, y postularme a puestos de investigación en frontier labs
- En mi país no hay frontier labs, y en los pocos institutos que existen hay demasiados postulantes
- Por mi situación familiar, moverme a otro país es difícil
- Y para cuando quizá sí pueda moverme, existe la posibilidad de que la RSI (mejora recursiva autónoma) vuelva innecesarios a los investigadores
- Me siento tan sin salida que incluso he considerado convertir mi hobby de carpintería en profesión
1 comentarios
Opiniones de Hacker News
¿Qué? Paso todo el día dirigiendo LLM, pero jamás aceptaría ser responsable de un producto financiero
El primer pilar sigue en pie. Puede que el autor no se dé cuenta de su propia influencia, pero por la evidencia de PR revertidos sé que, cuando salgo de un área que conozco a fondo, ya no puedo distinguir si el agente está diciendo tonterías. Incluso nuestro mejor agente, que tiene acceso al sistema distribuido que mencionó el autor, se equivoca seguido, tiene una visión limitada y sigue haciendo estupideces. Al final, la experiencia de los ingenieros del equipo vuelve a encarrilarlo
Mythos determinó con total seguridad que parte de nuestra base de código violaba cierta regulación y dijo que, si seguíamos operando como hasta ahora, había un riesgo serio. Pero no era cierto; se había alucinado los requisitos regulatorios. Lo supe porque ese código ya lo había revisado asesoría legal humana. Y se supone que este es el modelo de vanguardia disponible hoy. Uso mucho la IA generativa para ayudar a escribir código, pero ni a mediano plazo se puede depender de herramientas así para construir de verdad productos financieros con cumplimiento regulatorio. Sería una locura total. Es cierto que muchas empresas FinTech usan agentes para ganar velocidad, pero si los usan para lanzar productos sin que una persona los revise de verdad, están asumiendo un riesgo enorme
Antes de los LLM, en la mayoría de las empresas había espacio para que trabajaran juntos ingenieros brillantes e ingenieros promedio. Después de los LLM, solo los ingenieros “top” podrán sobrevivir. Ya no se necesitarán ingenieros promedio. Por la naturaleza de HN, la mayoría de los ingenieros que lean esto creerán que están en el 10~5% superior de su empresa/ciudad/país, así que pensarán que no son esos ingenieros “promedio” que se verán afectados por la adopción de LLM. Estadísticamente, probablemente estén equivocados. Al final es un tema de ego. Lo más probable es que no seas una estrella del rock, y que los LLM terminen quitándote el trabajo. Como siempre, los únicos ganadores serán las empresas y los ejecutivos, y la mayoría de nosotros, que estamos al final de la cadena, saldremos perjudicados
En mi caso, el desarrollador hizo algo de vibe coding y, como no tenía una comprensión profunda ni de los requisitos ni de su propio código, hubo que iterar varias veces para corregirlo. Se podría decir que es un problema humano, pero el efecto neto que yo veo es este: en los casos complejos, la antigua combinación de “tiempo moderadamente largo para escribir el PR + tiempo moderadamente largo de revisión” parece haberse convertido en “tiempo muy corto para escribir el PR + tiempo de revisión más largo”. No sé si realmente hay una ganancia en esos casos. A veces, incluso cuando el código es funcionalmente correcto, resulta verboso por tener demasiadas funciones intermedias, y parece que eso afectará revisiones futuras
Yo también tengo las mismas preocupaciones, pero a menudo las descartan o las esquivan con algo como “la velocidad de entrega y el ROI lo compensan, así que no te preocupes”
Personalmente, todas las empresas FinTech con las que trato han tenido algún tipo de cuenta de IA para desarrolladores desde el año pasado. Incluso en lugares como Jane Street, los empleados han publicado blogs diciendo que en su mayoría dirigen agentes. ¿Cuánto tiempo crees que tu empresa podrá resistir?
Veo muchos comentarios de “como la IA no puede hacer X con un 80~100% de precisión, nuestro trabajo está a salvo”
No quiero sonar demasiado pesimista, pero los modelos están mejorando rápido. Si hace unos 3 años alguien hubiera descrito el estado actual diciendo “el modelo crea una app MVP completa con un solo prompt en unos 30 minutos”, habría sonado a ciencia ficción. Los obstáculos que tienen ahora los modelos, como reducir la tasa de alucinaciones, garantizar el cumplimiento normativo y mantener una base de código limpia, no parecen estar tan lejos de resolverse. Incluso obtener información específica ya es parcialmente posible con varios servidores MCP/RAG. Me preocupa el futuro de los ingenieros de software. Cuando se resuelvan estos defectos, ¿dónde quedará la profesión? ¿En un rol de delegar trabajo a modelos de IA? Lamentablemente, eso no requiere años de especialización, así que es un arma de doble filo. ¿Revisar la salida de la IA? Basta con pedirle que explique cada línea que no entiendas. Así como los calculistas humanos fueron reemplazados por las computadoras digitales, creo que veremos una ola de despidos aún mayor. Hacer cálculos matemáticos complejos mentalmente puede ser un reto divertido, pero es mucho más lento y tiene más errores que una computadora. Del mismo modo, escribir código a mano parecerá un “reto” divertido, y la IA terminará viéndose como la calculadora moderna
https://youtu.be/5eqRuVp65eY?si=3fLT6S5q2OIUcu6r
Muchas cosas seguirán mejorando bastante. Pero si miras la historia moderna de las disrupciones bruscas creadas por la tecnología, hay un patrón que se repite. Como una avalancha o una inundación repentina, estos cambios abruptos suelen comenzar con uno o más avances importantes en cierta tecnología. La velocidad del cambio al inicio es rápida y caótica, pero luego se desacelera gradualmente a medida que se cosechan los frutos más accesibles y aparecen nuevas barreras y fricciones en el terreno recién abierto. Al principio de estos períodos, extrapolar hacia el futuro la tasa excepcional de cambio reciente tiene poca capacidad predictiva. Las explosiones súbitas y extremas tienden a volver a la línea de tendencia de largo plazo. Puede decirse que la disrupción actual de los LLM proviene de la acumulación de investigación desde 2010 y de su cristalización en el artículo de Transformers de 2017, que además detonó rápidamente investigaciones a su alrededor. Si es así, puede que ahora estemos en la mitad o en la etapa final de la fase de explosión acelerada de los LLM. La velocidad de los avances fundamentales y amplios que elevan todas las aplicaciones de LLM claramente se ha ralentizado, y muchos de los descubrimientos recientes de gran impacto están en expansión hacia dominios específicos, optimización, tuning y productización. Eso no significa que mañana no pueda aparecer otro avance del nivel de Transformers, pero históricamente los cisnes negros rara vez andan en manada
Los clientes ya no comprarían herramientas de software como hoy, sino que podrían crear internamente todo el software que necesiten, o hacerlo con consultores de prompt engineering. Podría ser un mundo muy distinto
¿O habrá unas 700 empresas unipersonales en todo el mundo y el resto simplemente no podrá trabajar? ¿La Matrix?
La productividad no ha aumentado tanto desde que salió Claude 3.5. Tengo acceso ilimitado a todos los LLM, pero la mayoría son basura y me hacen crear más trabajo del que me ahorran. Las únicas personas que se benefician con esta herramienta son las que producen rápidamente resultados de baja calidad. Si no estás de acuerdo, entonces tú también eres una de esas personas
Mi trayectoria profesional es sorprendentemente parecida a la del autor. Curiosamente, la parte que el autor ve como el primer pilar que se derrumbó es la que ahora me parece más sólida
Los LLM fallan repetidamente en las particularidades de nuestro negocio. Cosas como la legislación fiscal local, los detalles de los procedimientos contables y las particularidades de la implementación de nuestro libro mayor. Son excelentes para refactorizar, convertir entre lenguajes y rastrear bugs en código existente, pero cuando se trata de repetir y escalar nuestro dominio, siempre hay muchas partes sutilmente incorrectas. Puede que sea porque las empresas donde he trabajado lidian intencionalmente con áreas complejas para construir una ventaja defensiva. Son empresas que se sostienen porque no existe ningún libro del que puedas hacer una copia, y el know-how se queda dentro. Además, si en una FinTech los gerentes recomiendan hacer documentos de diseño rápidamente con IA, eso me parece demasiado descuidado para un negocio que maneja dinero. Especialmente cuando ocurren muchísimas transacciones pequeñas, es demasiado fácil asignar mal montos por millones. Estos bugs son realmente difíciles de manejar. Corregir la lógica es solo el paso 1; después hay que arreglar los datos mal calculados en una base de datos inmutable y encargarse de los procesos regulatorios y de la comunicación con los clientes. Las correcciones terminan siendo trampas que las nuevas funciones y la observabilidad tienen que tener en cuenta. Algo como “recuerda que el pico en los datos del 2 de febrero se debe al incidente X”
Estoy creando varios productos basados en simulación física, puramente desde primeros principios. Pero si se lo dejas sin investigación activa, reflexión y validación, termina generando código de cálculo cientos de órdenes de magnitud más lento e introduce rutas alternativas y atajos absurdos, produciendo al final cálculos inútiles. Esto probablemente pasa como en el 95% de los casos. La supervisión es muy importante, y el pensamiento arquitectónico todavía no se puede externalizar. Lo único que puedes externalizar es la ejecución
Claro, muchas veces un ingeniero de software senior también es experto en eso, pero no es indispensable. Tradicionalmente, era útil para una producción sin fricción que un ingeniero pudiera resolver como el 90% del trabajo sin preguntarle a un experto del negocio, pero justo el punto central del texto original es que esa “tradición” ya terminó. En el nuevo mundo, el trabajo del ingeniero senior ya no es tener directamente esa expertise de dominio, sino hacer que el agente la tenga o la adquiera, y garantizar que sea verificablemente correcta. Los ingenieros senior que se aferren a la idea de que la expertise avanzada del dominio los mantendrá a salvo van a terminar tan pronto en un callejón sin salida como los juniors que no hicieron la transición
Tienen un vocabulario profundo, así que suenan como si supieran más de lo que realmente saben. Escriben código y depuran errores visibles muy bien, pero eso se debe en parte a que el dispositivo de prueba ayuda mucho
La idea central es darle la documentación al LLM y hacer que el LLM haga muchas preguntas para despejar ambigüedades y posibles malentendidos. Recomiendo echarle un vistazo a Skills. Realmente ayuda. https://www.youtube.com/watch?v=6BB6exR8Zd8
Pudimos resolverlo con archivos claude.md/agents.md bien organizados. También implementamos supermemory.ai para que las nuevas decisiones siempre se le recuerden al agente de IA cada vez que se inicia una nueva sesión
Siempre recuerdo la infame frase de Steve Jobs: “las ideas son baratas”.
La ejecución lo es todo, y si los LLM de frontera resuelven la ejecución, entonces las ideas pasan a ser la puerta hacia la abundancia. Pero la abundancia por sí sola no garantiza el “poder de retención”. Lo que a menudo se pasa por alto es la voluntad humana de seguir con ello y de realmente preocuparse. Mucha gente no se preocupa lo suficiente, o no quiere, como para crear, mantener y adueñarse de algo. Tal vez puedas lanzar una V1 más rápido, pero ¿puedes seguir empujándola? Un buen ejemplo se ve en la herramienta de música con IA Suno. Ya produce resultados bastante buenos. Mucha gente juega un rato en su pequeño mundo personal, pero pronto se cansa y se va, y solo quedan unos pocos creadores prolíficos que lo convierten en un entorno “parecido al trabajo”. La escala y la economía de delegar y ejecutar pueden haber cambiado, pero todavía hay muchos factores a considerar
Incluso como alguien con formación musical limitada, así lo siento, así que es probable que los músicos sean todavía más críticos. Las primeras veces impresiona y las melodías son pegajosas. Antes sonaba raro en el fondo, pero eso en su mayor parte ya lo corrigieron. Pero después de varias decenas de canciones, todo empieza a sonar igual. Todo es genérico, las canciones no cuentan una historia y se siente como música de fondo para anuncios corporativos. Intenté escribir prompts más precisos y no ayudó mucho; la mayoría de los detalles que harían interesante una canción simplemente los ignora. Los resultados más interesantes, de hecho, aparecieron cuando hice que se desviara de su rumbo como si fuera un bug. Le pedí que mezclara dos géneros muy distintos y salió algo con una sensación inquietante que no recordaba haber escuchado antes. Pero si quieres trabajarlo más, siempre se vuelve difícil, y trata de regresar a resultados genéricos mientras ignora instrucciones detalladas. Suno sí puede hacer remixes. Es parecido al código. Los LLM ya son muy buenos para el porting de algo que ya funciona a otro lenguaje donde también funcione. Pero si solo tienes una idea, fracasan en la parte original. Para lograr que un LLM implemente bien una idea, tienes que darle tantas instrucciones que terminas peleando con la ambigüedad del lenguaje natural y, en la práctica, se parece mucho a escribir el código tú mismo
Puedes resolver la ejecución si los empujas lo suficiente y si tienes un sistema con el que puedas obtener código que realmente funcione. Pero eso precisamente es la ingeniería. En este momento, en su estado base, todavía están lejísimos de reemplazar la ingeniería. Tal vez dentro de 3 años puedan hacerlo. Se está moviendo rápido. Pero hoy no puedes simplemente decir “hazme un compilador de Rust mejor” y recargarte esperando el resultado
Me gustan las canciones y las escucharía en mi playlist, pero no consiguieron gran respuesta en el algoritmo de Suno. Tampoco las promocioné mucho en otros lados, y cuando las subí apenas obtuvieron unos cuantos likes. No me decepciona. Hice música para mí mismo y compartirla fue un efecto secundario. La conclusión que saqué de esto es que hace falta muchísimo trabajo para que a la gente le interese y disfrute algo que yo hice. Hay que hacer marketing, ponerlo frente a la gente y lograr que presten atención. También estoy convencido de que hay que vincularlo con un video, una historia, una personalidad, algún tipo de vibra, para darles una razón de conectar con ello. Para que “pegue”, tienes que repetir todo eso ante la misma audiencia y dejar que se familiaricen con ello. Por eso se necesita persistencia, y de verdad tienes que preocuparte por aquello que quieres vender. Antes de que la gente se quede, primero tengo que quedarme yo
https://en.wikipedia.org/wiki/Sturgeon%27s_law
La ley de Sturgeon dice que “el 90% de todo es basura”. Este aforismo fue acuñado por el escritor y crítico estadounidense de ciencia ficción Theodore Sturgeon al defender el valor del género. Sturgeon sostenía que, en cualquier campo, la mayoría de las obras son de baja calidad, y que por lo tanto la ciencia ficción no era excepcionalmente inferior
Mi impresión es que se usan como herramientas de generación de una sola pasada. No sé mucho de música, pero me parece que para un artista hacen falta etapas intermedias, separación de pistas, personalización de instrumentos y muchos otros elementos que desconozco. Sin eso, me parece difícil usarlas para trabajo profesional
No estoy completamente de acuerdo con este post. Un vibe coder no puede diseñar, desarrollar e implementar un sistema de complejidad media sin romperlo todo.
Gran parte de usar bien una aplicación como Claude es tener comprensión conceptual y experiencia con conceptos de ciencias de la computación. Son cosas que un vibe coder jamás tiene. Si las tuviera, no sería un vibe coder
«No sé qué hacer», entonces súbete a la ola
También nos subimos cuando la ola eran los sitios web y las webapps. Entré a la industria del software antes de internet y he seguido cambiando de montura. Nunca es demasiado tarde para aprender una tecnología nueva. Cada nueva ola crea nuevos tipos de trabajo y de trabajadores. Basta con convertirte en uno de ellos. Monta a la bestia y domina la herramienta. Es el mismo juego de siempre volviendo otra vez.
Si hay una habilidad que siempre tiene demanda, es la capacidad de estructurar cosas en la cabeza: trabajo nuevo, procesos nuevos, gente nueva, lo que sea. Yo afiancé y desarrollé esa capacidad hasta volverla una herramienta muy afilada trabajando como maquinista de prototipos. Para quien no esté familiarizado, un maquinista de prototipos es alguien que hace lo necesario para fabricar piezas complicadas, con plazos cortos, semana tras semana. Trabaja con metal, plástico, lo que sea. Te vuelves muy bueno para familiarizarte rápido con procesos, máquinas-herramienta y materiales. Si haces eso por un tiempo, terminas absorbiendo información nueva muy rápido y entendiendo el trabajo mucho más deprisa y con más precisión que mucha otra gente. Cualquiera puede empezar. Ten curiosidad y construye algo. Y luego construye más. Comparte lo que hiciste y construye lo que otras personas quieran.
En los 90 y los 2000 hubo la ola de que «la programación orientada a objetos va a cambiarlo todo». Era hacer en orientación a objetos lo que ya habíamos hecho con éxito cientos de veces antes. ¿Escribes código relacionado con aviones? En la universidad de verdad escuché que bastaba con comprar un objeto avión todopoderoso que hiciera todo lo del avión. ¿Pero no era la orientación a objetos la solución universal? Luego vino la generación de código, prueba Ruby on Rails, haz un sitio web en 2 segundos. Había generación de código por todos lados. La cosa se fue en direcciones raras y luego llegó TDD. Vi conversaciones reales en las que decían que, si no hacías TDD, eras tan mal ingeniero que deberían meterte en la cárcel. No, espera, no era TDD, era BDD la respuesta. Lean, no, Agile, no, agile en minúsculas, pero al principio era eso, no, Scrum, no, XML, espera, eso fue la década pasada, JSON, y al final SAFe. Y ahora es «¿ya viste este chatbot?». Cada ciclo trae cosas buenas si prestas atención. Pero también trae mucho humo y mucha ansiedad. Solo hay que experimentar y aprender. Una cosa que para mí no ha cambiado es que casi todo el mundo preferiría morirse antes que pensar con cuidado en el resultado de que sus sueños se cumplan. Mientras eso siga siendo cierto, la gente seguirá pagando para que alguien monte por ellos al dragón exagerado de la moda.
Todo el flujo de fábrica de resultados malos en masa, perdón, el flujo «AI native», es así: «Wow, convencí al chatbot de hacer algo que yo no entiendo en absoluto. ¡Qué bien hago mi trabajo!». Es como un premio de participación por construir cosas. Otra cosa lo construye y yo me llevo el crédito sin entenderlo bien. Mi esfuerzo no tiene rendimiento compuesto. No hay lecciones aprendidas. No se acumula comprensión. No hay ideas que lleven a innovaciones futuras. No hay diferenciación. Solo gritas al vacío hasta quedar mentalmente entumecido, y cuando la tragamonedas escupe una mezcla mediocre que «se ve suficientemente bien», al día siguiente repites. Si ese es el juego, yo me bajo. Qué bueno si a otros les gusta, pero pensar que aquí hay algún tipo de dominio es una ilusión. La única condición para «tener éxito» con esta herramienta es dejar de preocuparte y rendirte.
Ya lo había publicado antes, pero vale la pena volver a ponerlo
Trabajo en DevOps en una empresa muy activa en el uso de LLM. Las etapas fueron más o menos así: intentar que el LLM hiciera «muchas cosas», hacer que hiciera más, ejecutar varios agentes, volver otra vez a un solo agente pero hacer que construyera herramientas, y luego pasar a herramientas deterministas que tanto humanos como LLM puedan usar. La razón es esta: tanto en despliegue como en pruebas, las herramientas deterministas dan respuestas binarias y son repetibles. Si algo falla, siempre puedes volver a una herramienta que una persona pueda ejecutar. Además, son más rápidas. Un script simple corre en menos de 30 segundos, pero el «bla bla plausible» siempre parecía tardar de 2 a 3 minutos. Al final esto te regresa a este artículo. https://spawn-queue.acm.org/doi/10.1145/3194653.3197520 O sea: «haz una lista de tareas, escribe el script de cada tarea, combina los scripts en funciones, y las funciones se convierten en el sistema». Además, si dejas que el LLM haga lo que quiera, felizmente va a producir código. Puedes agregar pruebas para verificar que las pruebas funcionen. Eso ya se hacía con código escrito por humanos. También puedes leer el código. Y cuando lees el código, ves que a veces produce código que funciona mientras hace locuras absolutas. Los humanos también hacen eso, pero ese es otro tema. Al final, todavía tienes que verificar que el sistema que se construye tenga sentido. Dicho más simple, puede que programar haya muerto, pero la ingeniería de software sigue viva y muy activa.
Puedes hacer que un LLM grande haga de todo. Se puede, y de hecho se hace. Pero cuesta muchísimo dinero y tarda bastante. En cambio, si usas IA para construir herramientas que resuelvan de forma determinista la mayor cantidad posible de tareas del proceso, y luego haces que la IA use esas herramientas, todo corre mucho más rápido y más barato. Como extra, al final incluso puedes dejar la IA cara en la nube y pasar a modelos locales pequeños o medianos.
Si la visión del futuro del autor es correcta, los ingenieros de software competentes están a salvo
El conocimiento del dominio puede aprenderse mucho más rápido que cómo aplicar buenos principios de ingeniería. Es posible que un ingeniero cuya principal ventaja competitiva sea el conocimiento del dominio no sea tan sobresaliente en la ingeniería en sí. Aun así, podría encontrar trabajo en otras áreas de la industria donde sí se necesite el conocimiento del dominio acumulado
Muchos buenos ingenieros de software, con la arrogancia de pensar que el conocimiento del dominio era fácil de obtener, han arruinado innumerables sistemas ERP. Una enorme parte de TI consiste literalmente en meter reglas de negocio en sistemas
Y aun así sigo viendo y revisando código de desarrolladores de software “profesionales” que no siguen buenas prácticas de ingeniería de software. Decir que un ingeniero cuya principal ventaja es el conocimiento del dominio puede no ser bueno en ingeniería también aplica a ingenieros sin conocimiento del dominio. Al menos esa ha sido mi experiencia. Tal vez solo hemos tenido mala suerte
Porque el conocimiento del dominio valioso no es el de ayer, sino el de hoy y el de mañana. En los campos donde el conocimiento del dominio importa, está profundamente entrelazado con la ingeniería. No le encargarías a Jeff Dean desarrollar Unreal Engine desde cero. Aun así, también hay muchos principios de ingeniería de software que los expertos en dominio no han internalizado por completo o no ejecutan lo suficiente. Mientras el conocimiento del dominio siga siendo valioso, esta situación también continuará. Porque la ingeniería de software también es otro dominio
La metodología puede mejorarse mucho más rápido que adquirir conocimiento especializado. Lo primero es un tema de enfoque, así que se puede imponer y elevar rápidamente. Lo segundo depende de la disposición de esa persona para aprender, su capacidad y el tiempo disponible en ese momento, y no puede forzarse más allá de un apoyo razonable. Además, tiene un carácter acumulativo, así que la curva de aprendizaje inicial es mucho más empinada
Estoy usando Claude Code y Opus 4.7, y más que generar código incorrecto, tiende a escribir demasiado
Sigue teniendo valor pensar en una función específica y meterla en el código donde mejor encaje. Claude a menudo elige una capa del stack, por ejemplo la capa de presentación, y la empuja ahí. Si unas semanas después esos mismos datos se necesitan en otra parte, Claude no puede reutilizar el código de la capa de servicios y hace una especie de “trasplante”. Si una persona no presta atención, la cantidad de código se duplica y la lógica se repite. No parece que herramientas de IA como Claude vayan a mejorar mucho en esto pronto. Donde trabajo ya hay presión para reducir el uso de Opus 4.7 por ahorrar costos. Alguien dijo que para “correcciones simples de bugs” usemos un modelo más pequeño. A veces funcionará, pero ¿con qué frecuencia se puede saber de antemano que realmente será una corrección simple? Si los costos suben, parece probable que baje el interés por escribir “todo el código” con esta herramienta. Si la gente se mueve a modelos más baratos y menos efectivos, también es muy probable que desaparezca la presión de no revisar ese código. Ya veremos a dónde termina llegando todo, pero quizá no cambie de forma tan dramática como teme el autor
Solo con decirle a la IA que reduzca a la mitad las líneas de código en producción y revise si existe alguna otra librería reutilizable, el efecto es sorprendentemente bueno. También parece que se podría crear un bot de refactorización que detecte duplicaciones y las extraiga. Hoy no viene por defecto, pero no está nada claro que sea imposible
Pero la pregunta abierta es si tener demasiado código realmente es un problema. Estas herramientas ya son parte de la vida. Si resuelven problemas o ayudan a depurar más rápido, y si el software tiene menos bugs, entonces tal vez no sea demasiado código, sino exactamente la cantidad correcta de líneas
fooBar()yfooBarExtended()La segunda ya tenía los parámetros y funcionalidades adicionales necesarios para el problema actual. Pero Claude, en vez de llamar a esa función, seguía intentando agregar esos mismos parámetros extendidos a la primera. Incluso después de decirle que no lo hiciera, más tarde volvió a sugerir lo mismo, y a veces de verdad desespera
Sea cual sea la visión que uno tenga sobre el futuro de la industria, me cuesta creer que se pueda encontrar un éxito profesional mayor en la carpintería artesanal que en el software artesanal
Alguna vez me dijeron que intentara vender los muebles que hago, y mi respuesta siempre es la misma. Ya cometí una vez el error de convertir un hobby en trabajo, y no pienso repetirlo. Al menos el software todavía paga bastante bien
Hay alguien con quien trabajo que construye cosas como decks, jardines, caravanas, cobertizos y cercas, y gana muy bien. Claro, para ser justos, esa persona también tiene una habilidad impresionante
El marco de la puerta se pudrió y le pagué 4 mil dólares a un carpintero por fabricar un reemplazo. Reemplazar la puerta misma costaría fácilmente 25 mil dólares. Si te mudas a un distrito histórico importante con muchas puertas talladas a mano, se puede ganar un dinero decente
Pero la proporción del mercado que quiere pagar por software hecho a mano es exactamente 0%
No es carpintería, es agricultura. Hay que conseguir tierra y cultivar tu propia comida. La única forma de sobrevivir es no participar en la economía en absoluto