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. Horas hombre: razonable en teoría, injusta en práctica porque penaliza a quien trabaja mejor. Story points: útiles para planificación interna de equipos, pero difíciles de traducir a precio para un cliente. Precio fijo por funcionalidad: cómodo para el cliente, arriesgado para quien desarrolla.
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.
Pero más allá de la definición técnica, lo que importa es lo que los tokens representan en la práctica:
- El contexto que necesita el problema — cuánto hay que explicarle a la IA para que entienda qué resolver
- La profundidad del razonamiento — problemas complejos generan respuestas más extensas y requieren más iteraciones
- El número de ajustes — cada refinamiento, corrección o vuelta atrás suma tokens
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.
Este modelo no reemplaza la experiencia — la complementa. Un desarrollador senior navega el Nivel 3 con menos tokens porque sabe hacer las preguntas correctas desde el inicio.
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
Todo lo anterior apunta hacia un cambio más profundo en cómo se cobra el desarrollo de software.
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
Sería deshonesto presentar esto como una solución completa. Hay limitaciones reales que vale la pena nombrar:
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. El consumo puede ser síntoma de ineficiencia tanto como de complejidad.
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
El objetivo de este artículo no es cerrar el debate — es abrirlo con mejores preguntas:
- ¿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?
- ¿Estás registrando tu consumo de tokens hoy, o dejando pasar datos que podrían informar mejores decisiones mañana?
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 cuantificable que emerge del trabajo mismo — no de la estimación previa, no de la intuición, no de lo que dijo el cliente 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 un punto de partida para construir el historial que hoy no tienes, y que dentro de un año podría ser la diferencia entre cotizar con confianza o seguir adivinando.