Every time programming got easier, someone said it wasn't programming anymore

There are two mistakes AI agents make in SwiftUI with an almost comical persistence: breaking view identity inside a ForEach and putting state at the wrong level of the hierarchy. They make them so often, and they're so hard to spot on a quick read, that Apple has ended up publishing official skills to correct them.

Stop on that sentence for a second. The company that builds the framework has had to write instructions so the machines stop writing its own framework wrong.

That code compiles. It runs in the simulator. It gets through a demo. And it falls over later, in production, in front of real users, in a way only someone who understands what's happening underneath will see coming.

That's 2026 in a nutshell.

Seventy years of taking keystrokes away from programmers

The first thing to say is that none of this is new. It is, in fact, the only thing this profession has done since it began.

When John Backus's team introduced FORTRAN in 1957, their obsession wasn't making the language pleasant: it was proving that the code the compiler spat out could compete with hand-written assembly. Because if it couldn't compete, nobody would use it. There were programmers — good ones, the ones who really knew their stuff — convinced that letting one machine write the code for another machine was an elegant way to lose control.

Then came automatic memory management. Then truly high-level languages. Then libraries you no longer had to write yourself. Then Stack Overflow, which turned copy and paste into a job skill. And in our own house, in 2011, ARC arrived and took retain and release out of our hands.

I remember those forums perfectly. “This is going to create an entire generation that doesn't understand memory management.”

And you know what? They were right. Today there are excellent iOS developers who couldn't keep a reference count by hand. And there are also more apps, better and more ambitious ones, than at any other point in history. Both things are true at the same time, and they've been true at the same time since 1957.

Every abstraction took away a task. None took away the craft. Because the craft was never typing.

But this time the abstraction isn't deterministic

And this is where I get off the comfortable “we've been through this before.”

Let me explain: a compiler is a function. Same input, same output. If one day it generates an incorrect binary, that's a bug: you file a radar, it gets fixed, and it stops happening. You can trust a compiler with the same peace of mind you have that two plus two will still make four tomorrow.

A language model isn't a function. It's a probability distribution. It doesn't give you the correct answer: it gives you the plausible one, the answer that statistically best fits what it has seen a million times. And it gives it to you in exactly the same confident tone when it's right as when it's making things up.

It's the first tool in the history of software development that can be wrong with conviction.

That moves the work somewhere else. For seventy years programmers kept climbing levels of abstraction, yes, but always with solid ground beneath them. Now the ground has opinions. And when the ground has opinions, your job stops being writing and becomes judging.

I'm not saying this on a hunch. In a controlled 2025 trial, experienced developers took 19% longer to complete their tasks using AI… convinced they were going 20% faster (METR, 2025). 84% of developers already use AI daily, but only one in three trusts what it produces (Stack Overflow Developer Survey 2025). And since these tools arrived, duplicated code in repositories has gone from 8.3% in 2021 to 12.3% in 2024, while code that has to be rewritten within two weeks nearly doubled (GitClear, 211 million lines analyzed).

Now the other side, which is just as real: in field experiments with almost 5,000 developers, those using AI completed 26% more tasks, and the biggest gains went to the least experienced (Cui et al., Microsoft/MIT, 2025). Both results are true and they don't contradict each other: AI amplifies what's already there. If there's judgment, it multiplies it. If there isn't, it multiplies the chaos.

Because it doesn't reason. Because it doesn't abstract. Because it doesn't know what “correct” means in your project: nobody has ever told it.

Judgment can't be copied or generated. It's trained.

That's the idea we used to rebuild the Swift Engineering Program 2026 from the ground up. And the name change — from developer to engineer — isn't marketing: a developer writes; an engineer analyzes, designs, plans and answers for the quality of the result, no matter who wrote each line.

What you won't find here is an AI module tacked onto the end of the curriculum, with its hour of prompts and its group photo. The relationship with the agent is built throughout the whole program, with progressive permissions. Like a graduated driver's license.

In the first weeks, asking the agent for code is forbidden and asking it for explanations is mandatory. The Xcode 27 assistant is a private tutor available at three in the morning: it explains why that optional needs unwrapping, or what really separates a closure from a function. AI amplifies people who want to understand; it never replaces understanding.

In the second phase the agent gets demoted: from tutor to fallible teammate. You write, it proposes, you audit. And every week brings our signature exercise, “Find the agent's bug”: AI-generated code with genuinely subtle errors, the kind real models make. Your job is to hunt them down. Nobody comes out of that thinking the machine replaces them. You come out understanding that your judgment is the product.

And in the third, full Agentic Coding with Xcode 27: plan mode, skills, MCP, sub-agents, self-validation. You one level up, writing the spec, reviewing the plan before a single line is touched, and validating the result.

On top of that, the last hour of class is sacred: it's the Judgment Lab, where you write your own prompts and your own skills and we assess how precise the request is. Because if you understand neither the problem nor the code, how do you expect AI to help you solve it?

What's inside, no frills

124 hours of live classes over 31 teaching days, Monday to Thursday, 7–11 pm Spain time (CET), from October 5 to November 26, 2026. After that, 13 weeks of guided project work, from December 7, 2026 to March 7, 2027. Everything is recorded and published within 12 hours of each session ending, so you can follow it live, hybrid or fully offline. 40 seats, not one more.

Before October there are two pre-recorded modules in September. The first is pure algorithms, because there are millions of “developers” who don't know how to develop: they copy, paste and pray. The second doesn't have a single line of code and is probably the most important in the program: what a language model really is, what tokens and the context window are, why it hallucinates, and why it's brilliant with the familiar and dangerous with the new. Know the tool before you let it touch your code.

From there, the full path: Swift 6.4, SwiftUI with Liquid Glass (without a single deprecated API and compatible back to iOS 17), architecture with MVVM and Clean Architecture, strict concurrency with @MainActor and @concurrent, Swift Testing as a core subject (in the age of agents, your tests are the tool the machine uses to validate its own work), networking, SwiftData and, at the end, MCP, ACP and Spec Driven Development live, with the whole class working as a product team.

And it ends with the Case File: a SwiftUI app against a REST API of ours, with the core written by you, one feature that must be built with the agent and comes with a decision log — what you asked it for, what you accepted, what you rejected — plus a video defense explaining your architecture.

That log is the part of the whole program I care about most. Because in 2026 it no longer matters at all who wrote each line. What matters is whether you can defend it.

Seventy years later, someone still has to decide

There will be people building apps without knowing how to program. There already are. And some of those apps will hold up for a while, the way a building holds up until the day a pipe needs replacing and you find out nobody knows where the pipes run.

The question was never whether the machine can write the code. We've been answering yes since 1957, a little more every decade. The question is who decides which code deserves to reach production. That seat is still empty, and it's the only one AI can't fill.

Learning to find the way is your job. Making sure you don't get lost is ours.

See the Swift Engineering Program 2026