The Translation Layer Is Collapsing
For decades, software orgs followed a predictable pyramid: a small group defining 'why', a slightly larger group defining 'what', and a massive middle layer translating 'what' into 'how'—tickets to PRs, specs to code, status updates to business language. Ajey Gore, a veteran engineering leader, calls this the 'translation pipeline.' He's been arguing for years that the middle was bloated. Now, AI agents are proving him right.
Gore writes: "Most of what we did in the middle was translation... Each step had its own ceremony, its own job title, its own meeting cadence." The frameworks—Agile, SAFe, Spotify model—were all about making translation more efficient. But AI didn't come for job titles. It came for the task type: translation.
What AI Actually Ate
If your job was converting one well-defined input into a well-defined output—natural language to SQL, requirements to code, ticket to PR, log line to incident report—your task got compressed by an order of magnitude. The two ends of the pipeline didn't get cheap. Defining 'why' (strategy) and 'what' (product decisions) is harder because execution costs dropped to near zero. The middle is where most of the org chart lives, and it's getting eaten.
The Manager Who Doesn't Contribute
Engineering managers who exist solely to coordinate translation—run standups, unblock tickets, negotiate priorities, write status updates—face an existential threat. Gore observes two patterns: denial (defending rituals) and shift (managers who started writing code again, designing again, defining again). He writes: "If a manager isn't contributing to the why, the what, or the trust system that holds the how, it's hard to say what they're doing."
The New Team Shape
Gore sketches the emerging org: a small 'why' layer (unchanged), a larger 'what' layer (people who hold context and define 'good'—taste work, judgement work), and a much smaller 'how' layer doing the hardest work: architecture, trust systems, performance, the 5% of codebase agents shouldn't touch. Agents handle the bulk of conversion: writing PRs, updating docs, filing tickets, drafting release notes, reviewing each other's outputs.
Hands-On, Redefined
"The phrase 'hands-on' used to mean writing code," Gore writes. "Now it means being in the work—close enough to see when it's wrong, opinionated enough to define what right looks like." A founder writing prompts that drive an agent's product roadmap is hands-on. A CTO designing the eval suite that gates production deploys is hands-on. A staff engineer specifying contracts an agent must respect when modifying core code is hands-on. None of them may be writing the code. All are in the work.
What This Means If You're Hiring
Gore's blunt advice: "You're going to hire fewer people." Stop writing 2018-style job descriptions. The senior engineer whose pitch is 'I can convert tickets to PRs faster' is in trouble. Hire engineers who can define a harness, hold the line on quality, and design systems an agent can safely operate inside. The standup-runner archetype of engineering manager is over. Hire more 'what' people—those who can hold a thesis, define 'good' in ambiguity, and operate the agent themselves.
What This Means If You're an Engineer
Don't compete with the agent on translation. The agent will win. Pick up the work the agent can't do: define 'correct', build the harness, hold judgement, take responsibility for outcomes. Move toward the 'what' and 'why' without abandoning the 'how'. The middle is dangerous. The work that's left is more interesting and more valuable.
The Org Chart, Finally
The old org chart: why at top, what in middle, how at broad bottom, with manager class running seams. The new shape: why stays, what grows, how shrinks but gets harder. Management layer thins. Coordination collapses. Contribution goes up. Gore concludes: "The shape of the team is changing because the shape of the work is changing, and the work is getting closer to what we always said we wanted—judgement-heavy, hands-on, outcome-owning."
