If you are a young Malaysian with a proclivity to the wonderful world of computing, and might have just received your UPU results and considering (or second-guessing) a computer science degree, you have probably heard everyone and their shoeshine boy telling you that you picked the wrong decade for it. AI writes code now, the story goes, so coders are next for the chop. I think that worry rests on a quiet misreading of what a degree is even for. I'd argue, dear reader, that a computer science degree is one of the safest bets you can make right now, and the day it stops being worth anything is the day we stop using computers in any form. That is not a day I can see coming.
I came into software sideways, which is maybe why I see it the way I do. I studied applied physics, spent a while in a materials lab, and only later started writing code for a living. In a lab, most of the work comes in managing the project, i.e. scheduling work (which is really important because feedback loops here are in weeks if not months), alignment with stakeholders, designing experiments, writing papers/reports, etc. The actual implementation, i.e. the time in the lab, is a very small part of the work. This is not unanalogous to software engineering, the coding itself never felt like the real work to me. It's a means of translating the very messy domain of real-world problems into deterministic rules. The syntax has never been the hard part, because you could always look it up. Likewise, the lab procedures were never the hard part, because you look it up and you piece things together.
And that part, the looking-up and the typing, is what the machines have taken. An AI agent out-types me without breaking a sweat, and I am not going to pretend otherwise. But the typing was always the cheap part of the job.
The expensive part is everything that comes before and after the code.
My career has been spent building guardrails across enterprise self-service platforms, automated vulnerability management, and industrial digitalisation, but they always come down to the same thing: keeping software from failing in the ways that matter most i.e. the expensive failures. My current field, freight SaaS, is unforgiving that way. One example, without going into the nitty gritty details, is that a freight platform is usually multi-tenant. Rival brokers run their operations on one shared system, and each broker's consignment data, who is shipping what, where, and at what price, has to stay completely sealed off from every other broker on it. A database query that quietly forgets to limit itself to one tenant (or a software architecture that allows this mistake in the first place) will leak one broker's consignments straight into a competitor's result set. You don't see errors, you don't see crashes, because the catastrophe is completely silent and the leak could run for weeks. You can't patch confidential data that has gone out.
You might say: so design the system to fail loudly, make the leak impossible to miss.
You would be right. That is the job. But deciding which states must be impossible, and shaping a system so they cannot occur, is not something you look up an existing syntax for. It is systems-design judgement, built over years of watching things break, resting on enough theory to know which failure modes are even possible in the first place. That foresight is the challenge.
You might then say: fine, but I will write that judgement down, a SKILLS.md, a prompt library, an instructions file, and hand it to the agent. Context engineering, man.
Sure, and that is also the job. The people who could sufficiently and precisely compress all that knowledge would be the bearer of said knowledge, which is an amalgamation of everything they understand about the domain, the architecture, the failure modes, and N other dimensions of the problem space. A shared generic instruction you get from the next viral X post is not a shortcut around the expertise. It is a shadow the expertise casts, and the agent cannot cast it for you, because it has never seen your particular permutation of the problem. Again, dear reader, there is no shortcut to cognition. The best wielder of context engineering would be the experts in the technical and business domains you're operating in.
This is the part vibe coding skips. Prompting an AI to produce code with little oversight is fast, and a single engineer running a fleet of agents can write a startling amount of it in a day. I am not romanticising the old way here, nor am I a luddite. At work, I run agent orchestrations and build agentic harnesses in the form of state machines with deterministic correctness guardrails, with my recent monthly token usage racking up to about $7,000 on average. I'm experimenting with and building the latest paradigms, and I've been building LLM apps since 2022 and writing about it since the GPT-3 release. These are real tools that can result in meaningful amplification in an engineer's value creation, but the engineer does not believe in magic as the laws of thermodynamics dictate there's always a catch.
What the engineer cannot skip is the validation. Correctness is not something you can eyeball off a screen, and when the same AI writes both the code and the tests meant to catch its mistakes, nothing has really been verified. Everyone's been saying that writing code got much cheaper, and I'm not saying that's not true. I'm saying it's also true that verifying the code has not gotten as cheap as writing it, and a huge part of the industry has been hand-waving over this by bluntly throwing more tokens at the problem. As of June 2026, a careful human still does that verification better than any agent I have worked with. They have recently coined a term for this, the orchestration tax. However manifold your coding speedup is, the verification is a bill that always comes due, paid sooner in slower review or later in a scramble once everything looks finished. Again, there is no shortcut to cognition. There's no free lunch, even in the age of AI. I wrote in great technical depth about how we could tackle a chunk of the AI verification problem in this post, but the problem needs tackling and cannot be hand-waved away.
None of this means vibe coding is a dead end. For plenty of work it is exactly the right call. On a throwaway PoC, a weekend app, or a low-stakes internal software, where a bug costs nothing and you fix it in a minute, the speed is a huge plus and the verification hardly matters. The trouble only shows up where correctness is non-negotiable, where a quiet mistake results in significant financial/reputational damage, leaks data that cannot be pulled back, or might even result in the loss of life. The Therac-25 incident demonstrated what can happen when we adopt a lackadaisical attitude towards critical digital systems. You have to know which problem you're working on to optimise the speed-to-risk/value ratio, which is why it's best to ignore the next viral post on social media saying you shouldn't read code anymore - they don't know your problem!
In reliability engineering, you keep a system healthy in two ways, 1) by making it fail less often (mean time between failures, MTBF) and 2) by recovering faster when it does fail (mean time to recovery, MTTR). The tempting story with AI right now is that recovery has also become so cheap, that the agents will catch and patch the bug in minutes, so prevention never really matters in the first place. I echo Mitchell Hashimoto's sentiment on this (he's the creator of Terraform) that we cannot "yeet resilient systems entirely", going full MTTRmaxxing. Instead, we need to do a careful enumeration and analysis of the risks present in our systems and treat each component in the right amount of care in the MTBF-MTTR spectrum. For the data leakage failure mode I described earlier, MTTR is an absolutely useless metric.
A university degree has never been a certificate in the tools of the moment, i.e. the ones that turn over every few years. Misunderstanding this is precisely why we always hear the very common yet misplaced complaint that students don't get taught tool XYZ at the university (you hear this complaint regardless of the domain of study). It's not the university's job to teach you how to use Excel. Your degree trains you to build the things that do not exist yet. With solid fundamentals, you could go on to build the next hyperscalable LLM architecture beyond transformers, or at the very least you'll be the person automating the automations with robust abstractions of abstractions. It'd be a huge waste of time and money for universities to teach you how to use Cursor or Claude Code, which are the tools of this current moment. This is the way Paul Graham put it in an address to students called "What You'll Wish You'd Known". Choose a field of study that keeps the most doors open later, he argued, a habit he called staying upwind. If you were to choose between maths and economics, he said, pick maths, because the more fundamental subject leaves you more options later.
And you can see how staying upwind with fundamentals pays off in history, and I have a favourite story I reach for on this everytime. In 1940, the mathematician G. H. Hardy wrote an essay, A Mathematician's Apology, holding up number theory as his prize example of beautiful mathematics precisely because, he was sure, no one would ever find a use for it. That same "beautifully useless" number theory is now what secures every card payment and private message you send, thanks to computer science. The most useless thing he could point to, in a fundamental field of knowledge, became the backbone of public-key cryptography. Computer science sits in that same spot today. Computation, being so fundamental, runs underneath freight, banking, medicine, under nearly everything we touch, and knowing how it works goes with you into all of it. The fundamentals do not expire.
So when you're confirming your course selection, dear reader, remember that you cannot predict the market, or the job title you will end up holding. The only thing you can bet on is your own ability to take the fundamentals you are about to go deep on and turn them into a force multiplier for whatever comes next.