Generating Code Is Not the Same Problem as Inspecting Code

Few people realize how brutally complicated programming has become.

Software used to feel almost like a box: write the code, run it, fix the bugs.

That world is mostly gone.

Today, serious software lives inside huge interconnected systems spread across APIs, cloud services, databases, queues, regions, security boundaries, regulations, and third-party software.

A fintech platform may serve banks, currencies, jurisdictions, regulators, institutional clients, and risk models at the same time.

A hospital platform may span hospitals, countries, privacy rules, insurers, devices, workflows, and legacy systems.

And once software reaches this level of interconnected complexity, one old truth becomes impossible to ignore:

Generating code is not the same problem as inspecting code.

Writing something correctly in the first place and finding what went wrong afterward are fundamentally different tasks. But the explosion of AI coders has almost erased that distinction.

We have started confusing:

The AI can find the error after we give it feedback.

with:

The AI understood enough of the problem to generate the right code from the start, given the right prompt.

That is not the same capability. And in real-world software, confusing the two can get expensive fast.

The rest of this article is about why that happens and how we can use today’s Transformative AI with a Transportive mindset while we work toward systems capable of carrying nested semantic context correctly from the start.

You Are Coding Through a Minefield With No Warnings

Read more

TL;DR — What You’re About to Learn

This crash course is for AI engineers, investors, and advanced users who want to know how you can actually prove that an AI model deserves to be trusted when it makes predictive or otherwise falsifiable statements.

We will look at why benchmarks so often give the wrong impression, why genuinely unseen data changes the game, and how tools such as Monte Carlo simulation, Kupiec tests, Christoffersen tests, Bayesian monitoring, etc. can turn vague claims about AI reliability into something you can actually measure, test, and certify.

The central idea is simple: do not grade the AI. Grade the task. Then keep testing that grade as reality keeps producing new evidence.

That is what this crash course is about—and I will take the math seriously.

The Most Expensive Technology in History Still Comes With “Don’t Trust Me”

No exaggeration here: the most brutal thing we find in today’s AI industry is the wild contrast between its extraordinary ability to transform $1 trillion into powerful hardware and AI models and the obvious, frustrating impotence of those same models when they fail miserably at handling real-world tasks with consistent reliability.

Even more frustrating is how their CEOs, despite selling this frail technology, constantly remind us that we should let these systems replace humans by automating entire sectors of the economy, writing production software, diagnosing diseases, managing companies …  you name it.

Crazy, isn’t it?

However, you hear exactly the opposite whenever the industry is challenged to show measurable proof behind its revolutionary marketing claims:

Of course we can back our claims. Look at our benchmarks. What else do you need? AI sellers keep telling us, over and over again — despite including a small-print footnote in every chatbot: You cannot trust our AI.

Well, that is exactly the problem. Benchmarks are far away to be a good standard for objectively measuring the reliability, reproducibility, and predictive power of an AI model.

Benchmarks can be perfectly useful for assessing the merits of hardware, programming languages, and even toasters.

But when it comes to systems that must distinguish signals in an ocean of noise, where many real-world decisions ultimately reduce to true positives, true negatives, false positives, and false negatives — a benchmark score can look magnificent on a leaderboard… and collapse the moment it meets reality.

In fact, as we are about to see, the benchmark itself has recently become part of the problem.

Let’s see this in its most brutal form.

If the Student Knows the Exam Beforehand, What Exactly Are You Grading?

Read more

The biggest misconception about AI

Few people realize that much of our technological civilization, including advanced AI, rests on something that sounds almost impossible:

printing chips with light. But not with ordinary light.

Visible light is far too blunt to print the smallest structures demanded by today’s most advanced processors.

Because the process required to do it is so absurd that it sounds like the opening scene of a science-fiction movie.

The adventure, however, begins humbly, with one of the most ordinary elements in the periodic table:

Yep. Not some exotic substance harvested from a meteorite. Not a rare element available only to governments.

Nope.

Just a common, inexpensive metal, melted into a droplet barely a third the width of a human hair.

Then the real madness begins. Good luck with that. Twice.

