The agentic development factory: AI that works like a team, not a tool
I’ve been working with technology long enough to know where projects succeed and where they quietly fall apart. I know what it looks like when a project goes well, where the friction is, and where good ideas go to die in the gap between a designer, a developer, and a release pipeline. So when I decided to rebuild my blog from scratch, I could have taken the obvious route: open a code editor, ask an AI assistant to help with the tricky bits, and ship it when it looked good enough.
Instead, I ran it like a proper development factory. And what I learned says a lot about where AI is actually heading.
It’s not about prompts, it’s about flow
There’s a lot of noise right now about “prompt engineering”, as if the key to getting value from AI is knowing the magic words. In my experience that’s missing the point entirely. The value isn’t in any single interaction, it’s in how you sequence and connect a series of interactions into something coherent.
Matthew Syed, in Black Box Thinking, talks about how aviation became extraordinarily safe not by finding genius pilots, but by building systems that captured and learned from every small failure. Peter Simmonds, in Little Bets, describes how the best creative work isn’t a single brilliant insight but a series of small experiments that converge on something great. Both ideas apply here. What makes agentic development powerful isn’t one astonishing AI response, it’s the accumulation of many good handoffs, each building on the last.
When I rebuilt ducksource.blog, I had a UX designer working from a real Figma file. I had an architect thinking about long-term structure. I had a DevOps engineer handling deployment. I had myself making the calls that actually mattered: the technology choices, the architecture decisions, what to keep and what to cut. The agents did their jobs. I steered.
The factory in practice
The project started in Figma. I worked through the design, established a visual language, and the results went directly into the build. Not as inspiration or a vague reference, but as the actual specification. The design agent pulled from Figma, understood the intent, and implemented it faithfully. That’s a level of fidelity you simply don’t get when you describe a design in words.
Here’s a good example of how the factory adapts. Figma has an official MCP server, the obvious integration point for pulling design data into an agent workflow. Except it’s restricted to a handful of approved clients, VS Code, Cursor, Claude Code. Blocked. So rather than stopping, we wrote a lightweight wrapper around the Figma REST API and carried on. The design agent got exactly the data it needed, just via a different route. That kind of pragmatic problem-solving, working around an obstacle without drama, is what a good engineer does. It’s also what a well-structured agentic factory does.
From there, the architecture agent took the design and the brief and made the structural decisions: Astro as the framework, Cloudflare Workers for hosting, a static-first approach with room to grow. That wasn’t a guess or a default, it was a reasoned choice based on the specific requirements. When I pushed back on some of those choices in a follow-up, the response wasn’t defensive, it was iterative. The recommendations updated. That’s how a good engineer behaves.
The content migration was the kind of task that’s deeply tedious to do manually, all the frontmatter, images, slugs and metadata that needed to come across correctly. Doing it wrong breaks things in ways you might not notice for weeks. The content agent handled it systematically, flagged the edge cases, and got it done. Not perfect on the first pass, but fixable, and far better than starting from scratch.
You’re in the loop, not out of it
I want to be clear about something, because I think this matters. None of the above happened without me. I chose the technology stack. I decided which posts were worth migrating and which could be left behind. I reviewed every significant output before it went anywhere. I pushed back when something wasn’t right, and I made the final calls.
That’s not a limitation of the current technology, it’s the right way to work. The agents bring capability, I bring judgment. That combination is genuinely more powerful than either alone, and it’s a better dynamic than fighting an autocomplete tool that’s constantly guessing what you want from two lines of context.
This is the bit the “AI will replace developers” narrative gets wrong. The job isn’t writing code, it’s making good decisions about what to build and why. The job of steering the factory is still very much a human one.
Persistent context changes everything
There’s one aspect of this that I don’t think gets enough attention: continuity.
When you use a standard AI assistant in an IDE, each session is essentially stateless. It knows what’s in the current file and what you’ve typed in the current chat. It doesn’t remember that you tried something last week and it didn’t work. It doesn’t have an opinion about whether this week’s idea fits the architecture decisions made last month.
The agents I was working with had memory. They knew what had already been built, what decisions had been made, and why. When a bug surfaced that I’d seen before in a similar context, it got flagged immediately. Not because the model was smarter, but because the context was richer.
That’s the compound effect Simmonds is talking about in Little Bets. Each small iteration adds to a shared understanding, and that understanding is what lets you move fast without making expensive mistakes.
What this means for how teams work
I’m not suggesting everyone needs to rebuild their blog to understand this. But I do think the organisations that figure this out early are going to have a meaningful advantage.
The agentic development factory isn’t a replacement for engineering teams, it’s a force multiplier. A small team with good judgment and the right agentic setup can move at a pace that simply wasn’t achievable before. The bottleneck shifts from “can we build it?” to “what should we build next?”, and that’s a much better problem to have.
The work I described above took a day. A full website, designed from a Figma spec, built on a modern stack, with real content, legal pages, search, tagging and a deployment pipeline. That’s not magic, it’s flow. Specialised agents, clear handoffs, a human making the important calls, and a system that learns as it goes.
If you’re still treating AI as a code autocomplete, you’re leaving most of the value on the table.
ducksource.blog is built on Astro, hosted on Cloudflare Workers, and designed with Figma. The rebuild described in this post was completed in April 2026.