Software engineering has always been a story of rising abstraction. Not just in the sense that our tools have gotten more powerful, although they have. But in a deeper sense: each generation of engineers built scaffolding that let the next generation think at a higher level, closer to the problem and further from the machine. Assembly gave way to C. C gave way to managed languages. Frameworks appeared so you stopped thinking about the plumbing. Cloud infrastructure pulled the infrastructure concern out of the picture almost entirely. Each layer was a bet that the complexity being hidden was stable enough to be hidden. And mostly, the bet paid off.
AI is the newest abstraction layer. And it is not yet obvious the bet is paying off the same way.
I am halfway through an MSc in AI, and I have four years of software engineering behind me before the degree started. The curriculum is exactly what you would expect: linear algebra, probabilistic models, neural architectures, optimization theory, the full stack from the bottom up. The assignments are rigorous. You build systems that perform well on benchmarks and produce results you can reason about formally. You learn the theory and it is genuinely useful.
Then you go and build something that real people use in real time, and you discover that the things that trip you up have almost nothing to do with what you learned in the classroom.
The failure modes in production AI are not about model capacity or training methodology. They are about context design, trust calibration, interface clarity, and the behaviour of systems under conditions they were never explicitly tested for. The hardest bugs I have dealt with in the last year were not machine learning problems. They were systems design problems wearing new clothes.
The most important lesson I have taken from building real AI systems is this: the model is almost never the problem. The context you give it is. A state-of-the-art model with poorly structured context will produce confident, wrong output. A decent model with accurate, well-scoped context will outperform it reliably. Academic AI optimizes for the model. Production AI is mostly a context engineering problem. The MSc teaches you to make the model better. The job teaches you to make the input better.
On the good side of AI in software development: the compression of the distance between idea and execution is real and it is dramatic. Things that used to require specialized teams and months of work can now be prototyped in days. Not deployed, not production-ready, but tested against real users fast enough that you know whether to continue building before you have spent the time it used to take to find out. This is the version of the AI productivity story that is actually true, and it is underappreciated compared to the noisier narratives. It is not that AI writes your code. It is that AI reduces the cost of exploration so dramatically that you can explore more aggressively and fail faster, which is the actual goal.
I also think AI handles the ambiguity that lives between a requirements document and a working system genuinely well. Not the engineering decisions, but the interpretive work: figuring out what a user probably meant, synthesizing context from multiple sources into a coherent picture, reasoning about edge cases that are hard to enumerate upfront. These are tasks where the probabilistic nature of language models is a feature rather than a flaw. The model is not certain, and for this category of task, neither should it be.
On the bad side: the most dangerous property of capable AI systems is how confident they sound when they are wrong.
When a deterministic system fails, it fails legibly. An exception gets thrown, a number comes back wrong, a request times out. The failure is visible. When a language model fails, it produces a response that is well-structured, fluent, plausible, and wrong in a way that requires domain knowledge to catch. This asymmetry is a serious design problem that the industry has not fully reckoned with.
Building Leverage made this concrete for me in a way that no assignment ever did. Early on, the AI was responsible for confirming whether a live price level had been crossed during an active trade. One of our beta users had a stop set. Price hit it. The system said it had not been hit. When he pushed back, the system agreed with him. When he pushed back again, it reversed. Not because it had checked anything. Because the pressure of the conversation shifted what response it thought was expected. The model was not broken. It was behaving exactly as designed. We were using it for the wrong class of task.
That incident produced the architectural principle we have held since: models handle interpretation, code handles facts. The AI reads chart structure, synthesizes context, reasons about setup quality. A separate deterministic layer polls the live price on a timer and fires a notification when a level is crossed. No AI in that path. The arithmetic does not respond to pushback.
It sounds obvious once you have been burned by the alternative. It is not obvious before.
Where I think this goes over the next few years: I expect the architectural patterns will solidify in the way that other hard-won engineering patterns have. REST, database transactions, event sourcing. These became standard not because someone designed them from theory, but because enough teams hit the same walls and shared the lesson. The pattern of separating probabilistic reasoning from deterministic state will become a basic convention in AI system design. Right now it is a lesson you learn the hard way. Eventually it will be in the textbooks.
The agentic direction, AI systems that take sequences of actions rather than returning single responses, is where the genuinely open engineering problems are. The failure modes compound across steps. A small misread at step two becomes a large error by step five. Getting reliability here requires design instincts that are different from building a single-turn API call, and most of the intuitions engineers carry from traditional software do not transfer cleanly. This is where I think the interesting work is, and it is also the work that most closely resembles the kind of systems design thinking the MSc curriculum actually builds.
The history of software engineering is a history of rising abstraction. AI is the newest layer. But the lesson of every previous layer is the same: the abstraction only holds if you understand what it is hiding. Understand what the model cannot do, where deterministic code must take over, and where confidence without verification is a liability. Know that, and you can build serious things on top of the layer. Mistake the abstraction for reality, and you will spend a long time debugging things that should not be possible.
The bet on AI as an abstraction layer is being made right now, at scale, across every industry. Whether it pays off the way the previous bets did depends on whether the people building with it develop that understanding fast enough.