DEV Community: Remus Lazar

The Skill I Am Not Sure I Still Have

Remus Lazar — Wed, 07 Oct 2026 13:00:00 +0000

When I was about fourteen I spent my days in a computer club in Romania. Anyone could walk in. CP/M was the new thing, most of us were on 8-bit machines, Sinclair Spectrums and their local clones, and we were there because that was where the computers were.

One of the older members could read machine code. Not assembly, not the mnemonics — the hex. He would look at a dump and tell you what it did. When the club got a new printer we studied the specification and wrote a driver for it, he in Z80 machine code, straight into a hex editor. It worked the first time.

I had not thought about him in thirty years. Lately I think about him a lot, because I have a thought I keep having, usually late in the evening, and it is not a comfortable one. I think I am losing my coding skills.

I want to be precise about which ones, because the obvious version of this worry is wrong. My judgment is not decaying. It is getting more exercise than at any point in my career: what to build, whether the design holds, whether a test protects anything, what can be deleted. That part of me is in better shape than it has ever been.

It is the hands I am worried about.

What I have not done lately

I have not written a controller from an empty file since the spring. I have not spent an evening with a difficult bug and nothing but a debugger and my own head. I have not typed out a migration, a test suite, a client for somebody else's API.

These were things I was good at. Not remarkable, but good, in the way you are good at something you have done several thousand times. And I am fairly sure they decay. Not the knowledge of how, which stays. The fluency: the speed, the sense of what the next line is before you have thought about it, the feel for when something is wrong before you can say why.

In the twelve months of my own history I examined for Two Agents, Not Five, the share of my commits carrying an AI co-author line went from zero in May to over eighty percent in August. That number is a floor, not a measurement, because it only counts the commits where the tool signed its name. The real figure is higher.

Whatever I am, I am no longer the person who types the code.

Why should I keep doing it?

Then the counter-question, which I cannot answer cleanly.

Why should I keep doing something the machine does better? I do not hand-optimise assembly. I do not write my own JSON parser or my own HTTP stack. I have never once regretted not being able to do those things at speed, and I would think it strange if a colleague insisted on keeping the skill up.

Every generation of developers has given up a layer of craft that the previous generation thought was the job. Memory management. Build scripts. Hand-written SQL for every query. In almost every case the trade was worth making, and the people who resisted it were not preserving something important. They were just slower.

Nobody reads hex any more. Nobody needs to. The skill that made him the most impressive person in that room has left the profession entirely, and the profession is fine.

Maybe this is simply that, one layer up. Maybe writing a controller by hand belongs on the list next to manual memory management, a skill it is fine to have mostly forgotten.

Not the mnemonics. The hex.

Why this time might be different

Here is the version of the worry I cannot dismiss.

The thing I would be trading away is the thing I use to judge the output.

I can review AI-written code well precisely because I spent years writing it myself, badly and then better. When I read a generated change and something feels off, that feeling is not analysis. It is pattern recognition, built from thousands of hours of having been the one who wrote it. I know what a wrong abstraction looks like because I have written wrong abstractions and lived with them.

But I have been thinking about what he was actually doing at that club, and it was not typing. He was reading the machine's output directly and reasoning about what it would do, with no mnemonics and no abstraction in between. That is not the skill that became obsolete. That is the skill I use every day now, one layer up, when I open the diff instead of trusting the summary.

The layer he read is gone. The act of reading beneath the layer is the whole job.

But in The Test Data I Did Not Write, even a careful reading of the diff would not have been enough. I also had to question the assumptions against real data. Both kinds of review draw on experience I built while doing the work myself.

So if the skill that makes me a good reviewer is the skill that only writing keeps alive, then letting it go is not giving up a layer of craft. It is giving up the thing that makes the new arrangement safe.

I do not know how fast it decays. Judgment stays sharp for a while after the hands stop. Nobody I have asked knows how long a while is.

What I am trying

I have no rule for this one, and I am suspicious of anyone who says they do. But I have two experiments running.

