Evidence at a glance
Before Agents Can Take Tasks, They Need the Team’s Rationale
Tenex’s AI-native SDLC is an engineering workflow for enterprise software development and agent collaboration. Its MetaHarness puts project documents, plans, decisions, and shared skills in the code repository, with a CLI alongside them, so an agent can read not only the code but also why the team chose to build it that way. The system addresses a specific problem: agile teams often leave requirements and reasoning in meetings, chats, and people’s memories, while agents do not inherit that tacit context automatically.
The design is worth examining not because it gives agents yet another way to write code, but because it shifts the bottleneck from code generation to making organizational judgment transferable. When code generation speeds up, omissions in a plan can turn into implementation more quickly too. If the context is missing, an agent resuming work may carry a bad premise further than a human would.
Turning the Project Record into an Agent-Readable Workspace
MetaHarness’s central move is to put the project record under Git version control alongside the code, separating current facts, plans, and historical decisions. Tools such as Linear and GitHub provide working views, while the project record serves as a closer approximation of shared ground truth. When an agent returns to a task, it can read architecture documents, decisions, acceptance criteria, and verification commands instead of seeing only an isolated ticket.
The workflow Tenex describes starts with requirements and permissions, then moves through scope and planning, design review, implementation, demo checkpoints, testing and QA, release, and post-launch handoff. Tickets are expected to include acceptance criteria, while shared skills encode reusable practices. The accompanying CLI can check which tasks are ready, whether a plan is missing pieces, and whether the project record matches Linear. A validator can also reject a “done” status without evidence such as a pull request, tests, or sign-off. These mechanisms make completion a claim that needs evidence, rather than a status entered by convention.
That does not mean more documentation is always better. Tenex acknowledges that this structure can be excessive for a small team working on a single project, and the records themselves need ongoing maintenance. Its value depends on project complexity, how often work changes hands, and whether the team can keep the record aligned with actual decisions.
Paying for Delivery Still Misses Some of the Most Important Work
Tenex’s original objection to hourly billing was straightforward: if AI lets an engineer finish faster, charging by the hour can mean earning less for the same work. The company therefore ties engineer compensation mainly to delivered story points. In the interview, co-founder Alex Lieberman said Tenex then had 75 employees, about 90 percent of whom were engineers or AI strategists. He also said roughly half its customers were Fortune 2000 companies and half were mid-market businesses. These are figures reported by a founder in an interview, not independently verified industry statistics.
Measuring delivery does not eliminate incentive problems; it shifts the question from hours to what counts as delivery. Tenex says that inflated estimates and low-quality code produced to accumulate points have not been its biggest concerns. AI strategists, who are responsible for customer retention and growth, provide a counterweight to optimizing only for engineering points. Harder to measure are understanding a customer’s problem, assembling its context, designing an architecture, and deciding what not to build. CJ Hess said that as models improve, he spends less time coding directly and more time giving them enough customer context to work with.
That leaves a measurement gap in AI engineering organizations: tasks that fit into tickets are easy to score, while the judgment that determines whether a ticket should exist is not. If teams reward only delivered points, requirements clarification and architecture may look like unproductive time. But without accounting for that work, agents
Passing Tests Does Not Mean Anyone Wants the Product
Latent Space’s Kill My SaaS project sought a replacement for a speaker-management tool. The team had been quoted $43,000 a year for the software and received 72 submissions. The entry chosen by human judges ranked 19th on the AI judge’s leaderboard. This is not a comprehensive evaluation of AI judging, but it makes one boundary clear: checking whether software meets a set of scenarios is different from deciding whether people will want to use it over time.
The value of building software in-house is not limited to saving a vendor bill. Owning the workflow can let a team iterate more quickly around the needs of speakers and operators, but the ability to make changes quickly does not erase maintenance costs. Tenex’s counterpoint is that, especially at large companies, replacing a system embedded in existing operations can be expensive and risky. A build-versus-buy decision has to account not just for the purchase price and code-generation cost, but also for ongoing maintenance, migration risk, and who will keep improving the product.
This is also where agent evaluation stops being a substitute for product judgment. Agents can help implement requirements, and automated checks can verify some acceptance criteria, but whether users experience a better workflow still has to be judged in use. The Kill My SaaS result cautions against treating an AI judge’s ranking as a proxy for product quality: matching a description is not the same as solving the problem.
Standardize the Workflow Before Handing It to an Agent
Tenex describes the enterprise adoption challenge as the distance between “employees can use a model” and “agents can work reliably in a real business process.” If people in the same function handle work in different ways, an agent has no consistent definition of a correct result, and the team has trouble building a dependable evaluation. Data access and role-based access control also need attention: whether an agent can read a particular resource is not merely an engineering setting, but part of deciding whether it can safely enter a workflow.
So the practical question should not begin with whether an agent can perform a task. It should begin with whether the workflow is clear enough: are inputs explicit, are decisions recorded, can acceptance criteria be verified, and do permissions match the work? MetaHarness aims to put some of those answers into the project record and toolchain, but it cannot decide for a team what is worth recording or replace a business owner’s judgment of whether the result matters. Vertical AI products face a related trade-off: a general-purpose agent may take on a task without making specialized data, integrations, interfaces, and user habits irrelevant.
For a technical leader, a practical starting point is not to turn every activity into an agent workflow. Choose work that is handed off repeatedly, loses context easily, and has verifiable outcomes. Record plans, decisions, and acceptance evidence, then see whether maintaining that record takes less effort than coordinating through conversation. For a small, stable project, lighter documentation