Reading time: 8 minutes | Issue 34 | Book a Call

Happy Tuesday.

"It did a bunch of silly crap."

That was the head of product and engineering at a PE-backed SaaS company describing what happened when his team pointed Claude at their workflows. Fifteen million in annual revenue. Five developers, one QA engineer who's already outpaced, and a domain so specialized that replacing a single senior dev takes six months. They tried AI. The AI tried to help. The AI did not understand what it was looking at.

Microsoft committed $2.5 billion last week to embed engineers inside companies. Amazon committed $1 billion two days before that. Anthropic raised $1.5 billion with Goldman Sachs and Blackstone. OpenAI raised $4 billion. Nine billion dollars in ten weeks, all aimed at the same problem: making AI work inside companies that already exist. I spent last month watching that problem up close with one company, and I now understand exactly why the number is that large.

Inside the Issue

The market is obsessed with greenfield AI. Build something new from scratch, train a model on clean data, ship a product that never existed before. That's the story every conference keynote tells. It's also the story that applies to maybe 20% of the companies I work with.

The other 80% look like this SaaS company. A mature product. A codebase that predates large language models by a decade. Business logic that lives in the heads of engineers who've been there long enough to remember why the exceptions exist. Gartner puts the number at 60-80% of enterprise IT budgets going to maintaining and modernizing existing systems. Seventy percent of Fortune 500 companies still run software that's over twenty years old. DORA's 2026 AI ROI report quantified the gap: AI tools deliver 35-40% productivity gains on simple greenfield tasks, but 10% or less on complex brownfield codebases. A 4x effectiveness gap, hiding in plain sight. The greenfield narrative dominates AI discourse. Brownfield is where the actual engineering happens.

The SaaS company's head of product and engineering owns both the roadmap and the architecture. One person. He can't pause to figure out AI because he's the only one making technical decisions and prioritizing features simultaneously. Nobody on the team owns AI strategy. There's no strategy document. No infrastructure for it. When individual engineers tried AI tools on their own, the results were the "silly crap" he described: code that looked plausible but missed subtle requirements, duplicated logic that already existed elsewhere, and suggestions that violated undocumented business rules.

I've seen this pattern in enough engagements now to name the failure modes.

Failure 1: The review loop is wrong. In greenfield development, the AI workflow is generate, then review. Two steps. In brownfield, the workflow has to be understand, then generate, then verify against existing behavior. That third step is the one most teams skip because it requires knowledge of the system that doesn't live in any document. The METR study ran a randomized controlled trial with experienced open-source developers working on their own repositories, projects they'd contributed to for an average of five years. Those developers were 19% slower with AI tools. They believed they were 20% faster. The 39-percentage-point perception gap exists because brownfield verification is invisible work. The AI generates quickly. The engineer spends the saved time verifying that the generated code doesn't break something the AI couldn't see.

Failure 2: Context is the missing input. This SaaS company runs on manual Excel workflows that nobody has connected to what AI could automate. The engineers don't believe AI can handle their product. The engineering lead told me directly: anyone who can't be evidence-based about AI's role won't be involved in the rollout. I respect that more than blind enthusiasm. Blind enthusiasm is what produces the "silly crap." Skepticism, channeled into evidence-based evaluation with live demos on real problems, is what produces results. We closed this engagement with live code reviews and a live automation demo. Questions shifted from "can you do this?" to "when do we start?" within that session. The evidence changed the conversation. A slide deck would not have.

Failure 3: AI is compounding brownfield debt. GitClear analyzed 623 million code changes from 2023 to 2026. Code duplication is up 81%. Refactoring is down 70%. Legacy maintenance is down 74%. AI tools generate new code instead of reusing what exists. They produce atomic solutions, a passing test, a closed ticket, without consolidating against the existing codebase. For a greenfield project, this might be acceptable. For a brownfield codebase with ten years of accumulated business logic, every duplicated block is a future bug that has to be found and fixed in five places instead of one. Faros AI tracked 22,000 developers across 4,000 teams this year and found what they called Acceleration Whiplash: production incidents per PR tripled, bugs per developer rose 54%, and code churn grew 10x. The finding that should concern brownfield teams most: organizations with strong pre-AI engineering practices saw the same quality degradation as those without. Maturity alone doesn't protect you.

Our read: The $9 billion FDE wave makes sense when you see this pattern from the inside. Microsoft, Amazon, Anthropic, and OpenAI are all spending billions to embed engineers inside companies because the model alone can't solve the brownfield problem. The model doesn't know your architecture. It doesn't know your undocumented business rules. It doesn't know that the exception handler on line 4,200 exists because a client's API returned malformed data once in 2019 and the workaround became permanent. Embedded engineers learn those things. The question for mid-market companies is whether you need 6,000 rotating FDEs or a smaller team that stays long enough to accumulate the context that makes AI productive on your specific system.

