Crisis de identidad del programador

• La identidad del programador está siendo amenazada recientemente por la aparición de la IA y las herramientas LLM
• La cultura de la programación comenzó con la ética hacker del MIT en los años 50, considerando el acto mismo de escribir código como una técnica profunda (craft), y tomando como valores centrales la lógica precisa y la inmersión en la resolución de problemas
• Sin embargo, hoy la industria de la IA y las herramientas LLM buscan convertir a los desarrolladores en simples redactores de especificaciones u operadores, imponiendo una forma de "vibe-coding" en la que, en vez de escribir código directamente, solo se dan instrucciones en lenguaje natural
• El código generado por LLM es no determinista e impreciso, y elimina la comprensión profunda y la inmersión que se obtienen en el proceso de leer y escribir código directamente, cortando así la conexión con la base de código
• Las empresas, con el argumento de aumentar la productividad, obligan a usar estas herramientas y reemplazan la colaboración y la cultura de mentoría dentro del equipo por interacciones con IA, debilitando el vínculo humano entre desarrolladores
• Se está perdiendo el valor esencial de ver la programación no como un simple producto final, sino como un proceso de pensamiento y comprensión, y los desarrolladores deben resistirse a estos cambios para proteger sus habilidades, su disfrute y su identidad profesional

---

La esencia y la tradición del programador

• Escribir código no es una tarea más, sino la identidad misma del desarrollador, y el editor es a la vez taller y santuario: un espacio para pulir la técnica y entrar en estado de flow

  • Con herramientas como Vim se trabaja sin barreras entre el pensamiento y el código, creando un mundo inmaterial que influye en el mundo real
  • El proceso de resolver acertijos importa más que la imagen terminada, y en ese flujo técnico que va de los dedos al buffer, el tiempo desaparece

• A finales de los años 50, en el MIT nació una nueva cultura de programación, donde hackers de espíritu experimental y contracultural usaban la Flexowriter y la computadora TX-0 en busca del programa perfecto

  • Tomaban como objetivo escribir código elegante y conciso alrededor de la idea de "The Right Thing"
  • Los miembros del Tech Model Railroad Club se obsesionaron con el lenguaje de máquina, dominaron la magia digital y establecieron una cultura de compartir con otros estudiantes lo que descubrían

• En el crisol computacional del Building 26 se forjó la técnica de programar, y esa cultura establecida hace unos 70 años continúa hasta hoy, todavía presente en la mente de los desarrolladores y en las máquinas

  • El legado de los hackers antiguos permanece como una habilidad profunda y casi física, y sobre esa base se construyó una industria apasionada
  • Los desarrolladores siguen motivados por la misma maravilla, la misma sensación de logro y la misma elegancia de resolver acertijos

• Pero estos valores centrales que componen la identidad del programador están siendo amenazados, y el futuro de la programación, que antes parecía brillante y claro, ahora está cubierto por una oscuridad inquietante, engaño e incertidumbre

La imposición de una nueva identidad por parte de la industria de la IA

• La industria de la IA de miles de millones de dólares, la comunidad de Hacker News y los defensores de los LLM en LinkedIn sostienen que el futuro del desarrollo de software casi no se parece a la programación, y lo que hace un año parecía un meme, el "vibe-coding", se está volviendo dominante

  • Ahora los desarrolladores tendrían que escribir especificaciones en Markdown en vez de código, y desaparecen la inmersión profunda y la profundidad técnica que surgían al explorar cada rincón de una base de código, resolver acertijos y descubrir secretos
  • En cambio, mientras agentes piensan por el desarrollador, este debe aceptar una cognición dispersa y cambios constantes de contexto, dejar la resolución creativa de problemas en manos de la máquina y convertirse en un simple operador

• Algunos desarrolladores celebran este cambio y esa nueva identidad llamada "Specification Engineering", entusiasmados con convertirse en operadores y, como Steve Jobs, "dirigir la orquesta"

  • Uno se pregunta por qué se hicieron programadores si aparentemente no les interesa programar, o si no estarán confundiendo a Woz con Jobs
  • No parece que Prompt, Context o Specification "Engineering" vayan a ofrecer a los programadores una carrera brillante y próspera

• Esto implica una devaluación de la técnica, la destreza y el trabajo, desplazando la capacidad única del desarrollador para el pensamiento abstracto hacia un terreno donde ya no haría falta y entrando en un espacio que ya ocupan los product managers y los diseñadores

