My ADHD Dev Toolkit That Actually Works
A first-person ADHD workflow for AI coding: boring defaults, reusable prompts, and small rituals that reduce friction and re-entry cost.
Why does my ADHD dev toolkit start with less, not more?
My setup has very little glamour in it. That is the point. On rough afternoons, I want to reopen the repo and know the next move without rebuilding the plan first. When I work with AI every day, the biggest risk is rarely lack of capability. It is the reset cost at the start, drift in the middle, and a fried brain at 5 p.m. deciding whether the next step is tests, prompts, docs, or me staring into the fridge again.
Adult ADHD can affect planning, organisation, time management, and sustained attention (NIMH). I do not need a workflow that assumes perfect momentum. I need one that still works when momentum has packed a bag and left the building.
So my system is built like maintenance, not optimisation. Fewer choices. Fewer resets. More defaults baked into the repo, the editor, and the task itself. The difference shows up fastest when I have been away from a project for a day and the first ten minutes would otherwise disappear into tab-hopping.
What boring tools actually pull the weight?
The useful stuff is deeply unsexy. A pinned markdown file for "now, next, later". Workspace-specific settings in VS Code. A short repo instruction file that tells the model how we work here. Keyboard shortcuts I can hit without thinking. A daily shutdown note so tomorrow-me does not inherit a crime scene.
Copilot guidance is pretty plain about this: better results come from relevant context, narrower prompts, and smaller tasks, not mystical phrasing (Copilot prompt engineering). Repository-level custom instructions help for the same reason. They carry the boring context forward so I do not have to restate the house rules every time (Repository custom instructions).
VS Code supports the same kind of low-friction setup through keyboard shortcuts and workspace-scoped configuration (keyboard shortcuts, workspace configuration). That matters more to me than another shiny app because, for me, the fastest system is usually the one already living inside the project I have open.
| Boring tool | What it does | Why it helps on rough-focus days |
|---|---|---|
| Pinned task note | Holds the current step outside my head | Starting becomes "do line one", not "rebuild the whole plan" |
| Workspace settings | Carries project defaults automatically | Less setup, less rummaging, less drift |
| Repo AI instructions | Narrows prompts before I type | Fewer context dumps and fewer weird detours |
| Keyboard shortcuts | Gets me into commands quickly | Lower activation energy than menu hunting |
| Shutdown note | Leaves breadcrumbs for tomorrow | Cheaper restart when attention is thin |
The hard part is accepting that these tools are not supposed to feel impressive. They are supposed to feel quiet. If I notice the system too much, it usually means I have made it too clever.
How do I stop AI from making context switching worse?
AI can absolutely reduce drag. It can also turn one coding task into six tabs, three speculative refactors, and a little side quest that eats your afternoon. I have done that more than once: I have spent an hour polishing a prompt, then realised I had asked for three jobs and two escape hatches. It feels productive right up until nothing is actually finished.
In procedural tasks, interruptions cost more when they are more complex. Research on procedural work found that complex interruptions increased resumption time and sequence errors (PubMed). Another study modelled recovery as a measurable process rather than an instant snap-back (PubMed).
That is why I try to keep AI inside a lane. One file or one decision at a time. One explicit ask. One visible next step written down before I open chat. I want the model helping me turn the spanner, not grabbing the whole toolbox and throwing it across the shed.
This is also where internal guardrails matter. Our review loops and conventions do a lot of the boring work before taste and judgement kick in, which is the same maintenance-mode instinct behind AI review agents in the content pipeline. Guardrails are not bureaucracy when they save your brain from reloading the same context all day.
What does the smallest useful system look like?
When I rebuild my setup from scratch, I do not build a twelve-part life operating system by Friday. The version that sticks is smaller:
- Write one live task file. Keep a single note open in the repo with
now,next, andlater.Nowgets one item. - Create one project prompt. Add a short reusable instruction block with the repo rules, preferred output style, and what to avoid.
- Use workspace defaults. Save the editor settings, terminal layout, and common commands with the project.
- End the day with a restart line. Leave one sentence for tomorrow that says where you stopped and the next concrete action.
- Cut one source of choice. Remove one app, one board, or one ritual that makes you manage the workflow instead of doing it.
That is enough to feel the difference. On the days I leave a restart line, I spend less time reloading context and more time making the next change. You do not need a cinematic before-and-after montage. You need the first ten minutes of the day to stop punching you in the face.
What helps with late-day decision fatigue without turning into productivity theatre?
I use "decision fatigue" as shorthand because most developers know the feeling. Late in the day, choices get sticky and stupid. I feel it most after lunch, when small choices start taking twice as long. The science is messier than the phrase makes it sound, and recent large-scale field data found no evidence for decision fatigue in that specific healthcare context (PubMed). So I treat it as a practical description, not a sacred theory.
The fix for me is simple: remove choices before I need them. I decide my default editor layout once. I keep a small set of shortcuts. I start from the same task note. I ask the AI for one bounded thing instead of a grand plan for my entire existence.
This is why I like maintenance-mode thinking in general. The boring option often wins because it survives contact with an ordinary Tuesday. That is the muscle behind why we self-host our stack at ZeroLabs. Constraints do useful work when they keep the floor solid.
Both, probably. Plenty of developers without ADHD will get mileage out of fewer open loops, tighter prompts, and stronger defaults. But I built this kit because I personally need a lower-friction way back into the work when attention slips, energy drops, or the shape of the task turns fuzzy halfway through the day.
The catch is that no ADHD system is universal. Some people need more visual structure. Others need body doubling, timers, or environmental changes. My setup leans toward repo-native tools and boring rituals because I want as little distance as possible between "I should start" and actually starting.
Frequently asked questions
- What part of ADHD does this toolkit actually help with?
Mostly task initiation, re-entry after interruption, and the admin overhead around coding. I am trying to reduce the number of times I have to plan the work from scratch, not force myself into perfect focus.
- Which boring tools matter more than fancy productivity systems?
The ones already attached to the work win first: a single task note, workspace defaults, repo instructions for AI, and a shutdown breadcrumb. They beat a complicated stack because they live where the task already lives.
- How do you keep AI coding from increasing context switching instead of reducing it?
I open it with a narrow brief and a visible next step, then keep the scope to one file, one bug, or one decision. If the model starts spraying options everywhere, I stop and rewrite the ask before I keep coding.
- What is the smallest version of this system someone can start with?
One note with
now,next, andlater, plus one reusable AI instruction block for the repo. If you do only those two things, starting gets cheaper immediately.
- Is this workflow for everyone with ADHD?
No. It is my maintenance kit, not a diagnosis in markdown. Borrow the parts that reduce friction for you and leave the rest on the bench.
Start with one file and one rule. Open a task note in the repo. Write the next physical action. Then make your AI prompt smaller than feels necessary.
That is enough to get your hands back on the keyboard. After that, keep the systems that reduce drag and bin the ones that only make you feel organised. If this toolkit only works when you feel sharp, it does not work. It is decorative.
If you want the bigger Maintenance Mode frame, read Maintenance Mode: Why the Best Developers Treat Themselves Like Production Systems and The Decision Tax. They sit next to this piece for a reason.
If this angle is useful, keep going with AI review agents in the content pipeline, Claude Code hooks that replace half your Claude.md, and why we self-host our stack at ZeroLabs.