Tenex: pagar a ingenieros por output con IA y 75 personas

Tenex: 75 personas, la mitad Fortune 2000 y un modelo de pago incómodo

Tenex tiene 75 empleados, de los cuales el 90% son ingenieros o AI strategists. La mitad de sus clientes son compañías del Fortune 2000 y la otra mitad empresas mid-market con ingresos de entre US$100M y US$500M. Y paga a sus ingenieros por story points entregados, no por horas frente al teclado.

La cifra que mejor resume el experimento: la diferencia entre el ingeniero mejor pagado y el peor pagado de la empresa ronda las 4 veces. No es el 10x que prometía el relato del momento, pero es una dispersión salarial que casi ninguna organización de servicios profesionales toleraría sin conflicto interno.

Alex Lieberman y CJ Hess, su special projects lead, volvieron al podcast de Latent Space en el AI Engineer de Nueva York para contar qué pasa cuando esa idea se convierte en una organización de ingeniería completa. La pregunta de fondo que atraviesa toda la conversación sirve para cualquier founder: cuando construir se vuelve barato, ¿cómo decides cuánto vale el buen trabajo?

¿Por qué pagar por output y no por horas?

El argumento original de Tenex era simple y algo brutal: si la IA hace más rápido a un ingeniero, una tarifa por hora castiga justamente a quien mejor usa la herramienta. Cobras lo mismo por un trabajo que ahora toma la mitad del tiempo.

CJ lo vivió en primera persona antes de sumarse. Como consultor independiente facturaba por hora y, según contó, veía su output mejorar y acelerarse mientras terminaba cobrando menos. Ese fue el gancho del modelo de Tenex: alinear el incentivo con el resultado, no con la permanencia.

Los dos miedos clásicos de este esquema —que la gente infle estimaciones o que entregue código malo para acumular puntos— no se materializaron según Lieberman. La razón es de diseño organizacional: los AI strategists de Tenex están incentivados por retención y crecimiento de clientes, no por puntos. Si el equipo entrega basura, el cliente se va y el strategist pierde. Los incentivos de ambos roles chocan a propósito.

El problema real: cómo pagas lo que no es un ticket

La dificultad apareció en otro lado. A medida que los modelos mejoran, los ingenieros pasan menos tiempo escribiendo código y más tiempo metiendo el contexto del cliente en una forma que el modelo pueda usar: entender el problema, diseñar la arquitectura, decidir qué construir. Nada de eso cabe en un ticket.

CJ lo describe como un desplazamiento, no como una desaparición del trabajo técnico. Cuando el modelo llega al 90% de la solución con el contexto correcto, el valor se mueve hacia la conversación previa con el cliente. Y un sistema de compensación anclado a tareas entregadas tiene que hacer espacio para ese trabajo invisible.

Tenex recalibra el valor del story point al menos una vez por trimestre. Tiene lógica: si la IA duplica la capacidad de entrega, el punto debería deflactarse. La empresa reporta que el output de sus ingenieros se duplicó en el último año, medido en story points promedio por mes por ingeniero.

MetaHarness: el plan vive en el repo, no en la cabeza de alguien

La parte más replicable de la conversación es el sistema interno que Tenex llama MetaHarness. No es una herramienta mágica: es un conjunto de skills, documentos de proyecto y una CLI que los agentes usan para ejecutar el trabajo.

El principio es concreto. Existe un documento de plan canónico. Los agentes registran sus decisiones y lo que van haciendo. Todo se commitea a Git junto al código. Cuando un agente retoma una tarea, no lee solo qué se construyó: lee por qué el equipo decidió construirlo así.

La distinción que hace CJ es la que importa: la ventaja no está en que los agentes escriban código más rápido, sino en hacer legible el trabajo que rodea al código —el plan, los criterios de aceptación, las decisiones, la evidencia—. El propio artículo de Tenex sobre SDLC nativo de IA reconoce el costo: tanta estructura puede ser excesiva para un equipo chico con un solo proyecto.

La brecha de adopción: 90% con LLM, 5% con agentes en producción

Lieberman describe la adopción empresarial como una carrera por hitos, con cifras que dijo en el escenario del AI Engineer. Sobre unas 100 empresas con las que hablan:

• 90% ya desplegó un LLM de propósito general (Claude o Codex) a sus empleados.
• 60% avanzó en entrenamiento y enablement, el paso que casi nadie quiere financiar.
• Alrededor del 50% desplegó agentes de código en su organización de ingeniería. La audiencia del evento estimaba 70-80%.
• Solo 5% tiene un agente en producción haciendo trabajo que no es construir software.