El cambio en la dinámica de poder dentro de las empresas

• A medida que esta nueva identidad se impone en las empresas, cambia la dinámica de poder, y en un intento obsesivo de aumentar la productividad en el lugar equivocado, cada vez se obliga más a los desarrolladores a usar LLM de formas concretas

  • Si no obedecen, los expulsan, y deben usar productos que les anuncian su propia inutilidad o renunciar
  • Antes casi nunca la gerencia había dictado de forma tan específica las herramientas de los desarrolladores

• Los desarrolladores, como chefs o carpinteros, siempre han sentido gran orgullo por curar y perfeccionar sus herramientas, personalizándolas según su forma de pensar con configuraciones minuciosas del editor, ajustes en los dotfiles y armado del entorno de desarrollo

  • Han dedicado esfuerzo a personalizar su conjunto de herramientas como parte de su técnica, por lo que se siente como una intromisión que ejecutivos casi desconectados del trabajo cotidiano vengan a ordenarlo
  • Para programadores que durante décadas gozaron de cierta posición privilegiada dentro de las empresas, esta narrativa ofrece a la gerencia una nueva manera de inclinar la balanza a su favor

La diferencia esencial entre los LLM y los lenguajes de programación

• Algunos comparan el impacto de los LLM con la transición de lenguajes de bajo nivel a lenguajes de alto nivel (de Assembly a Fortran), pero es una analogía equivocada en varios sentidos

  • Fortran nacía desde la programación, no intentaba eliminar la técnica sino construir sobre ella, y ampliaba la precisión y expresividad de programar en vez de quitarlas
  • Fortran producía correctamente el resultado esperado a partir de la entrada; en el mundo de los LLM, ninguna de esas cosas es cierta

• Las computadoras y la programación pueden ser muy frustrantes, pero al menos siempre se podía confiar en su precisión, porque la programación ejecutaba exactamente lo que se le indicaba

  • Precisamente por esa dependencia y esa confianza en la precisión de la computadora, resulta fácil creerle a un chatbot cuando te gaslightea diciendo que sí hizo la tarea que le pediste

• Los LLM y su forma de trabajar son intrínsecamente imprecisos, tanto por las propiedades de los grandes modelos de lenguaje como por el hecho de dar instrucciones en lenguaje natural, que deja espacio para malentendidos

  • Es curioso que programadores que detestan el no determinismo hayan elegido este enfoque, cuando suelen preferir predictibilidad, composicionalidad, idempotencia y pruebas de integración que no sean inestables
  • El código generado por LLM representa lo contrario: caos inconsistente

• Dijkstra, en "On the foolishness of "natural language programming"", señaló que había que cuestionar la suposición de que el lenguaje natural simplificaría el trabajo, y subrayó que la ventaja del texto formal es que, para ser válido, solo necesita cumplir unas pocas reglas simples

La pérdida de comprensión profunda e inmersión

• Hay intentos de distinguir el desarrollo asistido por IA del vibe-coding mediante rigor y burocracia, pero eso ignora la naturaleza fundamental del problema

  • Cuando el LLM genera código, no se lee con el mismo cuidado con el que uno leería algo que escribió o revisó en un PR; hay algo en la programación con LLM que adormece la vista
  • Uno lo hojea por encima, se siente abrumado y aburrido, y cuando CI pasa y el programa compila, termina aceptando ciegamente trampas peligrosas
  • No se verifica si las pruebas quedaron configuradas para ejecutarse, si se importó una librería inexistente o si el modelo terminó implementando por sí solo toda una librería

• Una reseña o un resumen de un libro no puede reemplazar la experiencia de leerlo, porque hace falta recorrer cuidadosamente cada oración a lo largo de cientos de páginas y reflexionar sobre las ideas

  • Del mismo modo, hojear el resumen de un trabajo hecho por IA te quita la posibilidad de construir una comprensión profunda del dominio, del problema y de las posibles soluciones, y corta tu conexión con la base de código
  • Lanzarse al abismo de la ignorancia para dejar al descubierto el tema y sus implicaciones, aprender y comprender, es satisfactorio y esencial para hacer buen software
  • La propiedad, la agencia y el trabajo profundo y satisfactorio son reemplazados por una atención dispersa entre pestañas de agentes

