AI is making engineering faster. But is it making engineers better?

From GPT-3.5 to Today

At the time of writing this post, Opus 5.5, Fable 5.1, Astra, and GPT-6.1 Sol are among the latest frontier models people are using. Compared to GPT-3.5, it genuinely feels like we’ve advanced extraordinarily fast. Current models are roughly 10–15 times more capable and can handle workloads around 250 times larger than what we had at the end of 2022. That’s mind-blowing if you sit down and think about it, and it only takes a few prompts to appreciate how far we’ve come.

What once required hours, days, or even weeks of planning, researching, modeling, writing code, testing, debugging, and eventually releasing can now be accomplished in a fraction of the time. And when I say a fraction, trust me, a lot of things have become way faster.

But…does faster mean better? Most of the time, yes.

With today’s frontier models, speed often comes with better results. The progress is remarkable, to the point that I can understand why some people believe AI is sentient, or that it will eventually do everything humans do, leaving us all to become plumbers.

The Pokemon Fights

With all that said, I’ve seen developers who no longer read code because, frankly, they feel they don’t need to. Nowadays, pull requests can contain thousands of lines of code, and reviewing everything manually becomes a bottleneck. So people simply ask AI to review the code and then merge it. I’ve also seen architects and DevOps engineers who no longer fully understand the systems they’re designing. They don’t read documentation anymore. They just trust the output, generate gigantic Markdown files as “documentation,” and pass everything over to development teams to implement.

Heck, I’ve even spoken with SREs who install Claude directly on their database servers to debug things faster. But what really made me start thinking about all of this as Pokemon battles was watching people argue on social media. Think of whichever platform you prefer, or even workplace conversations on Slack. Nowadays, I feel that many people are gradually losing their critical thinking skills. They copy and paste conversations, discussion threads, or practically anything into a prompt, then use the generated output to construct arguments they don’t fully understand themselves.

In a funny way, I think of this as Pokemon. We’re all Pokemon trainers, and our Pokemon are the LLMs. We let them do the dirty work while we simply communicate our orders and relay their answers. Most of the time, it’s relatively easy to identify when someone is just channeling an LLM’s output into a conversation. What I find particularly fascinating is watching technical discussions between two individuals who don’t really understand what they’re debating. They’re essentially letting their LLMs argue with each other and decide the best outcome, without ever disclosing that the reasoning isn’t actually their own.

So, whose Pokemon is stronger? Is my Opus 5.5 Mid with my carefully crafted prompt better than your Astra Max with yours?

But think about it for a moment. Is this actually a bad thing? Or could it be a good thing? That, I leave it to you.

The Illusion of Understanding

How do you know whether you truly understand something? And what does understanding even mean in the first place?

About 11 years ago, when I was studying telecommunications engineering, one of the professors I admired most, my electromagnetism professor, used to say something that has stayed with me ever since: “If you truly understand a subject, you should be able to explain it clearly in at least three different ways.”

I still think about that from time to time, especially now. Can you explain how your backend handles queues? Do you understand how authentication works in your frontend application? Could you walk someone through the logic behind your database queries, without asking an LLM to explain it first?

This is where I think we need to be careful.

If you’re a solo developer building applications that don’t handle sensitive information or critical operations, perhaps none of this matters that much. You can probably tolerate some downtime, install Claude on your VPS, and let it figure things out. Restart services, debug issues, fix bugs, open pull requests, or even modify production code directly. If something breaks, you deal with it. And there’s nothing inherently wrong with experimenting that way. But not all software exists in that world. Many industries operate under strict availability requirements, handle sensitive customer information, and depend on teams of engineers who are accountable for the systems they build and maintain.

And this brings me to what I consider one of the most interesting consequences of the current AI boom: we’re becoming increasingly capable of building things we don’t necessarily understand.

The dangerous part isn’t that we don’t understand them. It’s that we might genuinely believe we do. And I’m certainly not immune to this. Recently, I decided to vibe-code two iOS applications as a way to “learn” Swift. Both applications turned out beautifully. They work, they do what I intended them to do, and I genuinely enjoyed the entire process.

There’s just one small problem….I don’t understand more than half of the code. In some places, I couldn’t even explain how the application is structured. What started as an experiment to learn a programming language gradually became an exercise in describing what I wanted and watching an LLM build it for me.

And somewhere along the way, I caught myself feeling as though I actually knew how to develop applications in Swift.

But did I?

I could build an application. I could make changes, add features, and solve problems by prompting an LLM. Yet if someone asked me to explain certain parts of the code, or reproduce them without AI assistance, I’d FOR SURE struggle. I had gained the ability to produce something without necessarily gaining the knowledge required to produce it myself.

That’s a fascinating distinction, and one I think we’re going to encounter more and more often.

Of course, none of this takes away from how extraordinary the experience was. Watching an idea become a functional application in a matter of hours, running it in a simulator, and seeing everything come together is genuinely exciting. A few years ago, achieving the same result would have required considerably more time, effort, and technical knowledge. Today, that barrier has been dramatically lowered. And I think that’s wonderful.

