The Carrier Wave

For a decade, engineering teams relied on something they did not know they were relying on: the cost of building. It kept them slow enough to stay aligned. In early 2026, that cost disappeared.

The feeling arrives before anything else does. It arrives in February, on a Tuesday afternoon, in the quiet minute after Kabir Joshi merges his own pull request.

He is twenty-two years old. Eight months into his first job. He has just shipped a webhook retry handler — exponential backoff, a dead-letter queue, a replay endpoint for the ops team — wired into the billing service’s Stripe integration. Three months ago it would have taken him three weeks. It took him three hours. He wrote the prompt. The agent wrote the code. He read the diff, ran the integration eval against a recorded-traffic replay of last Tuesday’s webhook storm, watched it pass, pushed to staging, merged. His tech lead is at a dentist’s appointment. Nobody is going to review this before it reaches production. He stares at the green checkmark on the merge and waits for something to happen inside him that does not happen.

He has been told, in some form, every semester of college, that this is the feeling he was working toward. The feeling has not arrived.

He orders lunch at his desk. A burrito bowl from the place on the corner. He eats it at his desk, looking at Slack, where nobody has said anything about his feature, because nobody knows it has shipped. He goes back to his backlog. He picks up the next ticket. The agent is ready.

I spent four months inside a company where this was happening. I am not naming it, not because the story is sensitive but because it is not particular. Every engineer I spoke to outside this company recognized it immediately. The details would be different. The shape would not.

This is how it begins — not with a crisis, not with a missed quarter, not with an incident. Just with a young engineer who has done good work and does not know why it feels like nothing. Multiply Kabir across the hundred and twenty engineers on the engineering floor. Multiply him across the industry. Nothing is broken. That is what makes it hard to see. The system still works. It just no longer aligns.

Something shifted at the turn of the year. Nobody is entirely sure what — some combination of model capability, agent harness, tooling around them, the particular month when the pieces finally fit. The teams noticed it first as a productivity surge. Individual engineers were producing at rates that would have seemed absurd in November.

And then the other thing started. The teams began to lose track of themselves — quietly, not all at once, and in ways that at first nobody connected.

Two squads will discover, in the same week of March, that they have built solutions to the same problem. A principal engineer will ship a migration in three hours and feel less proud than when it used to take three weeks. A manager will no longer be able to tell, from what she sees on GitHub, who on her team is doing the most important work. A junior engineer, eight months in, will produce impressive pull requests and be unable to explain why the system is designed the way it is.

Priya Ramanathan is thirty-one. Principal engineer. She spent her twenties at a well-known AI lab before joining this company two years ago. In her kitchen on a Saturday morning in early March, over ginger tea, she tells me a story about the year she was twenty-four.

She had spent two days debugging a memory leak with a senior engineer at the lab — two full days, pair-programming, hunched over one screen. A gRPC streaming client was holding on to one protobuf arena per dropped connection. In a dev environment it was invisible. On a training cluster that cycled preemptible workers every few minutes, it ate a gigabyte a day and crashed the parameter server on the third evening of every long run. The leak was in a vendored library nobody at the company had written. The fix, once they found it, was eleven lines. The two days were not about the eleven lines. The two days were when she learned how he thought. How he narrowed. What he reached for first. What he did when he was stuck — which was, she remembers, to stop typing and start reading the allocator’s source. She can name, now, a dozen habits of mind she absorbed in those forty-eight hours that have shaped every system she has built since.

“That couldn’t happen now,” she says.

“Why not?”

“Because the leak would have been found in an hour. The fix would have been written by an agent. He would have reviewed the PR from his phone and stamped it. I would have shipped fine. And I would have learned nothing.”

She is quiet for a moment. She refills her cup. The steam rises slowly and neither of us says anything. When she picks the conversation back up, she does not pick it up where she left it.

“I still talk to him,” she says. “He is at Google now. I do not think he knows what he taught me. I do not think he would describe those two days the way I just described them. He would say we fixed a memory leak.”

She uses agents more aggressively than anyone else on her team. She is the reason her team uses them as aggressively as it does. But she is also the only person I have found in the building who can articulate what has been lost in the last few months, and she is trying, in a way she cannot quite name yet, to rebuild some part of it before it is gone for good.

Her diagnosis, when she finally offers it — much later, after she has told me two more stories I am not including here — is this: collaboration used to work because work was slow. Every ritual — the PR, the RFC, the design doc, the standup, the pair-debug — assumed a particular tempo. The tempo was never the point. The tempo was the carrier wave. The alignment rode on top of it.

