No soy ingeniero de software

• El rechazo a la identidad de ingeniero de software comenzó hace 23 años, cuando recibió la evaluación de que era “un buen hacker, pero no un ingeniero”
• El paradigma de agentes se siente como una forma de hacer programas que deberían ser deterministas usando programas no deterministas
• La confianza en el código está en la legibilidad, la comprensibilidad, la eficiencia, la capacidad de razonamiento y la reproducibilidad de obtener la misma salida con la misma entrada
• Los agentic user flows del trabajo y los KPI de uso de IA se perciben como una forma de priorizar métricas y entradas en lenguaje natural por encima del buen código
• La visión de futuro de la industria de la IA parece ir más allá de reemplazar el desarrollo de software y fantasear con ponerle un foso al pensamiento mismo

---

Ingeniería de software y el paradigma de agentes

• La actitud de excluirse a sí mismo de la identidad de ingeniero de software parte de una experiencia de hace 23 años, cuando un colega le dijo que era “un buen hacker”, pero no un ingeniero
• El reciente “nuevo paradigma de agentes” parece una forma de pedirle a una máquina como Waylon Smithers que no cometa errores, y luego presentar el resultado como ingeniería de software experta
• Se está presentando como el futuro de la ingeniería de software una forma de escribir programas que deberían ser deterministas usando programas que producen salidas no deterministas
• La convicción básica sobre el código sigue estando en la legibilidad, la comprensibilidad, la eficiencia, una capacidad suficiente de razonamiento y la reproducibilidad de obtener la misma salida con la misma entrada
• Como la reproducibilidad ya es difícil en los sistemas reales, el acto mismo de escribir código no debería construirse sobre “arenas movedizas”
• Siguen importando detalles como el impacto que una vista compuesta por subconsultas acopladas y expresiones de agregación puede tener en el rendimiento de consultas, la inversión de control (Inversion-of-Control) y diseños que separan funcionalidades de los métodos para poder probarlas de forma independiente

Desconfianza frente al flujo de desarrollo centrado en IA

• Los agentic user flows exigidos en el trabajo no tienen un significado claro, y tampoco resulta convincente por qué una caja de texto de entrada en lenguaje natural sería mejor que elegir dentro de un pequeño conjunto de opciones
• Hay un impulso por usar agentes en todas las etapas del ciclo de vida del desarrollo de software, y hasta se dice que escribir código a mano será tratado como usar COBOL
• Los agentes parecen wrappers de prompts de LLM que evalúan salidas según el contexto, y el resultado real a menudo se siente insuficiente
• El uso de IA se sigue como KPI, pero durante los últimos 23 años ha sido más importante escribir buen código que cumplir KPI
• En el pasado, recibió la evaluación de que su código “parecía escrito por un matemático”, y lo tomó como un gran elogio
• La implementación de un staff software engineer del mismo trabajo no tenía interfaces explícitas, exponía el contenedor de DI como miembro public static y usaba configuración en CSV no porque fuera adecuada para datos tabulares, sino porque “era más fácil para los usuarios de negocio”
• Decir que esa implementación era muy mala le trajo problemas, y eso lo llevó a la conclusión irónica de que quizá no es un ingeniero de software
• Dos veces escuchó de alguien a quien considera inteligente el consejo de que, como la IA es el futuro de la escritura de software y de la industria, hay que aceptarlo, pero esa postura le parece descuidada
• El software de IA que ha probado se sintió como algo que interfiere con el proceso de pensamiento o incluso lo toma activamente en su lugar, y esa apropiación (co-option) le preocupa
• Líderes de grandes empresas de IA hablan con entusiasmo sobre el futuro de la industria del desarrollo de software, anuncian que sus productos tendrán devastating effects sobre el empleo y usan expresiones como “intelligence too cheap to meter”
• Ese futuro resulta terrible no porque las máquinas vayan a convertir a todos en clips de papel, sino porque están imaginando ponerle un foso al pensamiento mismo

