This post is part of an ongoing series on how LaunchDarkly engineers are closing the loop of the AI SDLC—and what we're learning along the way.
There’s a fantasy version of the software factory that I’ll call the dark factory: The lights are out, agents are doing all the work, and humans are nowhere to be found. It’s a seductive image, but it’s also where most teams get into trouble, because demos typically run on green-field code with clean constraints. The moment you point that fully autonomous dream at a real, load-bearing codebase, it gets confused, chokes, and maybe deletes your repo.
When I went looking for anyone running software factory patterns against enterprise legacy code, I found nothing. That inspired us to point coding agents at our oldest, scariest code and ask a simple question: Can the software factory model actually work where it matters most?
The haunted codebase
The code in question powered our flag-targeting UI, which is the screen that lets customers segment who sees what and when. It’s the heart of what LaunchDarkly does, and it’s also our oldest, most complex, most business-critical frontend. Before we got started, it carried roughly 66,000 lines of React across more than 400 files, as well as lingering Redux and Immutable.JS-era patterns layered on by dozens of people over more than a decade.
Edith, our CEO, jokes that the codebase had become like the Winchester Mystery House: the San Jose mansion where an heiress kept adding rooms onto rooms without a plan. Every time someone tried to wedge a new feature in, it got worse. Not so long ago, a team wanted to change our rollout menu, took one look, and gave up. People were spending weeks on changes that should take an hour, trying and trying and trying.
That’s the kind of system most teams route around, but I couldn’t shake the feeling that this work should have been easy enough for an agent. And a software factory only earns its name if it can run on the parts of the line everyone’s afraid of, which is why we decided to walk straight in.
The bet
The setup was deliberately constrained: two senior engineers, Claude Code, six weeks, and a $10K inference budget. The goal was 100% functional and visual parity, not a redesign.
A few of those constraints were load-bearing:
- No scope creep. I’ve watched “Let’s modernize the UI and also add four features” projects go exactly as badly as you’d expect. The rule here was: Just rewrite it. Rebuild the foundation and leave the experience identical.
- Six weeks, on purpose. Long projects quietly lose momentum. A tight box forces real progress.
- The $10K ceiling was mine, not Edith’s. She’d have happily spent far more if it led to meaningful improvements; I just thought spend was an interesting metric to track.
- Zero customer disruption. The flag-targeting UI is one of the most heavily used surfaces in LaunchDarkly. Parity wasn’t nice to have; it was the whole contract.
Getting the line ready
For anything this ambitious, you need to walk before you run. The year or so before the rewrite is what made the rewrite possible at all, and it’s the part most teams skip when they fixate on the agents and forget the factory floor.
A factory needs a clean, well-instrumented line. For us, that meant genuinely understanding the tooling and its limits, then making the codebase agent-ready. We pulled in context so agents knew how to operate, invested heavily in faster feedback loops, added better guardrails, leaned into agentic code review early, and onboarded Meticulous for visual regression testing. (In my personal opinion, if you do any frontend work, this is the best product I’ve found in years.)
It was immediately clear that whatever makes a human effective—fast builds, fast linting, fast type checks, good context, tight feedback loops, and real guardrails—will also make an agent effective. These things had become more important than ever, but they had also gotten easier, because the agents were there to help us do it. There’s no software factory without that groundwork. The agents are the machines; the feedback loops and guardrails are the line they run on.
The plan vs. the reality
The plan was beautiful: Rewrite 66,000 lines of React in six weeks. In week one, we’d plan. In week two, we’d build a slick autonomous system to crank out the rest. I truly, genuinely believed we’d be done in four.
Spoiler: We did not finish in four weeks. Or six.
Agents are great at scale, and I figured they’d carry us. But even the agents struggled. What saved us was the one asset a legacy rewrite actually has: The old code is ground truth. We pointed agents at the legacy implementation and said, “Extract everything that happens on this targeting view.” The agents would come back, proudly saying, “Great, did it, here you go.” We’d ask, “Can you double-check you got everything?” And they’d respond, “Oh, we missed some. Here’s more.” We ran that loop over and over until we’d wrapped our arms around the real behavior.
By the end of week six, we’d written about 36,000 lines of code, and most of it was generated in under two weeks. We weren’t anywhere close to done.
Remodeling room by room
That was when we stopped chasing the autonomous one-shot and broke the house into rooms. We’d already defined 22 discrete phases, and the mistake was trying to build them continuously and in parallel through one big clever system. We threw that out and went phase by phase. These weren’t small; each was an entire feature in the targeting frontend, comprised of thousands of lines. But at that scale, with a human genuinely in the loop, the same agents that were flailing started shipping.
The 22 phases eventually ballooned to 34 after we found everything we’d skipped. We’ve shipped this work internally—everyone at LaunchDarkly is on the new frontend—but we’re still chasing down small inconsistencies, with customer rollout next.
Final tally: about 39,000 lines of TypeScript and CSS across more than 380 files. And it cost roughly $7K of that $10K budget.
The dark factory is a trap
This is the lesson I most want other engineering leaders to take away, because it cost me the most time. It’s also the whole difference between the dark factory and the healthy AI software factory.
Chasing the dark factory ideal—where agents are fully autonomous and humans are looped out—led directly into what I call the autonomy trap. You end up doing Rube Goldberg development: spending all your time building an elaborate machine, where this agent is checking that agent and this thing is triggering that thing. You’re trying to perfect the contraption instead of getting to the actual goal, and it’s incredibly easy to get sucked into.
These are my two honest, slightly controversial takes from living it:
- Human steering is a force multiplier. I’ve not seen agents make consistently good enough decisions on their own, even with all the upfront context and steering I can throw at them. When I stay in the loop, I get materially better outcomes. That may not be true forever, but it’s certainly true today.
- Friction is signal, not noise. When you’re working—even if you’re agentic pair programming—you can feel where things slow down, and where the agent gets stuck. That feeling is information. If you automate it away entirely, you lose your most reliable instrument.
A healthy AI software factory isn’t a factory with the humans removed. It’s controlled automation, with clear phases, acceptance criteria, validation, and human judgment placed exactly where it has the most leverage.
The control layer is what makes the factory successful
The reason two people could safely rewrite a system 5,000 customers touch daily is that we never let velocity outrun control. We put the entire rewrite behind feature flags, which meant we could shove generated code into the codebase aggressively and still decide, separately and safely, who saw it and when. We ran agentic code review behind every flag as a guardrail, then dogfooded the new frontend internally before any customer touched it. This is the same “release it under guard, measure, then expand” loop we’d use to roll any risky change out progressively and pull it back the instant something regressed.
That loop is the software factory: Change gets flagged, released under guard, measured against the behavior you actually care about, rolled back automatically when it drifts, and cleaned up when it’s proven. The agents generate the work; the control infrastructure is what makes it safe to let them. That’s not a coincidence of how we built this project—it’s the thing LaunchDarkly builds. We were running a small, hand-assembled version of our own software factory on the gnarliest code we have, precisely because if it works there, it works anywhere.
What I’d tell you before you try this
Here are a few more lessons I’m taking forward:
- The key isn’t velocity; it’s ambition. The reason agentic development matters isn’t that we can move faster; it’s that we can attempt more ambitious things than we’d have dared before. In our case, a rewrite that large teams had abandoned became something two people could actually finish.
- Garbage in, garbage out. AI is an intent-amplification machine. Vague intent gives you vague results. It does not replace the thinking you have to do up front; it simply amplifies whatever thinking you bring.
- Bottlenecks don’t vanish; they move. Isolating everything behind a feature flag let us merge freely, but we still wanted the code to be good, which meant we spent a lot of time stuck in the code-review loop. A software factory doesn’t delete bottlenecks; it just relocates them. It’s crucial to build for where they’re going.
- If I did it again, I’d trust the old code more. Even using AI, we started by following a familiar pattern: Write specs, write plans, and do all the intermediate ceremony. Next time, I’d skip most of that and use the existing code as the source of truth. It’s the best spec you could ever have.
One last tell, and it’s my favorite. I knew the rewrite had actually worked when I started mixing up the old version and the new version. I genuinely couldn’t tell them apart anymore, which is exactly what parity is supposed to feel like. It was incredible, and also a little terrifying.
If you’ve shipped anything successful for long enough, chances are you’ve got a haunted codebase of your own. That’s where you should point your software factory first. Running it on the scary code instead of the easy code was the most useful thing we tried all year. I’d love to compare notes.
Join the waitlist for early access to LaunchDarkly tools for the AI software factory.
Edith Harbaugh, CEO and Co-Founder of LaunchDarkly, and Zach Davis, former Principal Engineer, shared more about this project at Enterprise AI Summit 2026.