• Joan Didion dijo: "Escribo para averiguar qué pienso, qué estoy viendo, qué veo y qué significa eso", y Peter Naur explora la misma idea en "Programming as Theory Building"

  • La "Theory" de Naur encarna la comprensión de la base de código: cómo funciona, su formalismo y su representación del mundo real
  • Ese contexto y esa intuición solo se obtienen mediante la inmersión, y Naur describe la "Theory" como el principal resultado de programar y el verdadero producto, incluso más que el software
  • Solo con una "Theory" bien desarrollada se pueden aplicar de forma efectiva extensiones y correcciones de errores a una base de código

• El buen diseño surge de la inmersión, del ir y venir en el buffer de texto y también del trabajo que a menudo ocurre lejos del teclado

  • Como no se puede contener toda la base de código en la mente, hay que sumergirse en módulos, clases y funciones para volver nítido un modelo mental borroso
  • Hay que leer y escribir código para ampliar la cognición y recuperar la familiaridad y la comprensión del dominio del problema

• Una vez construido parte del contexto y tras muchos intentos fallidos, por fin puede aparecer una solución, y hace falta sentir la disonancia del mal diseño

  • Solo al escribir código repetitivo y desagradable se descubre que existe una forma mejor: más concisa, elegante, componible y reutilizable
  • Eso obliga a detenerse para pensar a fondo el problema, tomar distancia y empezar de nuevo desde el principio
  • En cambio, el trabajo con agentes de IA carece de fricción, por lo que se evitan soluciones alternativas y ni siquiera se sabe si lo que se acepta es perfecto, mediocre, terrible o incluso dañino

El derrumbe de la colaboración en equipo y de la conexión humana

• La deuda cognitiva del código centrado en LLM va más allá de la pérdida de técnica: "slop-jockeys" con capacidad de atención reducida arrojan sus productos a pull requests y documentos de diseño, entorpeciendo la colaboración y obstaculizando al equipo

  • Los compañeros que hacen code review están entrando en crisis al darse cuenta de que ya no son la última capa de control de calidad, sino la primera
  • Tienen que señalar funciones recién agregadas pero nunca llamadas, librerías alucinadas y errores obvios de runtime o compilación
  • El autor, que claramente apenas hojeó su propio código, no se hace responsable y dice: "Claude lo escribió así. IA tonta, jaja"

• Los managers entrometidos y los ejecutivos que quieren ahorrar dinero están empujando a los equipos a reducir la interacción humana (ojalá de manera inconsciente)

  • En el aislamiento y la desconexión, ahora se nos da permiso e incluso se nos anima a levantar muros alrededor de la experiencia de trabajo
  • Cuando se necesita un compañero para programar en pareja, intercambiar y discutir soluciones, hacer prototipos, bosquejar arquitectura o responder preguntas expertas sobre partes oscuras de la base de código, se recurre al LLM en lugar de a una persona
  • Ya no harían falta un buddy de onboarding, un mentor o un colega; en su lugar, se puede hablar con una máquina
  • Evitar el contacto humano con un LLM se ha vuelto tan fácil que eso podría convertirse en la norma

La defensa de la identidad del programador

• Impacta lo dóciles que somos ante la narrativa del hype de la IA, cómo participamos activamente en el borrado planificado de la técnica y con qué facilidad entregamos nuestras herramientas de pensamiento

  • Fuimos de los afortunados que pudieron ganarse la vida con su hobby, pero incluso si se crean procesos estrictos y minuciosos para responder al slop, igual se está tercerizando la parte divertida del trabajo y reemplazándola por una tarea directiva y tediosa

• Los LLM parecen una solución de lanzar una bomba nuclear desde órbita al problema de la complejidad del software: en vez de resolver el problema real, se recurre a algo mucho más complejo y opaco para tratar apenas los síntomas

  • Reemplazar sed por Claude, o pedir respuestas sobre una librería o framework cuya documentación llevas horas revisando sin encontrar claridad, puede estar bien
  • Pero no quiero convertirme simplemente en operador o revisor de código y pasar al asiento trasero en el trabajo divertido e interesante

