Andrew Yang goes on CNBC and said, that what he has seen now is really fast moving change. Companies are offering fully autonomous solutions, companies are buying, the graduate market is suffering. AI is here.

So if you're a graduate, or experienced person, especially in computer science, you are worried.

I thought it may be useful to have a few pieces of context added to ensure we are on the same page. Not all code is created equal. Not all codes needs automation, nor is AI suitable to automate and/or work with for various levels.

Lets brushstroke this:
Grind, Innovative and Business code.

The Grind Code. Some code is extremely basic, and necessary. Integrating endless SQL tables, making systems talk to each other, and often untangling extremely case specific syntax takes up hours and hours of time. Its not creative, its not fun, its necessary. It has to be accurate, it has to be functional, fast, and reliable. Most code in the world running today in established companies fits this description.

If 'Grind Code' was a room, it would a messy kids room scattered with lego pieces from a hundred different builds, half built things, with not a single instruction manual in sight. And it would hurt to walk over it in bare feet.

The Innovation code. We often imagine this as the standard, but its much more rare. A new way of connecting systems, a new application of a plug-in, a new upgrade to the protocols or security, and suddenly its faster, better and opens up new ways of doing this. Innovation takes time, its risky, and it often has a very long tail of dependencies and issues.

Analogy: You can put a rocket on your car, and you're super happy that you've upgraded it. You take it for a spin, and your paint job is gone, a carpet of bugs are on the windshield covering your views, and the fumes are accidentally choking the passengers. You have to think bigger now.

The business code. This is where you sit down with the business unit, and try to speak the same language. You try to untangle what they want, how they want it, what is possible to do, and circle around architecture and tech stack plans for 80% of the work. Its curious discovery, a meeting of minds between two different worlds, but its fun once you get the hang of it. Your job is to apply coding logic to business logic.

If this was a room, it would be a speed dating tables set up, each face curiously looking at yours, hoping you can help them in some way.

Coding is not uniform, problems are not headlines. AI is not a perfect system either, and we simply dont know what the new model is going to look like, but its as unlikely to be all AI, as it is to be all human.

We are building a great deal on top of something we do not fully understand. This is because we do not take the time to understand, as we rush to build more and better.

Recent data shows that global spending on AI systems will surpass $300 billion in 2026. Seventy-two percent of enterprises now have at least one AI workload in production, up from 55% in 2024 and just 20% in 2020. The average enterprise runs 4.2 AI models in production, up from 1.9 in 2023. Eighty percent of enterprise applications shipped or updated in Q1 2026 embed at least one AI agent, up from 33% in 2024.

People produce work and errors in mostly predictable ways. When you train a person, you can observe where they’re weak, coach the weak spots, and watch them improve over a trajectory that, while uneven, is at least legible. You can predict roughly where a junior analyst will make errors. You can design reviews around those predictions. Over time, the person gets better in ways you can track, and the errors concentrate and then diminish.

AI does not work this way. Its capability shape is unusual. It can produce work of stunning sophistication in one paragraph and miss something elementary in the next. It can handle a complex logical chain and then fail a simple consistency check. The errors do not cluster around inexperience or known limitations. They are distributed unpredictably across the output, and they shift from run to run. You cannot build a training plan for this. You cannot say “it’s weak on X, so we’ll check X.” You have to check everything.

This is a kind of ‘House of Swiss Cheese’. From the outside, it looks solid. Walls, roof, doors, windows. But the walls are riddled with holes, and you don’t know where they are until you press on every surface. That takes time.

The Engineer and the Artist

An engineer treats problems as singular and ground up. Constrains, model shape and assumptions are assembled carefully one at a time, like a solid grid, it builds up into a predictable lattice. You roughly know where to look for gaps and problems. Engineers like lines, they like connections and systems and structures. It is obvious where there are missing parts, your eyes are drawn to it. Mistakes surface readily and easily as the system relies on cohesion to stand up.

An artist’s mistakes are less obvious, and more fluid. The role off an artist (in this analogy) is to colour in between the lines, and sometimes, shift those lines subtly. Sometimes the lines themselves were redrawn without telling you, and its not always obvious where the system begins and ends, or what good looks like. Even when you ask for the most boring, constrained output imaginable, there’s a creative restlessness to these systems that cannot fully suppress itself. AI is seeking to colour in everything it can, and if it can’t, it will seek to colour just as close as possible. Mistakes are hard to find when colours bleed into one another.

The emotional impacts

There’s a moment in every AI interaction that feels like magic. You describe what you need, and within seconds, something appears that would have taken you a week. A draft, a model, a plan, a piece of code. You look at it and think: I’m five steps ahead.

Then you start reading. A paragraph that contradicts itself. A number pulled from nowhere. A structure that looks right from a distance but collapses under scrutiny. An extra section you didn’t ask for, confidently inserted as though it belonged. A missing piece you explicitly requested, quietly omitted.

So the real arithmetic of AI is five steps forward, then one or two steps back. Those backward steps are disproportionately painful, because they arrive after you’ve already emotionally booked the gains. You thought you were five ahead. You’re actually three ahead, maybe three and a half. That’s still good. That’s still faster than doing it yourself from scratch. But the gap between where you thought you were and where you actually are is where the frustration lives. The disappointment of a retracted promise stings more than the honest difficulty of slow progress.

The practical lesson is unglamorous: budget for the cheese holes. When you estimate how long an AI-assisted task will take, don’t measure from the moment it produces output. Measure from the moment you’ve verified every part of that output and repaired what needs repairing. The generation is the easy part. The inspection is the work.