Claude Fable 5 and the New Programming: From Turbo Pascal to AI

Every time a more powerful artificial intelligence model appears, the same question comes back: are programmers finished? With Claude Fable 5 the question sounds louder, because we are no longer talking about an assistant that writes isolated functions or fixes a syntax error. We are talking about models capable of understanding entire projects, reasoning about architecture, debugging, proposing changes, writing documentation, reviewing security, and helping carry on long conversations about code, product, and technical decisions.

I don’t believe this is the end of programmers. That would be too simplistic. What I do believe is that we are entering an enormous democratization of software development. And that democratization is going to affect every level: the senior professional, the junior developer, the entrepreneur, the systems administrator, the independent creator, and anyone who has a clear idea but not always the time, the team, or the energy to turn it into a real application.

In my case I have experienced it in a very personal way. I started programming in another era, with Turbo Pascal, Turbo C, Delphi, and those tools that forced you to understand the machine, the compiler, the libraries, and your own limits very well. Then professional life takes you down other paths: companies, infrastructure, cloud, management, sales, marketing, projects, clients, teams. You don’t lose your technical judgment, but you’re no longer writing code every day the way you used to.

And, suddenly, AI has given me back part of that programming ability with less effort.

Not because the model does magic. Not because you ask it to “build me an app” and a serious product appears. But because it dramatically lowers the cost of trying again. It lets you recover speed, ask questions, compare options, test approaches, recall patterns, review errors, and move forward. In my case, that has translated into applications for iOS and Mac like Mbox Viewer Pro, FlarePurge, DocProtect, or FitBono; into tools for Windows like FlarePurge; and into open source projects like mboxshell, designed to open MBOX files from email backups.

It has also allowed me something that interests me almost as much as creating new things: rescuing old ones.

AI as a lever to recover forgotten software

One of the most beautiful parts of this stage isn’t about creating yet another trendy application, but about being able to rescue software, formats, and projects that seemed condemned to oblivion.

Over the past few months I have been able to refactor old and obsolete applications like bitadir.com, programacion.net, or glosarium.com. Projects that had history, usefulness, or personal value, but that dragged along old code, outdated dependencies, inherited structures, and technical decisions from another era. In the past, taking that on required an amount of time that was hard to justify. Today, with AI, you can review, understand, reorganize, and modernize at a very different speed.

It’s not automatic. You have to know what to touch and what not to touch. You have to test. You have to be skeptical. You have to read the code. But the barrier drops a lot.

The most personal example might be UnQuantum, the open source project I launched on GitHub to rescue the Q (Quantum) compression format, that MS-DOS compressor I loved. A format from the 1990s, originally created by David Stafford at Cinematronics, which used LZ77 with arithmetic coding and which had a historical connection to technologies like Microsoft Cabinet. I have reimplemented it in Rust for modern systems, with cross-platform support for Linux, macOS, and Windows.

Years ago, a project like that would have been a mix of nostalgia, scattered documentation, reverse engineering, and many hours of trial and error. It still requires all of that now, but AI helps order the process. It lets you better understand old specifications, compare implementations, write tests, structure the project, review portability errors, and document what you’re doing.

This is not “vibe coding” understood as throwing out instructions and trusting blindly. It’s something else: using AI as an extension of your technical memory, your analytical capacity, and your execution speed.

AI doesn’t destroy development, it changes its price

A few days ago I wrote on this blog about an idea I keep seeing very clearly: AI is not destroying jobs, it is changing the price of work. Applied to software development, something similar happens. AI doesn’t eliminate software. It reduces the cost of producing it, modifying it, testing it, and maintaining it. And when something drops a lot in price, very often it isn’t used less. It’s used much more.

If creating an internal utility used to take two weeks and now takes two afternoons, more utilities will be created. If refactoring an old website used to cost too much and is now affordable, more projects will be rescued. If building a niche app wasn’t economically worth it and can now be launched with less effort, more small, specific, personal applications will appear.

This doesn’t mean everything is going to be good. In fact, the opposite can happen: we’ll have more mediocre software, more code generated without understanding, more unnecessary dependencies, more apps that work in a demo but don’t hold up under real use, more security problems, and more abandoned projects because nobody knows how to maintain what the AI generated.

But that part doesn’t invalidate the change. It only reminds us that development was never just about writing code.

Programming is understanding the problem. It’s organizing. It’s deciding. It’s testing. It’s thinking about the user. It’s knowing when a solution is too complex. It’s knowing when a library isn’t worth it. It’s understanding what data you handle, where you store it, what happens if something fails, how it gets updated, how it’s signed, how it’s distributed, and how it’s maintained.

AI greatly speeds up writing code. But it doesn’t replace judgment.

Those who know how to program will have more of an edge, not less

This is where I disagree with the more alarmist headlines. I don’t see a future where “nobody needs programmers.” I see a future where many more people will be able to create basic or intermediate software, and where good programmers will be even more valuable.

Because when anyone can produce code, the difference will lie in producing good software.

A developer with judgment will be able to do more. Much more. They’ll be able to review the AI’s proposals, detect subtle errors, ask for better alternatives, split up tasks, create tests, design architecture, automate deployments, document decisions, and turn a prototype into something maintainable.

A person without a technical foundation will also be able to create things. And that’s positive. But they’ll depend much more on the model. If something fails, they may not know why. If the project grows, they may not know how to organize it. If a vulnerability appears, they may not see it. If a dependency becomes abandoned, they may not understand the risk.

The difference between “asking for code” and “building software” is going to be more and more important.