• Prefiero herramientas que ayuden con tareas repetitivas, a entender la base de código y a escribir el programa correcto, y me resultan desagradables los productos diseñados para pensar por mí

  • Rechazo productos que me quitan agencia sobre mi comprensión del software que produzco y cortan mi conexión con mis colegas
  • Aunque los LLM cumplan con todo el hype, igual perderemos todo esto y también la técnica
  • Los seres humanos importan más que las máquinas y las empresas que las respaldan, mientras ellas obtienen ganancias y el resto persigue el nuevo sueño americano que les venden
  • A cambio, estamos entregando nuestra capacidad de pensamiento crítico, la diversión, la técnica, la privacidad y quizá también el planeta

[command2alt]

En general, estoy de acuerdo.
Especialmente el cambio de contexto: pedir un prompt y luego, durante el tiempo de espera, se rompe la concentración y eso termina bajando la productividad. Si la velocidad de los LLM aumenta y la respuesta llega de inmediato, quizá eso se resuelva.

[serithemage]

Se siente mucho que el texto ya tenía una conclusión decidida de antemano y fue escrito para encajar en ella. El problema de que a los desarrolladores se les quite la responsabilidad de propiedad se lee, independientemente de los LLM, como una discusión sobre la "era del espíritu artesano vs. la era de la industrialización".

[GN⁺]

Opinión en Hacker News

• Lo que más me impresionó fue ver cómo los revisores de código se están quebrando mentalmente al darse cuenta de que ya no son la última etapa de control de calidad, sino la primera línea de defensa. Reciben solicitudes de revisión, pero ahora tienen que ir detectando una por una funciones nuevas que nunca se llaman, librerías agregadas de la nada, errores evidentes de runtime o compilación, etc. Y el autor del código se lava las manos con algo como: “lo escribió Claude”, “la IA se equivocó, jaja”. Desde que se adoptaron los LLM, la ley de Brandolini (la energía necesaria para refutar tonterías es mucho mayor que la necesaria para producirlas) se siente más real que nunca. Cuando un desarrollador con poca experiencia o poca habilidad genera miles de líneas en minutos, la responsabilidad real de garantizar la salud del sistema termina trasladándose a los revisores. Si ves el delta de líneas agregadas/eliminadas en los PR, los PR escritos por LLM casi siempre no hacen más que agregar código, mientras que los ingenieros senior con experiencia muchas veces eliminan tanto código existente como código nuevo agregan

  • En mi opinión, esto no es un problema técnico sino humano. Si pasa una vez, hay que dar una advertencia seria; si se repite dos veces, habría que escalarlo al manager y rechazarlo. No importa quién haya escrito el PR: al final lleva tu nombre, y si el código es un desastre, la responsabilidad también es tuya

  • Ya no hago code review en equipos grandes, pero si estuviera en una situación así, podría dejar pasar una evasión de responsabilidad una vez; si se repite, intentaría sacar a esa persona del equipo. Y si no fuera posible, me iría yo. Así de terrible me parece ese entorno

  • Creo que también tiene que ver con por qué últimamente siento que mi productividad bajó. Está la presión de producir más código más rápido, y además, cuando uso algo tipo agente, no logro captar bien el contexto completo del código que “escribí”. Solo puedo garantizar calidad dentro del rango que soy capaz de revisar cuidadosamente línea por línea, y ahí está el límite. Por eso últimamente uso la IA más despacio y de forma más conservadora, y aumenté la proporción de código que escribo a mano. La IA ayuda un poco cuando hay que aplicar definiciones de tipos claras o especificaciones repetidas a varias propiedades, pero incluso ahí el resultado no siempre es confiable

  • Cuanto más senior y con más experiencia es un ingeniero, más suele recortar código existente en proporción a lo que agrega. También vale la pena leer Negative 2,000 Lines Of Code

  • Creo que en el momento en que entra un LLM, la cuestión de a quién le trasladamos la responsabilidad se vuelve un problema social más amplio. La gente se atribuye los méritos cuando el resultado es bueno, pero cuando sale mal le echa la culpa a la IA con toda facilidad. Creo que con unos cuantos casos judiciales bien puestos, esa cultura cambiaría bastante

