Full stack was never a question of skill. It was a question of hours.

With ChargEV FleX, I carried the app, backend, admin interface and infrastructure myself. AI did not give me skills I was missing; it removed the constraint that had always stopped me using all of them together. My job changed. I became the person who orchestrates the work: deciding what to build, specifying it, questioning the approach and reviewing what comes back.

That is a different job, and I like it. It gives my experience more reach. But every agent I add brings more work back to the same person for judgment. I can run more implementations in parallel than I can properly think about.

I kept using the gain to start more.

The hours I would rather not count

Rather than trust my memory of how the summer felt, I pulled a year of my own history: commits, tickets, wiki pages, messages.

In July and August, my commits contained just over a million characters of commit messages — roughly twelve hours of reading, if I had ever read them back. In August alone I added 38 pages to our Confluence wiki, about 33,000 words. Before that, I had written none.

In those same two months, 24% of my commits landed between 22:00 and 03:00. In the ten months before, it had been 10%. Alongside that 64-day streak, the late-night work was harder to celebrate than the extra output.

I had been working with coding agents for about nine months by then, so these figures show how my hours changed, not when the agents arrived. July was also our launch run-up, and my data cannot separate that pressure from the way I was working.

On Saturday 18 July I made 87 commits across four repositories. The first was at seven in the morning, the last just before midnight. Nothing about it felt wrong at the time.

What felt different was how little there was to make me stop.

Waiting for a build, waiting for a colleague, reaching a point where I could not usefully push something further that evening: those pauses used to end my day. Friction was doing more work than I ever gave it credit for.

The agent loop is fast, rewarding and always available. While one task runs, I can start another, and a question becomes a plan with implementation one instruction away. At the peak I had four or five sessions open at once, across ten repositories in a single week.

I kept going, and it felt good, right up until it did not. I felt unusually capable and increasingly certain that the pace was fine.

The pace was not fine. It cost my family time, it cost my team calm, and it cost me sleep. I notice I listed myself last.

The damage I went looking for

The obvious question about all this output is whether any of it was good. I went looking for evidence that it was not.

Most of it is not there. Across 920 merged pull requests, the changes got smaller rather than larger — a median of 180 lines before, 149 after, and half as many commits each. They merged faster: a median of four hours became thirty-two minutes. Fewer were abandoned. Among the repositories that had a build pipeline in both periods, the failure rate stayed flat at about 1.7%.

One number did move: fixes went from 15% of tagged commits to 28%, and a file I had touched became twice as likely to need fixing within a fortnight. But those are also the months we went into production, and I am not going to pretend I can separate the two.

What I did find was somewhere else entirely.

In twelve months, across those 920 merged pull requests, a human being other than me left a review on thirteen of them. Not thirteen percent. Thirteen.

My first reaction was that review had collapsed under the volume. It had not. The reviews happened — over my shoulder, in Slack threads, in calls. My own happens earlier still, while the change is being built: reading the diff as it forms, pushing back, asking for the simpler version. By the time a pull request exists it has already been reviewed. It arrives as a result, not a request.

And that is a consequence of the pace. Review went where it could keep up: a comment thread on a pull request takes a day, a message in Slack takes a minute, and at two hundred commits a week only one of those fits.

Which is mostly fine, and it is faster. But it means the review leaves no trace. No comment thread, no requested change, no second name on anything. If my judgment starts slipping, there is nothing in the record that would show it — not to my team, and not to me.

The pause I kept filling

At EV Freaks we are a handful of people. In July and August I sent about 1,300 Slack messages a month, up from under 300 — and our main work channel barely grew. The extra volume went into channels that had not existed in June. My ability to produce work had outrun our ability to absorb it, and the overflow was not even landing where the team could see it.

In those two months I closed as many Jira tickets as in the previous ten, and I had written most of them myself. Every feature still needed somebody else to understand it and make decisions about it. That cost was easy to miss while I was looking at what I could build next.

Shipping a feature is not the end of its cost. It needs to be lived with: played with, questioned, refined once you have watched someone use it. That interval used to come for free, because building the next thing took long enough to provide it. Now I have to leave room for it deliberately, and five features can land in a week without any of them getting the week it needs.

This was the part I had not anticipated. Parallelism could exhaust the team and remove the pause in which a feature gets good.

I was filling that pause with more work.

The desk I could not see

I am pedantic about physical space. A messy desk stops me working. I clear it before I start, not after, and I have been like that my whole life.

It took me most of the summer to notice I had been running the digital equivalent.

I work from three machines: an iMac at home for the days I am not in the office, a Mac at the office, and a MacBook for the commute and the couch. All three had agent sessions open. Not running — open. Paused somewhere in the middle, waiting for a decision I had not made yet.

A session I have not closed is not a paused task. It is a piece of attention that stays allocated. Spread across three machines, I was carrying unfinished conversations I could not see, because nothing in that setup ever looks untidy.

The limits I am trying now

I need boundaries that hold even when the next task looks easy. These are the four I am trying to keep.

1. Two agents in parallel. Three at the absolute most.

That is a limit on my attention. Each agent creates work I have to understand, and opening another task does not give me more capacity to do that.

While an agent runs, I can read its reasoning and review the changes as they form. Or I can make a coffee and let it run without me. The waiting time is the point.

2. Leave a gap between the plan and implementation.

I take the plan to the couch on an iPad and read it away from the keyboard. No “start implementation” in the same sitting.

Then I come back with questions, push back, refine the scope and read it again. That second pass is where I decide whether the plan deserves to be built, before I get caught up watching it happen.

It also gives the work a stopping point. The plan can be finished for today without the implementation having started.

3. Close the session when the work is done.

One session per task, grouped by the work it belongs to — which also keeps the token cost down. When a piece of work is finished, a summary goes into my notes or the project wiki, and the session gets archived.

The part that changed most is that I now limit the sessions I postpone, not only the ones I run at once. When something has to wait, it is almost always better to write the summary, archive the session and open a task for the follow-up. A task is something I will find again. An open session on a machine I am not sitting at is not.

4. Take the day off.

The productivity gain can buy time with my kids. It can buy an evening away from the MacBook. I have to choose that use of it, because the tools will happily help me fill the time with more features.

This is the boundary that matters beyond the work itself. The other three help me manage my attention while I am working. This one requires me to stop.

A month in

I would like to end by telling you I worked this out in June and have been living well ever since. My own history says otherwise.

The correction is only about a month old. Through the summer, the number of repositories I touched on an average working day kept climbing — 1.9 in June, 2.6 in July, 2.8 in August — while I was telling myself I had it under control. My pace has come down since, and the last week of August brought my first multi-day break since June.

So I do not know yet whether these rules will hold. I know why I need them. I want the extra capacity to leave room — for my team, for the things we have already built to settle, and for my family.

Ask me again in six months. I will have the chart either way.