- Los desarrolladores senior y quienes no son desarrolladores reciben la misma frase de que los agentes de IA reemplazarán a los desarrolladores, pero la interpretan con criterios distintos: estabilidad y aprendizaje del mercado.
- Las áreas de negocio quieren lanzar rápido para obtener feedback y reducir la incertidumbre, mientras que los desarrolladores senior desconfían del aumento de complejidad que puede romper el sistema.
- Una vez que hay clientes, empiezan a operar al mismo tiempo dos ciclos: exploración de mercado y continuidad del servicio, y la responsabilidad central del desarrollador senior pasa a ser la gestión de la complejidad.
- La persuasión no termina con decir “la complejidad es el problema”; también exige satisfacer la necesidad de velocidad de la otra parte mediante experimentos más rápidos, como usar Google Forms o botones en una UI existente.
- La IA acelera la salida al mercado, pero puede perjudicar la capacidad de entender, modificar y depurar, y además no asume responsabilidad, por lo que el desarrollador senior puede separar Speed y Scale.
Por qué una misma frase se escucha con criterios distintos
- Los desarrolladores senior y quienes no son desarrolladores interpretan de forma distinta la misma frase: “los agentes de IA son el futuro del desarrollo de software y los desarrolladores dejarán de ser necesarios”.
- En copywriting, el mensaje debe ajustarse a la audiencia, y una misma frase cambia de significado según quién la reciba.
- La razón por la que la intuición del desarrollador senior se separa del optimismo sobre la IA es que la definición del problema cambia según si el foco del trabajo está en el aprendizaje del mercado o en la estabilidad del servicio.
Lo que preocupa a los desarrolladores senior
- Entre los desarrolladores senior hay quienes quieren introducir algo basándose en nuevas herramientas, prácticas de otras empresas o mejores prácticas vistas en Hacker News.
- Pero el tipo de senior más valorado pregunta primero: “¿de verdad hace falta?”, “¿qué pasa si no lo hacemos?”, “¿podemos aguantar por ahora y volver a verlo después si se vuelve más importante?”.
- Este tipo intenta evitar desarrollar al máximo, reducir y reutilizar.
- En el desarrollo profesional de software, lo que más preocupa a un desarrollador senior es la complejidad.
- Los casos especiales, los condicionales, una nueva tabla en la base de datos o un nuevo componente, todo eso añade complejidad al sistema.
- Quien es responsable de un sistema en funcionamiento termina temiendo el aumento de complejidad.
- Incluso los desarrolladores senior muy buenos para diseñar soluciones nuevas y creativas pasan a desconfiar de la complejidad cuando quedan a cargo de un sistema en producción.
Lo que preocupa a las áreas de negocio
- Marketers, personas de ventas, product managers y CEOs viven dentro de un ciclo en el que sacan algo al mercado, reciben feedback y aprenden si tiene valor o no.
- El objetivo de ese ciclo es el aprendizaje, y su mayor amenaza es la incertidumbre.
- Como ninguna estrategia garantiza el éxito, la incertidumbre actúa de forma implacable.
- Cuando las compensaciones de marketing y ventas, el sueldo del fundador y los datos del product manager se combinan con el paso del tiempo, la única forma de reducir la incertidumbre antes del deadline parece ser lanzar al mercado lo más rápido posible.
- Cuanto más se saca al mercado, más feedback se obtiene y potencialmente más se reduce la incertidumbre.
- Toda empresa comienza en este ciclo, que gira alrededor de la velocidad pura.
El segundo ciclo después de que aparecen clientes
- Cuando los clientes empiezan a pagar, aparece un segundo ciclo cuyo objetivo es la continuidad y la garantía del servicio.
- El sistema debe seguir funcionando, ser comprensible, depurable, modificable, enseñable y estable.
- Los desarrolladores senior valoran la estabilidad porque se les asigna la responsabilidad de negocio de seguir prestando servicio a los clientes.
- Lo que amenaza todo esto, otra vez, es la complejidad.
- La complejidad hace que el sistema sea menos comprensible, menos depurable, menos modificable, más difícil de enseñar y, en última instancia, menos estable.
- Si la complejidad sube, la estabilidad baja, el desarrollador senior no puede cumplir con su responsabilidad y pueden surgir problemas como interrupciones en los pagos.
- Si el objetivo del primer ciclo es reducir la incertidumbre, el objetivo del segundo es la gestión de la complejidad.
El punto donde falla la comunicación
- Después de que aparecen clientes, los dos ciclos —exploración del mercado y continuidad del servicio— funcionan al mismo tiempo.
- El negocio debe explorar posibilidades mientras sigue prestando servicio a los clientes.
- Según a cuál ciclo se dedique el tiempo, un mismo problema se ve de forma distinta.
- Las áreas de negocio quieren construir y lanzar más rápido para reducir la incertidumbre.
- Los desarrolladores senior, en cambio, a medida que aumentan los pedidos, se preocupan por la complejidad, el costo de mantenimiento, la comprensibilidad, la velocidad de desarrollo sostenida y la productividad con el paso del tiempo.
- Pero hablar solo en el lenguaje de la gestión de la complejidad difícilmente resuelve el deseo de reducir incertidumbre que tienen otras áreas.
- Para persuadir, la solución del desarrollador senior también debe expresarse como una solución al problema de la otra parte.
- La comunicación falla cuando se explica el problema desde la perspectiva de la complejidad, pero no se comunica la solución desde la perspectiva de la reducción de incertidumbre.
La fortaleza práctica de los desarrolladores senior
- La habilidad más útil de un desarrollador senior está en no construir cosas innecesarias y en encontrar oportunidades para reutilizar lo que ya existe.
- Si hay que recopilar datos mediante una encuesta, se puede usar Google Forms.
- En lugar de crear y probar una funcionalidad completa, se puede poner un botón en una UI existente y ver si la gente hace clic.
- Antes de incorporar un nuevo servicio de analítica, se puede preguntar primero cuál es la decisión más importante que requiere análisis y empezar con una sola decisión, un solo gráfico y una sola métrica.
- Es un enfoque parecido a poner una vela sobre un sándwich en vez de hornear un pastel de cumpleaños completo.
- Los desarrolladores senior aprenden a usar software ya existente para dar a la gente lo que quiere.
- Una forma breve de decirlo es: “Can we try something quicker?”.
- “quicker” reconoce la velocidad que la otra parte realmente quiere.
- “something” sugiere que puede haber otra manera de lograr el objetivo.
- “try” contiene la posibilidad de que algo imperfecto igual pueda ser suficientemente bueno.
- Esa frase reconoce la velocidad de reducción de incertidumbre que la empresa quiere, pero también deja espacio para que el desarrollador senior ejerza su experiencia de reducir, reutilizar y, cuando sea posible, evitar.
La presión que cambia con la IA y la responsabilidad que permanece
- Como la IA puede construir mucho en poco tiempo, la actitud de reducir, reutilizar y evitar puede parecer inútil.
- Pero la IA todavía no puede hacer una de las tareas del desarrollador senior: hacerse responsable.
- La razón por la que los desarrolladores senior valoran que el sistema sea comprensible es que, cuando surgen problemas, deben poder corregirlos.
- La comprensibilidad permite ampliar el sistema de manera inteligente cuando necesita crecer y seguir prestando un servicio estable a clientes que pagan.
- La IA aumenta mucho la velocidad para sacar cosas al mercado, pero también impacta el ciclo de estabilidad del que el desarrollador senior es responsable.
- Si agentes de IA, desarrolladores junior, personas no técnicas, inversionistas y quienes los rodean añaden código al sistema, el sistema termina recompensando demasiado la velocidad a costa de la estabilidad.
- La IA puede empeorar la comprensibilidad, la modificabilidad, la depurabilidad, la capacidad de enseñar el sistema y la posibilidad de garantizarlo.
- La IA puede volver inestable un sistema, pero no se hace responsable.
- Ese es el núcleo de la preocupación del desarrollador senior.
Un desarrollador senior más cercano a un editor que a un autor
- Una herramienta que puede usar el desarrollador senior es el desacoplamiento (decoupling).
- Durante mucho tiempo, solo los desarrolladores de software podían crear software, así que ellos se hacían cargo de ambos ciclos: el aprendizaje del mercado y la estabilidad del servicio.
- Era una estructura en la que un solo sistema sostenía ambos objetivos al mismo tiempo.
- Si se usan sistemas distintos para cada objetivo, se puede separar velocidad y estabilidad.
- Es parecido a cuando un novelista termina rápido un primer borrador y luego pasa por un proceso de edición donde rescata lo que funciona y descarta lo que no.
- El trabajo del editor es tomar las piezas que funcionan y convertirlas en un todo coherente.
- La versión Speed es un sistema orientado a la velocidad, un espacio donde agentes de IA, código generado sin revisar, desarrolladores junior y marketing pueden materializar ideas rápidamente.
- La versión Speed no busca comprensibilidad, sino estar lo bastante bien como para obtener feedback del mercado.
- La versión Scale es un sistema orientado a la estabilidad, diseñado por desarrolladores senior para ser estable, comprensible y escalable.
- La versión Speed permite que el negocio siga aprendiendo del mercado, y el desarrollador senior va detrás construyendo un sistema bien revisado y comprensible.
- El diseño de la versión Scale se ve influido por lo que funcionó y lo que no funcionó en la versión Speed.
- Las funcionalidades se crean en Speed y después se estabilizan en Scale.
- La forma concreta de implementación puede no estar clara, pero el punto central es separar explícitamente el trabajo que persigue velocidad del trabajo que persigue estabilidad.
- Frente a una solicitud ambiciosa, se puede decir: “la versión Speed estará lista en 3 días, y la versión Scale en unas 6 semanas”.
- La otra parte obtiene rapidez e impulso, y el desarrollador senior gana tiempo para observar y diseñar.
- Desde esta perspectiva, el desarrollador senior puede estar más cerca de un editor senior de software que de un “escritor senior de software”.
1 comentarios
Opiniones en Hacker News
La parte más importante de la experiencia viene del modelo interno del mundo, y no se puede separar de él
Normalmente se cree que cualquier cosa puede expresarse con palabras y que, si se transmiten esas palabras, quien escucha entenderá exactamente lo que quiso decir quien habló; esa creencia hace que aparezca la exigencia de “transmitir” la experiencia de un desarrollador a otra persona
En realidad, el conocimiento se transmite bastante bien con palabras, pero no así un modelo del mundo consolidado donde todo ese conocimiento está conectado. La IA puede saber muchísimos más hechos, pero todavía no usa ese conocimiento de una forma que produzca intuiciones sorprendentemente correctas con tanta frecuencia
Transmitir experiencia, en la práctica, se parece más a dar pistas sobre adónde ir y qué aprender; quien las recibe tiene que internalizarlas con esfuerzo y adquirir esa misma experiencia mediante proyectos adecuados
Se distingue entre quien entiende y aplica las “leyes de la física” del software, y quien solo anota procedimientos sin intentar comprender la esencia de cada paso
Esto se nota especialmente al enseñarle programación funcional a alguien acostumbrado a la orientación a objetos: a algunas personas se les rompe el modelo, y otras ven rápido que pueden traducir con relativa facilidad del mundo de las variables al mundo de las mónadas
Llevo casi 30 años trabajando, la mayor parte en una gran empresa, y cada semana dedico bastante tiempo a responder problemas que tienen personas recién llegadas. Muchas veces, con solo escuchar la pregunta, enseguida noto que la raíz del problema es que su modelo del mundo, la Theory de la que habla Naur, está incompleto o distorsionado y eso dificulta razonar
La tarea consiste en convertir la propia teoría en representaciones simbólicas como texto y diagramas, para que alguien con suficiente experiencia e inteligencia pueda formar un modelo mental parecido. Es decir, quisiera instalar mi teoría en la cabeza de otra persona
Una teoría del tipo que describe Naur no se puede trasplantar directamente, pero creo que el trabajo de un desarrollador senior, ya sea en el aula o en el campo, es traer experiencias y encontrar formas de reproducir ese tipo de teoría. Por eso la capacidad de comunicación es importante, y hace falta haber pasado muchas veces por el proceso de recibir teorías operativas de otras personas para desarrollar un instinto efectivo
Ahora esta se ha vuelto la parte más gratificante de mi trabajo, y mientras sienta que cumplo esta función de forma significativa, no tengo prisa por jubilarme
Cuando entreno y mentoreo juniors, trato de mostrar qué cosas son posibles y qué patrones llevan al fracaso, pero ese entrenamiento suele ser fragmentario e incompleto
Intento explicar, siempre que puedo, por qué se hace algo de cierta manera, pero no hay tantas cosas sobre las que diga tajantemente “esto no se hace”. A menudo me sorprende cómo resuelven problemas las personas a las que enseñé, y yo también aprendo con frecuencia
El entrenamiento funciona peor con quien no tiene interés en su propia contribución y solo ve el trabajo como una forma de cobrar un sueldo. Eso no significa que esté mal pensar así, pero si tu visión del trabajo se construye desde la indiferencia, es difícil internalizar la formación
https://andymatuschak.org/books/
Como desarrollador senior, odio muchísimo las generalizaciones tajantes
He visto fracasos tanto por actitudes como “¿de verdad hace falta esto?”, “¿qué pasa si no lo hacemos?”, “¿podemos aguantar así y volver después cuando sea más importante?” como por culpa de experimentadores
Cada sistema es distinto y cada producto también. Si haces firmware para un escáner CT, tu forma de tratar intentos nuevos debería ser distinta a la de un CRUD SaaS con 100 clientes
Sin duda hay seniors entusiastas y demasiado abiertos que empujan al sistema hacia rincones de los que luego es difícil salir, pero también hay quienes dicen que PHP5 ya es suficiente
Un buen senior tiene que saber reconocer ese momento
Entonces termina convirtiéndose en que, al tomar decisiones técnicas, hay que escuchar al vicepresidente y usar Elasticsearch
Obviamente a veces hace falta actuar, pero hoy el equilibrio está inclinado más de la cuenta hacia complicarlo todo innecesariamente
No significa que no haya que crear productos y servicios nuevos, sino que, al hacerlo, hay que buscar el camino de menor entropía total. También aplica a operaciones y a reducir deuda técnica
La optimización prematura es la raíz de todos los males
Dependiendo de si es una startup o una gran empresa ya sólida en flujo de caja, cambia el criterio al modificar una función central del producto
El texto me pareció interesante y estoy de acuerdo con su mensaje central de comunicarse mejor según el público
Pero el encuadre da la impresión de haber empezado por el camino correcto y luego haberse desviado un poco
Ambos bucles planteados se benefician de ser más cerrados y rápidos. Uno lleva al sistema más rápido a un punto de equilibrio “estable” y mantenible, y el otro se ocupa de la incertidumbre
La idea adicional de dividir sistemas para adaptarse mejor a la IA es algo que ya se venía explicando con spikes mucho antes de que la IA se volviera dominante
Me he dado cuenta de que, por lo general, no hay demanda entre los desarrolladores junior por mi intención de comunicar y compartir mi experiencia
En general, a los desarrolladores no les interesa buscar un mentor. Ni siquiera miran mi perfil de LinkedIn, ni me ven como una posible fuente de conocimiento y experiencia
No es que después de 30 años en la industria no tenga nada que compartir; es que no hay con quién compartirlo
Un desarrollador con poca experiencia propuso reemplazar un validador de URL con magia de IA, y yo me opuse proponiendo una solución de fuzzy matching basada en caché precargada con IA, pero a nadie le importó. Ahora el modelo de IA se cayó de repente y el sistema se rompió. Hay que volver a validar todo el sistema
Un desarrollador más joven que ascendió antes que yo estaba escribiendo un documento sobre cómo arreglarlo y me dijo: “Dan, ¿me puedes ayudar con esto?”. Lo ascendieron porque su forma de avanzar no es trabajar de manera racional sino escribir documentos y hacer reuniones, y ahora quiere demostrar liderazgo usando mi trabajo
Cuanto mejores soluciones propongo, más amenazantes les resultan a los desarrolladores menos experimentados, y como por lo general algo termina funcionando, a los managers tampoco les importa. Tal vez yo podría haber manejado mejor la situación, pero pelear contra tonterías cansa demasiado y yo solo quiero escribir buen código
En cambio, los juniors sí quieren conversar, almorzar y compartir lo que hacen. Los seniors son más cerrados y solitarios
Quizá sea solo nuestro lugar de trabajo, pero la oficina importa
Allí, algunos desarrolladores senior se enojaban cuando un junior hacía preguntas. Ya requería valor preguntarle algo a alguien con 20 años de experiencia, y aun así había un 50% de probabilidad de que te tratara mal
Fue una buena experiencia de aprendizaje, y ahora hago un esfuerzo consciente por mentorear
He mentoreado de forma intermitente durante las últimas décadas, y he tenido la suerte de conocer mentees excelentes. A algunos los he visto durante casi 10 años y ahora les va muy bien
No tengo nada especialmente útil que decir sobre cómo encontrarlos, pero sí existen
Pero justo después de que llegué, avisó que renunciaba porque ya había encontrado a su reemplazo, y al final no me salió bien
La mayoría de las pruebas de concepto que he visto terminaron convirtiéndose en producción cuando ganaron tracción
Varias veces todo el mundo prometió “si despega, lo reescribimos desde cero”, pero eso nunca pasó
El texto toca el tema de la responsabilidad y la rendición de cuentas, pero para quien asume el riesgo esas cosas no existen. Lanza una idea loca a las apuradas, espera que los clientes muerdan y se beneficia. Cómo hacer que eso funcione y escale, y cómo evitar que operarlo cueste más que venderlo, no es su problema
Hay empresas que llevaron el bucle de la derecha al extremo, y hoy dos de ellas son muy famosas. Lanzan algo rápido, escalan solo de forma lineal y luego salen a buscar dinero. Son empresas exitosas, con incontables usuarios y en algunos casos hasta cobran. Cualquier desarrollador senior o persona razonable que pregunte “¿esto es sostenible?, ¿cuál es la salida?” es despedido, y solo se quedan los creyentes
Si los ingenieros se limitan obedientemente a hacer lo que dicen los stakeholders no técnicos, aparece un vacío de responsabilidad y, cuando algún día estalla un desastre, termina señalado quien peor se puede defender
En cambio, si se amplía lo suficiente el panorama y se pregunta lo suficiente “por qué”, casi cualquier problema de negocio puede resolverse de una forma razonable que no empuje al sistema hacia una horrible puerta de un solo sentido
No en todos lados se le da a ingeniería esa autoridad, pero donde no se la dan tampoco logran retener a seniors que quieran que se respete su criterio. A veces la deuda técnica es la decisión correcta para el negocio, pero un ingeniero lo bastante senior siempre puede dejar una vía de escape
Eso sí, no se puede poner la pureza del sistema por encima del problema de negocio. El negocio es quien paga el costo del sistema, y si eso se olvida, también se pierde la base de la influencia
La conclusión del texto es básicamente el viejo consejo de “haz uno para tirarlo”. Yo también leí The Mythical Man-Month, pero el problema es cómo convencer a quienes toman las decisiones
Si no cumplía las expectativas, la desactivábamos o la eliminábamos; si no, la revisábamos y la refactorizábamos como correspondía
El equipo tenía mucha autonomía y casi no había quejas por plazos, en parte porque la mayoría de las demás áreas iban retrasadas. Solo marketing siempre tenía “ideas”
Que sea un prototipo o una prueba de concepto no importa en esencia si no puedes enumerar cuál es el problema real
Muchos equipos se quejan de que están hundidos en deuda técnica, de que es un gran riesgo y de que los hace más lentos, pero en el registro de incidentes no hay tantos eventos, ni nada que pueda atribuirse a haber ejecutado código riesgoso en producción. Tampoco aparece en el registro de riesgos una entrada que diga “este código es viejo, horrible y depende de algo sin soporte”, y ningún equipo puede explicar cómo ni cuánto los ralentiza la deuda técnica
Por otro lado, también he visto equipos pasar meses refactorizando antes del lanzamiento porque querían dejar “mejor” la app que escribieron. Se retrasó toda la entrega de valor, el liderazgo se enojó con razón y casi no quedó confianza
Tiene que haber buenas conversaciones sobre entrega entre el equipo y los stakeholders para que todos queden satisfechos, pero si no las hay, el stakeholder siempre gana
Se está pasando por alto el problema fundamental de los incentivos. Lo que quiere “la empresa” no importa; lo que importa es lo que quieren las personas que toman decisiones concretas
Hay gente que mantiene su puesto simplemente lanzando una nueva feature o app y haciendo que aparezca en alguna métrica de la empresa. Aunque un desarrollador senior diga que es una mala idea, esas personas no escuchan o no les importa. Porque su trabajo depende de eso
Pero en producto hay que alinear las features con lo que necesitan los clientes, así que hay que decirles a los investigadores que dejen de empujar
Un senior realmente competente entiende cuál es la cultura dominante de su empresa actual y qué hará falta dentro de 5 años, y luego se adapta en consecuencia
Una startup de 5 personas quizá no necesite complejidad extra que le recorte runway. Una empresa de 500 personas quizá sí necesite esa complejidad para mitigar los efectos de segundo orden de cada decisión de negocio
No es una lógica blanco o negro de “evita siempre la complejidad”, sino “agrega complejidad cuando tenga sentido”, y hasta esa pregunta se vuelve muy sutil cuando la empresa necesita sobrevivir unos meses más
Si faltan dos horas para que llegue la tormenta, en vez de pensar en arquitectura te preguntas: “¿se va a acumular tanta agua que ya no la podremos sacar?”
El problema que veo es que la gerencia juega juegos y no dice cuánta plata queda en realidad ni cuál es el cronograma real. Les da miedo que los colaboradores se vayan antes del momento crítico, pero entonces la gente sigue tomando decisiones tontas dentro de ese contexto y al final todos terminan buscando otro trabajo
Llevo varios días intentando transmitirle al equipo casi exactamente el mismo sentimiento, incluso con una frase casi idéntica a “¿de verdad tenemos que construir y probar toda la feature nueva? ¿Ya pusimos un botón en la UI existente para ver si la gente hace clic?”
Da la impresión de que los ingenieros están sufriendo colectivamente desde que producto decidió que ya no necesita usar sus propias funciones mentales. La idea es construir primero y averiguar después —o nunca— las user personas y la utilidad real
Antes se dedicaba tiempo a entender el dominio, a los usuarios y en qué proceso encajaba el producto, pero ahora simplemente se lanza lo que se cree que quiere un usuario imaginario y se experimenta hasta que funcione
Se produce exactamente el problema del que hablaba el texto original. Cada feature arbitraria hecha con vibe coding se vuelve una fuente de inestabilidad y riesgo, y como nadie tiene un modelo mental operativo de aquello, solo se puede mantener con más vibe coding
Aunque se pudiera reducir la complejidad a una sola dimensión medible, seguiría siendo solo uno de varios factores del espacio de soluciones
Hay otras propiedades como mantenibilidad, escalabilidad, confiabilidad, resiliencia, antifragilidad, capacidad de expansión, generalidad, durabilidad y componibilidad, y no todas aplican siempre
Creo que la capacidad de hablar no en una sola dimensión sino en términos de trade-offs dentro del espacio de soluciones es lo que separa a un senior de un Staff+
En cambio, si la entiende como aquello que durante los próximos 10 años-persona hará que desarrollar este sistema sea más fácil y más rápido, entonces significa elegir rodear por un costado donde el enfoque ingenuo intenta ir de frente
Como en la fábula de la liebre y la tortuga, es difícil entender el patrón en el que durante las primeras dos semanas todo parece rápido —se fuerza el ritmo, se cosecha lo fácil, se muestran resultados visibles y se obtiene el MVP— pero luego la velocidad cae cada vez más por un diseño inmaduro y por la mantenibilidad durante el desarrollo. Durante unas semanas pareció “rápido”, pero al final el cronograma se atrasó 6 meses
Pero si eres programador, tarde o temprano tienes que darte cuenta de que todos los posibles aspectos del diseño son trade-offs