In early 2025, a group of experienced open-source developers were asked how much faster AI tooling had made them. They estimated 20%. When researchers actually measured it, the same developers were 19% slower.
That gap is the most useful thing I have read about developer productivity in the past two years, and it explains why learning how to manage multiple projects as a developer has almost nothing to do with typing speed. The tools got faster. The days did not.
The numbers nobody wants to look at
The AI productivity story in 2026 is not that the tools are bad. It is that the thing they made cheap was never the bottleneck.
- 93% of developers now use AI tools. Measured productivity gains have flattened at roughly 10%.
- One study found a 741% increase in lines of code produced, and a 20% increase in actual releases. Code went up eleven times faster than shipped software.
- AI-authored pull requests wait 4.6× longer for review than human-written ones.
- 38% of developers say reviewing AI-generated code takes more effort than reviewing a colleague's.
Read those together and a pattern falls out. Generation got cheap. Review, integration and judgement did not, so the work piled up behind the one step that still runs at human speed. Making the fast part faster just grew the queue.
Now put your own week against that. If you are on three projects, the queue is not your only problem.
Where the day actually goes
The cost of running several projects is not spread evenly across them. It sits almost entirely in the moment you switch.
| What it costs | The number |
|---|---|
| Working on two projects instead of one | ~20% of your output |
| Adding a third project | ~40% of your output |
| Regaining focus after one interruption | ~23 minutes |
| Mental residue on complex code abstractions | 30 to 60 minutes |
| Freelancers running 3 to 5 projects | ~8 hours a week, lost to switching alone |
Forty percent is not a tax you can work harder to cover. Two extra hours in the evening does not buy it back, because the hours you lost were your best ones and the hours you added are your worst.
The four methods below all attack the same variable. Not how much you do. How often you switch.
Method 1: Cap your work in progress, and make the cap visible
The fix that changes the most is also the least satisfying: hold fewer things open at once.
Give yourself a hard limit of two items in progress. Not two projects you are responsible for, two items you are actively holding in your head. Everything else is queued, and queued means genuinely not started.
The reason to draw this on a board rather than keep it in your head is that overcommitment is invisible until you can see it. Four cards in a "doing" column is not four things being done. It is four unresolved contexts, each charging you rent.
Two rules make the limit real:
- When the column is full, you do not pull. You finish something or you renegotiate something. Adding is not an option.
- If a card can sit in "doing" for a week, it was too big. Split it by next action, not by component.
That second rule does more work than it looks like. Big cards are the reason people breach their own limits, because a card that cannot be finished today has to be held overnight, and holding it overnight is exactly the cost you were trying to avoid.
Method 2: Block by project, not by task
Most time-blocking advice tells you to schedule tasks. For anyone carrying several projects, that is the wrong unit.
Give a project a half-day or a full day. Not a 45-minute slot after standup and another before lunch. The people who hold multiple client engagements without their delivery falling apart tend to converge on the same shape: fewer, longer, project-shaped blocks.
Then switch at natural boundaries. Lunch, end of day, after a meeting that already broke your focus. A switch that lands mid-flow costs you the full 23 minutes plus the residue. A switch that lands where you had already stopped costs you almost nothing.
This is also the honest answer to the question of how many projects you can carry. It is not a number, it is a division problem. If a project needs a half-day block to move and you have ten half-days in a week, three projects is already tight. Four is a scheduling fiction.
Method 3: Protect one deep block, and put everything shallow behind it
The research on concentrated effort has converged on an uncomfortable ceiling: three to four hours a day is roughly the human maximum for genuinely demanding work. Not the maximum you can be at your desk. The maximum you can do the hard part.
Most developers get nowhere near it, and the reason is usually structural rather than personal. The deep hours get spent on things that did not need them.
So the shape of a day worth defending is simple. One protected block at whatever time your head actually works, aimed at the hardest problem you have. Everything reactive goes behind it: review, Slack, meetings, the small stuff that feels productive and costs nothing to context-switch into because there was no context to begin with.
Put the pipeline work in the deep block. Put the pipeline questions in the afternoon.
One caveat, because this is where the advice usually breaks for anyone on call. If your mornings get taken by things that broke overnight, that is not a discipline problem and no amount of blocking will fix it. That is an automation problem, and it belongs in a different post: scheduling the recurring work so it stops needing you is the actual fix. On the automated AWS pipeline I built for a sales-engagement platform, the point of getting ingestion to run hands-off was never elegance. It was that nobody had to start their day inside it.
Method 4: Point AI at re-entry, not at generation
Here is the part almost nobody is doing, and it follows directly from the numbers at the top.
Everyone is using AI to produce more code. The measurements say that mostly grows the review queue rather than the amount of software that ships. Meanwhile the genuinely expensive thing in a multi-project week, the 23 minutes plus residue you pay every single time you come back to something, is getting no help at all.
That is the gap. Use the tool on the return trip.
Before you leave a project, write a landing note. Not documentation. Four lines, for you, in the repo or wherever you will actually find them:
Where I stopped: worker prefetch is set to 1, retry queue wired but untested
Why: batch of rate-limited records was being hoarded by one consumer
Next action: reproduce with 3 workers, confirm the retry queue drains in order
Open question: does ack-after-confirm still hold if the downstream write times out?Then, when you come back, hand the model your landing note along with the diff since you left, and ask it for the thing you actually need:
Here is where I stopped and what changed since. Reconstruct what I was doing and what I was worried about. Do not write code. Tell me what I need to re-read before I can make the next decision.
That is a different request from "write this function," and it pays off in a place the productivity studies keep pointing at. You are not asking for output. You are asking it to rebuild the mental model you lost, which is the part that was costing you half an hour a switch.
The other habit worth building: re-read the note before you re-enter, not after. Reading it first turns a cold start into a warm one. Diving in and reconstructing as you go is how the twenty-three minutes happens.
I learned the value of writing down where I stopped on a job that took weeks of intermittent attention: re-architecting a verification pipeline that had hit a hard ceiling around 30 to 40 thousand records a day and needed to clear two million. The work was not continuous. It could not be. Every return cost real time until I started leaving myself a way back in, and the notes ended up mattering more than any individual debugging session did.
What this looks like in practice
Four methods is a lot to adopt at once, so this is the order that tends to stick:
| Week | Change | Why this order |
|---|---|---|
| 1 | Landing notes only | Zero scheduling changes needed. Works even if nothing else about your week is under your control. |
| 2 | Add one protected deep block | Small calendar change, immediate payoff. |
| 3 | Move to project-shaped blocks | Needs the deep block habit first or it collapses under meetings. |
| 4 | Enforce the WIP limit | Hardest, because it means saying no to people. Do it last, when you can point at the other three working. |
Start with landing notes. They are the cheapest thing on this list, they need nobody's permission, and they attack the largest single line item in your week.
Frequently asked questions
How many hours a day should a developer code?
Three to four hours of genuinely concentrated work is the realistic daily ceiling, and it is well short of the length of a working day. The rest is not wasted, it just goes to review, meetings, and coordination that do not draw on the same reserve. Measuring yourself against eight hours of deep focus is measuring against something nobody achieves.
Does AI actually make developers more productive?
Less than it feels like. Adoption sits near 93% while measured gains have flattened around 10%, and one controlled study found experienced developers were 19% slower with AI while believing they were 20% faster. The tools genuinely help with generation. The bottleneck for most people is review, integration and rebuilding context, and none of those got cheaper.
How many projects should one developer work on at a time?
One, if you can arrange it. Two is workable. Three is where the measured cost reaches around 40% of your output, which is steep enough that a third project often delivers less than shifting that time onto the first two would have. If you are past three, the honest fix is renegotiating scope, not finding a better system.
How do you pick a project back up without re-reading everything?
Leave yourself a note before you go: where you stopped, why, the next concrete action, and the question you had not answered. Read it before you re-enter rather than diving in and reconstructing as you go. This is also the single best use of an AI assistant in a multi-project week, because summarising a diff and rebuilding your mental model is exactly the kind of work it is good at.
Is context switching really that expensive, or is that just an excuse?
It is measurable. Running two projects instead of one costs roughly 20% of output and a third takes it to about 40%. A single interruption costs around 23 minutes to recover from, and on complex code the mental residue runs 30 to 60 minutes. The cost is real, and it is concentrated in the switch rather than spread across the work.
The part that actually changes your week
None of this is about working more. Every method above reduces the number of times a day you start from cold, because that is where the hours were going in the first place.
If you take one thing: the reason AI has not given you back your day is that it made the cheap part cheaper. Writing code was never what your week was being spent on. Getting back into code you had already left was.
I write about data pipelines and the systems that keep them running, mostly from client work. If you are wrestling with pipelines that break overnight and eat the mornings you meant to spend building, get in touch.
Mirza Hammad Tariq
Data & Automation Engineer with 5+ years on AWS: ETL pipelines, backend APIs and automation workflows in Python, SQL and FastAPI, built to cost less to run.