Let's be honest, writing code has never been cheaper. Describe a task, hand over enough context, and AI will produce an implementation that would have taken hours not so long ago. It'll explain that dusty piece of code nobody wants to touch, dig into a failing test and weigh up a few possible solutions while it's at it. Truth be told, it still feels a bit like magic.
The thing I keep tripping over is the gap between finishing a task and making a good engineering decision. A task can be perfectly correct inside its own little box and still drive the whole system in the wrong direction. That gap is where a term has started to make sense to me: AI reliability engineering. I'm using it for the work that makes AI-assisted changes dependable: pointing the work in the right direction, making sure the knowledge that matters actually reaches it, checking the decisions it makes, and learning from whatever happens next. It's still a working idea, and I want to figure it out through the work itself rather than on a whiteboard.
The map is not the road
Think of AI as the best satnav you've ever owned. It knows every street, it works out the route in a second, and it's very confident about it. What it doesn't know is that the off-ramp you need has been closed all week, or that the pothole on the corner has already eaten three tyres this year. The locals know that stuff, but nobody ever told the map.
Engineering decisions work the same way. A direct database call, an API or a background process could each solve the same problem, and which one fits depends on the system, the operational constraints, the team and what's likely coming next. AI can reason through those options really well, but only with the information that actually reached it.
Maybe another team is about to need the exact same capability. Maybe a similar integration previously fell over under load. Maybe that weird bit of code that looks like a mistake exists because an external provider doesn't behave the way its documentation says it does. Any one of those can flip the decision completely, and while some of them are written down somewhere, others live in someone's head, a chat from months ago or an incident the team has nearly forgotten about. That's how you end up with an implementation that looks convincing and still misses the one thing that should have shaped it. Perfect route, straight into the pothole!
"Just add retries, how hard can it be?"
Take a task to retry failed payment requests. Sounds like a five-minute job, right!? Well yes and no. What if the provider accepted the payment and the response simply never made it back to us? Send the request again and you've just charged the customer TWICE. Not ideal! The code has to deal with that uncertainty, and so do the tests and the recovery process.
An engineer who has been burnt by this before will spot the danger before they've finished reading the ticket. AI might spot it too, especially with the right context. The job is to make sure the question gets asked and that the answer is backed by evidence rather than vibes.
That's the real value of experience: knowing which detail deserves attention before it turns into an incident. It's also why lessons from a specific industry or system matter so much, because the useful lesson is usually far more specific than a general coding rule. "Handle errors gracefully" won't save you here, but knowing how payment providers actually behave will.
Build the highway or fix the road?
Future plans belong in these decisions too. If we KNOW a capability is about to serve several clients, the design should reflect that. If the expansion is only a maybe, building an elaborate framework today is like laying a six-lane highway to a house nobody has bought yet, and you'll likely spend more maintaining it than it ever saves you.
Guiding AI means being clear about the difference between what we know, what we expect and what we're guessing. I want it to challenge those assumptions as well as build whatever we land on, and that takes more than telling it to make something "scalable" or follow "best practices". Those words sound great in a prompt and mean very little on their own. It needs the actual constraints, and we need to decide which trade-offs we're willing to live with.
Learning on the job
I expect most of my learning here to happen through normal, everyday engineering work, roughly like this:
- BEFORE: I identify the decisions that matter and the context behind them, so the AI isn't driving blind.
- DURING: I look hard at the assumptions and check the failure cases, instead of admiring how quickly the code appeared.
- AFTER: I compare what we expected to happen with what actually happened.
When something does go wrong, the lesson has to outlive the conversation it came from. It could become a regression test, a short decision record or a documented constraint that guides the next change. Basically, every pothole you hit gets marked on the map so the next trip goes around it.
I also need to notice when my OWN guidance was wrong. Human review only adds value when it brings sound judgement and evidence, and a quick "LGTM" on a pull request proves very little. None of this is new, by the way. These are familiar engineering practices, and AI just makes me want to apply them far more deliberately, because the implementation now moves so fast that a bad decision can ship before anyone has had a proper look at it.
Wrap it up
AI has made the typing cheap, which moves the value to the thinking around it. My plan is simple: keep using AI on real work, pay closer attention to where its decisions need guiding, and turn those observations into a better way of working. That's how I intend to explore AI reliability engineering, through the decisions, failures and lessons of the actual job.
So if AI is writing your code, ask yourself who's telling it about the potholes. Because the satnav will happily take you straight through one at 120km/h, and it will be VERY confident about it the whole way.
Emile