El coding manual es una práctica artesanal
Si trabajas en software (producto, diseño o desarrollo) hoy seguramente te están lloviendo todos los días mensajes opuestos:
A) Tu rol está por desaparecer;
B) Tu rol va a ser el más importante de todos.
Lo complejo de esto es que siendo febrero de 2026, ambos mensajes son ciertos al mismo tiempo, y esto una señal demasiado fuerte, más grande que tu propia carrera individual. Es una señal de que el ecosistema de desarrollo de software está cambiando de fase, está evolucionando, sin vuelta atrás.
Yo lo veo como oportunidad porque peco de optimismo, pero no todos lo ven así, y en este artículo intento razonarlo.
Si vamos a la materia prima de un producto de software, al código en sí mismo, la situación es dramática, la AI está haciendo que escribirlo sea realmente trivial. Hace un par de días, Paul Graham (YC) dijo “When mechanical watches became obsolete around 1970 they represented almost exactly 700 years of refinement by some of the best minds of their time. That is a really long run.”, y si no te quedó clara la idea, luego Guillermo Rauch (Vercel) le respondió para ayudarte y hacerlo literal “When manual programming became obsolete around 2026, it represented almost exactly 183 years¹ of refinement by some of the best minds of our times. That is a really long run, but the runs are getting shorter.”.
Lo que quieren decir no es que el producto, sea un reloj o una mobile app, sean obsoletos (por ahora), sino que la forma de producirlo lo es. Hoy ya escribir código es un commodity, desarrollar una feature agrega 0 valor en sí mismo. El tiempo de una idea a que esté productivo colapsó totalmente, lo que llevaba antes 2 semanas, hoy lleva 4 horas, como mucho. Pero no sólo para los desarrolladores que ahora pueden ir mucho más rápido, sino que esto es más tremendo aún para quienes no sabemos escribir código, la pared que teníamos está totalmente rota.
Lost in translation
Aparece entonces una frase que seguramente también leíste, o si no, este es el momento: “el cuello de botella ya no es desarrollo, sino decidir qué hacer”. Hoy, en algunos contextos, pero no en todos, eso ya es cierto. Pero 100% seguro que antes de que termine este año, va a ser cierto para todos.
En ingeniería industrial 101 me hicieron estudiar la línea fordista para fabricar autos: estaciones muy definidas, movimientos exactos, tiempos cronometrados, flujo continuo. Durante años la respuesta para producir más fue siempre la misma: empujar la eficiencia en todos lados, más máquinas, más automatización, menos segundos por tarea. El problema es que ese enfoque asume que el sistema mejora como suma de partes, y eso nunca es cierto.
Desde Japón nos enseñaron no sirve optimizar todo al mismo tiempo. Hay que identificar dónde realmente se frena el sistema. El cuello de botella nunca desaparece, siempre existe uno.
En desarrollo de software, durante años, el cuello de botella fue escribir código. Eso justificó miles de reuniones, de emails, story points (!), roadmaps inflados y cambiantes, equipos gigantes y decisiones lentas “porque desarrollar cuesta mucho”.
Hoy, esa restricción está rota, la última milla de agregado de valor, el código, tiende a costo casi 0. Tanto es así que la AI se está auto-enseñando a escribir código, y ya no depende de nosotros esa mejora.
Entonces, el cuello de botella se va a mover, ya no está en producir, está en decidir qué producir, por qué y para quién:
Qué objetivo de negocio queremos lograr
Qué hipótesis vale la pena testear.
Qué no debería hacerse aunque sea técnicamente fácil.
Antes se podía esconder la poca claridad detrás de una complejidad técnica, ahora ya no… estamos obligados a que la optimización ocurra donde siempre fue más difícil: en el pensamiento, en el criterio, en la alineación y en el foco.
AI ven a mí, no yo a vos
Antes de seguir, es el momento de aclarar dos cosas para mi importantes:
Esto no lo estoy escribiendo con IA, lo usé para criticar y mejorar mi estructura, y corregir gramática. Por favor, luchemos como especie para no perder el crecimiento que el esfuerzo de plasmar una idea nos genera.
Esto lo viví en carne propia, sin saber escribir una línea de código durante el 2025 pude crear from021.io llegando a que empresas top lo usen, tener +3k usuarios. Además hice 5 MVPs para clientes sin tampoco tocar una línea de código. Obviamente cometí en el camino varios errores, por no saber promptear, por no saber distintos conceptos técnicos que fui aprendiendo… decisiones que imposibilitan la escalabilidad, riesgos de seguridad, peor calidad de la que quisiera. Pero en la big picture, hice mucho más de lo que podía haber hecho.
Es una sensación única, indescriptible, no hay límites, sólo intentar mantener una salud física y mental apta para continuar al otro día.
Ingeniería se rearma rápido. Y el resto, qué?
Durante 2025 conocí y vi a muchos desarrolladores y líderes de ingeniería probar nuevas herramientas, y poner en jaque sus procesos para adaptarse y embrace (no hay término en español que lo refleje mejor) el cambio.
No sólo en USA sino en todo LATAM veo que a toda hora, desarrolladores que antes romantizaban una tecnología/lenguaje específico, ahora no sólo pueden sino que buscan producir valor completo, no sólo como full-stacks sino más aún, tomando decisiones de producto, creando soluciones de punta a punta.
A nivel enterprise general, no veo todavía que los equipos de desarrollo ya estén todos a full onboard con IA como se puede ir en una startup o side-project pero los cambios ya se empiezan a ver. Entonces, si ingeniería logra ir en promedio u (supongamos) 50% más rápido, qué pasa con el resto de la organización? ¿esperar que esto impacte directamente sobre el negocio? NO.
El desafío está en cómo evitar que el cuello de botella NO pase a ser decidir qué construir.
Un primer acercamiento es desde el lado técnico: la autonomía. Vi de cerca durante el último año que en empresas líderes (las cuales tienen un crecimiento nunca antes visto), no paran de mejorar sus soluciones, no paran de agregar servicios y valor. En empresas como Vercel, Anthropic, Cursor, Lovable, pasan tres cosas muy destacables:
Todas estas empresas dan ownership a los desarrolladores a tomar decisiones de producto.
Los product managers saben de tecnología y desarrollo.
Los owners / founders son técnicos.
Entonces los límites de desarrollo son casi mínimos, pero lógicamente existe un cuello de botella: decidir que sí y que no hacer. Además, viven una competencia totalmente feroz, los ciclos tienen que ser cortísimos y la velocidad ya es parte del moat (motion is the other moat)..
Por eso, en estas empresas top, el bottleneck real está en el criterio: qué vale la pena construir ahora, y qué se descarta. El sistema entero está diseñado para que, una vez tomada esa decisión, el resto fluya sin fricción. No es que sea una solución única ni mágica, pero claramente hay algo que aprender de ellos, siendo parte del resto de los mortales.
Por otro lado, si pienso en organizaciones donde la tecnología es core, pero no es el negocio en sí (fintech, retail, salud, etc.), veo que “en general” el problema es distinto y hay mucho por hacer en esta nueva etapa. Mientras ingeniería se destraba cada vez más, el cuello de botella no está tan concentrado, está diluido en tiempos de alineación, en coordinación entre áreas, en roadmaps rígidos, en scoping eterno, en traducciones sucesivas entre negocio, producto y desarrollo.
En mi opinión, esto sucede porque:
Los owners/stakeholders tienen ideas, pero no criterio de producto, ni entendimiento de los constrains técnicos.
Los Product Managers traducen desde el negocio a una iniciativa, pero no tienen capacidad de análisis técnico real, y en muchos casos no tienen ownership sobre el impacto del negocio ($).
Los developers ejecutan sin ni siquiera un mínimo acercamiento al entendimiento del impacto esperado, o al menos la hipótesis, y hasta a veces ni capacidad o responsabilidad de scopear para minimizar el esfuerzo económico.
Acelerar entonces ingeniería sin transformar lo demás es insuficiente, el negocio no va a ver el impacto. El intentar lograr más output va a chocar contra un sistema de decisiones lento y fragmentado. Por eso, mientras ingeniería incorpora herramientas y cambia procesos apalancados en AI, agents, skills, frameworks…. producto y negocio también tiene que hacerlo, se tiene que lograr reducir la fricción estructural.
Gain conviction con discovery continuo, más que nunca
Íbamos bien… pero la realidad es que una vez resuelta la alineación, coordinación, capas de decisiones, el problema real, y más profundo, es que más output no es igual a mayor impacto.
El desafío es que exista un mejor sistema de decisiones: por qué y qué hacer, no sólo en cascada desde negocio a producto a ingeniería, sino en general.
Una feature aislada ya no diferencia, la hace cualquiera y peor aún, todos se copian todo al mismo tiempo. Aunque ahora puedas hacer 1000× más cosas, el costo de decidir es igual de caro porque la competencia también puede hacer 1000x más cosas.
Visto de otra forma, lo que más valor tiene es decidir qué NO hacer, y no se trata de “factibilidad”, no es una decisión técnica, es una decisión más que nunca de nicho, de use case certero, de cómo agregar valor a alguien, de cómo resolver un problema real.
El trabajo más grande ahora pasa a ser tener una hipótesis clara y bien formulada, y elegir bets para validar. Es donde el continuous discovery (by Teresa Torres), cobra más relevancia que nunca, sobretodo para ganar convicción en si algo “vale la pena” hacer, y transformar la pena en alegría.
Es momento entonces de construir un sistema y flujos de decisiones que funcionen a la velocidad que la AI permite para ejecutar y desarrollar código. Estos principios ya existen en producto hace años, pero quedaban a cargo de la intuición del PM o hasta de prácticas informales. Ahora no hay margen, tiene que darse de forma estructurada.
Proximidad total: no existe el research cada 3 meses, hay que hablar todo el tiempo a toda hora con los usuarios. No hay excusa para no estar cerca y poder crear relación 1o1 (ver cómo líderes de empresas top se manejan en X, respondiendo issues y sugerencias desde su cuenta personal.
Hipótesis con carne: hay que dedicarle mucho más tiempo a formular hipótesis de calidad y con impacto en el usuario, que se tiene que poder traducir directamente en impacto en el negocio. Hoy la trazabilidad y observabilidad en datos por release, cohort, es algo mínimo viable.
Data sobre idea creativa: explorar múltiples soluciones en paralelo, no una sola o en secuencia. El tiempo de prototipado de una solución funcional es mínimo y se puede poner en producción distintas alternativas al mismo tiempo.
Decidir con señales, no con docs bien escritos. Vale más que una feature tenga impacto en 50% de uso de una app, que cumplir un roadmap. Decidir cada vez más en tiempo real vale oro.
Parece trivial y hasta casi que ya lo sabemos pero voy una vez más… en empresas donde el sistema de decisiones es lenta y floja, la AI sólo va a amplificar el ruido y las incertidumbres: más cards en backlog, más output, más roadmap… el mismo impacto, o menor. En empresas donde ingeniería va más rápido y se resuelven los cuellos de botella de alineación y definición, la velocidad va a ser 3x, o sea que en 6 meses tu competencia va a haber hecho lo que a vos te llevaría 18 meses.
Get technical asap, por favor. Ah, y value = money.
Hasta ahora, el desarrollo de software se organizó según una división demasiado “clara” de responsabilidades. Producto pensaba el negocio, diseño representaba al usuario, desarrollo ejecutaba la solución. El famoso diagrama de los tres círculos funcionó durante mucho tiempo como una verdad casi incuestionable: cada rol se enfocaba en su especialidad y el valor surgía en la intersección.
Yo lo aprendí y valoré mucho tiempo, pero hoy es viejo, está desalineado con la velocidad actual del ecosistema. Sobretodo, porque la coordinación tradicional se volvió más costosa que la ejecución. Cuando desarrollar era muy caro, tenía sentido separar, traducir y alinear durante semanas, para cuidar al desarrollador.
Hoy nos tenemos que exigir más, transformar nuestros roles, usando AI para elevar nuestras capacidades:
Producto ya no puede vivir sin criterio técnico profundo, tiene que ser owner de la variable “esfuerzo” y resolver parte del código
No se trata de que todas las personas de producto sepan programar, sino de que quienes toman decisiones sobre prioridad y alcance, entiendan qué implica construir: cuánto esfuerzo requiere, qué compromisos genera, qué costos introduce y qué tipo de deuda crea.
Implica además que producto pueda prototipar, generar un primer código reutilizable, y hasta resolver quick fixes que liberen al desarrollador a enfocarse en cosas más complejas.
Desarrollo ya no puede enfocarse solo en ejecutar parte del código, tiene que ganar autonomía y pensar en el sistema.
Del otro lado ocurre algo análogo, el valor pasa a estar en cómo se define el problema, cómo se acota, cómo se toman decisiones técnicas con impacto real, y cómo se conecta con resultados de negocio. La autonomía se gana con frameworks de producto, entendimiento del negocio y responsabilidad del impacto económico, y esto implica que un dev pueda definir y priorizar una feature, y/o que pueda pensar en proponer un nuevo sistema de agents, o la mejora de la arquitectura / seguridad de un producto.
Negocio no puede desconocer frameworks de producto
Para definir qué se construye, en qué orden y con qué expectativas de retorno, no alcanza con objetivos de alto nivel o presión por resultados. Hace falta entender cómo se prioriza producto, qué implica cambiar el rumbo, qué costos introduce cada decisión y cómo se mide impacto real más allá del corto plazo.
Negocio tiene que dejar de empujar por volumen sin ver las consecuencias. Hacerse cargo del impacto significa alinear estrategia, priorización y métricas de producto, entendiendo que cada decisión de producto/desarrollo termina expresándose en dinero.
Diseño es algo transversal, y la marca y el taste cobran más valor que nunca
Diseñar pantallas es más trivial que el código… formularios, side bars y layouts se resuelven rápido, y se parecen cada vez más entre sí. El valor del diseño no está en la ejecución de un componente o pantalla aislada, sino en cómo se siente el producto, cómo se entiende y sobretodo, cómo se recuerda. La identidad es más relevante que nunca, al software lo veo cada vez más parecido a las marcas de ropa… la diferencia no está en sólo en la calidad de la prenda, sino en el estilo, la cultura que creas, el taste con el que se construye la marca.
Nuestra industria cambió, ya le pasó a la fotografía, a la música, al diseño gráfico.
Ahora nos tocó a nosotros… don’t panic, embrace it, and gain conviction.