Can AI Build Enterprise Software? What Benchmarks Show

Can AI build enterprise software?

Can AI build enterprise software? Yes, for isolated, well-specified pieces of it. No, not yet, for the end-to-end systems work that runs an actual business, because that work depends on context nobody wrote down.

What was the headline that started this experiment?

In September 2026, Anthropic announced that Claude had autonomously discovered a novel enzyme system tied to an array of DNA repeats, a pattern that echoes CRISPR. Roughly 950 Claude agents spent 21 hours combing a public database of DNA sequences, gathering more than 200,000 reverse transcriptases and narrowing the field to a handful of candidate systems for a human scientist to review. Anthropic says the process would normally take an expert weeks or months.

Feng Zhang, one of the scientists behind CRISPR, reviewed the pre-print and called it "an exciting example of how AI agents can contribute to biological discovery." That's not a hype quote from a vendor. That's independent scientific validation of a machine finding something new in a genome.

This fits a broader trend. METR, a nonprofit that tracks AI capability, has found that the length of software tasks frontier models can complete autonomously has been doubling roughly every seven months since 2019. Put those two facts together and the story writes itself: agentic AI is compounding fast, and it just found gene-editing machinery in an afternoon.

So why can't the same technology plug two internal APIs together?

Here's the tension. If agents can scan 200,000 genetic sequences and surface a genuinely new biological mechanism, why do the same agents still stall out, hallucinate a field name, or silently break a workflow when you ask them to connect your billing system to your CRM?

The honest answer: these aren't the same kind of problem. DNA discovery is a search task over a huge, clean, public dataset with one well-defined pattern to detect, a repeat structure near a gene. Enterprise integration is a judgment task over small, messy, private systems where the schema is inconsistent, the documentation is wrong or missing, and the "correct" behavior lives in someone's head, not in a spec.

That distinction is the whole article. Capability curves like METR's are real, but they're measured mostly on tasks that look like the DNA search: bounded, verifiable, well-specified. The moment you move to a domain where the ground truth is tribal knowledge, the curve goes flat.

What did we ask an AI coding agent to build in our experiment?

