Inside Tenex’s AI-Native Engineering Experiment: Paying for Output, Preserving Context, and Owning the Workflow

1. Guest Background

Tenex cofounder Alex Lieberman and special projects lead CJ Hess approach AI adoption from two connected positions: running an applied AI business and building the machinery its engineers use. Hess corrects his introduction at the start of this Latent Space interview: he is not the director of engineering. He was Tenex’s first employee, comes from software engineering, and previously operated an engineering consultancy.

Lieberman describes Tenex as an applied AI partner helping enterprises become AI native. Its initial offering was AI-powered development, but customers increasingly wanted broader help transforming their organizations. He says the company began eighteen months earlier and now has 75 employees, roughly 90% of them engineers or AI strategists. He describes the customer base as evenly divided between Fortune 2000 businesses and midmarket companies generating $100 million to $500 million annually. These are his descriptions of the business, rather than independently verified operating figures.

Hess’s current remit includes the internal engineering harness and platform work for deploying background agents into enterprises. That makes the conversation useful on two levels: how Tenex organizes its own production, and what it encounters when similar ambitions meet customer systems. The guests offer implementation experience from a service provider’s position, with the strengths and limits that perspective entails.

2. What the Episode Covers

Hess’s route into Tenex exposes a tension in selling engineering time. As AI helped him deliver consulting work faster, hourly billing meant he earned less. Tenex’s promise to reward output appealed because it let him share in the gains from improving his methods. The company primarily uses agreed story points as the unit of engineering compensation. Lieberman reports approximately a fourfold spread between its highest-paid and lowest-paid engineers; he does not establish a corresponding ratio of business value created.

An output-based system immediately raises questions about estimation and quality. Lieberman says Tenex’s AI strategists provide a counterweight because their incentives concern customer retention and growth. In his account, inflated estimates and barely acceptable code have not become the central problems critics anticipated. The harder issue is compensating work that does not look like coding: architecture, client meetings, and the effort required to understand what should be built. The episode describes that internal judgment without supplying an independent quality audit.

Hess expects customer understanding to become more valuable as models perform more implementation. His suggestion that the right context can get a model to 90% of a solution is an experiential claim, not a general success rate. The substantive point is about where effort moves: discovering requirements and turning a customer’s scattered knowledge into usable context can determine whether implementation addresses the actual problem.

Tenex’s meta harness supports that shift. Hess describes a system that grew from standardized skills into repository documentation and a CLI covering plans, visualizations, client readouts, and agent activity. Some formatting constraints have loosened as models improve, while expectations for recording decisions and execution remain explicit. The records go into Git.

For Hess, this material supplies information code cannot reliably contain: why a choice was made and what a conversation meant at the time. Durable records let another person or agent investigate without locating the original participant. Tenex watches average monthly story points per engineer, and Hess estimates that output roughly doubled during the year. Yet he also says estimation criteria are reviewed at least quarterly. The improvement is therefore an internal assessment made alongside a changing measurement system, rather than a controlled productivity result.

3. Core Views: Reasoning, Examples, and Limits

The episode’s central distinction is between equipping employees and delegating organizational work. Lieberman estimates that, among roughly 100 enterprises Tenex is speaking with, about 90% have rolled out general-purpose models, 60% have undertaken training, and 50% have effective coding-agent deployment. His estimate falls to around 5% for production agents doing nonengineering work. These figures describe his customer conversations, not a representative market survey. Their analytical value is the separation between stages that can otherwise disappear inside a broad claim of AI adoption.

Hess explains the difficulty through an example of forty people performing approximately the same function in different ways. Each person can receive tools and learn to augment an individual workflow. A background agent that proactively produces work for review needs something more consistent: a recognizable process and an agreed basis for deciding whether the result is correct. Without those, evaluations lack a stable target. Standardization is therefore a prerequisite in his argument, not proof that an agent will succeed once a process document exists. The interview does not establish how much variation any particular deployment can safely tolerate.

Permissions add another organizational constraint. Lieberman identifies repeatable back-office automation and data access control as recurring customer requests. He says Tenex moved from bespoke permissioning work toward its own gateway solution. The relevant distinction is between a tool’s technical ability to retrieve information and an employee’s entitlement to see it. However, the conversation does not explain the gateway’s enforcement mechanisms or demonstrate isolation results. It establishes a customer problem and Tenex’s direction of work, rather than validating a complete security solution.

