The unit of work for engineers has moved. Did your expectations move with it?

The unit of work for an engineer has moved. Our career ladder¹ had to move with it, and not by adding a checkbox for “uses AI, yes/no.”

I have built career ladders for five companies, and most of them outlived me. This time the ground under a ladder moved while I was still writing it, and none of the old versions would have survived the move.

Start with the smallest piece. Every ladder assumed (still most out there still do) the atomic unit of an engineer’s work was the code behind one ticket: you were handed a well-formed issue, you wrote the code, someone else had scoped it, someone else shipped it, someone else watched it in production. That is gone. About 95% of the code in our backend is generated and we decided from the beginning that we are not going to read most of our code. When a model can write the thing in one sitting, the code stops being the unit worth measuring.

At Integral the unit of work for any engineer is now a whole feature: design it, build it, ship it, roll it out, keep it alive. Not the diff, the feature, end to end. That single move resets every rung underneath it. “Delivers features” used to mean “writes the code for features.” Now it means the person owns the problem, the customer value, and the rewards, and AI is the thing that makes carrying that whole span realistic for one engineer instead of four.

It also resets what a normal day looks like. Integral tests how many things one engineer can carry at the same time. Not multitasking as a virtue, bandwidth as the actual differentiator: how much you can hold without losing focus, and whether you give your focus to the right thing at the right time. We are not happy working with engineers who take one ticket, put their headphones on, and finish it beautifully. Kudos to them, there are plenty of companies who love working with them. That is not us. And I don’t want small kingdoms, where one person is king of one domain and nobody else is allowed to see the whole system. If the only thing that sees the whole system is the AI, that is scary.

This is why velocity stopped being a signal. Shipping a lot of good working code was our proxy for competence, and AI made that proxy free. A free proxy is worthless. Here is the line the ladder is now built on, borrowed from Karpathy: we can offboard thinking/coding, we do not offboard understanding. An agent can produce the plan, the code and the tests. It cannot be accountable for whether the person who shipped it understood the system they shipped into. So the rung that used to reward output now has to ask what you understand and what number your work moves², because the shipping part no longer proves anything.

And it forced a new column onto the ladder: an actual expectation that grows with the level, covering three things.

What you spend, and why. AI is not free. Tokens cost money. We do not have a hard cap on what engineers can spend, but we expect people to know what they are spending and to have a reason for it, like adults. If you want to spend a thousand euros in one day solving one bug, fine, you just have to explain to me why we spent a thousand euros. That is not recklessness, it is how I hand over trust. If nobody can say whether the spend was justified, the accountability defaults to nobody. Same expectation from the other side: if you do something twice, the third time I want to know why we do not have an automation for it.

Fighting the slop. Slop is the confident, plausible, verbose, subtly wrong output that costs nothing to generate and everything to clean up. AI can make any idea, no matter how stupid, look finished: nice charts, five pages of perfect, and somebody reads it and says “yep, that sounds like a good plan,” and ships it. An engineer catches it in their own work, a lead is the slop stopper for their team, a manager builds the system that keeps it down. It leaked past the ladder too: “no AI slop” is now one of our stated engineering values, next to “answer the so-what before you post.” The test I actually use is in person. Come to the whiteboard and explain your stupid idea in five minutes, and I will do the same, and you tell me mine is not smart. If you cannot explain it to me without your AI, then I don’t need you in that loop, I can talk to the model faster and better myself. I don’t need a meat proxy between me and the AIs.

Knowing when to reach for it. At the junior rungs the expectation is blunt: keep the judgment-building friction, do not use AI to skip it. You have to eat the hard problem yourself a few times before you let a model eat it for you, or you never develop the taste to catch the model when it is wrong. This one has a cost, and we say it out loud instead of hiding it: given the choice, I would rather hand a large token budget to an experienced engineer than to a less experienced one, because the experienced one can tell when the output is garbage. The rule we landed on is “learn with AI, not around it,” and it holds at every level. Higher up it flips toward leverage, and a lead who is not building tooling the whole team reuses is leaving the biggest lever of the decade on the floor.

Scaling companies need a map