And this also affects companies. A company that uses AI only to lay off developers will probably end up with technical debt that grows faster and cheaper. A company that uses AI to multiply its technical teams, document better, reduce repetitive tasks, test more hypotheses, and launch products that weren’t viable before can gain a great deal.

The good question is not: “how many people can I save with AI?”

The good question is: “what can I build now that I couldn’t build before?”

Claude Fable 5 and the problem of overly powerful models

Claude Fable 5 represents this new phase very well. Anthropic presents it as a Mythos-class model for general use, with advanced capabilities in software development, technical work, research, and long-running tasks. But it also arrives with significant safeguards. In certain sensitive areas, such as cybersecurity, biology, chemistry, or frontier model development, the system may limit responses or redirect queries to a more controlled model, like Claude Opus 4.8.

This part seems very relevant to me, because it reveals a contradiction we’re going to see more and more.

On one hand, we want better models. We want them to program better, understand better, find errors, review security, help with research, and automate complex tasks. On the other hand, when the model is too good in certain areas, a reasonable fear appears that it could also be used to attack systems, exploit vulnerabilities, assist in dangerous uses, or transfer capabilities to competitors.

That’s where a new stage begins: very powerful models, but with internal doors.

You don’t just pay for artificial intelligence. You pay for an artificial intelligence conditioned by the provider’s policies. Some restrictions will make sense for safety reasons. Others may get mixed up with commercial interests. And others will simply be inconvenient for anyone who wants to use the model as a high-level technical tool.

This also forces you to think about dependency. If you base your development workflows on a single closed model, you accept its policy changes, its limits, its prices, and its decisions. Just as we learned with the cloud that it isn’t wise to depend on a single provider without an exit plan, we’ll have to learn the same thing with AI.

The risk of programming without understanding

The democratization of development will be positive, but not innocent. We’re going to see a lot of people create software without really knowing how it works. And that has risks.

The first is a false sense of control. If the application starts up, it seems like everything is fine. But maybe it doesn’t handle errors well, doesn’t validate inputs, has no tests, exposes data, misuses permissions, or depends on an insecure library.

The second is technical debt generated at high speed. Before, a bad architecture took weeks to grow. Now you can create a bad architecture in an afternoon.

The third is the loss of learning. If new profiles only ask for solutions and never understand why they work, they don’t develop judgment. This worries me especially with juniors. AI can be an extraordinary tutor if used well, but also a dangerous crutch if it replaces the effort of understanding.

The fourth is homogenization. If everyone uses the same models to generate the same solutions, we’ll see repeated patterns, similar interfaces, copied architectures, and common errors at scale.

That’s why I believe the new technical literacy won’t just consist of learning to program. It will consist of learning to work with AI without abdicating judgment.

From the programmer who writes code to the creator who directs systems

The classic image of the programmer was someone writing lines of code for hours. That figure doesn’t disappear, but it transforms. It will increasingly matter to know how to direct systems: models, agents, repositories, tests, deployments, documentation, APIs, permissions, data, and users.

Value will shift from “I know how to write this function” toward “I know how to turn this need into a system that works.”

That favors hybrid profiles. People who understand business and technology. Systems administrators who know where an infrastructure hurts. Entrepreneurs who know a niche problem. Journalists capable of automating document analysis. Lawyers who understand repetitive processes. Doctors or researchers who know what tool they’re missing. And, of course, programmers who know how to think beyond the code.

That’s where I see an enormous opportunity.

Not everyone will create big software companies. But we will see many more small tools. More personal projects. More internal utilities. More rescues of old software. More local automation. More applications that didn’t exist before because paying for their development wasn’t worth it.

In that world, software becomes more personal. More approachable. More tailor-made.

My personal conclusion

Claude Fable 5 is not the end of programmers. It’s a sign that software development is opening up. Just as personal computers, visual languages, the web, WordPress, GitHub, or the cloud did in their day. Each leap lowered a barrier. Each leap created noise. And each leap made the judgment of those who knew how to use the tool well more valuable.

Coming from Turbo Pascal, Turbo C, and Delphi, I have been able to go back to programming in a way that years ago would have seemed hard to fit into my day-to-day. I’ve been able to create new applications, refactor old projects, recover forgotten formats, and launch open source tools. That doesn’t make me a full-time modern software engineer. But it does prove something important: AI gives back the capacity to create to people who already had experience, ideas, and judgment, even if they weren’t immersed every day in the latest framework.

And that’s going to change a lot of things.

A world without programmers is not coming our way. A world with many more software creators is coming our way. Some will be good. Others will make disasters. The best will be those who combine AI with fundamentals: architecture, security, product, data, testing, user experience, and common sense.

Programming doesn’t die. It shifts.

Before, the question was: “do you know how to write code?”

Now it’s starting to be: “do you know how to direct the building of something useful?”

And there, whoever knows how to program, organize, and think will still have an enormous advantage.

Frequently asked questions

Can Claude Fable 5 replace programmers?

I don’t think it will replace good programmers. It can automate many development tasks and allow more people to create software, but technical judgment will remain decisive.

What changes for those who learned to program years ago?

AI lowers the barrier to coming back. It lets you recover speed, understand new tools, refactor old projects, and create modern applications without having to start from scratch with every technology.

Why will knowing how to program still be important?

Because generating code is not the same as building reliable software. You have to review, test, and understand architecture, security, data, deployments, and maintenance.

What is the risk of creating software with AI?

The main risk is accepting code without understanding it. That can generate technical debt, security errors, dependence on the AI provider, and applications that are hard to maintain.

P.S.: You might just find the Claude Fable 5 model locked down at the request of the U.S. Government because “it’s dangerous,” as if there weren’t plenty of other dangerous things. Although, of course, dangerous for what and for whom…