• Desde hace mucho siento que mucha gente que entra a la industria ve el código no como un oficio artesanal, sino como una forma fácil de ganar dinero. Desde que vi textos sobre desarrolladores de infraestructura open source que no logran mantenerse, pasando por programadores codificando en cafés, bootcamps y el movimiento de “solo necesitas aprender a codear”, grinders de LeetCode, y desarrolladores en San Francisco viviendo en su coche porque la vivienda es carísima, ahora el tema es automatizarse a sí mismos con IA y quedarse sin trabajo. El problema es la percepción de que los desarrolladores no son verdaderos profesionales. Los estándares son flojos, no hay código de ética, ni un conjunto de habilidades consistente, ni representación. Incluso la propia industria parece incapaz de defender sus intereses. Los abogados tienen su colegio, los médicos tienen su asociación médica, pero los desarrolladores solo tienen ansiedad existencial. Ahora el jefe te amenaza con “te voy a automatizar con IA y quitarte el trabajo”. Me pregunto por qué esta industria es tan hostil a sus propios intereses, cuando otras profesiones no lo son tanto

  • Creo que un “coder” y un ingeniero de software no son lo mismo. Que alguien termine un bootcamp y pueda hacer un programita simple en Python no significa que sea ingeniero de software. Si digo que tengo un título, me llaman elitista y me dicen que en ciencias de la computación solo se enseñan cosas inútiles para el trabajo real. Pero también es cierto que hay personas que, sin título, crecieron por su cuenta hasta convertirse en ingenieros excelentes. Aun así, coincido en que hace falta algún tipo de estándar. Si un bootcamper se mete a la startup unicornio de moda, perfecto, felicidades; pero en sistemas sensibles como Therac-25, preferiría que estuvieran a cargo personas con formación formal

  • ¿Que tu jefe te diga “si no automatizas, vas a perder tu trabajo”? Bueno, ese justamente es nuestro trabajo. Automatizar el trabajo es la esencia de lo que hacemos, y somos el grupo con más oportunidades y mejor entendimiento para automatizar su propio lugar de trabajo

  • Creo que la docencia tiene algo parecido al desarrollo. Hay maestros excelentes, maestros terribles, y muchos en el medio. Saber mucho de una materia no significa ser bueno enseñándola. Tal vez los desarrolladores se pueden ver como maestros que enseñan a las máquinas. Algunos enseñan carácter por carácter, idea por idea; otros enseñan transmitiendo una vibra general

• Dejando a un lado los LLM por un momento, a veces escribo código del que de verdad me siento orgulloso. Desde la estructura hasta cada línea, no hay una sola decisión sin motivo; es código que domino por completo como experto. Pero la mayor parte del tiempo no escribo código con ese nivel de perfección. La mayoría de las veces me permito un estándar algo más bajo, en plan “solo hay que terminar la tarea”. Aun así, cuando de vez en cuando logro entrar en ese estado de concentración y terminar algo bien hecho, se siente increíble; son mis mejores experiencias programando. Si además pienso en los LLM, en cierto sentido ahora es más fácil escribir código de alta calidad, pero en otro también es más difícil. Si entro profundamente en ese estado mental, puedo usar bien un LLM para llegar más rápido a un resultado mejor y con un estándar más alto. Puedo escribir código muy superior al que escribiría un LLM, pero también puedo escribir código aún mejor con su ayuda. El problema es que cada vez cuesta más mantener ese estado. Uno termina hojeando por encima el código generado por el LLM, ve que visualmente se ve bien y que además funciona, y lo deja pasar. Pero ese código aprobado a medias se va degradando poco a poco, y cuando llevas demasiado tiempo dejando pasar cosas con esa misma indiferencia, ya es tarde. Al final nunca te conviertes en el experto de ese código, y solo se acumula código mediocre

  • En los últimos dos meses, usando más IA, pasé por este proceso:
    1. La usé solo para cosas pequeñas, y me sorprendió lo bien que lo hacía
    2. Empecé a darle tareas cada vez más grandes, buscando cómo aprovecharla con eficiencia
    3. Llegó un punto en que la IA hacía casi todo como si fuera un agente, y yo solo revisaba el código al final
    4. Entonces me di cuenta de que “al final igual tengo que revisar yo mismo todo el código con cuidado, y la IA no es ese atajo exacto que esperaba” (por ejemplo, no puedes simplemente darle una idea general y esperar un buen código final convincente)
    5. Así que volví a usar la IA principalmente para tareas pequeñas La IA me parece útil para research, prototipos, POC o código desechable que “funciona, pero jamás usarías en producción”. En diseño fundamental o estructura prefiero trabajar yo mismo; para cosas pequeñas como implementar funciones o completar lógica de detalle, la IA sí ayuda bastante

