First Principles
The limiting factor was never writing the code
Mark Herschberg, Chief Technology Officer at Stynt, on why generating ten thousand lines of code was never the bottleneck, what accountability does to the cost of review, and the early signal on who’s struggling that he says he still can’t get.
Mark Herschberg
Chief Technology Officer, Stynt
What this conversation is about
A board asks why the team isn’t shipping ten thousand lines of code a day, given that AI can produce that in an hour. Mark Herschberg — CTO of Stynt, and an instructor at MIT — says it can, and so can he. But if he is being held responsible for the bugs, he now has to read ten thousand lines. Then he names the thing the whole argument turns on. The limiting factor was never writing the code. It was understanding and reviewing it.
That reframes what has actually happened. If generation was never the constraint, then making generation faster cannot produce the gain being claimed for it. It can only move work onto the constraint that was there all along — which is where a great deal of the pressure on senior engineers is now arriving from, without anyone having planned for it or counted it.
His closing answer is about a signal he does not have. He would like to see how quickly people pick up new tools and concepts, because at present you find out from the outcome, by which point they have been struggling for a while. It is worth asking what actually makes someone slow to learn a new tool. Acquiring a new pattern is expensive; running one you already know is cheap. When there is no spare capacity, people fall back on what they can already do — not out of resistance, and not because they are less able. The signal he wants would read as learning speed. Much of the time it would be measuring how much someone has left.
Three things to take from this
1.
Accelerating the wrong step doesn’t speed anything up.
If review was always the bottleneck, generating code faster moves the queue rather than shortening it. Before you count an AI rollout as a gain, work out where the constraint actually sat beforehand. Most teams have never measured that, which is why the promised numbers keep failing to appear.
2.
Accountability is what makes review expensive.
Mark’s point is not that the output is bad. It is that someone remains answerable for it. The moment a person’s name is attached to the bugs, the volume they must genuinely understand becomes the real workload, and it scales with everything the machine produces.
3.
Slow to learn usually means short on room.
When someone lags on a new tool, the instinct is to read it as aptitude or willingness. Learning costs more than executing, so it is the first thing to be cut when someone is at capacity. If several people on a team are suddenly slow to pick things up, that is a signal about the environment rather than about them.
“The limiting factor was never writing the code, it was understanding and reviewing the code.”
— Mark Herschberg
Host’s note — Dharma Ramasamy
Twelve conversations in, nearly every leader I have asked has described the same relocation: producing got cheaper, checking did not, and the difference landed on senior people. Mark is the first to explain why it was always going to happen. If the constraint was never generation, then speeding up generation could only ever push work onto the constraint that already existed. The surprise was never in the outcome. It was in how many people expected something else.
What interests me more is his closing answer, because I think the signal he wants would tell him something other than what he is asking. He would like to know how quickly people pick up new tools. But learning is metabolically expensive in a way that executing a known skill is not — it needs working memory, tolerance for being briefly incompetent, and the willingness to be slower today in exchange for being faster later. All three require spare capacity. Under sustained load, all three are withdrawn first, and the person retreats to what they can already do well. From the outside this looks exactly like resistance, or like a slower learner.
So the honest version of his question is not who learns fastest. It is who currently has room. If one person on a team has gone slow on new tooling, that may well be about them. If several have, at the same time, the environment is the finding.
Be on the series.
Ten minutes, two cameras, nothing to prepare, and you see the edit before it publishes.
Get in touch →Who still has room.
Mark wants an earlier signal on who is struggling, rather than learning it from the outcome months later. That signal exists — it just isn’t a measure of ability. Reading where the capacity has gone, while there is still time to act on it, is the work I do.
How the diagnostic works →