Engineering brief
Paying engineers for output exposes AI's real bottleneck: process
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- This year
- Warnings
- None
Tenex pays engineers by story points, reports a 4x pay spread, and says output doubled in a year. The stronger signal for leaders: only 5% of enterprises have a non-coding agent in production, because processes aren't standardized enough to automate.
Output-based engineering is becoming real; process, permissioning, and comp design now decide AI adoption speed.
Watch if you're designing output-based compensation or building agent harnesses and want one firm's operating details.
Summary
The model. Tenex, an applied AI consultancy, pays engineers by story points rather than hours, and reports a roughly 4x spread between its highest and lowest paid engineers. The bet is that AI widens output variance, so compensation should follow output. The two classic failure modes, sandbagging story points and shipping bad code, have not shown up. The harder problem is paying for non-coding time such as architecture and client meetings, which is forcing the model to evolve.
The evidence. The firm claims per-engineer output roughly doubled over the past year, with models like Opus 5.5 doing more long-running work. Story-point criteria are recalibrated quarterly to keep pace with model improvements. Tenex also describes a "meta harness": structured documentation, a CLI, and agent decision logs checked into the repo, so context never lives only in someone's head. These are useful operating details, but all self-reported; there is no external validation or quality measure.
The adoption gap. From client work, Tenex estimates 90% of enterprises have rolled out a general LLM, 60% have training and enablement, only 50% have coding agents in engineering, and just 5% have a non-engineering agent in production. That drop is the real story. It is not model quality that holds enterprises back; it is workflow standardization, data permissioning, and governance. CIOs and CISOs are struggling to control what agents can read across the company.
The process lesson. CJ Hess says you cannot automate a process that does not exist. Teams with 40 people doing similar work slightly differently cannot build reliable background agents. Standardization has to come first, then evals and handoff. The tradeoff is that standardizing too early can lock in weak processes. Tenex's advice is to build process before automation, which is easy to agree with and hard to do in large organizations.
The SaaS debate. The host's example of replacing a $40,000-a-year middle-tier SaaS for $1,000 in his competition shows the pull of one-of-one software. Alex pushes back: in large enterprises, the risk of ripping out core systems is too high, and the deciding factor is whether the prize is big enough to justify the cognitive load of maintaining non-core software. Tenex built its own OS and CRM because iteration speed matters there.
What's missing. There is no data on code quality, retention, or long-term outcomes under output-based pay. The 2x output claim could hide growing architecture debt. CJ hints that the model may move away from story points toward true output value as agents do more of the work. The signal to watch is whether Tenex can keep compensating fairly as models improve.
My take
I think the story-point pay experiment is genuinely interesting, but I'd be careful generalizing from it. Tenex selects for engineers who want to go long on AI, and that self-selection does a lot of the work. The more transferable lesson is the process one: agents only produce when workflows are standardized, decisions are written down, and permissioning is solved. Most teams would get more from investing in that before touching compensation.
I'm also skeptical of the 2x output claim without a quality measure. Output can double while architectural debt grows quietly. The metric worth watching is whether story points hold up as models keep improving. If Tenex moves toward outcome-based compensation, that will be the real signal.
What to do with this
- Audit one non-engineering workflow to see whether it is standardized enough to automate, and document the gaps.
- Ask your engineering team to keep agent decision logs in the repo and review them after two weeks.
- Review your compensation model for non-coding time before AI raises output and widens pay variance.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
Model Choice Barely Matters: Fix Engineering Culture, Not AI Tools
AI model choice explains under 1% of developer output variance, per Jellyfish's 50,000-engineer dataset. The levers leaders control matter more.
Human behavior simulation is close to usable, but check the 85% claim
Simulated users predicting behavior at 85% accuracy could change product testing, but the claim is vendor-generated and the ceiling is too convenient.
Stop evaluating models. Start evaluating the risk around them.
1,368 AI failures later: deployment controls, not model quality, determine real-world harm. Failure-driven evals follow. No production proof yet.
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.