DEV Community: Remus Lazar

Two Agents, Not Five

Remus Lazar — Sat, 19 Sep 2026 20:20:06 +0000

AI helped me ship more this summer. Learning to stop has been harder.

Between 15 June and 17 August I committed code on 64 consecutive days. Then I took one day off and started again.

I was bringing ChargEV FleX into production, working across more of the product than I ever had before. The agents were fast, the work was rewarding, and there was always something else I could get done.

For much of that time, it felt like I had finally found a better way to work. Then I looked at when I was doing it.

What became possible

I have been a senior developer for a long time, and I could always work in any part of the stack. What I could not do was work in all of them at once. I had my areas and worked with people who had the others, because a working week only holds so much hands-on coding.

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 I wrote just over a million characters of commit message — roughly twelve hours of reading, if I had ever read it 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.

Your Reader Has a Context Window Too

Remus Lazar — Wed, 09 Sep 2026 16:03:26 +0000

AI made writing cheap. It did not make reading cheap. That gap is where most of my collaboration problems came from this year.

The message that proved his point

A while ago a colleague sent me a message I have been thinking about ever since.

He had counted the characters. His document was about 13,100 characters. My feedback on it was 17,100. So my feedback was 30% longer than the thing it was feedback on, and he found that absurd.

I did what I suspect a lot of people would do. I disagreed, and I explained why at length. I pointed out that resolving ambiguity is genuinely more expensive than creating it. I mentioned that the working session behind those 17,100 characters had produced roughly 126,800 characters of dialogue that I had read and processed, about ten times his original text, and that a raw character comparison therefore said nothing about the actual work.

Every word of that was true. It was also the single worst message I sent all year.

He said the text was too long. I answered with something much longer, about how much text I had produced. I proved his point better than he could have.

The asymmetry nobody planned for

Here is what actually happened to my workflow over the last three years, stated plainly. Producing text went from expensive to nearly free. Consuming text did not change at all.

That is the whole thing. Everything else is a consequence.

I can now take a messy pile of thoughts, structure them, check them for contradictions, get pushback on them, rewrite them three times, and end up with a dense, well-organised document in the time it used to take me to write a rough first draft. My throughput went up by something like an order of magnitude. It is the single biggest productivity change of my working life and I am not giving it back.

I should be honest about one thing, because it would be easy to read this as a story about AI. The long documents were not new. Digging through my Slack history, I found the same argument with a colleague in 2021, two years before any of these tools existed: too much context, too much reasoning, too long to read. I have always written this way. What used to hold it in check was not judgment. It was time. There were only so many hours in which to produce 17,000 characters of feedback, and that limit was quietly doing the reader's flow control for me. AI did not create the problem. It took the brake off a car I had been driving too fast for years.

But the person receiving that document is exactly as fast as they were in 2019. Same eyes, same working memory, same number of hours. Their side of the pipe did not widen by one bit.

We built a 10x transmitter and attached it to an unchanged receiver. In any other engineering context we would immediately recognise what happens next.

Receiver throttling

Both diagrams made with an image model, labels mine.

If you have ever debugged a system where a fast producer feeds a slow consumer, you know the failure modes. The queue grows. Latency climbs. Eventually you either drop messages or the consumer stalls out entirely.

Human collaboration has the same failure modes, and they look like this.

Dropped messages. They skim. They read the first paragraph and the last one. They answer the easiest of your five questions and silently discard the other four.

Growing latency. Your document sits unread for three days, not because it is unimportant but because they cannot find a block of time large enough to process it.

Consumer stall. They stop engaging with your output entirely and start responding in single words. If you have ever had a long, careful message answered with ok, you have seen a stalled consumer.

The mistake I made for a long time was reading these signals as a lack of interest, or as sloppiness. They are not. They are flow control. A slow consumer that starts dropping packets is not being rude. It is protecting itself from a producer that is not respecting the link speed.

The reader's context window

The framing that finally made this click for me was borrowing the language of the models themselves.

A model has a context window: a hard limit on how much it can hold at once. Push past it and things fall out, usually the material in the middle, quietly, without an error message.

People have exactly the same constraint, and we have always known it. What is new is that we now have a vocabulary precise enough to reason about it. But the human version has two properties the model version does not.

First, tokens cost the reader something. For a model, filling the context is billed to whoever runs the inference. For a person, every token is paid in attention, and attention comes out of a fixed daily budget that also has to cover their own work. A colleague once told me that reading my output and catching up on the threads around it consumed roughly half the time he had available for the project that day. I had read that sentence before, but I had not really heard it. Half his day. For input.

Second, and this is the part I got wrong for years:

The window is not the bottleneck. The retrieval is.

The experiment that changed my mind

After the argument about the 30 percent, I rewrote the document. I put a compact decision table at the top, one row per open point. I tagged every point by type. I collapsed all the reasoning behind expandable sections.

I did not delete anything. I added the tagging and the cross-references, which means the new version was longer than the one he had complained about.

His reaction to it was one word: great.

Same content. More characters. Completely different reception.

So it was never the volume. It was the time to first useful token, how long he had to read before he found the thing he actually had to act on. In the first version that was several minutes. In the second it was about ten seconds. The reasoning was still all there, but it had moved from mandatory to available, and that turns out to be the entire difference.

Length is a bad proxy for cost. It is just the only one that is easy to measure, which is why we all reach for it. The real cost is how long until the reader can do something with this.

The compression tax

Which leads to the uncomfortable conclusion, and the reason I now think most AI writing advice is aimed at the wrong problem.

The advice is usually to write less. That is not right, and it is not even achievable, because the volume is a symptom. The right move is to spend part of the time AI saved you on compression, not on more output.

That is a real tax and it is the least fun part of the workflow. Generating a dense, thorough, well-argued document is now the easy half. Deciding what the reader has to do, putting that first, and demoting everything else to optional is the work, and it is work the tools do not do for you, because they do not know your reader.

Five rules, all learned by breaking them

The ask goes in line one. What you need, by when, in what form. Everything else is context, and context is optional by definition.
A reply to criticism must be shorter than the criticism. No exceptions. If I need more than five lines to respond to too long, I am not clarifying, I am defending.
Never cite your own effort. How much work went into it is invisible to the reader and irrelevant to their decision. Mentioning it only invites them to price it.
One message, one open question. A message with five asks gets answered on the easiest one.
The ten second test. Open your own message and look for the action you need. If you cannot find it in ten seconds, restructure, do not just shorten.

The part that is actually hard

There is one more thing, and I do not have a clean rule for it.

The same colleague told me that reading my output felt strange in a way he struggled to name. Not wrong, the content was fine. But the voice was gone. He put it as: text has a personal note the way a voice does, and this one was somebody else's.

He was right, and it was not about the AI producing the sentences. It was that in optimising for structure and density, I had squeezed out every trace of what I actually thought about any of it. The document was correct and it was empty.

The cheap fix, which works better than it has any right to: two or three lines in your own voice on the front. What you think. What you are unsure about. What worries you. Ninety seconds of typing, no tooling, and it turns a report back into a message from a person.

The productivity gain is real. I am ten times faster at producing than I was. But that number is measured at the wrong end of the pipe, and I spent about six months celebrating it before I noticed that nobody at the other end had gotten any faster at receiving.

They still have not. They are not going to.

If you have solved this in your own team, I would genuinely like to hear how. Preferably briefly.