None of that AI rework matters if you never had a working ladder to begin with. So, briefly, why we bother.

There is a scale book, and everybody can recite it. Four domain teams, four tech leads, two staff engineers, a head of engineering, a head of product, two agile coaches, and you are 40 people, easy. If I ran that play nobody would ask me why. I don’t believe in it. Right now we have two titles, engineering lead and product engineer, and I intend to keep it roughly that way to 25 people. Everybody is a super IC, including the leads, including me.

But a fast-growing company is exactly where a career ladder earns its keep. When you scale quickly, expectations blur out faster than any meeting can fix. The engineer who was obviously senior on an eight-person founding team is now one of twenty, and nobody can say what “senior” accounts for here anymore. You do not fix that with a town hall, because it is not a communication problem. It is the org drifting off the terrain: the map you drew last year no longer matches the ground people walk on every day.

A career ladder is that map. And the map is not the terrain. It is a deliberate simplification you carry so you can find your way when the ground gets confusing, which in a growing company is always. Kept honest, it drags the org back to the ground it actually stands on. Left as a trophy on the wall, it is worse than nothing, because now the drift has your signature on it.

Watch how the blur plays out without one. Two engineers do the same quality of work. One gets promoted, one does not, and nobody involved can tell you why in a sentence. That is the tell. Then it snowballs: people start optimizing for whatever got the last person promoted, which is usually visible output, reviews turn into negotiations, and your best engineers quietly decide the game is unreadable and open other companies’ job posts. It is not a people failure. It is a missing shared definition of the role, and it compounds every time you hire.

The only way the map stays useful is to keep redrawing it. I am not in the business of writing a framework that fits everybody. I am in the business of fixing this company for the next two years, with the people I have. So ours is a living document that takes feedback from the engineers and hires it describes. It is on v0.4 already, public on purpose, and it churns: whole rungs get rewritten between versions when someone points out they measure the wrong thing. We would rather ship a version that is honestly incomplete than sit on a “final” one that quietly lies. A ladder that admits what it does not know is one people trust enough to argue with, and that argument is the health check.

Two structural rules keep ours honest:

• Every skill sits in exactly one place. Go looking for a behaviour and cannot find it? Then it is missing. Say so, and we add it.
• The ladder describes the role; our review cycle with our 4C framework (coming soon) scores the person against it³. It hands out no promotions on its own, and it is not a checklist you fill in to earn the next rung.

Neither rule is clever. Both are the difference between a map that survives a real team and one that gets quietly ignored by Q3. The second one is the one people break, and it is the expensive one: the moment a ladder becomes a checklist, everyone’s world shrinks to the boxes, they stop taking bets, and you have traded real risk for the comfortable feeling of certainty in a business that has none to give.

The takeaway

People keep asking what you add to a career ladder to make it AI-native, as if it were one more competency to bolt on. Wrong question. AI does not add a box to tick. It changes what the boxes are for. It moved the smallest unit of work we measure, from the code to the whole feature, and it forced a new column onto the chart: what you spend, why you spend it, and how hard you fight the slop.

Going AI-native is not about adopting a tool. It means re-opening every definition of “good” you were comfortable with, because the thing that used to prove someone was good, shipping a lot of code, is now the cheapest thing in the building. There is no blueprint for this, and I like that. But the map is not the terrain, and AI just moved the terrain. Redraw the map, or keep scoring people against a world that stopped existing.

Come argue with it.

Footnotes

1. obviously, I did not invent this, and I try to keep mine honest about that. The shape goes back to Google’s engineering levels, then most of us actually adopted the idea after Camille Fournier’s The Manager’s Path, which pins each rung to a distinct unit of work. That is the exact assumption this post argues just broke, so she is due for an update too. I borrow shamelessly, then bend it until it fits Integral. ↩

2. We ask leads to name the metric their work moves. A lead who cannot name the number they are embarrassed (or proud) of is not really owning the outcome. ↩

3. Internally we score people against the ladder on a recurring cycle we call 4C: Competent, Contributing, Compatible, Committed. The ladder is the role; the cycle scores the person against it. ↩