# AI Will Always Need Humans Behind It. And the More You Know, the More Valuable You'll Be

There's a sentence that's been making the rounds on social media, podcasts and startup hallways for months now, repeated like some kind of enlightened mantra: **"AI still needs programmers today, but in a few months or years that'll be gone."**

And I have to ask... really? Are we talking about technology or fortune telling?

Let's talk straight. No smoke and mirrors. Facts on the table.

## Transformers Are Nine Years Old. And They're Still the Same.

In 2017, a team at Google Brain published a paper that changed everything: **"Attention Is All You Need."** That's where Transformers were born — the architecture sitting underneath virtually everything we call generative AI when it comes to language models: GPT, Claude, Gemini, GLM, DeepSeek...

Nine years later, the base architecture is still the same. That's not an opinion, it's a verifiable fact. It's been scaled brutally — more parameters, more data, more VRAM, more money — and surrounded by layer after layer of tools, guardrails, agent pipelines and advanced training techniques. But the core, the attention mechanism that makes an LLM work, hasn't changed in its essence.

So what does that mean in practice? That the underlying problems haven't gone away either. They've just been better covered up.

## How an LLM "Knows" Things. Or Doesn't.

Here's the part nobody explains because it sounds too much like a math lecture and people tune out. But it's the key to everything.

An LLM doesn't store information the way a database does. It doesn't have a table somewhere with "The Earth is round: TRUE." What it has is an extremely high-dimensional vector space — think of a map, but with thousands of dimensions instead of two — where each word, concept or token occupies a position. And what defines that position is its proximity to other concepts based on how they appeared related in the training data.

That's called an *embedding*. Here's how it works: if during training the model reads millions of texts where the word "king" appears near "crown," "throne" and "palace," the vector for "king" in that space ends up close to all those concepts. The model doesn't "understand" what a king is. It knows that word lives in that neighborhood.

Now apply the same logic to something more sensitive. If a model is trained on a significant amount of text where "earth" appears alongside "flat," "disc," "edge" or "conspiracy"... the vector for "earth" picks up a statistical proximity to those concepts. The model has no way to know that's false. It simply reproduces the probabilistic distribution of what it learned.

An LLM is, at its core, a system that predicts which word is most likely to come next given a context. **It doesn't reason. It doesn't evaluate. It doesn't judge. It calculates probabilities.** And those probabilities are a direct reflection of what it was fed.

![Injecting prompts into an LLM...](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/GGKGYXwqT64KbSTzJWQ8pq.jpg)

## RL, RLVR, and the Art of Fine-Tuning Without Retraining

That said, let's be fair. The industry hasn't been sitting on its hands. The techniques of **Reinforcement Learning from Human Feedback (RLHF)** and its evolution, **RLVR (Reinforcement Learning with Verifiable Rewards)**, represent a real and significant step forward in how models are improved after pre-training. The idea is elegant: instead of retraining the entire model — which is absurdly expensive in time and money — the model receives feedback on its own responses. Responses evaluated by humans, or cross-checked against verifiable results, generate a reward signal that steers the model toward more desirable behavior.

RLVR goes a step further: instead of relying on human evaluators for everything, it uses objective rewards when the result is verifiable. Is the math answer correct? Reward. Does the code compile and pass the tests? Reward. This allows models to be fine-tuned in a much more scalable way in domains where objective truth exists. Assuming we accept that code compiling and passing tests makes it correct. **Spoiler: it doesn't.**

And here's something important to understand: these techniques allow new versions of the model to be created without retraining from scratch. Think of it as continuous, directed fine-tuning that improves specific behaviors without touching the fundamentals. That's a real advance, not hype. But the problem of judgment doesn't go away. It just shifts.

## Who Decides What's Correct?

If training a model with RLHF requires humans to evaluate responses... which humans? With what criteria? With what level of domain knowledge?

