La IA y el nuevo alcance de los proyectos
Hace poco vi este video de YouTube y me dejó pensando bastante más de lo que esperaba.
No tanto por las capacidades concretas de los modelos actuales, sino por una idea más profunda: quizá seguimos pensando en el desarrollo de software con las limitaciones de hace unos años, mientras las herramientas que utilizamos han cambiado radicalmente.
Muchas de las reflexiones que siguen nacen de esa sensación.
La evolución de los modelos como eras
Una forma interesante de entender la evolución reciente de la IA es pensar en ella como una sucesión de eras.
La primera gran etapa fue la de las llamadas a herramientas. Modelos como Sonnet 3.5 no fueron los primeros capaces de invocar herramientas externas, pero sí los primeros que lo hacían de forma suficientemente fiable como para integrarse en flujos de trabajo reales. Por primera vez era razonable delegar tareas completas y no solo pedir fragmentos de código.
Después llegó la era de las tareas de larga duración. Modelos como Opus 4.5 empezaron a mantener el contexto durante periodos mucho más largos, permitiendo abordar problemas que requerían horas de trabajo en lugar de unos pocos minutos. Ya no era necesario dividir cada tarea en decenas de instrucciones intermedias: podías describir un objetivo y dejar que el modelo encontrara gran parte del camino por sí mismo.
Y ahora parece que estamos entrando en una nueva etapa: la era de la orquestación.
Modelos como Mythos no solo entienden el código sobre el que trabajan. También parecen entender mejor cómo organizar el trabajo, dividir tareas, verificar resultados y coordinar distintos procesos para alcanzar un objetivo. La diferencia no está únicamente en escribir mejor código, sino en gestionar mejor el trabajo necesario para producirlo.
Hay que ir a por más
La reflexión más interesante del vídeo no era técnica.
Era una observación bastante incómoda: los modelos están mejorando más rápido que nosotros.
Durante años nuestra ventaja consistía en aprender más herramientas, dominar más tecnologías o acumular más experiencia. Pero si las capacidades de los modelos crecen a un ritmo superior al nuestro, intentar simplemente “seguir el ritmo” probablemente no sea suficiente.
La alternativa es aumentar nuestra ambición.
Muchos de los tickets de Jira que cerraba hace un año podrían resolverse hoy de forma casi trivial con modelos modernos. Eso significa que las tareas que antes justificaban jornadas completas de trabajo ya no aportan el mismo valor.
Si la ejecución se vuelve más barata, lo lógico es dedicar más energía a problemas más grandes.
El skeuomorfismo en el desarrollo de software
Hay otra idea que me pareció especialmente interesante: quizá estamos viviendo nuestra propia fase skeuomórfica como desarrolladores.
El skeuomorfismo era una tendencia de diseño que intentaba imitar objetos físicos en interfaces digitales. Las primeras aplicaciones móviles parecían brújulas, estanterías o blocs de notas porque necesitaban convencer a los usuarios de que podían sustituir a los objetos reales.
Con el tiempo dejamos atrás esas imitaciones porque ya no eran necesarias.
Algo parecido podría estar ocurriendo con muchas de nuestras herramientas de desarrollo.
Seguimos extremadamente ligados a terminales, editores, flujos de Git y convenciones heredadas porque forman parte de nuestra identidad profesional. Pero eso no significa que sigan siendo la mejor forma de trabajar en un mundo donde la IA participa activamente en el desarrollo.
Hay preguntas que suenan absurdas al principio, pero que resultan interesantes cuando se analizan con calma:
- ¿Por qué no podemos versionar determinados archivos pero sí otros?
- ¿Por qué seguimos definiendo nuestra identidad profesional por los lenguajes que conocemos?
- ¿Por qué nos cuesta tanto eliminar código?
Muchas de estas respuestas tienen más que ver con la historia de nuestras herramientas que con necesidades reales del presente.
No significa que debamos abandonar todo lo que conocemos, pero sí cuestionar qué parte de nuestros procesos existe por una razón válida y qué parte simplemente sobrevive por costumbre.
El cambio de nivel
Durante mucho tiempo tuve una forma bastante simple de clasificar los proyectos que quería construir.
Un pequeño script o una automatización personal era un side project.
Una aplicación con usuarios, infraestructura y posibilidades reales de negocio era una startup.
Y luego existía una tercera categoría: los proyectos demasiado grandes.
Ideas que requerían equipos enormes, años de desarrollo y recursos completamente fuera del alcance de una persona o de un equipo pequeño.
La IA está alterando esa clasificación.
No porque la complejidad haya desaparecido, sino porque el coste de producir software se ha reducido drásticamente.
La generación de código, la investigación técnica, la documentación, las pruebas, el análisis de errores e incluso parte del diseño de arquitectura pueden acelerarse enormemente con herramientas que hace apenas unos años no existían.
Como consecuencia, muchos proyectos han descendido un nivel.
Lo que antes parecía una startup completa ahora puede convertirse en un proyecto paralelo desarrollado por una sola persona. Y muchas ideas que habríamos descartado automáticamente por inviables han pasado a ser, al menos, explorables.
El nivel “G-Brain”
Una de las ideas más curiosas del vídeo era la existencia de un nuevo nivel todavía más pequeño.
Un nivel formado únicamente por un archivo Markdown.
Puede sonar exagerado, pero cada vez hay más procesos que antes requerían una aplicación completa y que ahora pueden describirse como una serie de instrucciones ejecutadas periódicamente por un modelo.
Revisar pull requests, clasificar incidencias, generar informes, monitorizar repositorios o producir contenido son tareas que en muchos casos ya no requieren una interfaz compleja ni una infraestructura dedicada.
A veces basta con un archivo de instrucciones ejecutándose cada cierto tiempo.
Es una forma completamente diferente de pensar sobre qué constituye realmente un producto.
¿Siguen existiendo los proyectos “demasiado grandes”?
Quizá la consecuencia más interesante de todo esto es que la definición de “demasiado grande” se ha vuelto mucho menos clara.
Hace unos años era fácil identificar proyectos imposibles para una persona o un pequeño equipo.
Hoy ya no lo tengo tan claro.
No porque ahora sea trivial construir una alternativa a AWS, Salesforce o Slack. Evidentemente no lo es.
La diferencia es que la barrera de entrada ha cambiado.
Antes muchas categorías estaban completamente cerradas para cualquiera que no tuviera cientos de ingenieros. Ahora es posible construir prototipos funcionales, explorar mercados y validar hipótesis en espacios que antes parecían inaccesibles.
La pregunta ya no es si puedes construir una primera versión.
La pregunta es hasta dónde puede llegar esa primera versión antes de necesitar una organización completa detrás.
Y esa distancia es cada vez mayor.
Pensar en amplio, no solo en grande
Por eso creo que la idea correcta no es necesariamente pensar más grande.
Es pensar más amplio.
Tradicionalmente las startups competían especializándose en un espacio muy concreto. Era imposible cubrir el alcance funcional de gigantes como AWS porque simplemente no existían los recursos necesarios.
Ahora eso está empezando a cambiar.
No porque una persona pueda replicar décadas de ingeniería acumulada, sino porque el coste de añadir nuevas capacidades se ha reducido enormemente.
Funcionalidades que antes requerían equipos especializados pueden implementarse en días o semanas. La amplitud de lo que un producto puede ofrecer está creciendo mucho más rápido que el tamaño de los equipos que lo construyen.
Y además existe un fenómeno interesante: cada vez más usuarios pueden construir por sí mismos las piezas que les faltan.
Si diseñamos sistemas suficientemente flexibles, no necesitamos anticipar todas las necesidades posibles. Los usuarios pueden extender el producto de formas que ni siquiera habíamos imaginado inicialmente.
Eso cambia por completo la forma de pensar sobre la construcción de software.
La prueba de la “idea estúpida”
Hay una idea que resume bastante bien todo lo anterior.
Si una idea no parece un poco absurda al principio, probablemente no sea lo suficientemente ambiciosa.
Durante años aprendimos a descartar automáticamente determinadas categorías de proyectos porque asumíamos que estaban reservadas para empresas enormes.
La IA está obligándonos a revisar esos supuestos.
No porque los problemas difíciles hayan desaparecido, sino porque muchas de las restricciones que considerábamos permanentes ya no lo son.
Quizá todavía no sabemos dónde está el nuevo límite de lo posible.
Quizá ni siquiera existe una definición clara de lo que significa un proyecto “demasiado grande”.
Y precisamente por eso merece la pena explorar ideas que hace unos años habríamos descartado sin pensarlo dos veces.
Las reglas del juego están cambiando. La pregunta es si seguimos pensando con las limitaciones de ayer o empezamos a construir con las capacidades de hoy.