Who should be uncomfortable. If your AI strategy assumes you can point a model at your existing codebase and get useful output without first mapping the invisible contracts, you're going to produce expensive silly crap. If your team has tried AI tools and dismissed them because "they don't work on our product," the tools might be fine. Your codebase might not be AI-readable yet. And if nobody on your team can explain the business logic behind your most complex module without looking at the code, you have a context problem that no model, regardless of capability, will solve on its own.

Sources: Limestone Digital engagement data, 2025-2026 | METR: metr.org (RCT, 16 developers, 246 tasks) | GitClear 2026 Maintainability Gap: gitclear.com | Gartner IT Budget Analysis 2026 | Microsoft Frontier Company: geekwire.com (July 2, 2026) | Amazon FDE: cnbc.com (June 30, 2026) | Anthropic JV: cnbc.com (May 4, 2026)

After watching this pattern repeat across multiple engagements, I built a five-question scoring tool we now run before any AI initiative on a mature codebase. Each question maps to one of the brownfield failure modes above. Score yourself honestly. The number tells you whether you're ready for AI or whether you need to do foundation work first.

Question 1: What percentage of your business rules are documented? Not "we have a wiki." Documented means a new engineer could read the docs and understand why the system behaves the way it does without asking someone. In the SaaS engagement, the answer was close to zero. The domain knowledge lived entirely in senior engineers' heads. AI tools pointed at a system with undocumented rules will generate code that violates those rules confidently. If your answer is below 40%, budget time for context extraction before any AI work begins.

Question 2: How many data systems disagree with each other? We've measured this in prior engagements (Issue 11, Issue 13). One client's claims data lived in three systems that contradicted each other 12% of the time. AI can't automate decisions when the underlying data contradicts itself. If your team has to "know which system to trust" for different scenarios, that knowledge is a prerequisite the AI doesn't have.

Question 3: What's the replacement timeline for your most senior engineer? This SaaS company's answer: six months minimum. That replacement timeline is a proxy for context concentration. The longer it takes to replace someone, the more undocumented knowledge they carry. AI amplifies the work of engineers who understand the system. It can't substitute for their understanding. (For a deeper dive on this risk, revisit the key-person audit from Issue 18.)

Question 4: Has your team tried AI tools and dismissed them? If yes, find out why. "It didn't understand our codebase" means your codebase isn't AI-readable, not that AI doesn't work. The distinction matters because the fix is different. The SaaS company's team had dismissed Claude after unguided experiments. When we ran a live demo on an actual hard problem from their codebase with proper context, the reaction shifted in one session.

Question 5: Does your PE sponsor expect results in 30 days or 90? This engagement's PE partner was on every call. His involvement cut the vetting cycle by roughly 60%. The CEO joined the third call in approval mode, not evaluation mode. PE firms in 2026 don't fund 90-day pilots. They fund 30-day sprints. If your timeline is 30 days, you cannot spend the first three weeks making your codebase AI-readable. That work needs to be done, or in progress, before the sprint clock starts.

01  Ford rehired 350 veteran engineers after AI quality tools failed. VP of hardware engineering Charles Poon said it on a press call: "Mistakenly, we thought that by just introducing artificial intelligence and ingesting the design requirements, that would produce a high-quality product." Ford let experienced engineers leave before their knowledge could train the AI. The result: three years and billions in warranty costs. They brought back the "gray beard" engineers, who retrained the AI and rebuilt quality processes. Ford now tops JD Power's 2026 Initial Quality Study for the first time in 16 years. The lesson applies beyond manufacturing: AI without domain expertise produces confident errors.

Source: Bloomberg | TechCrunch | Forbes (June 25-30, 2026)

02  Microsoft Frontier Company launched with $2.5B and 6,000 engineers. Amazon committed $1B two days earlier. Anthropic and OpenAI launched parallel ventures in May. The model makers are all becoming implementation companies. Every one of these ventures is built on the same thesis: the model isn't the bottleneck. Getting AI to work inside an existing business is. That's the brownfield problem with a nine-figure price tag.

Source: GeekWire | CNBC (July 2, 2026)

03  GitClear's 2026 analysis: code duplication up 81%, refactoring down 70% since pre-AI baselines. Across 623 million code changes, AI-assisted development is producing more atomic, duplicated code while legacy maintenance has dropped 74%. AI writes new code instead of reusing what exists. For brownfield codebases, this means AI tools are actively compounding the technical debt they were supposed to reduce.

Source: GitClear / LeadDev (July 2026)

04  Gartner projects 40% of enterprise applications will have embedded AI agents by year-end. Up from less than 5% in 2025. But 74% of AI initiatives are not scaling past pilot. The adoption-value gap is the real story: companies are installing agents faster than they're learning to govern them. Agent governance is becoming the new cybersecurity conversation.

Source: Gartner | Technology Radar July 2026

If the brownfield problem sounds like your codebase, that's what our Step Zero diagnostic was built to quantify. We map your system's invisible contracts, score your context debt, and hand you a remediation plan before any model touches production. Step Zero can end in stop. Sometimes the honest answer is "not yet," and knowing that saves more money than starting anyway. Two diagnostic slots open this month.

Until next Tuesday,

— Mark Ajzenstadt

Founder, Limestone Digital