First, you need a laser pulse to strike a single tin droplet and flatten it into a tiny disk.

Then, a fraction of a microsecond later, you must strike that same microscopic droplet with a second, vastly more powerful pulse.

Before a single second has passed, tens of thousands of droplets have already met the same fate. Droplet after droplet, the swarm ignites, each tiny sphere erupting into incandescent plasma at around 220 thousand °C, nearly forty times hotter than the surface of the Sun.

For one fleeting instant, you have created a tiny artificial star inside a laboratory. And from that star comes the prize you were searching for:

extreme-ultraviolet light EUV

The light capable of printing the smallest structures inside the most advanced chips on Earth.

There is only one problem.

The moment EUV light touches almost anything, it disappears.

Read more

The AI industry will confidently promise to reinvent education, medicine, science, dating, warfare, and lately even your mortality.

But ask what its coding models can already do, and everyone suddenly turns into a nervous, defensive salesperson.

Well, it depends.

The model may produce incorrect results.

Human supervision is still recommended.

No kidding. Human supervision is also recommended when humans write software. That is why we have code reviews, tests, staging environments, debuggers, incident reports, and senior developers staring at broken deployments late into the night.

The strange thing is that AI coding is being judged by standards that human programmers have never met. One camp shows an agent building a tiny web app and announces that software engineers are finished. The other watches the same agent misspell a variable and announces that machines cannot reason.

Both conclusions are ridiculous, and both come from the same statistical mistake.

Everyone stares at the numerator: how many coding tasks did the AI solve?

Almost nobody checks the denominator: what kind of tasks were they?

And that denominator contains nearly the whole story:

Was the model asked to write a ten-line utility function or repair a payment system spread across forty services?
Did it receive the whole repository or three disconnected files?
Could it run the tests?
Were the tests any good?
Did the documentation match the code?
What kind of task was the model actually given?

So here’s the first hint: whenever you analyse an AI coder, inspect its soft underbelly — the denominator: a ten-line function is not a forty-service payment system. A full repository is not three pasted files. A model with tests, logs, tools, and retries is not the same machine as a chatbot forced to guess from a vague prompt.

AI coding ability does not come from a clever little homunculus — a tiny programmer hiding inside the model and doing all the thinking.

It comes from the whole setup:

model + context + tools + feedback + human judgment

Change the setup, and the same AI can look brilliant, useless, or confidently break a system it never understood.

And this is where both camps rig the experiment.

The optimists show the cleanest run. The pessimists remove half the context, tie one hand behind the agent’s back, and present the crash as scientific proof.

Neither tells you when the machine is actually useful.

That is the skill worth learning: knowing whether the agent simply needs more context, has made a bad guess, has written code that only looks correct, or has wandered so far from the architecture that you need to drag it back by the collar.

Learn to spot the difference, and AI coding becomes less of a dark art — and more of a practical defensive skill.

SOFTWARE FOLKLORE IS LYING TO YOU

Let’s start with the myths that keep us from understanding AI coders — and from using them properly.

Look at the table below. These are the stories about AI that, if you’re a developer, you’re probably tired of hearing from other developers — even though, as you’ll see, the evidence points the other way.

Software engineering is not uniquely irrational, of course. Every field has its favorite myths. But ours are especially bizarre because developers love talking about evidence … right up until AI coding comes up.

So let’s put those beliefs on trial and see which side the evidence actually favors: the techno-optimists or the techno-pessimists.

Spoiler: neither.

Myth One: The Parrot Alibi

AI coding only works because the model has already memorised the answer.

Read more

Welcome to the First TechUnderWorld Skool Crash Course

This is the first course in a series designed to prepare you for the next generation of AI—far beyond the usual tutorials, headlines, and recycled explanations.

We will not only examine what is broken in today’s AI.

We will explore the most serious mathematical and engineering ideas being developed to fix it: the same problems currently keeping the major AI labs busy.

But you do not have to wait for those labs to package the next generation into a product.

Here, you will learn how to recognize what is coming before it reaches the mainstream.

What is the trick?

The right mathematical and engineering mindset.

