The Speed of Prototyping in the Age of AI

Sunday 31 May 2026 · 7 min read

Note: This is a reflection on how my workflow has shifted over the past year, not a product pitch. Results will vary.

From “I wonder if…” to “It works”

A few years ago I wrote about my love of throwaway prototypes – those quick proof‑of‑concepts that let an idea leave the mind and become something you can actually run. Back then the biggest bottleneck was me: spending time scaffolding a project, wiring the boring parts, and finally reaching the interesting code.

Fast forward to today. The bottleneck has almost disappeared. AI‑powered coding agents now handle the scaffolding, generate boilerplate, and even suggest the first implementation of a core function. The result is a workflow where the gap between a vague question and a runnable prototype has shrunk from days to minutes.

The new repos that illustrate the shift

If you glance at my recent GitHub activity you’ll see a burst of fresh projects:

• Sakoa – a progressive systems language I’m building from scratch, featuring an effect system, three memory modes, and a MIR with multiple backends.
• Kato – a notation language positioned between JSON, TOML, and YAML, designed to be equally readable by humans and AI agents.
• Seal – a tiny CLI that moves secrets out of .env files and into OS‑native credential stores.
• Karabiner – an iOS‑first, agent‑native messaging app.
• Plim – an embeddable, Notion‑style block editor with a framework‑agnostic core and React bindings.

A few years ago that list would have been three half‑finished repos, a couple of abandoned branches, and a single prototype I was quietly proud of. Now the prototypes exist, they run, many have tests, and a couple are beginning to look like real projects. Not every repo will become a product, and that’s intentional: the ability to try something without a huge upfront cost is valuable in itself.

How AI changes the shape of engineering work

The most surprising effect is not just speed, but the way it forces a different kind of thinking. When I’m not typing every line, I’m spending time on:

• Boundary definition – describing contracts between components before the code exists.
• Prompt engineering – writing specifications that an agent can follow reliably.
• Delegation – deciding what to hand off to a model versus a junior teammate.

These activities feel like a small shift, but they have quietly reshaped my mental model of a project. I now frame problems at a higher level, then let the agent flesh out the details. The skill of “describing exactly what success looks like” becomes the common currency for both humans and models.

Measured productivity gains

I’ve been tracking my own day‑to‑day engineering tasks for curiosity’s sake. Using a rough “time‑to‑PR” metric for typical work items, I’m now averaging about four times faster than before agents were a meaningful part of my workflow. Some days the gain is larger, some days a stray suggestion from the model costs me an hour to unwind – I count those in the average.

The more interesting effect is the expansion of what I’m willing to attempt. Refactors that used to sit in a “nice‑to‑have” column now fit into an afternoon. Experiments that would have required a lengthy design doc become quick side‑projects. The cost of trying has dropped enough that I’m comfortable building things I would previously have debated out of existence.

The hidden trade‑off: staying sharp

Higher velocity also means I write less raw code. To avoid losing technical dexterity, I deliberately carve out time for manual work:

• Building a feature end‑to‑end without assistance.
• Reading source code directly instead of asking the model for a summary.
• Debugging in a traditional IDE rather than pasting a stack trace into a chat.

These sessions are slower and sometimes frustrating, but they keep my mental model of how things work intact. The upside is that the freed‑up time lets me explore, learn, and prototype without guilt.

Impact at my day job

The same speed boost has shown up at work. Without revealing confidential details, I’ve been able to:

• Deliver an automation that now supports other engineers, a piece I plan to write about once I have clearance.
• Reduce internal codespace bootstrap times by roughly 50 % after digging into startup scripts and container images.

Both initiatives would have been “nice ideas” a couple of years ago, but the extra headroom created by AI assistance made them feasible alongside my core responsibilities.

I’m not alone

Several engineers have published similar observations:

• Mike McQuaid (Homebrew lead) explains his sandboxed, git‑worktree‑driven agentic setup, arguing that more token spend translates directly to more velocity.
• Cassidy Williams (Hub) showcases tiny personal projects built with the Copilot CLI, including a setup that maps a Logitech MX Creative Console to Elgato lighting.
• Simon Willison’s Superpowers post surveys what coding agents can accomplish in the wild.

Reading these accounts reinforces the sense that the shift is broader than my own experience.

A balanced view

I remain cautious about the larger picture – environmental costs, financial models, and social implications are still open questions. AI is not magic, and the tools are only as good as the prompts and oversight we provide.

What is clear for me right now is that the day‑to‑day reality feels faster, the scope of what I can attempt is larger, and the space for playful experimentation has expanded dramatically. That combination has made the work feel genuinely enjoyable.

I won’t wrap this up with a tidy conclusion. I’ll keep prototyping, keep digging into the manual bits when I need to, and keep watching what changes and what stays the same.

Until next time… ✌🏽