Adding a contact form to this site would probably have taken me 3 days. With AI, it took an hour.
The hour wasn't spent typing faster. Most of the work in a project like that is a long run of small decisions, and almost all of them have a well-known answer. AI now supplies those answers instantly. What's left are the few decisions that actually need me, and that's where the hour went.
This post is about those decisions: how to spot them, why they matter more than ever, and what that means for how we build software.
Every Project Is a Tree of Forks
Building software is a walk through decisions. Pick a language, and a set of frameworks opens up. Pick a framework, and its choices for storage, testing and deployment open up behind it. Every fork multiplies the futures a project could have.
Take the contact form. This site is pre-rendered to static HTML and served by Cloudflare Pages, so the first question is where a message even goes. After that: how do you stop spam? Which service sends the mail? How do you test it without sending real email? Each answer opens smaller forks of its own, from input limits to what the page shows once the message is sent.
So much of software development has been knowing the most common approach to a known problem. Most forks have a well-trodden branch, and experience meant knowing which one it was. The harder skill was spotting the few forks where the well-trodden branch was wrong.
The Old Cost: Research Before Code
That's what made estimates so hard. An estimate was never really how long the code would take. It was the coding time multiplied by how uncertain the path was:
estimate = coding time × uncertainty
A familiar problem kept the multiplier small. A new one could make the coding the smallest part of the estimate. On a high-uncertainty project, the first few days produced no code at all: they went to researching the possible techniques and finding out which one most people used.
For the contact form, the research list writes itself. How does a static host accept a POST? Which CAPTCHA? Which mail API? How do you keep their keys out of the repository? None of those are hard questions. But answering all of them, then building and testing the result, is how a contact form becomes a 3-day estimate.
The Common Path Is Now Instant
This is where AI makes the biggest difference. At every fork where I just need the most common solution, the answer is there at once, already written.
A project used to mean a thousand tiny decisions, most of them settled by following best practice. In the contact form alone:
- an email of at most 254 characters, a subject of 1 to 200, a message of at most 10,000
- rejecting line breaks in the subject, so nobody can inject email headers
- checking the CAPTCHA on the server before any mail goes out
- returning just the page body to an HTMX request, and the whole page otherwise
None of those needed me. Each has a best practice, and the AI already knows it. The research days all but disappear: the contact form, estimated at 3 days, took an hour.
The Forks That Are Yours
With the small forks handled, my attention goes to the decisions that matter: the ones where I add value. For me they come in three kinds.
Testing the working prototype. Once it runs, does it actually do the job? For the contact form, that meant a preview server that accepts posts only in test mode, so automated browser tests can submit the real form without sending any mail.
Alignment with other systems. Does it fit what it talks to, and what talks to it? This site is static HTML on Cloudflare Pages, so the form posts to a Pages Function that handles /contact and nothing else. The CAPTCHA and the mail service are Cloudflare's own, set up in Terraform alongside the rest of the site's infrastructure.
Plans for the future. Does today's choice leave room for where the project goes next? Only /contact runs code, so every other page stays plain static HTML.
Of the contact form's nine forks, those three needed me. The other six had common answers.
Context Steers the Rest
Even the forks that matter can be augmented with AI. What it takes is getting the right context into the model's context window, efficiently, every time.
For that, I built Mission Control: a project manager that runs on my Mac, with Claude Code built in. It keeps two kinds of context:
- What I'm building. Every project and todo carries its description, plan and notes.
- What I'm building on. Every codebase carries notes that act as Claude's memory of it: its architecture, conventions, gotchas and decisions.
A chat about a todo starts with that context and saves what it learns back as new notes. The same context is available as tools over MCP, so Claude Code in a terminal reads it and adds to it too.
Take one gotcha from this site: the preview server accepts contact submissions only in test mode, and real mail is the Pages Function's job. As a Mission Control note, it would be in every chat about the contact form from the first message.
Context windows are now large enough that, with a reference system like this, the AI builds the right solution most of the time. How Mission Control works is a post of its own.
What Experience Means Now
Experience used to show in the code itself: clear comments, well-chosen method names. AI now goes with something logical there on its own.
Experience now is knowing what context the system needs, and knowing what to look for in a review. Above all, it is spotting the forks in the decision tree, the earlier the better, and adjusting the solution from there.
When I review something like the contact form, my questions aren't about names. Does it post to the right place? Is spam checked before any mail goes out? Can it be tested without sending real email?
A wrong turn caught near the root costs one branch. Caught near the leaves, it costs a whole subtree.
The Decisions That Add Value
The common answers used to cost days of research and a thousand small decisions. Now they arrive in moments. That frees developers to focus on the decisions that truly add value: does it work, does it fit, and where does it go next?
The contact form went from a 3-day estimate to an hour. Three of its forks needed me; the other six had common answers.
For a developer, that means more time on the work only they can do. For a manager, estimates shrink along with the uncertainty. For a director, it means a team whose experience goes where it counts.
The branches that matter were always where the value was. Now there's time to find them.