Let me give you a concrete example. For me, using TCA (The Composable Architecture) in a SwiftUI app means adding an unnecessary layer of complexity that goes against the very design of Apple's frameworks. An aberration. For others, it's the most robust architectural solution out there. Which answer does RLHF reinforce? The most upvoted one? The most starred on GitHub? The one from whoever has the most followers on X? Because we've both found the optimal solution to our own problem.

Or worse: what about security? An LLM can suggest code that works perfectly but contains an SQL injection vulnerability or exposes sensitive data. How does the model know that's a problem if no one has explicitly told it — with rigorous technical judgment — that it's wrong? And if someone did tell it... with what criteria did they do so?

The loop doesn't close on its own. *Guardrails* — filtering and restriction layers added on top of the model — are exactly that: **patches**. External corrections that try to compensate for what the model, by its very nature, can't resolve internally. They're necessary and useful, but they're not intelligence. They're rules. And rules are written by people. And people have different levels of knowledge, different criteria, different opinions and different biases.

![Teaching Spec-Driven Development](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/4fN2ntL1Q1FtopAnzyFTrU.jpg)

## Software Is Not Just Code. It Never Has Been.

There's another argument in the "programmers will soon be unnecessary" narrative that strikes me as pure science fiction: the idea that an AI can build software from start to finish with just a vague description of what you want.

What do you want? That's the problem right there. Because **"build me a task management app" is not a specification.** It's the starting point of a conversation that lasts weeks with the client, the design team, the business team, the marketing team...

What's the user flow? What's the underlying data model? Does it sync with a backend? Which one? What privacy regulations apply? How is it monetized? What metadata does it need for the App Store? What's the differentiating value proposition against the 1,500 apps published every single day? What about accessibility? Because design depends heavily on it.

And once all of that is defined and the code exists... who audits it? Who validates there's no data race in the concurrency layer if we're not using Swift 6 by default? Who reviews that user data is properly encrypted? Who decides which architecture to use or how it'll scale when the app goes from 100 to 100,000 users?

Software is design, strategy, architecture, technical judgment, business understanding and legal accountability. **Code is just the form all of that takes.** And that understanding cannot be delegated to a probabilistic system. That's exactly why the evolution of programming is called *Spec-Driven Development* — development driven by specifications. Couldn't be clearer.

## The Only Verifiable Fact

The industry has changed forever. That's true. **AI has eliminated the most mechanical layer of development:** boilerplate code, repetitive documentation searches, project scaffolding. It has sped up processes that used to take hours. It has democratized access to certain levels of implementation.

And in this new world, the traditional junior-versus-senior distinction is evolving into something different: **analyst versus architect**. Someone who knows what to ask the AI, what to review in its output, what to validate, what to throw out and why. Someone with the technical judgment to direct the tool — not the other way around.

**AI amplifies what you already know. If you know a little, it amplifies a little. If you know a lot, it makes you very hard to replace.**

That's why the path forward isn't learning how to use ChatGPT. In Apple development, the path runs straight through understanding Swift 6, strict concurrency, data architecture, security, API design and the Apple ecosystem at depth. With that foundation, AI is an extraordinary multiplier. Without it, it's a black box generating code you can't tell is working correctly... until it breaks in production. Technical debt that will blow up — count on it.

![Think](https://image.service.eu.axinom.net/transform/72a20w8irkd812lj5hqycl0ft-3dl5y1dj0seejmhh8wynzscv2/DdP5tyxtLa7Rpu2u7B7TeN.jpg)

## Conclusion: Don't Let the Smoke Blind You

*Transformers* have been with us for nine years and their fundamental nature hasn't changed: they are probabilistic systems that predict text based on the statistical proximity of concepts in a vector space. Improvements in training — RLHF, RLVR, directed fine-tuning — are real and significant advances. But they don't solve the judgment problem, because **judgment always comes from a person**.

What changes with AI isn't that programmers disappear. What changes is the level of knowledge required to stay relevant. And if you think about it, that's the exact opposite of what the headlines say.

So keep learning. With depth, with judgment, reading code the way you'd read in your native language. Because when AI takes over the surface layer of development, what's left will be exactly what's hardest and most human: **thinking**.