Welcome everyone. Today I want to talk about something that's been on my mind a lot lately. AI Realism. This talk started out as a blogpost I started writing months ago, where I witnessed:
There's a divide I'm witnessing. Among colleagues, friends and online. And it worries me.
And it's also something that I've been experiencing myself.
Those who love and embrace the seemingly endless possibilities of modern AI. That lean into the hype.
Maybe not hate AI, but kind of hate what our "vocation" is being reduced to. The art of software creation that's losing its soul. Those who are skeptical.
Where do you sit? I want to make the case for a realistic middle ground. Where we can appreciate the power and possibilities, yet acknowledge some risks and realities that come with that.
Introduction, note on that this is my story. The things I've seen and experienced for myself. I'll mention a few outside sources to back up some conclusions I make, but it's my approach to the world of AI.
Play on the worry angle?
But it's hard to deny that it's a powerful tool. Created some landing pages (and looked good!) and created some tools that were very useful to me.
On the one hand, it's hard to ignore the possibilities. I had an idea, described it to my AI of choice, and it transformed my written ideas into something workable at a speed I could never match myself. We can argue about the code behind it, but the result was there.
Even build a Kubernetes cluster with the help of AI, something I could never have achieved in the same time it took now.
Things I could do myself, but that were alot faster and easier when the AI set it up for me. So powerful!
I mean I can write HTML, but AI can do it faster!
But this power has also led to a flood of new ideas and projects, especially online. Where people have gotten to really hate the AI slop.
You can demonstrate the cycle: someone has an idea on Thursday, spends a weekend talking to AI generating code, shotguns it over the internet, and by Monday they're onto the next thing. This has been dubbed "AI slop" or "slopware", "abandonware", etc.
It used to take experience to build software, or to find issues/security flaws. Now it doesn't.
From an article. The worth has changed. But not for the people using the software, for the ones creating the change.
Just an excerpt from a Reddit thread made for new projects. The amount of things being tried out is crazy...
But it's not just new projects. The flood is hitting existing open source too. Maintainers are being overwhelmed.
Open source maintainers are seeing a wave of AI-generated issues and pull requests. This flood is just too much to handle for human maintainers. And it's destroying Open Source, something that the Software engineering world has relied upon for decades!
It's gotten so bad that you see a lot of open source projects now adopting some form of AI policy. With a lot of projects just straight up saying "No" to AI and LLM generated contributions in any form.
A lot of our enterprise clients work in heavily secured environments. Most sane companies would not just let any AI get all-access to all of their data, right? But the hype is powerful. So a lot of companies are exploring. And they should!
And they have long running projects, that are business critical. So that shifts their priorities often.
Then there are companies with a completely different problem. Their software has been around for years. Continuation, maintenance and reliability matter much more than speeding up development or adding features.
AI is incredible at creation. As an AI realist we have to acknowledge the fact that AI can do certain things a lot faster then people can.
But maintenance? Refactoring? Legacy? That's where the current generation seems lacking.
So why is it that AI shines in the creation of new things, but is seemingly much less reliable at maintenance work? Let them sit with it.
My opinion on this can be summarized into a single word. Section 1.
When you really zoom out. LLMs really are an advanced form of autocomplete. They are next-token prediction machines and they base the next token on the context you've created for it.
Imagine you're starting a new project. You create a plan with your AI, write down choices, set up guidelines. You slowly build up the context the AI needs to generate things according to your vision.
If you have experience, you might set up context that makes the AI write code your way. Using a framework you know, tools you've enjoyed. When set up this way, AI is a fantastic productivity booster.
Let's flip the situation. We've inherited a legacy codebase. A project predating AI assistance as we know it today.
The context we deemed so valuable hasn't been gathered the same way. The reasoning between choices as they were made might not be obvious anymore. Why is it done this way? Why does the model look like this? Why did they add that field to the database?
Surely, we could go through existing documentation, retrieve data from old tickets, Git history. Slowly rebuild some context. But it's a completely different approach from how a greenfield project gathered its context.
From practice, we saw that this lack of context made AI much less effective. The idea wasn't wrong, but within an existing project it just didn't fit. And sometimes they're just plain wrong.
Personal example, and you can imagine that finding these 3 mistakes took a lot of effort and would've easily be hidden if I had let it continue running.
But we had other examples, showing us beautiful Java 21 code in a Java 8 codebase we couldn't upgrade, or stuck in old RxJS/Angular patterns because nobody bothered to update it.
When there are no specific instructions, the AI uses whatever is in its context. Old files, old patterns. Where you might want to modernize, it copies the past. And in large codebases, it's hard to determine what's relevant.
It always takes experience to determine what context matters. And unfortunately, a system prompt doesn't replace years of hard-earned judgment. This problem isn't new either!
In the end, someone has to answer for the system as a whole. As an AI realist we gotta acknowledge that even though AI can help us build things faster, we in the end own the problem.
The argument of "AI wrote it" simply doesn't cut it when an important system goes down or makes a complicated mistake that's hard to recover from.
Older example, but it's still a valid question nowadays. Who's in control here?
Someone will have to go in, understand what happened, and take the right steps to recover.
All of the Big 4 consultancy companies have made mistakes. The AI came up with fake references, the company/colleagues didn't check. Now they look bad, not the AI.
It's not unthinkable that an AI agent goes in and takes a first stab. Especially with the enormous hype around AI agents. But even then, a person somewhere will have to be the backup. That someone will have to understand how the system works, how it ties together.
Blaming AI doesn't solve your problems. As realists we assume things WILL go wrong — so we bound the damage on both sides: constrain the AI, and harden the system so a bad call can only do so much.
Kubernetes example; AI was told not to, but did anyway. Better guardrails needed!
We've had juniors make mistakes like this. They were useful learning mechanisms — teams built better guardrails and recovery plans because of them.
Here's the new fear: we learned by doing it ourselves and dealing with the fallout for months. With AI that pain becomes less obvious — but someone still needs the judgment it used to build.
With the enormous rise of AI, we have to think about responsibility. If we only rely on AI, are we really in control?
You all know technical debt. Shortcuts from the past that need to be repaid to your codebase.
Cognitive debt is similar but different. Instead of needing to repay technical shortcuts, we're lending out understanding. Not just as a developer, but as teams. Our shared understanding of how our software works diminishes by over-reliance on AI.
And it's not just a feeling. People like Martin Fowler, Dax, and even Anthropic themselves have observed the same.
Anthropic published results concluding that effectively using AI requires the very skills that atrophy from AI overuse. Let that sink in. Don't know what Atrophy means? Neither did I.
But even Anthropic admitted to seeing the "atrophy" of coding skills. The slow erosion of the logical puzzle-solving skills we built over years. Reduced in size and strength. Becoming weaker.
In my own experiments with agentic development, the speed at which it created code made it hard for me to effectively review and understand what it was doing. Finding a bad decision sometimes felt more like luck than thoroughness.
We've all been there right? Reviewing large PRs? This becomes so much more difficult when LLMs are doing the work and you have to review it all, cause it's your name on the merge.
Although most results were impressive, they didn't feel like what I was looking for exactly. Something was off, and I found it hard to put into words — which made it hard to iterate on.
This is where the biggest trap lies for teams. If teams get gutted because AI makes fewer people possible, the knowledge of how the system works will walk away. The understanding of why things work a certain way will be lost. As an AI realist we have to admit that this is worrying and could be the cause of a lot of problems down the line. So I closed a PR I felt was too large, that I couldn't understand what was going on anymore.
Final sections - Conclusion!
There's an old saying that every good engineer should work towards making themselves obsolete. Perhaps AI is just another big step in that direction. And as AI realists, we have to admit that this power unleashed is not going away anymore.
The biggest personal risk for any developer. The slow decay of hard-earned critical thinking and puzzle-solving skills. It was never about writing code.
Thinking is the most important, which means AI is a fantastic tool that can help us write more, better, faster. That's for sure! As AI realists we can acknowledge that our jobs will never be what they were before.
AI Realist take - use AI as a tool to help you.
Use it as your 24/7, always on, always happy; junior dev, rubber duck, pair programmer etc. Let is explain concepts to you, let it explain how something works, etc. Let is give you new ideas or things to look at to more deeply understand a thing. When you start something large or complicated, start it yourself. You'll understand better what to ask for and what to look for in a good solution.
AI realist also has to acknowledge the incentives at play for the large providers.
Also make sure you can work without your fancy tool, don't only build your workflows directly on these tools. The tokenomics we've seen already reflect that the real cost of AI usage is much higher then what we're paying. And we haven't even mentioned things like ethics, power/water consumption etc.
Take a moment, AI is a fantastic tool, but a tool. It empowers us to do more, faster, better. But when we're using AI to speed up, to be more productive — we should sometimes slow down, stop and think. Am I using AI to think better? Or am I using AI to avoid having to think?