We will move through research papers, patents, emerging architectures, and recent mathematical developments to build a precise map of what is happening—both from above and deep inside the machinery.

You will learn which technologies could shape AI over the coming months and years, why they matter, and how to evaluate them for yourself.

That last part is the most important.

The goal is not merely to give you information.

It is to help you develop the skills and instincts to navigate the next AI wave independently.

TechUnderWorld Skool delivers hard facts, real mathematics, and serious engineering in simple language—told as an immersive, almost cinematic story.

Enjoy the course.

Prepare for a Semantic Machine, Not a Token Parrot

We talk to language models in messy human language: incomplete, ambiguous, and packed with assumptions we never bother to state.

And you already know the price. The same damn ritual: prompt. Correction. Clarification. Another correction. Five more messages…

Eventually, the machine produces something close to what we wanted in the first place… or not.

Human language is much more than words. Most of the time, another person can understand what we mean from a few words, a gesture, or even a look.

Try that with a machine, and things can become complicated — or completely nonsensical — very quickly.

That brings us to the second reason: context.

Humans are remarkably good at separating the different, sometimes completely contradictory, meanings of the same word, gesture, or idea.

We do it almost effortlessly.

The same sentence can sound serious, sarcastic, affectionate, threatening, or absurd depending on who says it, when they say it, and what happened five minutes earlier.

Now imagine that same situation inside a transformer — the token-processing engine at the core of today’s LLM chatbots.

LLM Chatbots Are Sticky Tokenizers

Some of you may argue that self-attention does not keep every token locked inside its own little box.

And yep, you are right.

Each attention head updates a token by mixing information from the tokens around it, giving more weight to whatever the model considers most relevant. So there you have it: context is being handled. What is the problem?

The problem lies in what can happen when that mixing is repeated across layer after layer.

Think of making a salad. At the beginning, every ingredient is easy to distinguish. You can clearly see the tomato, the lettuce, the onion, and the cucumber. Then you add oil and vinegar and start tossing everything together. The ingredients are still there, but their flavours begin to mix, and the boundaries between them become less sharp.

Self-attention can do something similar with token representations.

It mixes and averages information again and again, so distinctions between words, meanings, and their roles in the surrounding context can gradually become blurred inside the model.

LLMs learn contextual regularities from enormous collections of token sequences. They are extremely good when a new situation resembles combinations encountered during training.

But context is combinatorial.

Suppose meaning depends on ten contextual variables, each with ten possible states.

That already gives:

possible combinations.

No training set can explicitly cover them all.

Of course, the machine does not need to memorize every combination if it learns reusable concepts and rules for recombining them.

That is the whole trick.

Current LLMs do not always learn those clean factors. Sometimes they learn shortcuts, statistical habits, and correlations that work beautifully, until familiar pieces appear in an unfamiliar arrangement…

Take two apparently simple concepts:

justice and law.

Their relationship is not fixed.

It changes with the jurisdiction, the institution, the historical period, the type of offense, and the moral framework being applied.

We should really write:

In one context, legality and justice may largely coincide.

In another, something can be perfectly legal and still widely considered unjust.

Even within the same legal system, their relationship may change between contract law, criminal law, military law, or politically regulated conduct.

The words remain the same, but the relationship between them changes.

This remains difficult for current LLMs because, despite what many introductory AI explanations may suggest, processing context does not guarantee that a model will represent different contexts as clean, explicit, and separable structures.

In many real-world cases, legal, cultural, and religious assumptions remain implicit and entangled inside the model’s learned representations, as the animation above illustrates conceptually.

So how does the industry try to solve it?

By throwing more data, more parameters, longer context windows, and more corrective training at the problem.

And yes, the results improve, but only by throwing exponentially more compute at the problem, with energy consumption rising sharply alongside it.

Worse, getting more answers right does not mean the machine has understood why they are right. It may simply have learned better shortcuts through familiar patterns.

The next machine will need something more explicit.

Not merely tokens mixed with context.

A representation in which concepts, relationships, assumptions, and constraints can be inspected, recombined, challenged, and changed independently: a truly semantic machine.

THE CONTEXT CURSE OF TODAY’S AI

Read more