What AI Changes About Engineering Culture — and What It Should Not

Software development is going through its most visible change in decades. AI assistance has moved from autocomplete to something closer to collaboration: generating implementations, proposing designs, finding defects, writing tests. Anyone leading an engineering organisation is watching output rise and wondering, sensibly, what else is changing underneath.

Having led engineering teams through this transition, I have come to a simple framing: AI changes the economics of producing software. It does not change the economics of being right. Culture needs to follow that distinction.

What to embrace

The productivity is real and leaders should say so plainly. Work that consumed days — scaffolding, migrations, boilerplate, first drafts of tests — compresses dramatically. Small teams reach further. Ideas get prototyped in an afternoon that would once have justified a project plan.

Embracing this means more than permitting tool use. It means redesigning the work: smaller teams with broader scope, faster loops between idea and evidence, and a planning process that assumes exploration is cheap. Treating AI assistance as an individual convenience, rather than an organisational capability, wastes most of its value.

What to protect

Two things must survive the shift, because nothing about the technology provides them. The first is judgment. Generated code is confident by default; whether it is correct, secure and appropriate to the system around it remains a human question. Review is no longer a courtesy stage — it is the job.

The second is ownership. A team must be able to explain what it shipped: why this design, why these trade-offs, what happens under failure. ‘The model wrote it’ is not an account of a system; it is an abdication. The teams that thrive treat AI output the way a good senior engineer treats a capable junior’s work — welcomed, used, and never merged unexamined.

Growing engineers in an AI-assisted world

The most serious cultural question is developmental. If early-career engineers no longer spend years writing routine code, where does judgment come from? It will not arrive by osmosis.

Leaders need to build the practice deliberately: engineers reviewing and critiquing generated work, explaining designs aloud, debugging systems they did not write, framing problems before reaching for a solution. These were always the differentiating skills; AI has simply removed the layer of routine work that used to hide them.

The organisations that get this right will produce a generation of engineers who think at the level of systems and outcomes earlier than any before them. The ones that do not will produce operators of tools they cannot question. The difference between those futures is not the technology. It is leadership.