Engineering excellence in the age of Artificial Intelligence (AI)
Data & AI
Software Development
IT Architecture
In this blog, Linzi Shearer, Head of Capability Development at Opencast, explores how AI is reshaping software engineering and what that means for capability, quality, and accountability. From shifting skill demands to the growing importance of judgement and validation, Linzi sets out why strong engineering fundamentals matter more than ever in an AI-enabled world.
There's a tempting story doing the rounds about AI and software engineering. It goes something like this: AI writes code. AI debugs code. AI ships code. So, the engineer's role compresses, engineering excellence becomes a nice-to-have, and speed wins. Buy the licences, train people on the tools, and you're done.
I think that story has it backwards, and I want to make the case for why.
A note on the perspective I'm writing from: I'm not an engineer. I lead capability development for Opencast's Architecture & Engineering practice. My job is to make sure the way we grow our people keeps pace with how AI is reshaping the work. What follows is what we're learning as we design that framework for a workforce increasingly working alongside AI.
The work we do shapes the standard
Opencast works at the heart of government, healthcare and other sectors where trust matters. Our AI Manifesto starts there, and it does so because the context isn't neutral. We're not shipping marketing automation. We're not building consumer apps. The systems our consultants help clients to design and run are the systems people interact with when they apply for benefits, access health services, deal with the justice system, or pay tax.
That context shapes the standard. Plausible-but-wrong is not a defect we can absorb on behalf of our clients. The cost of getting it wrong falls hardest on the people who need those services most, and who have the least power to push back when things go awry. Working for purposeful organisations means taking that asymmetry seriously.
It's why we've been so deliberate about how we approach AI as an organisation. Our position is "augmentation, not replacement", and we mean it in the strong sense: AI helps the work, our people are accountable for the work, and the human decision remains at the start and end of any AI-supported process.
That's not caution dressed up as principle. It's the only honest position for a B Corp consultancy operating in regulated and public sector delivery.
The version of engineering excellence we're building has to fit that picture.
Why the bar goes up, not down
The optimistic case for AI in software development is that the easy parts of the job get easier. First-draft code, boilerplate, scaffolding, test stubs. That's largely true, and it's a real productivity story when the conditions are right.
What the optimistic case underweights is what happens on the other side. More code is being generated faster than at any point in the industry’s history. The reviewing, validating, integrating, and operating load goes up in proportion. The engineering skills that compound under that pressure are exactly the ones the seductive story says are becoming obsolete.
The evidence is starting to catch up with the intuition. GitClear's analysis of 153 million lines of changed code found that in AI-assisted environments, copy-pasted code is rising sharply while moved and refactored code is declining: a measurable signal of falling code quality at the population level. The DORA 2024 report, looking at AI adoption across software teams, found that perceived productivity rises with AI use, but underlying delivery throughput and stability can fall where engineering practice is weak.
AI exposes engineering practice. It doesn't substitute for it.
The pattern is familiar to anyone who has run delivery for any length of time.
Tools amplify what's already there. Strong engineering practice gets stronger. Weak engineering practice gets faster at producing weak output.
Where engineering attention shifts
What changes in the day-to-day under AI augmentation isn't whether engineering matters. It's where attention must go.
Less time is spent on first-draft code. More time is spent on reading and validating AI output against what the code is actually meant to do, in the context it's actually meant to run in. More time goes on system-level reasoning about how generated code fits the architecture around it. More time goes on the discipline of refusing a plausible-sounding suggestion when it's wrong, which is a harder skill than it sounds when the suggestion looks right.
The failure modes are specific. A function that silently catches an exception it should have surfaced. A refactor that preserves behaviour but breaks the architectural intent. A test suite that passes because the AI shaped the tests to fit the code rather than the requirement. These are the things engineers now have to spot at speed, on code they didn't write.
Test design and review craft stop being a tax on velocity and start being where the value sits. Knowing when not to use AI becomes a first-order capability rather than a footnote.
These shifts don't reduce engineering. They concentrate it.
The skills that compound
Naming all of this in the abstract is easy. Doing something about it takes a serious piece of work, and that's where the capability development side of my role comes in.
Over the last few years, I've supported the development of a new model of capability for Opencast and introduced our first integrated skills taxonomy. What it gives us is a single language for what good looks like across every practice role, and a consistent way to measure what we have against what we need. That baseline now underpins how we hire, how we develop our people, and the career conversations we have with them.
Without a baseline of what good engineering capability looks like in our context, any claim about how AI is changing it would be opinion. What's emerged from this work is that AI-era engineering capability splits into three categories:
Skills that are evolving. Capabilities that already existed and are being reshaped by the presence of AI in the workflow. Code review is the clearest example. It's still code review, but the shape of the work changes when a meaningful proportion of the code arrived without a human author. The skill doesn't go away; it grows new edges.
Skills that are new. Capabilities that didn’t exist in any meaningful sense three years ago. Prompt design as an engineering discipline. Recognising the categories of AI failure mode that don’t show up in standard testing. Reasoning about the security implications of AI-generated code on a client estate. These are now first-class engineering capabilities, and they need to be developed deliberately.
Skills that remain essential. Capabilities that don’t change in nature, but become more load bearing under AI augmentation. Judgement. Ethical reasoning. System thinking. Collaboration with non-engineering colleagues. Communicating clearly with clients about what can and can’t be done responsibly.
These are sometimes called meta-skills, but I'd rather call them what they are: the essential skills that have always distinguished great from good engineers.
This three-way frame is shaping how we hire, how we grow, and how we structure the experiential work that does most of the heavy lifting in capability development.
What this means for clients
The same argument turns outwards. If you're commissioning AI-augmented delivery from any partner, here are the questions worth pressing.
What's your quality bar, and how is AI changing it? Is the partner raising it, holding it, or quietly lowering it? Where does code review accountability sit on AI-assisted work? Who owns the validation step, and what's the practice underneath it? How is the partner growing the new skills, not just providing the tools? And what's their position on where AI output stops and engineering judgement starts?
A partner who has thought this through has clear answers. A partner who hasn't will tell you about adoption rates.
Close
AI doesn't make engineering excellence less important. It makes it the precondition for any AI use worth doing. The version of AI-augmented delivery that's worth buying, and worth being part of, is built on people who are excellent at engineering first, and supported by an organisation that knows what it's growing them into.
That's the standard we're working to.
References
GitClear, Coding on Copilot: AI Code Generation Impact Report, 2024. Available at: gitclear.com
DORA / Google Cloud, State of DevOps Report 2024. Available at: cloud.google.com/devops
OpenPerspectives is our platform for Opencast people to share their thoughts and perspectives on modern digital delivery. It offers practical insight into user-centred design, engineering excellence, product leadership, data-driven decision making and building expert capabilities, grounded in real-world experience.