The tooling discussion makes a related case for judging systems at the task level. Hess describes complementary use of models and environments: Codex for review and some computer-use tasks, and Amp for cloud execution and cross-model collaboration. His preference concerns the interaction between writing, reviewing, and running work, rather than a single model’s abstract superiority. The guests believe per-task costs have recently fallen, but Hess explicitly allows for a reversal if expensive frontier models deliver sufficiently better results. A host’s example of moving spreadsheet cells sharpens the economic question: additional intelligence is valuable only when it improves the relevant outcome enough to justify its price. No comparative benchmark in the episode establishes a universally optimal combination.

That same tension between capability and implementation drives the disagreement over vertical AI. Lieberman worries that highly customized enterprise expectations require extensive integration and service work, putting pressure on software-style margins. He also questions whether frontier models will absorb capabilities that currently support separate products. A host pushes back with Harvey and OpenEvidence, arguing that specialized data, interfaces, integrations, and user habits can retain value. Bloomberg and Superhuman serve as analogies for paying for a specialized working environment. These examples are arguments offered in the conversation, not independent verification of any company’s competitive position.

Hess makes the disagreement more precise by separating an agent sold mainly as a vertical capability from an application that organizes a workflow and places an agent inside it. Strategic data or compliance advantages may also matter. This reframing avoids treating an entire category as either protected or doomed. The useful question becomes what a product actually owns in the customer’s working life: a reproducible task, or a process with tools, constraints, and accumulated context.

The build-versus-buy exchange reinforces the need to distinguish initial capability from continuing responsibility. A host says a replacement for software quoted at $40,000 annually cost about $1,000 to build, but production use was still planned for the next conference. That does not establish a $1,000 annual operating cost or proven reliability. Lieberman emphasizes the consequences of replacing established systems and the cognitive burden of maintaining noncore software. The host adds a positive argument: custom software may improve the experience for everyone involved and shorten iteration cycles. Together, the positions move the decision beyond cheap code generation toward the value and burden of ownership.

4. Learning and Application

For engineering leaders, the compensation discussion suggests a practical design exercise before adopting output-based pay. Define how work is estimated, who accepts delivery, and how rework affects the assessment. Make architecture, customer discovery, and coordination visible rather than assuming they will be captured by coding points. Tenex’s strategist role offers one possible counterweight, but retention incentives do not automatically validate every technical decision. When models improve, preserve changes to estimation criteria alongside delivery records so that a rising point total is not mistaken for an equivalent increase in customer value.

Repository memory can begin with one project. Store the objective, important constraints, decision rationale, relevant customer context, execution record, and acceptance outcome beside the implementation. The test is whether a new engineer or agent can explain why the system took its current shape. Hess’s account of relaxing some formatting requirements is instructive: a complete template is less useful than a record that answers an actual question. Teams should retain structure where it helps retrieval and judgment, rather than measuring success by document volume.

For an enterprise agent pilot, choose a repeated activity and ask several practitioners how they recognize a satisfactory result. Identify shared inputs, exceptions, review decisions, and conditions for returning work. If those answers remain incompatible, individual assistance and process clarification are sensible intermediate steps. Background execution should come with explicit data access rules and a clear route back to human judgment. A gateway proposal can support that work, but the existence of a gateway cannot substitute for testing the permissions a deployment actually enforces.

Model evaluation and software ownership can then use the same unit of analysis: a completed, acceptable task. Compare outcome quality, review effort, and cost rather than rewarding token consumption or assuming the most capable model is always necessary. For build-versus-buy decisions, consider initial development, migration, continuing maintenance, failure consequences, and improvements to participant experience together. The inexpensive SaaS replacement discussed in the episode is a reason to investigate, not evidence that a critical system can be replaced safely at its prototype cost. When evaluating a vertical product, ask whether its specialized data, interface, integrations, or workflow would remain valuable if the underlying model improved substantially.

The employment discussion requires an equally concrete standard. Hess describes an intention to redirect people toward other problems, including cross-team coordination and strategic resource allocation. That is a possible destination for job redesign, not evidence that displaced workers have already moved successfully into new roles. Lieberman explicitly rejects the comforting idea that AI only removes work people dislike; income matters regardless of enjoyment. A credible reallocation proposal should therefore name the next responsibility, training required, and available transition opportunity. Employees can use the same information to assess which capabilities to develop. Lieberman’s emphasis on training and enablement supports instruction in real workflows rather than merely distributing tool accounts.

Finally, the New York discussion offers a useful discipline for choosing projects. Lieberman sees a smaller AI community than San Francisco’s but substantial commercial opportunity, while the closing exchange stresses meeting customers and confronting business realities. Applied to a team, that means pairing each proposed capability with a real user, an acceptance condition, and an owner of ongoing consequences. Customer proximity can improve the choice of problem; it still does not establish that a proposed automation has delivered value.

Source

• Original episode: AI in NYC: How Tenex Builds an AI-Native Engineering Team — Alex Lieberman & CJ Hess