The carrier wave is gone. Individuals with agents now move faster than the coordination mechanisms that used to hold teams together. The mechanisms have not been replaced. They have been hollowed out over a matter of weeks. The PR still exists; it is just no longer where decisions get made. The standup still happens; it is just that a day’s work does not fit in a day anymore.

Coordination was never designed. It was subsidized — by the slowness that has now been removed.

The two auth services are discovered on a Monday morning in March. A production incident exposes them — small, customer-invisible, but sharp enough that a postmortem is required. Two squads have, over the preceding six weeks, independently built the same service-to-service auth layer: short-lived JWTs, a key-rotation protocol with a ten-minute overlap window, a small in-memory revocation cache. One squad needed it in front of the billing service. The other needed it in front of the feature-flag service. The incident is a token one squad issued that the other squad’s cache had never heard of, because their clock-skew tolerances differ by four seconds. Neither team knew the other’s work existed. Both services pass their tests. Both were written mostly by agents, across perhaps forty hours of engineer time each.

Ananya Sengupta is the manager who has to write the postmortem. She is twenty-seven, six direct reports, three years into her first management role. I sit in her corner of the office on Tuesday evening while she writes it. She has a notebook open beside her laptop, and the notebook is more interesting than the screen — she has drawn a timeline of the six weeks, two parallel lines that never touch, annotated with the names of engineers who sat twelve feet apart the entire time.

She does not frame the incident as a communication failure. She writes it as an economic event.

“Last year,” she says, not looking up from the notebook, “two engineers on different teams could each spend six weeks on the same problem and we would call it a disaster. Because six weeks is a quarter of somebody’s year. Now they can each spend forty hours on the same problem and we do not even find out for six months.” She taps the two parallel lines. “The cost used to catch it. The cost was the coordination mechanism. We did not know that then.”

She saves the draft. She does not send it yet. She stares at the parallel lines for a while.

What the two teams needed was thirty minutes of conversation before either of them started — thirty minutes that, in November, they would never have scheduled, because the RFC process was doing that work for them. Nobody writes an RFC for forty hours of work.

Vikram Shetty, the CTO and co-founder, reads the postmortem on Wednesday morning. He is thirty-eight, built the company with two others four years ago. He draws a different conclusion. He sees a process failure that can be solved with a tool — a cross-team search, a duplication-detector, something.

Ananya sees a tempo failure that cannot be solved with any tool because the tool is downstream of the mechanism that is missing.

The Slack thread between them runs for most of Wednesday. It is long, and polite. Ananya sends me screenshots of it later, and the thing that strikes me is how carefully they are talking past each other. Vikram keeps proposing solutions. Ananya keeps describing the problem. They are both precise. They are not having the same conversation, and they do not realize it until much later, if they ever do.

Rohan Mehta has been a staff engineer for four years. He has a standing desk in the corner of the third floor, near the window, and an unusual number of browser tabs open at all times. He is the person on the team the juniors go to when they are stuck — or he was, until recently.

A PR with four thousand lines of diff — a refactor that pulls the notification pipeline out of the monolith and into its own service, with a new queue, a new retry contract, and a migration for forty-odd call sites — lands in his review queue on a Thursday in late March. He stamps it in nine minutes. He tells me the next week that he stopped reading somewhere around the queue adapter. He is not proud of this. He is also not going to do it differently tomorrow. The volume queued up behind that PR is larger than his working week. If he read every diff at the depth he used to, he would review three of the week’s forty.

This is not a review failure. It is a volume failure. Rohan has not become a worse reviewer. The ratio has changed underneath him.

The PR ships on Friday. Two weeks later, a production bug is traced back to a single line inside it: the retry policy on the new queue had been loosened from three attempts to ten, and the jitter floor pulled down from two hundred milliseconds to twenty. On a normal day it made the flaky downstream look healthier. On a day when that downstream briefly stalled, it made forty thousand concurrent retries hit a cold cache at the same instant. The agent had walked through the trade-off at the time — a careful argument about the p99 latency of the flaky dependency, with a caveat about thundering-herd risk buried three turns later — in a chat conversation with the author. The author cannot find the conversation. He has had seventy conversations with agents in the two weeks between. He is not sure which of the seventy it was in. The reasoning is gone. Not deleted — just buried in a place nobody will look.