The first is to write something by hand every so often. Not as a productivity measure, since it is not one, but as a calibration. A small feature, start to finish, no agent. Partly to keep the fluency. Mostly to notice whether the fluency is still there, which I would not otherwise find out until it mattered.

The second is to watch my own reviews. If I start approving changes faster, if the number of things I rename or delete starts falling, if I find myself accepting the summary more often than opening the diff, that is the signal. Not that the code got better. That I stopped being able to tell.

The question I am left with

It is possible that in five years this worry will read like someone at that club insisting everyone should still be able to read hex. It is possible it will read like the last generation that could check the machine's work, wondering out loud whether anyone would replace them.

I do not know which. I know that the second version is the one I would rather be wrong about, and that being wrong about it requires doing something now, while I still have the skill to notice.

If you have an answer, I would like to hear it. This is the one question in this series I could not close.

Originally published on Medium.

The Test Data I Did Not Write

Remus Lazar — Wed, 30 Sep 2026 19:19:22 +0000

In July I was looking at our charging map and saw two pins where there should have been one. Same charging site, a few metres apart, two listings. I zoomed out and found another. Then another.

This should not happen. Our map pulls charging stations from several sources: the German federal register, the roaming networks, Tesla. The same physical site often appears in more than one of them, and a nightly job decides which copy users see. That job had been running for fourteen months. It had been changed twenty times. At the end of May it had been refactored, made faster, made to use less memory, and given its first proper test suite. All tests passed.

The fixture said the operator names match. In 9,269 real pairs, they matched once.

When we measured, a third of the register listings we were showing had a duplicate from another source within a hundred metres.

This is about how that happened, and about what I have changed in how I review code I no longer write myself.

Every change was an improvement

The idea behind the job was simple. Run a series of passes over the data, in order. Each pass asks whether two records share a key, for example the same charger ID, exactly the same coordinates, the same address with the punctuation stripped, the same rounded position and the same operator. If they do, hide the lower-priority copy.

Most of it was written by agents, one pass at a time. Each change was small, readable and reasonable. Each one solved the problem in front of it.

The refactor in May was the most polished of all. The instruction was to consolidate the passes while preserving behaviour, and it did exactly that. It preserved the behaviour. It also wrote fifteen tests, and those tests are where the flaw was hiding.

The tests agreed with the code

In the test fixtures, the register record and the roaming record for the same site carried the same operator name. It is the obvious way to write that test. It is also almost never true.

In the real data, the names matched once in 9,269 pairs of duplicates. The two sources name operators differently: a municipal utility on one side, the company running the charging network on the other. Both are correct. They are never the same string.

One of the tests even asserted the flaw as intended behaviour: records from different companies must never be merged. In the real data, that was nearly every duplicate we had.

Test data that nobody took from reality does not test the concept. It tests whether the code agrees with the assumptions of whoever wrote it. When the same agent writes both, the answer is always yes.

The moment that did not happen

If I had written that test by hand, I would have needed a duplicate pair. I would not have invented one. I would have opened the production mirror and pulled a real one, because that is easier than making one up convincingly. And I would have seen a utility's name on one side, a network operator's on the other, and the pins a few metres apart. The concept would have broken right there, in the fixture, before any code was reviewed.

That is what the slow work used to do for me. Writing the test was not just checking the code. It was the moment the concept first met the data. Nobody scheduled it. It was a side effect of the effort, and when the effort went away, it went with it.

I have to be honest about the rest. The refactor was merged seventy-eight minutes after it was opened, without a review. That is a failure, and it is mine. But I have reread that change since, carefully, and I am not sure I would have caught it. The code is clean. The tests are thorough, well named, and they pass. There is nothing wrong in the diff.

The flaw was never in any diff. It was in an assumption that twenty diffs had inherited. By July, the newest pass carried a comment in capitals: MUST stay last. That is a design telling you something. At the time it read like care.

The fix was also written by an agent

This is not a story about the machine getting it wrong. The replacement was agent-written too. What changed was the question.

