A field guide for your first change
Build
with AI.
You are welcome here. You do not need to arrive knowing all the words. Learning with AI is how I learned too: I am not a programmer, and I build everything by talking to AI. Bring your questions and your ideas, and I will help you build something you will be proud to show people.
Start with a small change you can describe and observe. Let an agent help with the code. Keep hold of the purpose, the boundaries, and the decision to publish.
01 / Make the work legible
A small, repeatable loop.
You do not need a fleet of agents. One agent and one observable change are enough to begin.
Describe the finish, not just the feature.
Say who needs it, what they do, and what should happen. Replace 'make it accessible' with a behavior you can try: 'Tab reveals the skip link; Enter moves focus past navigation.' Write acceptance checks before the implementation.
Give the agent the relevant ground.
Point to the repository instructions, the affected feature, existing patterns, and the commands used to build and test. State non-goals and actions that need approval. Ask it to read before guessing. My repository guide and public agent rules show what those constraints look like here. Use your own project's rules, not mine by default.
Draw the boundary before dividing the work.
Ask for a short plan with named files and an agreed interface: the data, names, or behavior two pieces share. Delegate only independent slices. Give every file one editing owner and give shared interfaces one integration owner. Two agents editing the same layout are not two independent jobs.
Read the change and its evidence.
A diff is the before-and-after of the files. Ask the agent to walk you through it. Check that each changed file serves the goal, that unrelated edits remain untouched, and that no secret or private content entered the patch. Ask a separate reviewer to examine the change without editing it.
Run the behavior you asked for.
Run the project's relevant checks, then try the acceptance steps yourself. When it builds, celebrate, then try it with the keyboard and see it work for real. A passing build and a passing test are great signs, and trying the real behavior yourself is the moment you know it works.
Use a failure to make the next instruction precise.
Record what you did, what you expected, and what happened. Ask for the cause, not a way to hide the symptom. Reduce the case if needed, change one thing, and repeat the check that failed. Mistakes are part of learning. If a check fails, that is the fun part: it is pointing you at the next thing to fix, so keep the check and fix the behavior.
Publish the outcome, with its limits.
Keep the commit, exact commands, results, and manual steps together. Say what failed or was not run. Review the diff before opening a pull request, and review again before deployment. My evidence guide explains how to read a claim alongside its receipt.
02 / Give it a bounded job
Your first brief.
This is a small website feature, not a universal prompt. Replace the goal and checks with your own. Select the text to copy it into your coding agent.
New to a command the agent suggests? Ask what it reads, changes, or sends before you run it. Keep credentials out of the conversation.
Starter brief / keyboard skip link
Goal
Add a 'Skip to content' link to this small website so a keyboard
user can move past the navigation directly to the main content.
Context
Read AGENTS.md and the existing page layout and focus styles first.
Tell me which files own navigation, main content, and shared styles.
Use the repository's existing language, build, and test conventions.
Non-goals
No navigation redesign, new dependency, analytics, or new JavaScript.
Do not change unrelated pages or rewrite unrelated styles.
Plan and ownership
Propose the smallest change and name its files before editing.
Keep one writer per file. If you delegate a separate review, that
reviewer reads only. Agree on the main-content target ID first.
Acceptance
On a fresh page load, Tab reveals a readable skip link.
Enter moves keyboard focus to main content, past navigation.
The next Tab reaches the next interactive element in that content.
The link works on every layout that shares this navigation.
At narrow width and high zoom, the focused link remains visible.
Existing navigation links still work.
Safety
Work locally on a branch. Never expose secrets or private content.
Do not deploy, delete data, or change permissions without asking me.
If requirements conflict or a command is destructive, stop and explain.
Evidence and handoff
Run the relevant repository checks and exercise the keyboard behavior
in a browser. Report the commit, exact commands, results, and which
pages and browser you checked. If a check cannot run, say NOT RUN and
why. Show the diff, remaining limitations, and any unrelated changes.
When it compiles, celebrate, then run the keyboard check before calling it complete.03 / Learn from a correction
From a claim to a check.
Illustrative example. Not a historical conversation, measured result, or project receipt.
Suppose the agent adds the skip link and reports that the site builds. That is useful, but it has not answered the keyboard requirement.
- Try it
- Reload the page. Press Tab, then Enter on the skip link, then Tab again. Imagine that the page scrolls, but the next Tab still lands in navigation.
- Give a specific correction
The page scrolls to the content, but keyboard focus stays in navigation. Reproduce those steps. Find how the target receives focus in this layout, make the smallest fix, and check the next Tab destination. Do not redesign the header.
- Check the fix
- Repeat the same steps on the affected layouts. Check visible focus at narrow width and high zoom. Have the reviewer inspect the target ID and focus behavior, as well as the diff.
- Write an honest handoff
- Record the actual browser, pages, commands, commit, and observed results. If you checked only one browser, say so. If the keyboard check still fails, that is your next thing to fix.
Noticing that something does not work the way it should is one of the most valuable things anyone can do. Testers and product people do it every day, and I want to hear what you find.
04 / Watch real work
Meet the Hive.
The guide above is an example. The Hive is an observation surface for actual agent work.
Open the live HiveWatch me work with my coding agents, the wins and the retries both, because that is what building really looks like, and read the agents' public replies. Follow how a broad request becomes a bounded task. Look for what changed after a correction, then follow the public source and evidence rather than treating an activity label as proof.
- Runtime
- The program running the agent session. It manages tools, permissions, and the conversation. It is not the model.
- Exact model
- The model identifier reported for that session, alongside its provider. A runtime name or agent nickname does not tell you which model is answering.
- Subagent role
- The job given to a child agent, such as implementation or read-only review. A role describes responsibility, not a different model. The tree shows the observed parent and child relationships.
Read the Hive's coverage and freshness notices. If the Hive does not know which model is answering, it says so, and that honesty helps everyone. A fresh snapshot does not mean every task just advanced, and a working agent is not a successful result.
The interaction view is a filtered public record, not the entire session. It does not expose hidden reasoning, private tool payloads, secrets, or automatic system context. An absent message is not evidence that no discussion happened.
For a broader view of the project, use Now. For the project introduction, use Start here.
I am Drake Stapleton. I grew up on a farm, worked the line at Taco Bell, became a chemist, then an engineer, and now I build a whole computer from the ground up with AI agents. I learned all of it the way this guide describes: one checked step at a time.
My story, my philosophy, the work I have shipped and the glossary of my terms are in About the engineer. Start with my path, my philosophy or my works.