We wanted to see the gap firsthand, so we ran our own small test. We picked three ordinary internal systems that exist at almost any mid-sized company: a customer support ticketing API, an internal inventory service, and a billing endpoint with a handful of undocumented business rules (a discount that only applies to accounts opened before a certain date, a tax exemption flag that isn't in the schema comment). We asked a leading coding agent to build a single internal tool that reads from all three and flags orders that need manual review.

We weren't looking for a demo. We were looking for what happens when an agent has to infer behavior that was never written down anywhere it could read. This is closer to the daily reality covered in our look at the best AI coding agents in 2026 than to a genome scan: most of the work agents get handed inside a company looks like our test case, not like Anthropic's.

Where did it break, and which three failure patterns showed up?

Our results weren't random. IBM and UC Berkeley analyzed 310 agent traces on IT-automation tasks and built a failure taxonomy called MAST. Our test matched three failure modes they'd already named:

1. Incorrect verification. The agent declares the task done without actually checking the result against ground truth. Across every model IBM and Berkeley tested, this was the single strongest predictor of failure. In our test, the agent reported the review-flagging logic was working. It was, for one of three undocumented rules. It had quietly skipped the tax exemption case.
2. Action-reasoning mismatch. The agent's stated plan and its actual code diverged, usually invisibly, because nothing forced them to stay aligned.
3. Lost context and unclear termination. Longer sessions lost track of earlier constraints, and the agent didn't reliably know when it had actually finished.

The researchers also found that weaker open models cascade: GPT-OSS-120B racked up 5.3 distinct failure modes per failed trace, while a frontier model like Gemini-3-Flash stayed closer to 2.6. Model quality changes how badly you fail. It doesn't remove the failure.

Do benchmarks reflect business logic, or are they a greenfield trap?

The benchmarks that get quoted in demos are almost all greenfield, single-issue tasks. GPT-5.2 hits 72.8% on SWE-bench Verified, a benchmark of isolated, well-scoped coding problems. That number gets used to argue agents are basically expert engineers now.

But a newer benchmark called SWE-EVO tests something closer to real work: sustained, multi-file software evolution over time, the kind of thing our integration test resembled. On SWE-EVO, the best configuration, GPT-5.4 with OpenHands, resolves just 25% of tasks. That's not a small gap. It's the difference between a tool you can trust unsupervised and one you have to babysit.

It gets worse when the code is actually proprietary. Real-SWE, released in 2026, is built entirely from private, licensed production codebases rather than public GitHub repos. The top-performing combination, Claude Fable 5.1, solved only 38.8% of tasks. The New Stack summarized it bluntly: even the best coding agent still fails more than 60% of the time on real enterprise code. If you're choosing which frontier model to build internal agents on, that gap between public benchmarks and private-codebase performance is worth reading alongside our Claude Fable 5.1 vs. OpenAI Astra comparison before you commit.

What is the quality tax when AI code ships faster but breaks more often?

Even the successes carry a cost. CodeRabbit analyzed 470 real pull requests and found AI-authored code produces about 1.7 times more issues per PR than human-written code. Logic and correctness errors were 75% more common, and security vulnerabilities showed up at up to 2.74 times the rate.

For a weekend hackathon project, that quality tax is a rounding error. For a system that touches billing or customer data, it's the kind of defect rate that turns into an incident report. This is the same bottleneck we've written about in how AI coding agents broke CI/CD: the code arrives faster than anyone can verify it, and verification is exactly the step MAST says agents are worst at policing themselves.

Why is enterprise integration harder than biology-scale pattern matching?

The deeper issue isn't the model. It's the shape of the systems being asked to connect. Bain & Company argues that the current agent boom risks repeating a mistake enterprise software made from the 1980s through the early 2000s: building sprawling, feature-rich systems instead of clean, callable building blocks. Most companies' business logic and data layers were never designed with the assumption that an agent, or anyone outside the original team, would need to call them through a documented, role-scoped API.

Bain puts a number on the cost of that design debt: roughly $100 billion in enterprise labor is tied up in the manual coordination work between systems, the exact seams agentic AI is supposed to close, and more than 90% of that opportunity remains uncaptured. The genome database Claude searched was designed from the start to be machine-readable at scale. Your ticketing system, inventory service, and billing API almost certainly were not.

Why do 95% of enterprise AI pilots fail to move the P&L?

MIT's Project NANDA studied enterprise generative AI pilots across 150 leader interviews, a 350-employee survey, and 300 public deployments, and found that about 95% fail to deliver measurable P&L impact. The report's core finding is that the bottleneck usually isn't model quality. It's an organizational and integration gap: generic AI tools that never adapt to a company's actual workflows and undocumented context. That's the same gap our small experiment ran into on a three-API test case.

What role do shadow AI and citizen builders play?

Here's the part that matters for how work actually gets done right now. Since agents can't yet reliably wire enterprise APIs unsupervised, employees are doing it themselves, often with no one signing off. Around 98% of organizations now have employees using unsanctioned AI tools, and engineering teams have the highest adoption rate of any department at 79%. Only about 9% of organizations have AI governance systems that actually work in practice, despite a third of executives claiming full oversight. IBM's 2025 breach report found shadow-AI-linked breaches cost $670,000 more on average than standard ones.

That's the honest current state of "AI building enterprise software." It's not agents replacing engineers end to end. It's individual employees, AI-assisted, patching together the same undocumented integrations that agents alone can't finish, usually without anyone in IT knowing it exists.

Should you build or buy internal software with AI right now?

Agentic tools are strong enough now to meaningfully accelerate building your own internal software. They are not strong enough to replace the judgment of someone who actually understands how your business's systems fit together. The failure modes above, weak verification, action-reasoning drift, undocumented business rules, aren't bugs that a bigger model fixes next quarter. They're the direct result of asking a pattern-matcher to guess context that only exists in your company's history.

The practical move isn't to wait for a better model or to hand the keys over blind. It's to treat AI-assisted internal tools the way Bain recommends treating agent-facing systems generally: with clean, documented, role-scoped interfaces rather than black boxes. Giving internal builders that documented, governed layer is better than leaving the work to ad hoc shadow AI. Own the API contracts, own the review process, and let the agent do the drafting under the supervision it deserves. That's a very different posture than assuming the DNA discovery headline means your internal software is about to build itself.

So, can AI build enterprise software?

Yes, for isolated, well-specified components: a single function, a single API call, a scoped feature with a clear spec. No, not yet, for full enterprise systems integration without a human supplying the context that was never written down. The numbers back this up on both sides: agents resolve 72.8% or more of isolated benchmark tasks but only 25% of long-horizon, multi-file work, and just 38.8% of tasks built from real private codebases. Even successful output carries 1.7 times more defects than human code. And 95% of enterprise AI pilots still fail to show up in the P&L, not because the models are weak, but because nobody gave them the context the business runs on. The gap isn't intelligence. It's documentation, and that's a problem companies can actually go fix.