La industria del software lleva décadas midiendo el trabajo equivocado.
No porque los desarrolladores sean poco productivos — sino porque las herramientas de medición capturan actividad, no pensamiento. Horas trabajadas. Commits realizados. Historias completadas. Todo contable, todo visible, y casi todo irrelevante para entender cuánto y qué tan bien se resolvió un problema.
La IA no vino solo a acelerar el desarrollo. Vino con algo inesperado: una señal nueva. Cada sesión de trabajo con un modelo de lenguaje deja un rastro cuantificable — el consumo de tokens — que por primera vez permite asomarse al esfuerzo cognitivo real detrás de una tarea.
La pregunta que ninguna metodología resuelve bien
Si desarrollas software por cuenta propia o lideras un equipo de consultoría, hay una pregunta que aparece en cada proyecto y que casi nunca tiene una respuesta satisfactoria:
¿Cuánto cobro por esto?
No es una pregunta de negocio. Es una pregunta técnica disfrazada de pregunta de negocio. Para responderla bien, necesitas estimar la complejidad real del problema — y ahí es donde todo se complica.
La industria ha intentado resolverlo de muchas formas. Las horas hombre penalizan al que trabaja mejor: quien resuelve algo en dos horas cobra la mitad que quien tarda cuatro. Los story points sirven para planificar internamente pero son imposibles de convertir en precio para un cliente externo. El precio fijo por funcionalidad pone toda la incertidumbre del lado de quien desarrolla — y quien desarrolla casi siempre subestima.
Todas comparten el mismo problema de fondo: son aproximaciones subjetivas a algo que nadie ha podido medir de forma objetiva — la complejidad real de un problema de software.
La IA está introduciendo algo que puede cambiar eso.
Por qué la complejidad es tan difícil de medir
Dos tareas pueden parecer similares en la superficie y ser radicalmente distintas en profundidad.
"Agregar un campo al formulario de registro" suena simple. Pero si ese formulario está conectado a tres sistemas legacy, tiene validaciones en cuatro capas y nadie documentó las reglas de negocio, la tarea real no tiene nada que ver con lo que parece desde afuera.
Las métricas tradicionales no capturan eso. Las horas miden el tiempo transcurrido, no la dificultad real. Los story points reflejan una estimación grupal que depende de quién esté en la sala y qué tan bien conoce el sistema. La experiencia ayuda, pero no escala — y no es transferible de un proyecto a otro de forma sistemática.
Lo que ha faltado siempre es una señal que emerja del trabajo mismo, no de la estimación previa.
Tokens: qué son y qué representan
Cuando trabajas con un modelo de inteligencia artificial, ya sea para generar código, revisar lógica, planificar arquitectura o depurar errores, cada interacción consume tokens. En términos simples, un token equivale a una fracción de palabra: aproximadamente 1–2 tokens por palabra en español. En otras palabras, lo que los tokens revelan es cuánto contexto necesita un problema para ser entendido, cuántas iteraciones se requieren antes de llegar a respuestas de calidad, cuántos ajustes y correcciones se acumulan en el camino. No es actividad, es esfuerzo cognitivo real, visualizado de manera cuantitativa.
Ejemplo concreto: generar el esquema inicial de una base de datos puede consumir unos 2.000 tokens. Depurar un error de concurrencia en un sistema distribuido puede llegar a 50.000. Esa diferencia no es arbitraria — refleja complejidad real.
El patrón que emerge: complejidad y consumo
Con suficiente historial de trabajo con IA, aparece una correlación que no es perfecta pero sí significativa:
| Nivel | Tipo de tarea | Tokens estimados | Ejemplos |
|---|---|---|---|
| 1 – Operativo | Baja incertidumbre | 500 – 2.000 | CRUD básico, scripts simples, ajustes de estilo |
| 2 – Funcional | Variabilidad media | 5.000 – 20.000 | Integraciones de API, módulos con lógica de negocio |
| 3 – Sistémico | Alta incertidumbre | 20.000 – 100.000+ | Arquitectura, debugging complejo, refactoring profundo |
No es una regla fija. Un prompt mal construido puede gastar 30.000 tokens en algo operativo. Pero con historial propio, estas bandas se ajustan y vuelven predecibles.
Los tres niveles en detalle
Nivel 1 – Operativo: Baja incertidumbre. El problema está bien definido y la solución tiene un camino claro. La IA ejecuta con poca orientación adicional. En términos de pricing, este nivel es el más fácil de cotizar porque la variabilidad es pequeña. El riesgo de subestimar es bajo.
Nivel 2 – Funcional: Variabilidad media. Hay decisiones de diseño involucradas y se requiere contexto del sistema. La IA propone alternativas y el desarrollador orienta, descarta, ajusta. Aquí el consumo de tokens empieza a reflejar algo valioso: las iteraciones de decisión. Cada vuelta en la conversación con la IA es una micro-decisión que en el modelo de horas quedaba invisible.
Nivel 3 – Sistémico: Alta incertidumbre. El problema está mal definido, involucra múltiples sistemas o tiene dependencias que no están documentadas. El desarrollador guía activamente la exploración, y el trabajo se extiende en múltiples sesiones. Es el nivel más difícil de cotizar con métodos tradicionales — y donde los tokens aportan más valor como señal.
Un desarrollador senior consume menos tokens en problemas Nivel 3 (desarrollo de código) porque tiene mayor experiencia y probablemente dispone de más técnicas para encuadrar el problema desde el inicio. Eso no invalida el modelo, la señal sigue siendo válida, pero el historial tiene que ser tuyo, no el de otro.
De los tokens al precio: cómo usar tu historial
El valor real de medir el consumo de tokens no está en una tarea aislada — está en el historial acumulado.
Supón que llevas tres semanas registrando el consumo por tarea completada:
- Semana 1: 180.000 tokens para 8 tareas → promedio ~22.500 por tarea
- Semana 2: 210.000 tokens para 11 tareas → promedio ~19.000 por tarea
- Semana 3: 195.000 tokens para 10 tareas → promedio ~19.500 por tarea
Tienes una capacidad productiva medible: ~200.000 tokens semanales, ~20.000 por tarea en promedio. Si llega un proyecto nuevo con 12 funcionalidades, puedes clasificarlas por nivel y proyectar el consumo total esperado, contrastándolo con tu historial.
No es una fórmula exacta, pero es una base cuantificable que antes no existía. Más importante: cuando un proyecto termina consumiendo el doble de lo estimado, tienes datos concretos para entender por qué — y para cotizar mejor la próxima vez.
El modelo que cambia: del tiempo al valor resuelto
Si la complejidad de solución de un problema puede medirse de manera más precisa, el modelo tradicional de pricing para ese trabajo cambia por completo.
Modelo tradicional
Precio = horas × tarifa
Este modelo tiene un problema fundamental: penaliza la eficiencia. Quien resuelve algo en 2 horas cobra menos que quien tarda 8, aunque el valor entregado sea idéntico.
Nuevo enfoque
Precio = complejidad × capacidad de resolución
La complejidad la determina el problema. La capacidad de resolución la aporta el desarrollador — incluyendo las herramientas que usa y qué tan bien las usa.
Bajo este modelo, un problema Nivel 3 tiene un precio que refleja su dificultad real, independientemente de si se resuelve en 6 horas con IA bien utilizada o en 6 días sin ella. El cliente paga por el problema que se resuelve, no por el tiempo que toma resolverlo.
Los tokens no implementan este modelo por sí solos, pero sí aportan la evidencia que hace la conversación de pricing más sólida.
Lo que los tokens no resuelven
No todo consumo refleja valor. Un prompt mal planteado genera muchos tokens con poco resultado. Si estás aprendiendo a usar IA o explorando territorio desconocido, el consumo será alto aunque el output no lo justifique. La señal tiene ruido — y ese ruido tarda un tiempo en calibrarse.
La experiencia sigue siendo la variable más importante. Un desarrollador senior resuelve problemas Nivel 3 con menos tokens que uno junior, no porque el problema sea más simple, sino porque sabe encuadrarlo mejor desde el inicio. Los tokens miden el trabajo visible — no la calidad del pensamiento previo que lo hace posible.
Los modelos de IA evolucionan rápidamente. Lo que hoy requiere 30.000 tokens puede resolverse con 8.000 en seis meses gracias a modelos más eficientes. El historial no es estático — necesita actualizarse conforme las herramientas mejoran.
No reemplaza la conversación con el cliente. Al final, el pricing es también una negociación. Los datos de tokens aportan argumentos, no respuestas automáticas.
Preguntas abiertas para tu equipo
Algunas de estas preguntas no tienen respuesta fácil, y está bien así:
- ¿Estás midiendo la complejidad de tus proyectos antes de cotizarlos, o cotizas y después descubres la complejidad?
- ¿Cuánto de tu pricing actual se basa en datos propios versus intuición acumulada?
- ¿Qué pasará con el modelo de horas cuando los clientes entiendan que la IA puede comprimir días en horas?
- ¿Debería el precio de un proyecto reflejar el tiempo invertido o el problema resuelto?
- ¿Tiene sentido, en tu contexto específico, empezar a medir tokens ahora — o hay otras señales que ya te están diciendo lo que necesitas saber?
Conclusión
"¿Cuánto cobro por esto?" seguirá siendo una pregunta difícil. La complejidad del software no desaparece porque ahora tengamos mejores herramientas.
Pero por primera vez hay una señal que emerge del trabajo mismo, no de la estimación previa ni de lo que el cliente describió (o no describió) en la reunión inicial. El consumo de tokens deja un rastro del esfuerzo cognitivo real involucrado en resolver un problema.
No es una fórmula. Es la información que empieza a acumularse desde la primera tarea que registras — y que en un año convierte el "¿cuánto cobro?" en una pregunta que puedes responder con datos propios.