4x faster, thinking bigger: what AI prototyping actually changes

Daryl Cecile published a personal accounting on Sunday of what a year with AI coding agents has done to his engineering velocity. His headline number: roughly 4x faster on time-to-PR for typical work. But the more interesting claim is about the shape of the work itself, not just its speed.

Cecile, who builds software at GitHub (he refers to a “day job” where he has cut internal codespace bootstrap times by roughly 50%), tracks his output loosely. He is careful to note variance: some days the agent is faster, some days it costs him an hour to undo something “delightfully strange.” The 4x average is a rough self-measure, not a controlled study. But the pattern across his GitHub activity is concrete and worth examining.

Over the past year, Cecile has published repos for Sakoa (a progressive systems language with an effect system and three memory modes), Kato (a notation language designed for both humans and agents), Seal (a CLI that kills the .env file by stashing secrets in OS-native credential stores), Karabiner (an iOS-first agent-native messaging app), and Plim (an embeddable block editor with a framework-agnostic core). He notes that a few years ago that list would have been three repos with READMEs, two abandoned branches, and one working prototype. Now the prototypes exist, they run, and some have tests.

The claim is not that AI wrote those projects. The claim is that AI collapsed the time between “I wonder if” and “oh, it works” to the point where trying an idea is cheaper than discussing it in a document.

The real bottleneck shifted

Cecile’s most useful observation is about what changes when you are not typing every line. “I’m thinking about boundaries, contracts, and how the pieces fit together,” he writes. “I’m writing prompts and specs that describe the system holistically, before the system exists.”

That is the opposite of the common fear that AI coding tools make engineers dumber. Cecile reports that the skill of “describing exactly what success looks like, in a way that a junior engineer (or a model) can act on without you in the room” is the same skill in both directions. He has gotten noticeably better at delegating, to both agents and people, because the abstraction layer forces him to plan before building.

This matches what other engineers in the field have been reporting. Cecile points to Mike McQuaid (Homebrew lead, ex-GitHub engineer of 10 years) and Cassidy Williams (current GitHub engineer) as fellow travelers. McQuaid has written about using sandboxing and git worktrees to parallelize work, framing “more tokens/spend directly translates to more velocity.” Williams has been wiring her Logitech MX Creative Console to control Elgato lights via Copilot CLI, a project that would have been a nonstarter before the bar for “I’ll just build this myself” dropped.

Simon Willison’s broader survey of coding agent capabilities, which Cecile also nods to, reinforces the pattern: the threshold for what constitutes a weekend project has shifted.

The cost of not typing

Cecile is honest about the downside. “The same velocity that makes me productive also means I’m typing less code than I used to,” he writes. He has noticed his own technical dexterity slipping and has started carving out time for manual work deliberately. Implementing something end-to-end by hand. Reading source code instead of asking for a summary. Sitting with a debugger instead of pasting a stack trace into a chat.

This is the tension that every engineer using coding agents faces. The tools are good enough to do most of the work, but the moments where AI is not enough still call for an engineer who actually knows what they are doing. Cecile is explicit that he does not want to make the deal where the tools do everything.

The flip side is that the hours he used to spend on “the unavoidable middle bits of a project” are now freed up for exploration, learning, and prototyping. That is a trade he is happy to make, and it is the same trade that shows up in his GitHub activity. The new repos are not all serious projects. Some will not turn into anything. That is the point.

What this means for AI builders

Cecile’s piece is a personal reflection, not a research paper. It does not claim generalizability. But it is one of the more useful first-person accounts of what a year of sustained agent use actually does to an engineer’s workflow, because it tracks both the benefits and the deliberate countermeasures.

The 4x number is interesting but secondary. The primary signal is that the bottleneck has moved from typing to thinking. Engineers who can describe systems at a higher level of abstraction, who can write prompts and specs that actually capture the shape of the work, will get more out of the tools. Engineers who treat the agents as a black box that writes code for them will find themselves unable to debug the things the agents get wrong.

The industry is still figuring this out in real time, as Cecile notes. The environmental, financial, and social questions have not gone anywhere. But for the engineer who wants to try an idea on a Sunday afternoon, the cost of trying has dropped enough that the default response to “I wonder if” is now a running prototype, not a document.

That is the change worth watching. Not the speed of typing, but the cost of exploration.