But it also makes me wonder whether we’re confusing the capabilities of our tools with our own capabilities. We have access to more knowledge and computational power than ever before, but does that necessarily mean we’re becoming more knowledgeable ourselves? Or are we simply becoming better at asking something else to do the thinking for us?

Only our imagination is the limit now… right?

The Current State of DevOps, SRE, Ops, or Whatever You Want to Call It, in the Age of AI

Before diving into this, I want to clarify that what I’m about to share is based primarily on my own professional experience, along with observations and conversations with other infrastructure engineers working across different industries. Some of these perspectives come from people I’ve met at IT events in Japan, others from DevOps and infrastructure communities around the world, and many from engineers I regularly interact with in my professional life. In other words, this isn’t meant to represent the entire industry, but rather what I’ve been seeing firsthand.

If you spend enough time on Twitter/X, you’ve probably come across countless stories of people building entire applications in a weekend, sometimes completely on their own or in teams of just two people. They vibe-code everything, from the frontend and backend to the infrastructure that runs it all. And honestly, some of what they’re accomplishing is impressive. But there’s a considerable difference between building something that works and being responsible for keeping it working, especially when real customers and businesses depend on it ($$)

The reality of working in infrastructure, particularly within established companies and production environments, tends to look quite different. You are rarely working in isolation. Instead, you are part of a larger engineering ecosystem, collaborating with backend and frontend developers, product managers, QA engineers, security teams, technical leads, and sometimes even legal and compliance departments. Every architectural decision, infrastructure change, or production deployment can affect systems that other people depend on. What seems like a simple technical decision might have implications for security, availability, performance, costs, or the work of an entirely different team. And unlike a personal project, you can’t always afford to experiment freely, break things, and figure out the consequences afterward.

This is where I think the conversation around AI and infrastructure becomes much more interesting. Because the question is no longer simply whether AI can build and operate these systems, but rather how much responsibility we are willing to delegate to it, how well we understand the decisions it makes, and who ultimately remains accountable when something goes wrong.

Databases

In many companies, you won’t be allowed to connect an LLM of your choice, or even a company-approved model, directly to a production server and let it execute commands freely.

Imagine a company running MySQL on a self-hosted or bare-metal server somewhere in a cloud provider’s infrastructure. That machine is probably accessible only through secure channels such as SSH, Tailscale, or a VPN. It might contain sensitive information belonging to thousands of customers, and keeping it operational is critical to the business. Downtime is simply not an option, and if something does go wrong, you better hope there’s a properly designed high-availability (HA) architecture in place.

Traditionally, operations on these machines have been performed manually or through peer-reviewed scripts, with a human engineer responsible for accessing the environment, passing the necessary security checks, and executing the required commands. It could be restarting a service, fixing a database extension, applying an operating system security patch, adjusting database performance configurations, or simply debugging an unexpected issue. Given the current state of AI, corporate policies, and compliance requirements, I find it difficult to imagine most established companies allowing an LLM to execute commands freely on such critical boxes.

Of course, LLMs can help write scripts, prepare step-by-step execution plans, and identify potential failure scenarios. But in many production environments, there is still a need for another engineer, or a few, to review the proposed changes and for an authorized person to execute or supervise the operation.

And why is that? Well, there are several reasons, but these are the ones I consider most important:

1. Accountability. Management still wants a human being responsible when something goes wrong.
2. Operational control. Manually executing an operation gives you a clearer understanding of what happened, where something went wrong, and when. You’re in control.
3. Safety and confidence. Your team knows that what’s being executed is exactly what was reviewed and approved.
4. Unpredictability. We don’t always know what an LLM might do. We think we understand its behavior, but that can be another illusion of understanding. Something goes wrong? Is Claude suddenly going to generate and execute a 200-line Python script to fix something it shouldn’t have touched? Good luck reviewing that during a production emergency.
5. Security and compliance. Legal, security, and compliance teams generally don’t want autonomous LLMs freely operating on machines containing sensitive customer information.
6. Engineering responsibility. Being accountable for an operation encourages engineers to actually understand what they’re doing.

I’m not suggesting we should keep doing everything manually forever. Automation has always been fundamental to infrastructure engineering, and AI will undoubtedly become an increasingly important part of it. But there’s a difference between controlled automation and giving an LLM the freedom to make decisions on critical production systems.

The goal is not to keep engineers typing commands forever, but to make sure someone still understands what’s happening and remains responsible when things go wrong.

Solutions Architecture

When it comes to designing something from scratch that needs to integrate with an existing system, LLMs are quite good at getting the ball rolling. They can analyze requirements, explore different approaches, and offer genuinely useful suggestions on how to design a solution. Until they don’t.

I’ve personally encountered this limitation many times. Even with carefully prepared context and whatever prompt magic the Twitter wizards recommend, there’s almost always a moment when an LLM suggests something that simply doesn’t make sense, introduces unnecessary complexity, or creates a risk that might become a serious problem later. And when someone is just reading aloud a document generated by an LLM without actually understanding the architecture they’re proposing, I’m pretty sure you will notice. That’s not exactly the kind of engineering approach most companies appreciate.