"Preserve the behaviour" gets you a better version of whatever you already have, flaw included. "Take a snapshot of production and tell me how many duplicates users can see" gets you a number. The number was a third. From there it took four days to replace the passes with something that matches on distance and street name and does not depend on the order it runs in. Two more corrections followed, and both were found by dry runs against real data.

Same kind of tool, same quality of code. The difference was whether anyone was asking about the outcome or only about the code.

Reviewing the code

I still review every change, and most of how I do it has not changed. I just know now which level it works on.

Small steps. I ask for a plan, then for the first step. A two-thousand-line change cannot be reviewed. It can only be approved. A hundred and fifty lines can be read and argued with in ten minutes. Across the summer, the median change in my repositories stayed at around 35 added lines while the number of changes more than doubled.

Read it where I would have written it. The agent's summary is a claim, not evidence. One of the changes in this story described a functional test suite it did not contain. I open the code in the IDE, follow the calls, run the tests, set a breakpoint.

Attack it. I assume the change is correct and try to prove otherwise: the empty list, the second call, the timeout, the error that is logged and ignored. The attempt is the review.

Rename and delete. If I cannot name something better than the agent did, I do not understand it well enough to approve it. And the generated version of anything is too complete. Something can usually go.

Distrust coverage. For each test I ask whether it would fail if the behaviour I care about broke. If not, it is documentation, not protection.

All of this is worth doing. None of it would have found the duplicates. Small steps kept every change reviewable, and every change was fine. That is the trap: twenty correct steps can carry a wrong idea a long way.

Reviewing the concept

So I have added a second level, and it works on different material.

Where did the test data come from? For anything that models the outside world, I want at least one fixture taken from real data. An invented fixture tests the code. A real one tests the idea.

Measure the outcome, not the algorithm. The refactor was checked against real data, but only through the job's own statistics: how many records each pass touched. They looked fine. They described what the code did, not what users saw. I now ask for one number that describes the result from the outside, and I check it against production.

Read the comments that apologise. "MUST stay last", "workaround", "for now". Each one marks a place where the design pushed back and the code pushed through.

Look at the product. No test found this. I found it by looking at the map. It is the cheapest review there is, and the one I did least.

Where the saved time should go

The agents have given me back a lot of time. So far, most of it has gone into more changes: another step, another feature, another summary accepted because it reads well. That is the easy place for it to go, and I think it is the wrong one.

The time belongs one level up: what the system assumes about the world, where its data comes from, which rule depends on which. That used to be the expensive kind of thinking, and most of us only did it when something was already on fire.

It is also where the tools are strongest, and where I used them least. An agent can read a whole service in minutes and draw it: the data flow, the order of a nightly job, which component trusts which input. Ten minutes with a good diagram tells me more about a design than an hour of reading diffs.

A diagram of the deduplication job would have shown six boxes in a fixed order, each comparing one exact field across sources. Anyone who knows how the register and the roaming networks name their operators would have stopped at the box that compares operator names.

That is the part the agent cannot do. It can draw the picture. It cannot tell that the picture is wrong, because it does not know which names never match, or that a comment in capitals is a warning. That knowledge is what years of building things gives you, and for an experienced developer, having the picture handed over ready to read is a larger gain than the typing we no longer do.

The picture is still a claim, like the summary. It shows what the code does, not whether that fits the world. So I check it the same way: against one real case.

What review is now

I used to think of review as the part after the work. It turns out it was always the part that decided whether the work was any good, and some of it happened while I was writing: in the tests, in the fixtures, in the small resistance of code that did not want to fit.

The machine has taken the writing, and with it that resistance. What it has given back is time, and tools that can show me a whole system in one picture. I can spend that time on more changes. Or I can spend it where the flaw in this story actually lived: in the design, the assumptions, the big picture. That is what experience is for.

So I still try to break the code. But more and more, I spend my time trying to break the idea behind it, before twenty good changes are built on top of it.

Originally published on Medium.

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.