Capital de Tokens
Programar en 2027: cuando escribir código deja de ser el trabajo
Hay una forma sencilla de resumir buena parte de la revolución actual de los agentes de IA:
el cuello de botella se está moviendo del código a la intención.
Durante décadas, convertir una idea en software exigía una enorme cantidad de trabajo intermedio: elegir herramientas, escribir funciones, recordar APIs, depurar sintaxis, conectar librerías, revisar pull requests y repetir el ciclo hasta que el sistema hiciera lo que queríamos.
Los modelos actuales están comprimiendo buena parte de esa cadena.
Ese cambio está detrás de las predicciones que Thorsten Ball publicó en septiembre de 2026 sobre el futuro del desarrollo de software y que después sirvieron como base para el video en español “Así Será Programar en 2027 (Esto Es Lo Que Se Viene)”.
Ball plantea ideas deliberadamente agresivas:
- el code review tradicional morirá;
- escribir código dejará de ser una habilidad central;
- la terminal perderá protagonismo como interfaz humana;
- los tokens se convertirán en una nueva forma de capacidad computacional;
- la separación entre PM, diseño e ingeniería se reducirá;
- buena parte de la interfaz gráfica podría generarse al vuelo;
- muchos bugs ya no serán errores de implementación, sino errores de especificación.
Algunas suenan futuristas.
Otras ya empiezan a parecer descripciones del presente.
Pero conviene aclarar algo desde el principio: “2027” es el encuadre del video, no una fecha límite precisa de Ball. En su texto original, él mismo advierte que parte de esta transición puede tardar una generación y que dentro de diez años todavía habrá personas cobrando por escribir código manualmente.
La pregunta interesante no es si todas sus predicciones ocurrirán exactamente el próximo año.
Es otra:
¿qué cambia en nuestra profesión cuando producir código deja de ser la parte escasa?
1. Del código como producto al código como subproducto
Hasta hace poco, escribir software era caro.
Una funcionalidad aparentemente sencilla podía consumir días o semanas porque había que:
- entender el problema;
- diseñar la solución;
- escribir el código;
- integrar dependencias;
- probar;
- depurar;
- revisar;
- desplegar.
La IA no elimina todas esas etapas, pero reduce brutalmente el coste de varias.
Un agente puede abrir un repositorio, leer su estructura, implementar una feature, ejecutar tests, interpretar errores, modificar varios archivos y volver a intentarlo sin que el humano escriba una sola línea.
Eso cambia la economía del trabajo.
Cuando producir código era caro, el código concentraba una gran parte del valor.
Cuando producir código se vuelve abundante, el valor se desplaza hacia otras preguntas:
- ¿qué deberíamos construir?
- ¿para quién?
- ¿qué restricciones no podemos violar?
- ¿qué arquitectura soportará el crecimiento?
- ¿cómo sabemos que funciona?
- ¿qué riesgos aparecen al conectarlo con sistemas reales?
- ¿cómo distribuimos el producto?
- ¿cómo sabemos que alguien lo necesita?
Ball resume esa transición diciendo que el oficio de escribir código puede desaparecer mientras el oficio de construir software se vuelve más importante que nunca.
La distinción es fundamental.
Una IA puede generar una implementación impecable de una mala idea.
2. El code review no desaparece: cambia de nivel
Una de las predicciones más provocadoras es que el code review tradicional está muerto.
La lógica es fácil de entender.
Si un agente produce 300 cambios en segundos y un desarrollador coordina cinco agentes en paralelo, pedirle a otro humano que lea detenidamente cada línea deja de escalar.
El volumen supera la capacidad humana de inspección.
Pero eso no significa que desaparezca la revisión.
Significa que la revisión sube de nivel.
En vez de preguntar:
¿Esta variable está bien nombrada?
la revisión puede concentrarse en:
- ¿la feature hace lo que el producto necesita?
- ¿rompe alguna propiedad importante del sistema?
- ¿introduce una superficie de seguridad nueva?
- ¿respeta límites de datos y permisos?
- ¿qué ocurre ante fallos parciales?
- ¿la migración es reversible?
- ¿las métricas confirman el comportamiento esperado?
- ¿el agente entendió correctamente la tarea?
La unidad de revisión deja de ser necesariamente la línea de código.
Puede convertirse en el sistema, el comportamiento y la evidencia.
Eso implica que tests, evals, observabilidad, invariantes y entornos de prueba pueden volverse incluso más importantes, aunque algunas formas de testing manual o rutinario pierdan protagonismo.
El futuro no parece “menos verificación”.
Parece verificación a otra escala.
3. El nuevo bug: “pediste la cosa equivocada”
Esta puede ser la idea más importante de todo el texto de Ball.
Cuando un modelo puede implementar correctamente una especificación, muchos fallos dejan de parecerse a:
el programador escribió mal el código.
y empiezan a parecerse a:
nadie especificó el caso importante.
Imaginemos una plataforma de reservas.
Le pedimos al agente:
Crea una web para reservar habitaciones.
El agente la implementa.
La interfaz funciona.
La base de datos funciona.
Los pagos funcionan.
Pero dos usuarios pueden reservar la última habitación al mismo tiempo porque nadie pensó en concurrencia.
¿Es un bug de programación?
En sentido estricto, el software puede estar haciendo exactamente lo que se le pidió.
El error estaba antes del código.
Faltó modelar el dominio.
Faltó formular una propiedad:
una habitación no puede quedar confirmada para dos reservas incompatibles.
Ese tipo de error obliga a los desarrolladores a fortalecer habilidades que durante años parecían secundarias frente a la implementación:
- especificación;
- pensamiento de sistemas;
- modelado de dominios;
- identificación de invariantes;
- diseño de escenarios adversos;
- análisis de riesgos;
- comprensión profunda del negocio.
Paradójicamente, cuanto mejor programe la IA, más visible se vuelve nuestra incapacidad para expresar lo que realmente queremos.
4. La terminal puede morir como interfaz, no como infraestructura
Ball también afirma que la terminal está muerta.
Tomado literalmente, probablemente sea exagerado.
Los shells, CLIs, APIs, bases de datos y herramientas tradicionales seguirán existiendo porque los agentes necesitan mecanismos deterministas para actuar.
Lo que sí puede desaparecer es la obligación de que el humano aprenda cada interfaz directamente.
Antes:
humano → SQL
humano → git
humano → bash
humano → kubectl
humano → APICada herramienta exigía que aprendiéramos su lenguaje.
Con agentes:
humano → intención en lenguaje natural → agente → herramientasLa terminal deja de ser necesariamente la interfaz primaria.
No porque bash desaparezca, sino porque el agente se convierte en una capa de traducción.
Puedes pedir:
Muéstrame los veinte usuarios más recientes que fallaron el onboarding y agrúpalos por causa.
Y el agente decide si necesita consultar SQL, revisar logs, ejecutar un script o combinar varias APIs.
La máquina sigue hablando lenguajes formales.
El humano deja de tener que hablarlos todo el tiempo.
5. Tokens como nueva capacidad de producción
Otra de las predicciones más interesantes de Ball es económica:
los tokens se convierten en el nuevo paradigma de computación.
La analogía es con los primeros ordenadores personales.
Hubo una época en la que poder producir software dependía, en parte, de tener acceso a hardware costoso.
En un mundo de agentes, la restricción puede desplazarse hacia otra pregunta:
¿cuánta inferencia puedes comprar o ejecutar?
Un equipo con acceso a modelos mejores, contextos más grandes y millones de tokens puede desplegar mucha más “capacidad cognitiva artificial” sobre un problema.
Eso introduce una nueva variable en los proyectos.
Antes medíamos:
- horas de ingeniería;
- número de desarrolladores;
- servidores;
- almacenamiento;
- ancho de banda.
Podemos empezar a medir también:
- tokens por tarea;
- coste por agente;
- iteraciones por feature;
- inferencia necesaria para validar;
- capacidad paralela de agentes.
No significa que los tokens reemplacen a toda la computación tradicional.
Tampoco significa que el acceso quede necesariamente concentrado para siempre: modelos abiertos, hardware local y mejoras de eficiencia empujan en sentido contrario.
Pero sí aparece una nueva forma de capital productivo:
capacidad de razonamiento bajo demanda.
6. Equipos más pequeños, pero no empresas automáticas
El video lleva las predicciones de Ball hacia una consecuencia organizativa: equipos capaces de producir mucho más con mucha menos gente.
Es plausible.
Si una persona puede coordinar varios agentes, una pequeña vertical de producto puede necesitar menos manos para:
- prototipar;
- programar;
- diseñar;
- documentar;
- analizar datos;
- automatizar operaciones.
Pero aquí conviene evitar un salto demasiado rápido.
Construir software no es lo mismo que construir un negocio.
Aunque la implementación sea barata, siguen existiendo problemas difíciles:
- distribución;
- confianza;
- marca;
- adquisición de clientes;
- ventas;
- soporte;
- cumplimiento;
- regulación;
- relaciones;
- conocimiento del mercado.
Si cualquiera puede replicar una feature, la ventaja competitiva puede desplazarse precisamente hacia aquello que no se clona con un prompt.
Eso puede beneficiar especialmente a pequeños equipos e indie developers, pero no convierte automáticamente cada aplicación generada en una empresa viable.
7. ¿Desaparece la tríada PM + diseño + ingeniería?
Ball cree que la separación tradicional entre product manager, diseñador e ingeniero perderá sentido.
Probablemente sea más útil hablar de compresión de roles que de desaparición.
Una persona con buen criterio de producto puede pedir prototipos, evaluar variantes y producir una primera implementación con agentes.
Un ingeniero puede explorar flujos de UX sin esperar días por un mockup.
Un diseñador puede construir prototipos funcionales.
Las fronteras operativas se vuelven más porosas.
Pero siguen existiendo capacidades distintas:
- visión de producto;
- gusto y coherencia visual;
- arquitectura;
- seguridad;
- conocimiento de dominio;
- investigación con usuarios.
La IA reduce el coste de ejecutar.
No garantiza buen criterio.
Por eso el profesional valioso puede parecer menos un “especialista que produce artefactos” y más una persona capaz de tomar decisiones completas de extremo a extremo.
8. UI generada al vuelo y software personalizado
La predicción más cercana a ciencia ficción es que los modelos sean tan rápidos que parte de la interfaz se genere en tiempo real.
Muchos elementos de UI existen porque una máquina tradicional no entiende la intención del usuario.
Necesitamos:
- menús;
- filtros;
- dashboards;
- formularios;
- paneles de configuración.
Son una especie de API visual para humanos.
Si un sistema entiende directamente lo que queremos, podría generar la interacción adecuada para cada contexto.
En lugar de buscar un filtro escondido, podríamos decir:
enséñame solo clientes con riesgo alto que hayan reducido consumo esta semana.
Y el sistema podría construir una vista temporal para esa petición.
La idea se vuelve todavía más radical cuando la generación de software es suficientemente barata: aplicaciones personalizadas para individuos o para cada cliente.
No una app para un millón de usuarios.
Quizás un millón de variantes de una app.
9. Lo que esta visión subestima
La tesis de Ball es útil precisamente porque obliga a pensar en extremos.
Pero hay razones para mantener escepticismo.
Los modelos siguen cometiendo errores
Aunque mejoren rápidamente, todavía existen:
- alucinaciones;
- fallos de contexto;
- errores silenciosos;
- malas suposiciones;
- vulnerabilidades;
- regresiones;
- resultados que parecen correctos sin serlo.
La automatización aumenta la velocidad de producción, pero también puede aumentar la velocidad con la que propagamos un error.
La responsabilidad no se puede delegar a un token
Cuando un sistema mueve dinero, datos sensibles o infraestructura real, alguien sigue teniendo que responder por sus decisiones.
El software heredado no desaparece rápido
Gobiernos, bancos y grandes corporaciones operan sobre sistemas que viven durante décadas.
La frontera tecnológica cambia más rápido que la adopción institucional.
El criterio sigue siendo escaso
Un agente puede generar diez soluciones.
Saber cuál es la correcta sigue requiriendo comprensión.
Ese puede convertirse en el verdadero cuello de botella.
10. La nueva jerarquía de habilidades
Si esta transición continúa, el desarrollador no se vuelve irrelevante.
Se vuelve diferente.
Las habilidades que pueden ganar valor son:
1. Especificar
Convertir una intención ambigua en condiciones claras y verificables.
2. Diseñar sistemas
Entender dependencias, datos, fallos, permisos, concurrencia, seguridad y arquitectura.
3. Verificar
Construir evals, tests, invariantes, observabilidad y mecanismos de feedback.
4. Coordinar agentes
Dividir un problema, paralelizar trabajo, administrar contexto y detectar cuándo escalar.
5. Entender producto y negocio
Saber por qué una feature existe y qué resultado pretende producir.
6. Mantener criterio técnico
No necesitas memorizar cada flag de una CLI, pero sí necesitas comprender lo suficiente para detectar cuándo una decisión del agente es peligrosa o absurda.
La gran paradoja de la programación asistida por IA es que escribir menos código puede exigir entender más sistemas.
11. El cambio real: subir un nivel de abstracción
La historia del software es, en parte, la historia de abandonar detalles que antes eran imprescindibles.
Pasamos de:
voltajes
→ código máquina
→ ensamblador
→ lenguajes de alto nivel
→ frameworks
→ servicios cloud
→ agentesCada salto hizo que parte del conocimiento anterior dejara de ser una tarea cotidiana.
Pero no hizo desaparecer la ingeniería.
Cambió el nivel al que operamos.
Eso parece estar ocurriendo otra vez.
La interfaz del desarrollador se mueve desde:
escribe esta implementación
hacia:
define el resultado, las restricciones y la evidencia de que funciona.
Y quizá esa sea la mejor forma de entender el futuro que describen Thorsten Ball y el video.
No es un futuro sin programadores.
Es un futuro en el que programar ya no significa necesariamente escribir código.