I sit with Rohan the following week, after the bug has been traced and fixed. He is eating lunch at his desk — a habit, I have noticed, that nearly every engineer in this building shares, and that none of them seem to enjoy.

“I used to teach through review,” he says. “Not on purpose. It just happened. You read someone’s code slowly, and you see the place where they almost got it right, and you leave a comment, and they come back with a question, and by the end of the thread you have both understood something you did not understand before.”

He looks at his review queue. It has eleven items in it.

“I can’t teach anyone anymore,” he says. “I can approve. I can’t teach.”

I ask him if the juniors notice.

“They don’t know what they’re not getting,” he says. “That is the thing about this. The absence is invisible to the person who would have benefited from the thing that is absent.”

Ananya has been going to the same café every Sunday afternoon for eleven weeks, since the first week of January, when she began to feel she could no longer answer basic questions about what her team was doing.

She is working on a document nobody asked her to write. It is, when I first see it in late March, forty-three pages long. She shows it to me with a kind of embarrassed pride, the way you show someone a project you have been working on alone for too long. It is a careful, stubborn description of what her team is actually doing, week by week. Not what they are reporting. What they are doing.

She has written it because her 1:1s have stopped telling her what she needs to know. The engineers come in, report status, leave. What they say is true. It is not what she needs. What she needs is what they were deciding, and the decisions have moved into places she cannot see — chat histories with agents, PRs that shipped before she heard about them, conversations in channels she is not in because nobody remembered to add her.

“I can tell you what shipped,” she says. “I cannot tell you why it was built that way. I used to be able to tell you that.”

She can no longer evaluate, from GitHub, who on her team is doing the most important work. The engineer who spent a day curating context, writing evals, and shepherding an agent through a gnarly problem looks indistinguishable from the engineer who vibe-coded a throwaway. Both have a PR merged. Both say the right things at standup. One of them is doing the work that will determine whether her team is still here in two years. She cannot, on most days, tell which one.

She shows the document to Priya in the first week of April. Priya reads it overnight. She texts Ananya at six in the morning: Can we talk before standup?

And then there is Kabir.

Kabir ships his feature on a Tuesday in February, feels the hollow where the pride used to be, and carries the feeling for weeks without being able to name it. He does not bring it up in his 1:1s. He does not mention it to his college group chat, which is where he is most honest and also least honest, because everyone in the group is having the same experience and none of them are discussing it. They post screenshots of things they have shipped. The screenshots have become more impressive and the feeling behind them has become thinner and nobody talks about the gap.

In March, Kabir’s days take on a particular rhythm. He arrives, opens his laptop, picks a ticket, talks to the agent, reviews what the agent produces, ships it, picks another ticket. Some days he ships three things. He is, by any measure the company tracks, having the best quarter of his short career. His manager tells him this in a 1:1, and he says thank you, and means it, and feels nothing.

He starts leaving the office earlier than he used to. Not because the work is done — the backlog is bottomless — but because by four in the afternoon he has run out of whatever it is that makes him want to be here. He takes the bus home and reads on his phone and does not think about what he shipped. He could not, if you asked him on the bus, reconstruct the reasoning behind the second PR of the day. He merged it four hours ago.

The specific thing Kabir is feeling is what Priya will later have a name for. I didn’t really write this — the agent did. The engineer who shipped a feature in three hours feels less pride than when they shipped it in three weeks, even if the outcome is better. Craft identity was built on struggle, and removing the struggle removes the identity marker. You cannot argue an engineer out of this feeling. It is a legitimate response to a real change.

But that shift is weeks away for Kabir. In February and March he only knows that the thing he came here to do does not feel like the thing he is doing.

What replaces the old rituals is not another ritual. It is a different architecture of how teams work. Priya has been describing this to me for weeks before she says it cleanly, on a walk one evening in early April, after a long day. We are on the street outside the office, in the noise of evening traffic, and she has been quiet for two blocks.

Three shifts follow from the death of the carrier wave, she says.

The first: Intent over Implementation. Pre-agents, you aligned on code because code was expensive. Now, code is cheap and plans are expensive. The coordination artifact shifts from the PR to the decision about what to build. That alignment has to happen before the code, not after, because after is too late — the code already exists.

The second: Contracts over Context. When humans cannot keep each other in context fast enough, machine-readable interfaces have to carry the coordination weight. Typed APIs, capability declarations, schema registries, compatibility checks in CI. The contract is the coordination. Agents on both sides respect it, and humans inherit the discipline.

