Déjà Vu: A Reflection on Engineering and Competence in the Age of AI

Introduction

Do you know how to implement QuickSort? Bubble Sort? Merge Sort? Great. Now a more interesting question: when was the last time you actually implemented one? Probably quite a while ago. And yet, I bet you've sorted data many times since then, whether with sort(), an ORDER BY in SQL, Excel's sorting function, or one of the countless libraries that abstract the problem away. Did you stop understanding sorting algorithms? Of course not. You just stopped implementing them by hand because a better abstraction became available. This happens all the time in computing. If you studied computer architecture, you probably implemented combinational circuits (how I miss PCS2355... not!), built adders, wrote Assembly programs, or had to think about manual memory management. Today, most of us work with high-level languages, rely on libraries written by other people, run applications in containers, and consume cloud services without thinking much about the enormous number of layers underneath them. Every one of those layers faced resistance. There have always been people who confused a new abstraction with a loss of competence. As if no longer manipulating registers meant understanding less about computers. As if programming in Python were somehow "less engineering" than programming in C. Maybe every major abstraction is first perceived as a loss before we recognize it as a gain. Lately, I've been having a strong sense of déjà vu. I remember defending Python to colleagues who practically argued that C was the only "serious" programming language. C was faster, gave you control over memory, produced more efficient programs, and kept the programmer closer to the machine. Python, on the other hand, was interpreted, dynamically typed (what a sacrilege!), slow, and hid details that many considered essential knowledge for any good programmer. The inevitable result, according to that argument, would be generations of professionals who understood less and less about computers. I never saw it that way. My argument was practical, not dogmatic. When I was implementing cryptographic algorithms and we were chasing milliseconds, C—with routines written in Assembly!—was the right tool. In other situations, Python abstracted away a huge amount of detail that simply wasn't adding much value to the problem I was trying to solve. That meant I could spend much more time thinking about the application domain and much less about the mechanics of the implementation. Today, I think we're having almost exactly the same debate again. There's a quote attributed to David Wheeler that I particularly like:

"Any problem in computer science can be solved by another level of indirection."

I think he was absolutely right. But today I'd add another:

Every successful abstraction changes what it means to be competent.

AI as the Next Abstraction

Until now, the major abstractions in computing have mostly abstracted the machine. AI is a different kind of step. For the first time, we're starting to abstract some of the cognitive work involved in software engineering and, more broadly, in computing itself. AI can now write code, produce documentation, suggest architectures, generate tests, translate between languages, explain APIs, summarize articles, build queries, review pull requests, and help with many other tasks. What matters to me isn't so much the quality of any single output. It's the fact that we can now usefully automate activities that, until recently, depended almost entirely on the intellectual work of specialists. I certainly don't work the same way anymore. I write less code today, but I produce more. Time that I used to spend implementing things is now spent deciding what should be implemented, why it should be implemented and, most importantly, how best to implement it. Implementation still matters. But it is no longer the main bottleneck. The harder part is understanding the problem correctly, breaking complex systems down into manageable pieces, making architectural decisions, integrating different technologies, and critically evaluating what the AI produces.

The Same Story in Cybersecurity

If you work in security, you've probably seen something similar before. For many years, a large part of threat intelligence was distributed as IoCs: hashes, IP addresses, domains, and URLs. David Bianco captured the limitations of this approach with the Pyramid of Pain. The progress wasn't in abandoning IoCs. It was in realizing that they were representations of something deeper. As we move up the pyramid toward TTPs, we spend less time chasing individual artifacts and more time modeling adversary behavior. We moved up a level of abstraction. And by doing so, we became better at building robust defenses. Maybe we're going through the same transition in computing now. Code is a representation. A KQL query is a representation. A Sigma rule is a representation. An IoC is a representation. Even a prompt is a representation! For a long time, being good at producing these representations was a pretty good proxy for competence. AI weakens that connection. It can produce very good representations. But that doesn't mean it understands the problem those representations are supposed to solve. What matters increasingly is understanding what sits behind them: understanding the problem, forming good hypotheses, designing solutions, recognizing limitations, evaluating trade-offs, and exercising technical judgment. In other words:

Knowledge hasn't become less valuable. It has just moved somewhere else.

Method

If you agree with the argument so far, is the answer simply to "use AI"? That would be about as useful as telling someone to "write a program" to solve their problem. The difference was never the tool. It was always the method. "Working with AI" isn't a skill in itself. It's a discipline. It means learning how to break problems down, provide the right context, validate answers, understand limitations, integrate tools, and build processes that are reliable and reproducible. I've learned a lot from following Matt Pocock. One observation of his stuck with me in particular: AI pushes our work toward strategic thinking. The more I look at my own day-to-day work, the more I agree. I spend less time producing technical artifacts and more time thinking about how those artifacts should be produced in the first place.

Conclusion

I've seen colleagues treat "work produced with [the help of] AI" as if it were automatically inferior. I don't see it that way. Much of the history of computing is the history of people learning to create more value by working at progressively higher levels of abstraction. Compilers didn't make knowing Assembly less valuable. High-level languages didn't make knowing C less valuable. Frameworks didn't make understanding protocols less valuable. AI is simply giving us another level of abstraction. And, as has happened many times before, that changes what competence looks like. We'll still need a deep understanding of the fundamentals of computing. Maybe more than ever. The difference is that this knowledge will be expressed less through our ability to produce representations ourselves and more through our ability to formulate problems, design solutions, guide intelligent systems, and exercise technical judgment. AI doesn't make engineering less important. It makes it more important. Because once execution is no longer the main constraint, the things that actually distinguish a great professional become much easier to see. The history of computing isn't the history of writing more code. It's the history of having to write less and less of it to solve bigger and bigger problems. The challenge isn't deciding whether we're going to "use AI." It's learning how to actually work with it.