What AI Changes for Engineering Managers
A lot of the conversations now are debating which AI coding assistant to adopt: Claude Code? Codex? OpenCode? and how do you measure the difference. These are real questions, but I think they hide a bigger question of how the whole management of software production is supposed to change in the AI age. What’s the role of Engineering Managers, what’s the role of a CTO?
The act of writing code (always seen as “the constraint”) is subject to a drastic acceleration that will become more evident every month that passes. When we look at the whole production of software the constraints are now moving to how we manage our knowledge so that it can be fed to LLMs, to our ability to write specifications, and most importantly, to our judgment: how we evaluate the development work in the broader context of our software production philosophy.
These are not the only core competencies Engineering Managers will need to master in the age of AI. For instance, there is also a lot to say about AI governance; so much, in fact, that I will defer to another post to talk about that.
Specification Literacy Is A Management Competency
I would argue that writing good specifications has always been a required core competence of Engineering Managers, but the reality is that the popularization of the Product Manager role (first in the early 2000s in Silicon Valley and soon after elsewhere) has somehow ended up outsourcing the whole task to other roles.
I think Specification-Driven Development definitely swings back the balance towards Engineering Managers. Being able to describe clearly and completely a product construct with the necessary level of technical details in a way that an agent can execute it without many rounds of clarification is going to be the key differentiator. We have always relied on humans who could fill gaps through inference and conversations, and on (sometimes multiple levels of) “refinement sessions” to translate a product requirement into a workable specification. But as the development (as in “coding”) cost reduces, the relative cost of writing specifications will increase, and it will be natural to look at ways of improving it.
Of course this is not a new problem. Ambiguous documentation is often the cause of project delays and of production defects. What is new is the velocity of change. AI creates new selection pressure, an organisations that previously survived on informal human interpretation cannot do so at AI execution speed. What was a mostly hidden cost becomes visible and existential, and the gap between managers who can write precise, unambiguous specs and those who cannot will be extremely visible.
The practical implication for Engineering Managers is that writing specifications that are complete from a product point of view, aligned with the system architecture, accurate from a technical point of view and thoughtful of all edge cases is now a management-layer responsibility.
Actively Managing Documentation Quality and Format
As long as I have been in the industry (26 years and counting) we have always grudgingly tolerated incomplete, ambiguous, and stale internal documentation because somehow it was of “some” value for humans, who would hopefully spot old information, resolve contradictions through conversationss with colleagues and double check the important points. The system worked, imperfectly but acceptably.
LLMs consume documentation much more literally than humans, and have trouble reliably making sense of contradicting information, generating code against a stale document with the same confidence they bring to a current one. While there is no notable example yet of documentation quality becoming a disaster, the clock is ticking, with AI compressing the timeline.
Another dimension that most engineering leaders have not yet considered is the distinction between human-consumable and LLM-consumable documentation. What’s the difference between documentation written for a human reader and documentation written to be queried by an LLM? And which one is more useful? As we are (or will be soon) searching for internal documentation via LLM and not our intranet search engine anymore, I think the answer is clear and that the format and properties of the documentation are changing. And with that, the realization that documentation quality is no longer an aspiration or a technical debt item at the bottom of the backlog, but becomes a risk to monitor and manage.
Judgment is the Scarcest Skill
The word I see more frequently nowadays in AI coding debates is “judgement”. It is a word I like, maybe because I think that, as humans, we might still have an edge on that. For a long time we have hired and measured engineers on their knowledge of programming languages, on their ability to translate specifications into code, carving out separate definitions (senior/staff Engineer, Architect) for candidates with a wider range of skills. However these complementary skills (knowledge of SDLC best practices, cloud infrastructure, testing, software design to name a few) become central when working with AI coding tools that are still short-sighted and lacking the full context of how the company operates and what the medium and long term evolution plans of our systems are.
On some level, I think this will be a long standing limitation of AI coding tools. No matter how much we document, and how well we document, there will always be some context that escapes an AI tool. We don’t pursue certain design choices because of some old technical debt; we don’t change some API formats that are obviously incorrect because some existing customers rely on them being “incorrect”; some services are split in counter-intuitive ways because of how our organization was shaped years ago (Conway’s law).
As the code gets produced faster, Engineers at all levels must develop judgement. Must be able to analyze the code produced not only for its correctness, but most importantly for its alignment with all the industry, company and department best practices, processes and policies. Similarly the Engineering Manager’s job is shifting. It is no longer enough to verify that work gets done; it is to ensure that every engineer carries this judgment, that they can sense when an implicit decision has been made by our favourite AI tool and decide whether it should stand or not. Similarly engineering interviews need to weight architectural reasoning, constraint identification, and systems-level judgment far more than code production.
What This Means for our Everyday Work
These three shifts (specification ownership, documentation quality, judgment) are all examples of cases where AI makes existing management failures more visible, and more consequential. These are not new categories of failures at all, but they become quantitatively and qualitatively more serious.
Adopting AI tools does not create any value by itself. It creates value only when the organization is able to change to use it in the most effective way. Engineering Managers and CTOs who accept the challenge of changing in the next twelve months will be the ones who have understood that their job has shifted. It has moved from managing execution to owning the full process. The ones who treat AI adoption as a tooling question will find themselves managing the consequences.