The third: Curation over Review. EMs and TLs stop being the PR bottleneck and start owning the shared substrate — surfacing conflicts before they happen, curating team-level context, deciding what does not get built. The manager’s value is no longer in reading every diff. It is in making sure the team is building the right things and knows what each other is building.

She says all three in one breath, past the evening traffic, without making them sound like a framework. I write them down on my phone while she walks ahead. When I catch up she is talking about something else.

A friend of mine — staff engineer at a different company — read an early version of this and pushed back. Every generation of engineers, he said, has some version of this complaint. Senior engineers have been saying juniors do not learn fundamentals since the invention of the IDE. The compiler hid the assembly. Stack Overflow hid the docs. Autocomplete hid the function signature. Each wave produced the same anxiety; most of the anxieties did not come true.

He is not wrong about the pattern. What I cannot make fit inside the pattern is the ratio. Every earlier wave sped up a step — typing, lookup, compiling — without changing the unit of work. A function still took time. A PR still took time. A team could still keep pace with its own members. What has moved this time is not the speed of writing. It is the speed of writing relative to the speed of coordination. The first number has jumped by roughly an order of magnitude in a quarter. The second has not moved at all.

Ananya begins in the second week of April. She does not announce what she is doing. She does not propose a process overhaul. She starts with one thing.

The first thing she builds is what she calls a team capability manifest. One YAML file per team, checked into the monorepo at a well-known path. What the team owns, down to the service and schema. What it exposes — endpoints, message types, the version guarantees on each. What it depends on, pinned to minor version. What it is deprecating, and by when. A pull request that changes a field the manifest marks stable, or drops a version another team’s manifest depends on, now fails CI before a human sees it. It takes four engineers eleven days to produce the first version. Three of those days are spent arguing about what the team actually owns, because nobody has ever written it down. Half the engineers forget to update it for the first two weeks, until the CI check starts red-lighting their merges.

The second thing, which grows out of the first, is a set of team-level context files — an AGENTS.md pattern, at the organization level, the team level, and the session level. Every engineer’s agent reads the team’s context before acting. It is also the artifact that finally makes Ananya’s own job legible again — an engineer who contributes to the context file is visibly contributing to the team in a way GitHub does not measure.

The third is an intent forum. Fifteen minutes, once a week, every team declares what it is starting that week, not what it finished. The first time it runs, nobody takes it seriously. Two engineers phone it in with vague one-liners. The second time, it prevents a duplicated week of work. After that, attendance is no longer a problem.

The fourth is decision records as agent output. Any change touching a shared contract requires a one-page rationale. The agent produces the first draft as part of the work — not after. The engineer reviews and signs it. Most of the records are short. All of them are findable. Some of them are bad — pro-forma, rubber-stamped, the engineer clearly not reading what the agent wrote. But even the bad ones leave a trail that the old process did not.

And two more: a shared eval harness — golden traces of the cross-service interactions that matter, extended by whichever team is touching the contract, so a change to the auth service’s token format runs against the billing service’s consumer tests before it merges; and a weekly conflict review — managers only, no status, conflicts only.

The manifests worked. The evals worked. The intent forum worked. The one thing that still did not work was deciding what not to build. The mechanisms could surface conflicts and prevent duplication — but the question of which work mattered most, which bets to kill early, which agents to point at which problems — that had just moved up a level. Ananya could see it clearly. She did not yet have a mechanism for it.

The thing Ananya cannot build with infrastructure is the mentorship loop. That one has to be rebuilt explicitly and with humans in the room. She and Priya pair once a week now. Priya and Kabir pair for two hours every morning. The pairings are not mentorship in the old sense. They are something new, with agents in the loop, where the senior engineer is teaching not how to write code but how to hold a problem, and the junior engineer is teaching the senior what the new tools make possible.

The first time Kabir and Priya pair, she asks him to walk her through a PR he shipped the previous week. He cannot. Not because the code is bad — it is fine — but because the decisions that shaped it were made in a conversation with an agent that he cannot reconstruct. She does not tell him this is a problem. She asks him to pair with her on the next one, live, with the agent in the room and both of them watching. By the third session, Kabir is narrating his reasoning out loud as he works. He tells me later that this felt strange at first, like talking to himself. Then it felt like the most natural thing in the world.

And then there is the part of this that is not solvable with infrastructure at all.

Priya says it to me one evening in mid-April, on the same walk where she first articulated the three shifts. We are at the same stretch of street. The traffic is lighter this time.

