AI Saved Him Months of Work. Here's What He Actually Did All Day.
Andreas Kling built an open-source web browser from scratch. Not as a weekend project, but as a multi-year effort with a team of serious engineers. The man knows what difficult technical work looks like.
Last month, he faced a migration that would have taken him several months to complete by hand: porting 25,000 lines of C++ from Ladybird's JavaScript engine into Rust. He did it in two weeks. Zero regressions across 65,000 tests.
He was clear about how that happened: "This was human-directed, not autonomous code generation. I decided what to port, in what order, and what the Rust code should look like. It was hundreds of small prompts, steering the agents where things needed to go."
That sentence deserves a slower read.
Hundreds of small prompts. Steering the agents. All day, every day, for two weeks.
Kling wasn't sitting back watching AI work. He was working the whole time. The difference was that the gap between "deciding what to do" and "seeing it done" had collapsed to almost nothing.
The Distinction That Changes Everything
The popular version of the AI-productivity story goes: "AI did months of work in two weeks." It's accurate in terms of output. But it creates a misleading picture of what actually happened in that room.
The AI didn't decide to port LibJS. The AI didn't choose Rust, set the correctness criteria, design the testing pipeline, or run the adversarial review passes. The AI didn't catch the tradeoffs between idiomatic code and byte-for-byte compatibility. Kling did all of that, every day, across hundreds of small decisions.
What the AI did was execute those decisions instantly, at scale, without fatigue.
Simon Willison, who flagged Kling's post, has been documenting exactly this shift. He's calling the discipline "agentic engineering" and writing a guide on the new practices it requires. His central framing is blunt: "Writing code is cheap now."
Not free, exactly, but close enough to change the calculation on almost everything:
"Many of our engineering habits, at both the macro and micro level, are built around the core constraint that producing a few hundred lines of clean, tested code takes most developers a full day. Coding agents dramatically drop the cost of typing code into the computer, which disrupts so many of our existing intuitions about which trade-offs make sense."
The constraint that shaped how we plan, how we prioritize, how we staff teams, how long we think things should take. That constraint has moved.
The Part That Isn't Cheap
Willison makes a second point that matters just as much as the first.
"Delivering new code has dropped in price to almost free. But delivering good code remains significantly more expensive than that."
He lists what makes code good: it works, it's tested, it handles errors gracefully, it's documented, it's maintainable, it doesn't quietly break future work. The AI can help with most of this. But someone still has to set the standard and verify it was met.
Kling verified it by running two parallel pipelines, C++ and Rust, simultaneously on every piece of JavaScript that went through them. He ran multiple adversarial review passes, asking different models to look for mistakes and bad patterns. He defined correctness as byte-for-byte identical output, not just roughly-working output.
That's what made the zero-regression number real. Not just using AI, but defining what success meant and building the verification to prove it.
What This Looks Like Running Marketing Agents
I run a multi-agent system for content and marketing at Magnified. There's a content strategy agent, an SEO research agent, a thought leader monitor (which is what wrote this article, in fact), and coordination layer that connects them. They work through shared files, pass tasks between themselves, and run without constant supervision.
What I notice is the same pattern Kling described. The agents are fast and reliable on execution: write to a brief, follow a format, hit a word count, apply a framework. Where they stop and flag things is the judgment layer: is this source credible enough? Is this angle too close to what we published last week? Is this finding interesting enough to be worth Derek's time?
That's not a limitation I'm trying to automate away. It's the natural boundary between what agents do reliably and what needs a human.
The directing work is still real work. Kling spent two weeks on it. I spend time on it daily. It just doesn't look like typing code or writing copy. It looks like making hundreds of small decisions about what to build, in what order, to what standard.
What Moves When the Bottleneck Moves
For most businesses in Singapore, the bottleneck in getting things done has been execution capacity. Not enough hours, not enough hands, not enough people who can do the work at the required standard. That's a constraint SMEs here feel acutely, given the cost of talent and how competitive hiring has become.
That bottleneck is shifting. Not entirely gone, but moving. And when the bottleneck moves, everything built around managing the old bottleneck needs to be reconsidered.
Willison puts it this way: "Any time our instinct says 'don't build that, it's not worth the time,' fire off a prompt anyway, in an asynchronous agent session. The worst that can happen is you check ten minutes later and find it wasn't worth the tokens."
The threshold for "worth doing" has changed. If something would take three days manually, it was rarely worth it for a small business unless the return was obvious. If it takes 20 minutes to direct an AI through it, that calculation is different.
This means three practical things for SME leaders.
Your most valuable people are your best directors. The person who can brief clearly, define success criteria, and evaluate output critically is more valuable now than the person who can produce output quickly. These aren't always the same person. Willison notes that one engineer can now be implementing, refactoring, testing, and documenting in multiple places simultaneously. The constraint isn't execution anymore. It's direction quality.
Vague briefs produce vague output at speed. Kling knew exactly what he wanted: byte-for-byte identical output, confirmed by 65,000+ tests, with well-defined interop boundaries between the old and new code. That clarity is what made the AI useful. Without it, he'd have had 25,000 lines of Rust that mostly worked, with no way to prove they worked. Your team's ability to define success precisely is now a direct lever on AI output quality.
The verification step is not optional. The AI shipped zero regressions because Kling built a verification system before he started, not after. The test suites, the parallel pipeline, the adversarial review passes. In business terms: the quality check has to be designed upfront. "I'll review it at the end" is not a system. The teams who get good AI results are the ones who figured out what good looks like before the AI started working.
The Framing Worth Keeping
There's a version of the AI narrative that makes it sound like humans are increasingly watching from the sidelines while AI does the real work. Kling's experience is a useful corrective.
He did months of work in two weeks because he made better decisions faster, with execution overhead removed. He was still the one deciding what to port, in what order, to what standard, verified by what test. The AI gave him leverage. He was still the one applying it.
Willison is documenting this as a discipline worth taking seriously, which I think is right. "Agentic engineering" is not just coding productivity. It's a model for how high-quality complex work gets done when AI handles the implementation layer.
For any business where complex work gets done, the same model applies.
Sources: Andreas Kling, "Ladybird adopts Rust, with help from AI," Ladybird blog, February 23, 2026. Simon Willison, "Writing about Agentic Engineering Patterns" and "Writing code is cheap now," simonwillison.net, February 23, 2026.
Derek runs a multi-agent AI marketing system at Magnified Technologies and writes about practical AI adoption for business leaders and employees.