At Tenex, the reasoning behind a piece of software is meant to live in the same place as the software. The firm builds AI systems for large companies. It checks its project plans, its coding agents' decision logs and the surrounding project context into each code repository, so an agent that picks up the work can read why something was done as well as what was done.
The setup came up when Tenex's Alex Lieberman and CJ Hess joined swyx on Latent Space, in a conversation recorded at AI Engineer New York and published on October 21, 2026. Tenex calls its internal system MetaHarness. The firm also described it in an August 5, 2026 post, Building an AI-Native SDLC, written by Lieberman, Hess, Dan Zakon and Arman Hezarkhani. SDLC stands for software development life cycle, the steps that take a feature from planning to shipping and maintenance.
A few terms first
A coding agent is an AI model that writes and changes code on its own, using tools such as a terminal, instead of only suggesting lines to a person. A harness is the software around the model. It decides what the model sees, which tools it can use and how its work is checked. A repository, or repo, is the version-controlled folder that holds a project's code. Git is the tool that records every change made to it.
Why context matters to Tenex
Earlier in the conversation, the discussion turned to how the work itself has changed. In one first-person account, time at Tenex had gone from coding a lot to coding less. The view offered was that models given the right context can now get roughly 90% of the way to a solution. On that view, much of the value lies in sitting with the client, gathering everything they can "brain dump" and passing it to the model. That only works if the context is written down somewhere the model can find it.
How MetaHarness grew
Tenex started by standardizing a set of skills, which are reusable instruction packages that tell an agent how to do a recurring task. Most engineering teams have probably done something similar by now, the discussion noted. At Tenex this grew into a tightly structured set of documents inside each repository, plus a command-line tool (CLI) that the models themselves use to drive the work: drafting a plan, producing a visualization or writing a readout for a client. The aim is for the steps around writing code to happen automatically, and in the same way, across the team.
At the center is a large canonical plan document with a shared structure. As models have improved, Tenex has loosened how strictly that structure is enforced, and it has done the same across the rest of the system.
Once a plan exists, agents build it. They log their decisions and progress in what was described as a "very opinionated" format. All of it is checked into Git. Most of it is Markdown, a plain-text formatting style, though the preference voiced in the episode is shifting toward HTML and the illustrated "picture books" the agents produce.
Why write docs when the code exists
Some engineers argue that the code itself can be a codebase's memory. The episode took the opposite view: a team needs to know why a decision was made and what conversation led to it. With the code and that written record together, any question about past work has a durable answer. "It's never like in someone's head. It's always in the repo," which was said to give Tenex's agents and tools "superpowers." At many engineering teams, that knowledge still exists only in conversations or in people's memories. Tenex's stated goal is to push further, so that all the context sits in one place and agents drive more of the work without people supplying everything up front.
The company's post fills in how the record is organized. It separates current facts, future plans and historical evidence. Startup hooks, small scripts that run when an agent session begins, load the relevant architecture, decisions, acceptance criteria and verification commands into each session. The CLI checks the links between records: a ticket that points to a milestone that doesn't exist produces a specific error that can be fixed. The CLI also syncs these records into Linear, a project-tracking tool, and into GitHub. Automated syncing may rewrite designated metadata blocks but must leave the surrounding human reasoning intact. A claim that work is finished is blocked if no evidence is linked to it. An internal system, Tenex OS, builds project-health views from the record, so nobody has to write status reports by hand.
The authors keep humans responsible for architecture, judgment and what ships. They also concede that this much structure can cost more than it saves for one small team working on one project, and that it only works if teams record their knowledge consistently.
Opus writes, Codex reviews
Tenex lets engineers choose their own tools. Asked which models were most popular in the office, the answer was that "the vibe right now is Opus 5.5," Anthropic's model, described as good, fast and cheap. In the episode it was said to have replaced a rotation of two or three models, picked depending on whether a job needed something cheap and fast, something very smart or something suited to a particular problem. Asked about Fable, another model, the reply was that it wasn't being used much, and that many people were "defaulting away from it."
Codex, OpenAI's coding agent, is still a common choice at Tenex for computer use, where the AI operates software and browsers the way a person would. According to the episode, Opus 5.5 is the main model for most of the team, and the best results still come from combining the two: Opus writes the code, Codex reviews it, and the two go back and forth on the engineer's machine. For Codex work, the model named was 6.1 Sol, most likely OpenAI's GPT-6.1 Sol, which OpenAI offers through Codex as a lower-cost model for coding, computer use and professional work.
Moving the loop off the laptop
In the episode, Amp was named as an "interface of choice" for this workflow. Amp is a coding-agent tool whose default model, the conversation noted, is Opus. Amp recently started letting users connect their Claude Code subscription, which was called "a pretty big game changer." An estimate offered during the exchange put the cost savings at about 80%. Amp's documentation narrows how that works: only Amp's Claude Code mode uses the linked subscription, and that mode runs on Anthropic's Claude Agent SDK rather than Amp's own agent. Amp's other modes don't draw on the subscription, and remote machine costs are billed separately.
The main appeal described in the episode is that Amp takes the work off the engineer's own computer, using what it calls orbs. In Orbs, Explained, Amp's Thorsten Ball describes an orb as a remote machine that holds the repository and a running Amp agent. A user can steer it from the web, a phone or the command line. Orbs sleep when idle and wake when prompted, and agents can create other orbs and exchange messages or files with them. Tenex has ties to Amp: in the episode it said it had co-hosted a happy hour with the Amp team the week before, which prompted some joking about "orbing out."
The conversation then turned to Anthropic: wasn't it odd that the company had never captured remote environments the way orbs had? Anthropic's own options include cloud-hosted Claude Code and Claude Tag, which it introduced on June 23, 2026 as a shared agent that colleagues can hand work to inside Slack channels. In the episode, these tools were seen as useful for teams collaborating, perhaps on non-technical tasks, but they hadn't reproduced the local setup. Amp was praised for being opinionated instead of trying to be a general solution, and for working across models. Opus writes the code, and an engineer can hop to a second orb and tell it to look at the first one and review its work. That recreates on remote machines the write-and-review loop engineers would otherwise run on their own laptops.
Building MetaHarness is part of a special-projects role at Tenex, described in the episode as finding "the bleeding edge of what the models can do" and giving them tools to do it better. The same work feeds an internal platform meant to take background agents out to enterprise clients in a way that is "truly, truly helpful to them."