“The mechanics are the easy part,” she says. “The motivation is not. If that part is not addressed honestly, the best engineers quietly disengage and the whole effort fails in a way that looks like adoption issues but is actually a values mismatch.”

She has been thinking about this as three separate feelings that leaders often conflate.

The first is what she calls dilution of ownership. I didn’t really write this — the agent did. You cannot argue engineers out of it. You have to shift what ownership means. Ownership is not “I typed these characters.” It is “I am accountable for this outcome, I understand this system deeply enough to debug it at 2 a.m., and I made the judgment calls that shaped it.” When someone demos work now, Priya asks a specific question: what did the agent try to do that you stopped it from doing, and why. The first time she asked, the engineer needed almost a full silent minute to find an example. He has an answer ready now. So does everyone else who has sat through that question once. That is the craft now.

The second is legibility of contribution. Two engineers ship the same feature. One took thirty prompts and three failed evals to get there. The other got lucky on the first try. GitHub cannot tell the difference. Decision records, eval contributions, context contributions — these make the difference visible. If the performance rubric still rewards “ships features” without distinguishing between “ships features on a well-lit path” and “built the well-lit path others ship on,” you systematically demotivate the engineers you most need.

The third is unequal payoff. The engineers who invest in the shared substrate — the context files, the capability manifests, the eval harnesses — do the highest-leverage work on the team. If they are rewarded the same as the feature-crankers, rational engineers stop doing it after one cycle. When someone’s work prevents three teams from hitting the same bug, Priya has started saying so, out loud, in the all-hands. The first time she did it, the engineer she named — a quiet backend developer who had written most of the eval harness over two weekends — did not know she had noticed. He told me afterwards that the moment changed something for him. He had been thinking about leaving.

There is a deeper thing underneath the three feelings, and Priya says it to me only once, after I have turned the recorder off. We are sitting on a bench outside the office. It is late. She is tired.

Some engineers here are not worried about recognition, she says. They are worried that the job they loved is going away. The person who became an engineer because they loved writing code is watching the writing-code part get automated. This is not paranoid. It is accurate. And it has happened in the span of a single quarter.

The honest response is not “don’t worry, your job is safe.” It is: “the job is changing, here is what the new version looks like, and here is why it is still worth doing.” Taste, judgment, system design, debugging under uncertainty, deciding what not to build — these are more important now, not less. But you have to say it out loud, repeatedly, and show it in how you reward people. Otherwise the defaults fill in the vacuum.

She is quiet for a while.

“Culture gets set from the top,” she says. “And the window to set it is narrow. Roughly the next two review cycles. After that, the norms calcify around whoever got rewarded in the meantime.”

Vikram, when Priya brings this to him in mid-April, is not unsympathetic. He is also running a company. He has a release to ship by end of month. A competitor shipped something similar three weeks ago and the board has asked him twice about the timeline. He left a company he loved to start this one. He has not taken a vacation in fourteen months. The thing Priya is asking him to prioritize is real, and he knows it, and it is not the thing that will kill the company this quarter.

If the release slips, none of this matters. If the culture slips, everything does. He is choosing the one he can measure. He will be rewarded for the release. He will not be punished for the culture.

He commits to changing the performance review rubric before the mid-year cycle. The calendar keeps arriving. The review cycle will come whether or not the rubric has changed. And the defaults do not wait.

I am writing this in late April. The story is not finished. It cannot be, because the thing that produced it is four months old.

Ananya’s document is no longer a document. It is becoming a set of templates, checked in, which parts of the team have started to use without knowing she wrote them. Priya is running a weekly session with Kabir and two other engineers, teaching something she has started calling decision craft. Kabir, at eight months in, can answer questions about the authentication service that he could not have answered in February. The questions he can answer have nothing to do with authentication.

Kabir, the last time we spoke, told me something I want to end on. He said that the hollow feeling he had in February is mostly gone. I asked him what replaced it. He thought about it for a long time.

“I know what I decided this week,” he said. “I know why. If someone asked me tomorrow what I built, I could tell them, and I could also tell them the three things the agent wanted to build that I refused, and why. That is not the same as the feeling I thought I was coming here for. But it is a feeling. And I think it is the one that is going to last.”

He looked at his screen, which had a green checkmark on it. He did not stare at the checkmark. He closed the laptop, and went home.

What grew in its place was smaller, slower, and visible in a way the old thing had not been. Nobody could mistake it for free.

The carrier wave did not come back. They built something else on top of the silence.