SUMMARY
Paul Storer-Martin, Mallon’s CTO and a practising instructor since 2002, argues that production readiness has nothing to do with finishing a curriculum. It means a graduate can be trusted as one of the people standing behind a system’s code, understanding it deeply enough to catch what a test suite, and increasingly an AI assistant, will miss.
The Sunday evening before my first day teaching for Mallon in 2002, our founder, David Mallon, sat me down and, in about twenty minutes, distilled the entire Unix process model to its essentials.
I’d been in engineering for eight years by then, and teaching for four of them. I thought I knew this material cold. I’d taught C++ to new hires at Microsoft. I’d taught deep, broad stacks to Tier 1 banks. I was, if I’m honest, pretty confident walking in.
I spent the rest of that week relearning things I thought I’d already understood.
That’s roughly what I mean when a client asks me what “production ready” actually means for a graduate. It has nothing to do with whether someone has finished a curriculum. I was eight years into a career, and I still had more to learn about fundamentals I thought I’d mastered. A graduate who’s finished a training programme is at the very start of that same process, not the end of it.
There’s a view doing the rounds at the moment that’s worth naming directly: that code itself is becoming commoditised, so the detail of what it does, and how, matters less than momentum or throughput. AI writes it faster, the argument goes, so understanding it deeply is a diminishing return.
I don’t accept that, and I’ll go further: I think it’s backwards.
Detail matters. The technical, architectural detail of how everything we write actually executes, including what AI writes on our behalf. Hold an internalised mental model of how things actually run and you can reason more deeply, surfacing issues almost nothing else will catch. A thirty-second glance at code, a colleague’s or a model’s, is enough to see that it is functionally correct, passes every test, and still hides an obvious race hazard.
That’s the safety net we provide when we review a pull request. It’s a responsibility we cannot, and should not, offload to anyone or anything else.
We are the underwriters of every PR we approve.
That’s not a comfortable line to build a graduate programme around, because it means the job isn’t “write code that passes the tests.” It’s “be someone whose sign-off means something.” A graduate who can produce plausible-looking output isn’t production ready by that definition. A graduate who can look at plausible-looking output, theirs or an assistant’s, and tell you why it’s wrong, is.
This isn’t just a personal hill I’m prepared to die on. GitHub’s own Octoverse 2025 research found that 80% of new developers now use an AI coding assistant within their first week, and GitHub’s own guidance to engineering leaders following that finding is blunt: AI doesn’t invent good patterns, it repeats whatever is already in the codebase it’s working in. Good foundations scale. Weak ones get amplified.
GitHub’s recommendation that follows from that is the one I’d underline for any engineering leader reading this: invest in architectural review capacity, because as developers become more productive, senior engineering time becomes more valuable, not less. That is a company with every commercial reason to say its own tooling is sufficient on its own, publishing the opposite conclusion. The underwriting function doesn’t get less important as AI adoption rises. It gets more important, and it needs to start earlier, before a graduate’s habits are set rather than after they need correcting.
A common misconception I hear in client conversations is that engineers only need to learn what they explicitly need for their current job. I think the opposite is true. Breadth deepens understanding.
A student who’s explored C++ smart pointers has no trouble understanding how reachability-based Java references work with garbage collection. A developer who’s seen how argument-dependent lookup works in C++, and why it’s necessary, can understand why some languages have avoided free functions entirely. A developer who knows at least two languages has a frame of reference for critical analysis, and it shows in the quality of their code, and in their ability to underwrite someone else’s.
That’s not an argument for teaching graduates every language they might encounter. It’s an argument against teaching to a single narrow stack and calling it done.
BuiMost buyers ask us how we do things. The question I wish more of them asked is how long it’ll take us to learn how they do things.
Our flagship programmes are built on fidelity. The environment, processes and tooling students learn through are the ones they’ll use when they hit their desks. In our ideal case, we don’t create a facsimile of what they’ll later experience. We run the whole programme in the real thing: real infrastructure, real tools, real entitlements management. Many buyers think that’s ambitious, or unrealistic. Mallon Associates has done exactly this for over thirty years.
Removing the gap between the training room and the real world means real problems occur during the programme, and students get to solve those problems alongside their instructors, before they’re the only person in the room. When they join their teams, they’re far less likely to be adrift waiting for a senior developer’s help when something similar happens again.
There’s a specific moment I watch for that tells me it’s working, and it isn’t a satisfaction score. It’s the first time a student opens with “so that means…”. They haven’t just understood what we’ve discussed; they’ve taken the principles and built their own mental model of the domain. From that point we’re not just teaching, we’re accelerating their own learning. It’s infectious, and the whole cohort invariably responds in kind. The best part for me is that’s typically when I start learning from their perspective too.
If I could change one thing about how banks train graduates today, it would be how they think about retention. The fear is understandable: train someone well and you’ve made them more valuable to your competitors. So the instinct is to keep cohort goals modest. Why over-invest in people who might walk?
That instinct is backwards. Train people poorly and you may reduce their opportunities to leave, so they stay, and they’re less effective for years, or they feel uninspired and leave anyway. You haven’t protected the investment. You’ve hobbled its ability to deliver any return.
Under-training to keep people is the most expensive saving you can make.
A graduate doesn’t become production ready by finishing a course. They become production ready the day you’d trust their sign-off on a pull request, because they understand what it does and why, well enough to catch the thing the tests didn’t.
That’s not a finish line. I was eight years in and still relearning fundamentals from David Mallon on a Sunday evening. The graduates I’m proudest of are the ones still doing that a decade later.
It means being able to understand a system well enough to be trusted with reviewing and standing behind changes to it, not simply having completed a training programme. A production-ready graduate can read unfamiliar code, investigate a problem before escalating it, and recognise when something that passes every test still hides a real issue.
It raises the bar rather than lowering it. GitHub’s own Octoverse 2025 data shows AI assistants reproduce whatever patterns already exist in a codebase rather than inventing better ones, so the human judgement that catches a wrong pattern before it spreads matters more as AI-assisted output increases, not less.
By removing the gap between the training room and the real environment. Mallon’s programmes run on real infrastructure, real tools and real client systems wherever possible, so graduates solve genuine problems alongside a practising instructor before they’re the only person in the room when something goes wrong.
For more than thirty years, Mallon Associates has built graduate and early-careers programmes around real systems, real code, and the environments engineers will actually work in, not a generic curriculum delivered by career trainers.
Every engagement starts with a conversation.
Talk to us about building production-ready graduates.