Of course, this process has been evolving too. Nowadays, I see it as more of a hybrid approach, where the architect understands the existing system, knows where things stand, and has a clear idea of where the architecture needs to go. AI then becomes a tool for reviewing decisions, identifying unknowns and unknown unknowns, challenging assumptions, and helping steer the ship in a safer direction, while the architect remains at the HELM (pun intended).

What I find really interesting and fascinating is that this actually pushes us, as engineers, to read and understand whatever the LLM suggests. We are not simply feeding sentences into a model, approving everything it generates, and dumping the result into a gigantic Markdown file for someone else to implement. If anything, we become even more responsible for what we are about to introduce into an existing system. Is it secure enough? Is it efficient? Are we connecting the right components? Have we considered potential failures? What have we missed? Did we accidentally let some AI slop slip into a sensitive part of the architecture?

New architectural designs also need to be explained to other engineers, technical leads, management, and sometimes third parties. And the only way to explain a complex system clearly and simply is to genuinely understand what you are building, rather than just repeating what an LLM suggested.

Personally, this is the part of DevOps I enjoy the most, and I like the direction in which it’s evolving. AI helps us save an enormous amount of time researching new technologies and exploring different approaches, while also pushing us to stay up to date, think outside the box, and challenge our assumptions without losing responsibility for what eventually gets implemented and delivered to customers.

Security

I believe security will be one of the areas that continues to grow the most in the coming years. Cyberattacks are becoming increasingly sophisticated, with new vulnerabilities being discovered and exploited at remarkable speeds. Data breaches, supply-chain attacks, impersonation, and increasingly convincing phishing attempts are just a few examples of what organizations are dealing with today.

Yes, AI can help identify vulnerabilities and even suggest or automate patches, but what happens when, once again, security policies prevent us from running LLMs directly in critical environments? Many operations will still require human intervention, from applying security patches to rotating credentials and secrets (Infiscal can help to certain extent rotations). But with the growing number of vulnerabilities and attack vectors, DevOps and security teams will remain busy securing pipelines, patching containers, monitoring infrastructure, responding to on-call incidents, and proactively testing their systems.

LLMs can certainly help us identify vulnerabilities faster, understand how they might affect our infrastructure, and prepare remediation plans. However, identifying a problem is one thing; safely fixing it in a production environment is another. The actual patching, approvals, verification, and responsibility for those changes will, in many environments, still fall on the engineering teams.

And as AI makes it easier to build and deploy increasingly complex systems, I suspect we’ll also have more infrastructure to secure, more dependencies to monitor, and more potential vulnerabilities to worry about. AI might make individual security tasks faster, but that doesn’t necessarily mean there will be less security work to do.

Final Thoughts

There are several topics I decided to leave out because this post was already getting a little long, e.g: LLMs and their role in managing downtime, cloud and infrastructure costs, full system debugging, high-availability testing, the famous 10x DevOps engineer, and a few others. What I really wanted to share was my perspective on the current state of frontier LLMs and how DevOps, SRE, or whatever variation of the name you prefer, is evolving alongside them.

Some people believe we won’t have jobs much longer, that engineers are being replaced, or that AI is dramatically reducing the amount of work left for us to do. But from what I’ve experienced, the opposite seems to be happening. We’ve never had this much work to do, and I believe we’re only seeing the beginning of it. Pandora’s box hasn’t been fully opened yet, but we’re already catching a glimpse of what’s inside. And once it opens completely, I suspect even more work, complexity, and responsibilities will emerge. AI is making it easier to build things, but that also means more systems to maintain, more infrastructure to operate, more vulnerabilities to address, and more decisions whose consequences someone needs to understand.

And this brings me back to what I consider the most important point of this entire post: the ability to write code and the ability to understand a system are not the same thing. For years, writing software required a certain level of technical knowledge simply to turn an idea into something functional. AI is rapidly lowering that barrier, and I think that’s an extraordinary achievement. But generating working code doesn’t automatically mean understanding the architecture behind it, the infrastructure it depends on, the security implications, or what happens when something inevitably goes wrong. We might be reaching a point where producing software becomes increasingly easy, while truly understanding and taking responsibility for it becomes even more valuable.

So learn how computers actually work. Learn networking, how systems are designed, how applications communicate, how databases operate, and how secure infrastructure is built. I’m not necessarily telling you to become an expert programmer, although programming is incredibly fun and something I still enjoy myself. What I’m saying is that you should focus on understanding the fundamentals of the systems that run all that code. Learn how LLMs work too, explore their capabilities, understand their limitations, and use them to your advantage. Because if you genuinely understand how to design and build systems, writing the code becomes just one part of the problem, and increasingly, one that AI can help you solve.

I don’t think the future belongs simply to engineers who can write the most code, nor to those who can generate the most code with AI. I think it belongs to people who understand what they’re building, can question what AI produces, and know how to make decisions when things don’t go according to plan.

AI might make writing code easier than ever, but it doesn’t make understanding what we’re building any less important. If anything, it makes that understanding more valuable than ever.

---

Originally published at Mirairo.