- AI prototyping speed has helped one developer ship six distinct projects in roughly a year, from a systems language to a secrets manager CLI.
- Developers using AI prototyping speed consistently report 4x faster time-to-PR, with some tasks shrinking from days to a single afternoon.
- The productivity gains are real, but engineers warn that letting AI do everything risks quietly eroding the technical skills that matter most.
- AI is changing not just how fast engineers build, but how they think — pushing planning and system design to the front of the process.
- AI prototyping speed has helped one developer ship six distinct projects in roughly a year, from a systems language to a secrets manager CLI.
- Developers using AI prototyping speed consistently report 4x faster time-to-PR, with some tasks shrinking from days to a single afternoon.
- The productivity gains are real, but engineers warn that letting AI do everything risks quietly eroding the technical skills that matter most.
- AI is changing not just how fast engineers build, but how they think — pushing planning and system design to the front of the process.
AI Prototyping Speed Is Rewriting the Developer’s Day
AI prototyping speed has become one of the most quietly significant shifts in software development over the past two years — and it’s starting to show up in the numbers. Developer and writer Daryl Cecil recently published a detailed account of how AI tooling has transformed his personal workflow, and the headline figure is hard to ignore: he’s averaging roughly 4x faster time-to-PR on typical engineering tasks compared to before AI agents became a regular part of how he works. That’s not a marketing claim from a vendor. That’s a working engineer tracking his own output, with the caveats and failed experiments counted in.
The broader software industry has been circling this conversation for a while. GitHub’s own research on GitHub Copilot found developers completed tasks up to 55% faster when using AI assistance. Cecil’s self-reported 4x figure sits well beyond that — though it’s worth understanding why. He’s not just using autocomplete. He’s working with AI agents in a more integrated way, offloading scaffolding, boilerplate, and initial implementation drafts entirely. The gains in AI prototyping speed compound quickly when the entire front end of a task — setup, structure, first draft — is handled by an agent.
Six Projects in a Year — and They Actually Run
The proof is in the repositories. Over the past year or so, Cecil has shipped an unusually wide range of personal projects. There’s Sakoa, a programming language he’s designing from scratch, complete with an effect system, three distinct memory modes, and a mid-level IR with multiple backends — the kind of thing that typically takes years of weekend sessions to get off the ground. There’s Kato, a notation language designed to sit between JSON, TOML, and YAML while being explicitly friendly to both human readers and AI agents. Seal is a small CLI tool that sidesteps the .env file entirely by storing secrets in OS-native credential stores. Karabiner is an iOS-first, agent-native messaging app. Plim is a Notion-inspired embeddable block editor with a framework-agnostic core and React bindings.
That’s five named projects, plus a few more he says aren’t ready to be public yet. By his own admission, without AI in the mix, the realistic output would have been closer to three repos with READMEs, a couple of abandoned branches, and one working prototype he’d be quietly pleased about. The gap between those two realities is what AI prototyping speed actually looks like in practice — and it’s a gap that widens the more deliberately a developer learns to work with agents.
It’s Not Just Faster — It’s a Different Kind of Thinking
Here’s the part that gets lost in most productivity-focused coverage of AI tools: the speed increase isn’t the most interesting thing. What Cecil describes as the more significant shift is structural. When you’re not typing every line yourself, you’re forced to operate at a higher level of abstraction. You’re writing specs and prompts that describe what a system should do before it exists. You’re thinking in terms of boundaries and contracts between components rather than implementation details. AI prototyping speed, in other words, changes not just your output rate but your entire mode of engagement with a problem.
That’s a meaningful cognitive shift. It’s closer to how a senior architect thinks about a system than how a developer in the middle of a sprint typically operates. Cecil draws a direct parallel to the skill of delegating to junior engineers — the ability to describe what success looks like clearly enough that someone else can execute without you hovering over their shoulder. As it turns out, that skill transfers directly to working with AI agents. And practising it more deliberately makes you better at the human version too.
This isn’t a universally celebrated development in engineering circles. Some developers worry that rising to the level of “prompt engineer and system designer” means losing touch with the craft of actually building things. Cecil shares that concern and is direct about it: he’s noticed his own technical dexterity slipping when he lets AI handle too much, and he’s actively pushed back against that by carving out time to implement things manually, read source code directly, and sit with a debugger rather than pasting stack traces into a chat window.
The Hidden Cost: Keeping Your Skills Sharp
This tension — between AI prototyping speed and staying genuinely capable as an engineer — is probably the most honest and underreported aspect of the current moment. The tools are good enough now that you can build a working prototype without deeply understanding what you’ve built. That’s useful in some contexts and genuinely dangerous in others. Production systems, security-sensitive code, performance-critical paths — these are places where “it works” and “it’s correct” can be very different things, and where an engineer who hasn’t kept their skills sharp will eventually hit a wall.
Cecil’s approach is deliberate and practical: he treats manual engineering time as something to actively protect, not something that just happens. End-to-end implementations by hand. Source code read rather than summarised. Debugging with actual tools. It’s slower, he acknowledges, and sometimes frustrating. But it’s a hedge against the scenario where the AI isn’t enough and the human in the loop needs to actually know what they’re doing. Relying on AI prototyping speed without maintaining that foundation is, in his view, a long-term liability.
There’s a reasonable argument that this is just the latest version of a debate engineers have had repeatedly — about IDEs, about high-level languages, about frameworks that abstract away complexity. Every generation of tooling raises the floor of what you can build without deep expertise, and every generation produces the same worry about skill atrophy. What’s different this time is the pace and the scope of what’s being abstracted away.
Real-World Impact Beyond Personal Projects
Cecil also points to concrete wins in his day job, though he’s cautious about the details pending appropriate sign-off. Two stand out. First, he’s been able to build and ship automation that directly supports other engineers on his team — a piece of work he describes as genuinely meaningful and something he hopes to write about in depth. Second, he’s managed to cut internal development environment bootstrap times by roughly 50%, which is the kind of infrastructure improvement that quietly multiplies productivity across an entire engineering organisation.
Neither of these, he notes, are things he’d have had the headroom to tackle alongside his core responsibilities a couple of years ago. That’s the compound effect of AI prototyping speed operating at the team and organisational level — it doesn’t just help individuals ship more, it creates the slack that lets engineers take on the higher-leverage work they’d otherwise have to defer indefinitely. Teams that understand how to harness AI prototyping speed at scale tend to find that the benefits are non-linear.
What This Means for the Industry
Cecil’s experience is one data point, and he’s careful to frame it that way. Individual workflows vary enormously, and what works for a developer who’s been deliberately building these habits over a year won’t automatically transfer to a team that just switched on Copilot last month. But the directional signal is consistent with what’s being reported across the industry — from GitHub’s research to Stack Overflow’s annual developer surveys to the hiring decisions being made at companies from early-stage startups to large engineering organisations.
The developers who seem to be getting the most out of AI tools aren’t the ones using them as a faster search engine or a smarter autocomplete. They’re the ones who’ve genuinely changed how they approach engineering work — thinking more carefully about system design upfront, getting better at specifying what they want, and staying sharp enough on the fundamentals to catch what the AI gets wrong. Understanding how to apply AI prototyping speed without losing sight of engineering rigour is the skill that increasingly separates good engineers from great ones in an AI-assisted world. The floor has risen. The ceiling, if anything, has too.
Source: https://darylcecile.net/notes/speed-of-prototyping-age-of-ai