• Este ensayo coincidió totalmente con lo que pienso y me dio gusto leerlo. En la empresa intentamos usar IA, pero en la mayoría de los casos el resultado era malo y al final casi todo lo volvía a escribir yo mismo. Me convence cada vez más que delegar a la IA tiempo de pensamiento innecesario o resolución de problemas es una pésima decisión para mi carrera. La IA no pasa de ser un generador de texto de calidad media

  • Lo que más tristeza me da es que, en realidad, yo podría ser muy bueno programando con LLM. Mis colegas están completamente fascinados con el nuevo mundo y no hacen más que producir código basura generado por IA, además de tardar muchísimo. En cambio yo sí tengo noción de arquitectura de software y sé pedirle al LLM casos borde importantes; o sea, sé mejor “cómo darle instrucciones a la IA”. Además manejo bien el contexto y, por mis características neurodivergentes, llevo mucho tiempo entrenando cómo comunicarme con entidades que funcionan distinto a mí, así que puedo empatizar con un LLM de una forma más mecánica. Mis colegas se frustran más porque el LLM no les lee la mente. Pero los LLM también van mejorando, así que mi ventaja no será eterna. Y mientras más código basura de IA se acumule, más habrá que usar otro LLM para lidiar con ello, en un círculo vicioso. Al final nadie va a entender qué hace el código, y yo quizá termine rezándole al dios máquina

• Sobre la duda de “¿por qué esa gente decidió ser programadora si ni siquiera parece interesarle el código en sí?”, yo subrayaría que el objetivo es resolver problemas. Programar es un medio, no un fin. “Ajustar el editor, los dotfiles y el entorno de desarrollo” puede ser divertido, pero a mí me parece complejidad innecesaria y con gusto lo delegaría

  • Configurar directamente el editor, los dotfiles y el entorno de desarrollo al final te da familiaridad con tu espacio de trabajo, mejora tus habilidades con las herramientas y te permite construir un ambiente más productivo. Que luego te conviertas en “la persona a la que llaman” cuando hay que tocar scripts de build viene de haber cuidado esas cosas. Hay demasiada gente que, incluso tras diez o veinte años usando Git, sigue sin entender conflictos de merge o el uso básico, y entonces todas las tareas molestas terminan cayendo sobre quienes sí aprendieron bien las herramientas

  • Decir “esto no tiene valor” es un tipo de argumento que, si lo llevas hasta sus últimas consecuencias, puede terminar en “¿y qué valor tiene existir siquiera?”

  • El propósito de casi todos los trabajos del mundo es resolver problemas, así que me pregunto por qué, entre tantas profesiones posibles, eligieron justamente software

  • Estoy 100% de acuerdo con eso de que “el objetivo es resolver problemas, y programar es solo el medio”. Quienes se entristecen porque la IA reemplace la programación son más del tipo “artista del código”, gente más apegada a la ‘forma’ de lo que se construye. Yo me enfoco en el problema mismo, así que no me afecta en absoluto que la IA programe en mi lugar

  • Tanto la idea de que “programar no es el fin, sino el medio” como la de que “jugar con el editor es divertido pero no valioso” son cosas totalmente subjetivas. Incluso si desaparecieran los problemas a resolver, seguiría habiendo gente a la que le gusta programar por sí mismo; si en el mundo no existiera un solo problema, igual habría mucha gente que disfrutaría programar

• Me pareció muy interesante este texto. Coincide casi por completo con lo que siento sobre programar con LLM. Yo era de los que programaban simplemente porque les gustaba, y además disfruté hacerlo como profesión. Pero últimamente me da pena no poder llevar al trabajo ese hobby que tanto me gustaba. Se convirtió en una tarea completamente distinta