Ese último número es el dato del artículo. La inteligencia cruda está disponible y barata; lo que falta es la última milla para difundirla dentro de la organización.

El research de mercado acompaña esa lectura. El 2026 Connectivity Benchmark Report de Salesforce, MuleSoft y Deloitte Digital, basado en 1.050 líderes de TI, señala que la empresa promedio gestiona 957 aplicaciones y solo el 27% está conectada, con la integración de datos como obstáculo citado por el 82% de los encuestados, según reportó ZDNET. El mismo informe indica que los líderes planean destinar el 19% de su presupuesto de TI a agentes de IA.

Y hay un cuello de botella que Lieberman menciona y que casi nadie presupuesta: permisos y RBAC. Cuando cada empleado tiene Claude o Codex y necesita acceso a datos específicos, los CIO y CISO se quedan sin un panel de control decente. Tenex empezó construyendo esas soluciones a medida y terminó productizando un gateway propio.

¿Pagar por output sigue teniendo sentido si la IA escribe el código?

Un estudio de investigadores de Harvard con datos de Jellyfish —300 millones de eventos de trabajo en más de 700 empresas y 700.000 empleados entre 2021 y marzo de 2026— encontró que introducir agentes de código aumenta 30% las líneas de código, 20% los commits y 23% los pull requests, pero no mueve de forma significativa la tasa de resolución de issues y epics, según publicó Ars Technica.

La explicación: la revisión humana absorbe la ganancia. Los pull requests requieren más revisiones y los revisores dejan más comentarios. El output sube; el software entregado, no necesariamente.

Eso valida la decisión de Tenex de medir en story points y no en líneas de código, y a la vez explica por qué su modelo necesita strategists con incentivos opuestos. También coincide con el research de Karat, difundido en octubre de 2026: el 90% de los líderes tecnológicos de EE.UU. usa IA para producir más sin recortar headcount, el 82% reporta más volumen de features, pero el 67% dice que el tiempo para llevar una feature al mercado aumentó y el 44% reporta más errores de código.

Vertical AI: ¿producto o feature del agente que ya usas?

Lieberman se declara escéptico con el AI vertical: si cada empresa espera una solución hecha a medida, ¿cómo se entrega eso con márgenes de software? Y si los modelos frontera siguen mejorando, ¿cuánto de la tarea se la come una herramienta general?

La respuesta de CJ es más útil que el debate: distingue entre un producto vertical cuya función principal es un agente ejecutando una tarea y una herramienta que mejora el flujo de trabajo alrededor de esa tarea. La pregunta que queda no es si gana el vertical AI, sino qué productos se vuelven el lugar donde la gente hace su trabajo y cuáles terminan siendo una función del agente de turno.

¿Qué significa esto para tu startup?

1. Antes de automatizar, documenta el proceso. La frase que Lieberman le repite a su equipo es directa: no puedes automatizar un proceso que no existe. Si 40 personas hacen la misma función de 40 maneras distintas, no tienes un proceso: tienes 40. Ese es el trabajo previo, y es más barato que cualquier licencia de agente.

2. Escribe el porqué, no solo el qué. Adopta la lógica de MetaHarness a tu escala: un documento de plan versionado, decisiones registradas en el mismo repo que el código, criterios de aceptación explícitos. Un agente que retoma una tarea meses después necesita el contexto de la decisión, no solo el diff. Empieza con un solo proyecto antes de estandarizar toda la organización.

3. Revisa tu esquema de incentivos antes que tu stack. Si pagas por horas y tu equipo usa IA, estás penalizando a tu mejor gente. Si pagas por tickets, estás ignorando el trabajo de arquitectura y de contexto que ahora define la calidad. Cualquiera sea el modelo, define quién tiene el incentivo contrario —alguien que pierda si el output es malo— y calibra el valor de la unidad al menos una vez por trimestre.

4. Mide el resultado, no la actividad. El estudio de Harvard es la advertencia: más código no es más software. Pon tu métrica en features que llegan a producción y en la tasa de retrabajo, no en commits ni en tokens consumidos.

La lección más incómoda de Tenex no es que su modelo de compensación sea replicable —no lo es para la mayoría—, sino que la ventaja competitiva se mudó del código al contexto. Quien logre que el conocimiento de su empresa viva en un lugar legible para humanos y agentes, gana. Quien lo deje en la cabeza de tres personas, va a pagar por ello en cada iteración.

Fuentes

• Latent Space — AI for the Fortune 2000: How Tenex Builds an AI-Native SDLC (fuente original)
• ZDNET — AI agent adoption and budgets will rise significantly in 2026
• Yahoo Finance / Karat — AI Is Making Top Engineers More Valuable
• Ars Technica — AI coding agents generate more code, but not more software