[GN⁺]

Comentarios de Lobste.rs

• En un libro de Mary Walton sobre W. Edwards Deming aparece una anécdota así. A un obrero de fábrica se le descompuso una máquina y solo empezaron a salir productos defectuosos; lo reportó, pero como el mantenimiento se tardó, intentó arreglarla por su cuenta y entonces llegó el supervisor y le dijo que simplemente la siguiera usando
  Al final, la instrucción era “haz productos defectuosos”, y él dijo algo como: “¿Dónde queda mi orgullo como trabajador? Sería mejor si el supervisor me respetara aunque fuera tanto como a la máquina”. Lo que pasaba es que él no quería fabricar productos defectuosos y cobrar por eso

  • ¿Es este libro? https://deming.org/the-deming-management-method-by-mary-walton/
    ¿Vale la pena leerlo?

• Tengo mucha menos experiencia que el autor, pero al inicio de mi carrera intenté sacar parte de un flujo de trabajo de negocio fuera de CSV por varios problemas con CSV, y en ese momento me respondieron: “Para los flujos de trabajo de negocio, CSV es más fácil”
  En ese entonces, igual que el autor, sentí que esa respuesta era bastante mala, pero con el tiempo he llegado a pensar que esa decisión estaba más cerca de ser la correcta

• Si todavía te atormenta una opinión tonta del tipo “hace 23 años alguien dijo que no eras ingeniero de software”, creo que la solución es no darle tanta importancia a la opinión ajena
  Si te frustran las políticas tontas de tu empleador o la falta de responsabilidad de tus colegas, puedes buscar otra empresa. Hay 8 mil millones de personas en el mundo, muchas de ellas quieren que una computadora haga algo por ellas, y muchas de ellas pagan por programación
  Suena como decir: “Cuando empecé a trabajar en una panadería, un compañero dijo que los croissants eran una conspiración de Big Dairy para vender más mantequilla; tomé eso como base de mi cosmovisión y concluí que nunca más podría trabajar en una panadería”. Si no estuviera la edad del autor, habría pensado que era un estudiante de preparatoria, pero si está hablando de algo que pasó hace 23 años, claramente ya está bastante más grande que eso

  • Solo puedo adivinar por qué están marcando este post, pero me siento bastante seguro de esa suposición. Aun así, el problema central no es tanto que el tono sea poco amable, sino que esquiva la tesis principal del texto
    El punto del texto no es que el autor literalmente no sea un ingeniero de software; probablemente ha trabajado durante mucho tiempo con ese título. El punto se parece más a que excluirse a sí mismo de ese título es una reacción a lo mucho que ha cambiado esta industria
    Es como decir: “Esto no es ingeniería, es una tontería. Si esto es lo que significa ser ingeniero de software, entonces yo no soy eso”
    En lo personal, empatizo con ese sentimiento. Muchas veces he sentido que llamar “ingeniería” a lo que hacemos como desarrolladores de software es casi un insulto para otras ramas de la ingeniería. Sobre todo porque, aun llamándolo así, en realidad no nos importa mucho lo que construimos
    Un ingeniero civil se toma muy en serio que un puente se caiga, y cuando ocurre un colapso importante, toda la industria reacciona y aprende para intentar que no vuelva a pasar. En cambio, un supuesto “ingeniero” de software puede tumbar producción una y otra vez por razones completamente evitables y aun así ponerlo en su currículum como si fuera una historia de éxito
    Sobre la tendencia actual en la ingeniería de software —o sea, no preocuparse por el código que realmente se despliega y delegar su escritura a otra “inteligencia”—, seguramente ya se imaginarán lo que opino
    Entiendo por qué está pasando esto, y no quiero decir que tenga todas las respuestas sobre qué hacer. Pero no deberíamos fingir que esto es un trabajo serio, es decir, “ingeniería”