• Ya tengo mis años. Hacia 1995 programábamos en un entorno totalmente distinto al de hoy. En esa época el ingeniero conocía al cliente objetivo, el stack tecnológico y las tendencias del sector, y realmente llevaba la batuta. Tu código era tu patio de juegos: lo rehacías como querías y hasta definías tu propio estilo de indentación o de llaves (si se rompía, tú mismo lo arreglabas). No había unit tests como ahora (a lo mucho se validaban parámetros), casi no había code reviews formales, y en lugar de eso se hablaba con colegas en la oficina mientras se rayaba el pizarrón. Si había un bug, se arreglaba de inmediato. Al final management ganó, y parece difícil que esa era del ‘cowboy coding’ vuelva. Puedes extrañar a la Apple de los 90, pero ya no se puede regresar ahí. En verdad era divertido

  • Yo empecé más o menos en esa época, y nosotros sí hacíamos revisiones de código periódicas por ISO 9001. Imprimíamos el entregable, nos juntábamos tres personas en un cuarto, revisábamos cada línea y todos tenían que firmar. Lo hacíamos en un RTOS de control industrial. La gestión del proyecto se llevaba con un diagrama de Gantt de 40 pies impreso y pegado en la pared. Época completamente waterfall

  • Yo empecé a finales de los 2000, y en ese entonces las rutas de carrera y los límites entre especialidades eran mucho más claros. El sysadmin y el desarrollador estaban claramente separados, pero ahora esperan que yo también cubra el rol de operador de sistemas, así que el alcance del trabajo creció. Yo desarrollé habilidades de sistemas como hobby, y cuando me tocaba asumir esa clase de trabajo, en la práctica las ignoraba porque la documentación del vendor y los trainings eran tan malos que daban ganas de mirar para otro lado

  • No creo que toda la industria vaya a volver al cowboy coding, pero sí creo que en ciertos entornos ese estilo sigue vivo. En WhatsApp entre 2011 y 2019 el ambiente era bastante libre. Depende del entorno, pero según el costo de detectar errores antes o después de producción, cambia qué enfoque conviene. Personalmente prefiero un enfoque que reduzca el costo de arreglar errores. Eso sí, obviamente intento no cometer errores vergonzosos y sí hago las pruebas realmente necesarias

  • Ahora entró demasiada gente con mentalidad de negocio, demasiado vibe coder y demasiados script kiddies, y todo se volvió pésimo

  • El problema del cowboy coding es que un solo miembro poco confiable puede arruinar al equipo entero. Mientras más grande es la organización, más inevitable es que aumenten también esos miembros problemáticos, y para evitar explosiones necesitas cada vez más mecanismos de control. En equipos pequeños de élite basados en confianza, el cowboy coding es lo más eficiente; pero como es difícil evaluar bien a los candidatos al contratar, no encaja nada bien en organizaciones grandes. Tal vez sobreviva solo en empresas pequeñas o en equipos pequeños dentro de empresas grandes

• Me cuesta estar de acuerdo con la frase del autor: "<i>Los LLM son una solución tipo arma nuclear final dirigida contra la complejidad del software. En vez de resolver el problema real, intentan aliviar los síntomas trayendo una complejidad todavía mayor</i>". El objetivo central de adoptar IA es centralizar a los “trabajadores creativos, caros y altamente calificados” en unas poquísimas empresas que diseñan IA, y despedir a los trabajadores creativos del resto de las compañías para dejar solo mano de obra simple. O sea, el objetivo es simplificar con IA toda la complejidad de los negocios. Si usamos como ejemplo El mago de Oz, nadie quiere mirar detrás de la cortina; todos solo quieren que su trabajo sea más fácil. Es un fenómeno nacido de ignorar por completo los riesgos de largo plazo para quedarse con las ganancias de corto plazo

  • Esa clase de centralización ya pasó en muchas industrias. Por ejemplo, la banca antes tenía banqueros locales que tomaban decisiones reflejando las características de su región, pero luego todo pasó a decidirse centralmente desde el HQ. Los banqueros locales fueron empujados al mundo “debajo del API”, mientras la élite del HQ se queda con toda la riqueza. Vale la pena revisar conceptos como “Legibility” y “Seeing Like a State”

• Me encantó este texto. También coincido con algunas opiniones de que resolver problemas importa más que el código. Pero creo que si empezamos a delegar a la IA incluso los problemas que requieren pensamiento profundo, esa capacidad misma de resolver problemas profundos puede atrofiarse con el tiempo. Simplemente decir “hazme algo” no me parece verdadero problem solving

  • Creo que se pueden disfrutar ambas cosas: resolver problemas y la artesanía. Lógicamente, resolver problemas tiene más valor, pero para mucha gente la diversión de “hacerlo con las manos, tocar, construir” era una parte enorme del placer, y por eso lamentan perderla. Quienes se definen como “programadores”, como en este texto, por lo general disfrutan de verdad resolver problemas, crear, hacer las cosas por sí mismos y el tinkering