AI can code, what now? Reflections on architecting and engineering post-AI

Published 2026-10-24, About 10 minute read.

About three and a half years ago I opened up ChatGPT and asked it to write a limerick about Area 51:

In the desert, there's a place quite scary
Where conspiracy theories can be airy
It's called Area 51
Where aliens are said to be fun
But the truth remains quite contrary

I didn't think it was all that impressive, and after watching it struggle to do any meaningful coding task I closed the window.

Last week, I was about to log off and I realized I hadn't typed code in maybe weeks. Paradoxically, the past 6 months have been my most productive code-generating period of my career. I had seriously dismissed AI code generation for years, yet in the past 6 months I discovered that AI not only can generate code, but is now the main engine creating the features and platform I work on today. It happened fast. And despite my extreme reservations and strong feelings about AI generated code, it happened to me.

This is the question everyone is thinking: AI can code. Now what? What does it mean to be an engineer?

I posit that there is an irremovable core to software engineering that still exists even in the mode of AI code generation.

Please don't appeal to "taste." It's expertise 📎

I've heard many say that engineers are now the "tastemakers." Many say now that we bring an ineffable ability to direct Claude (or Codex, Cursor, Copilot, Devin, etc., etc...) down the "right path." The reasoning I hear is that humans will always need to be "in the loop." Surely, there is some aspect of coding and engineering not capturable by AI models, even as they grow larger and more sophisticated.

But the word "taste" is doing a disservice to our profession. Choosing good primitives is not taste. Setting up architectures that allow groups of engineers to coordinate many features in a single platform is not taste. Deciding on APIs and what to expose or keep private is not taste. These are all examples of expertise and judgment from humans that understand how code works and have learned through experience how to design systems that are robust.

For example, I have Claude generate TUI applications for my daily workflows. I have it make these executables in Rust. I have only a conversational ability in Rust, but I find with Claude I'm able to generate the applications I want without having to go through the "onboarding" of becoming fluent with a low-level language. I can trust that things written in Rust are robust and performant. These tools help me organize my workflows, my merge requests, and my terminals and worktrees.

My expertise still helps me develop a better application than if we were to throw a junior developer at the same task. When I first booted up the application, I noticed the Rust app was slow in updating the status of all my workflows. I found for some reason the app was fetching MR requests sequentially, so I was able to instruct Claude to use Tokio. I knew enough about network requests, asynchronicity and parallel tasks that I knew that this would be the correct way to refresh fetched data from multiple places. I could tell Claude exactly how to batch requests, what the TTL should be, and what should happen even in the TUI while the requests were in flight. I was able to do this in a minute and move on to other things. This wasn't taste. This was my expertise, hard won from hours of working manually with promises in JavaScript land and learning the ins and outs of network requests, callback hell, async/await, task delegation, microtasks...

Although the level in which software engineers work now has been lifted to a higher level, there still remains an expertise that is objective and tangible. This is also why I am not afraid that AI bots will replace me- just yet.

The skill question is not new nor unique to software engineering 📎

When I was a teacher there was a joke: if you can't hack it as a teacher you can always become an administrator. The idea was that the truly skilled teachers would always stay as a classroom instructor, while those administrators were teachers that didn't have the same skill, and so being a "manager" of sorts meant they could still perform well while relying on the other skilled teachers to do the real work.

I've heard the same joke when it comes to managers and individual contributors. Just read any Dilbert comic ever made. For some of the same reasons as in the teacher world, engineers can "always just become a manager" to avoid the problem of being underskilled and let others do the work.

While there's a reason these jokes exist, we know these are exaggerations. There are great technical people in manager positions, and I've known many great educators that join the dark side of administration.

The important bit I'm getting at is that we have an analogy with AI agents here and a corresponding "joke." If you're not a very good engineer, you can always become an AI manager.

I think this is how the AI-averse can sometimes boil down the code generation question. If we can just "become a manager" and offload "the real work" to agents, what is an engineer supposed to be assessed by? How do we tell when one engineer is actually great, if Claude is doing the work?

But I think this is over-simplifying the question. I also think that this problem of assessing the expertise of software engineers (and any other complex, skilled profession) is not new.

The truth is that we've never had great ways to assess and evaluate software engineer expertise. Often, naming functions, familiarity with colloquialisms like frameworks, and over-reliance on pet coding interview performance have served as proxies for "expertise." Yearly performance evaluations look at things like MR approvals and merges, the number of Jira tickets marked as "done," and the general feelings people have about you.

And so what do we rely on when code generation is shifted to be Claude generated? It's a question that requires evaluators who are are not content to look at proxies to answer.

I'm not saying that it's easy to objectively measure expertise. This has been a long-standing problem in the teaching world, and they haven't fully solved the problem there.

We are now looking deeper and past just "when to avoid duplicating a function" or "what's your favorite CSS framework." We're asking what skilled and expert engineers bring to the table, and now we're forced in a way to set aside the minutiae of these low-value proxies. We want to know, despite the tool choice, what makes you a more effective engineer. These things will distinguish and continue to distinguish us from AI agents.

Unfortunately, companies tend to follow the most evil and simplest solution: moar agents means moar better engineer. OR: We don't need engineers now! Often these decisions are from up on high- the directors or the vice presidents whose minds were blown while being AI-psychosised late into the night.

Tech is not the only area being "disrupted" right now 📎

Mathematicians right now are in a tizzy. If you haven't heard OpenAI released a swath of math results, and Claude has produced proofs of a few major results in outstanding problems.

It's really interesting to see people in this field now reacting. Some respond with resignation.

Some, notably Terence Tao and Grant Sanderson, are arguing that AI is also just exposing a part of their profession that was underserved: understanding and motivated explanations.

Their arguments resonate with me as a software engineer. We now, in many ways, have the mechanism for features and coding quickly written, just like mathematicians are having the proofs assembled and "discovered" for them. But, mathematicians and engineers alike still are integral in understanding, arranging, architecting, coordinating, and communicating out these pieces to colleagues, managers, and the public.

This is the stuff good engineers are made of.

What about those that are becoming engineers today? 📎

When I talk with my mentees and others that are new to the profession, I talk less about code implementation these days. It's been a while since I've had to build a class myself, wire up a request cache, or name a function/variable. Frameworks seem to be more and more the same implementation detail that I don't have to worry so much about at a low level. But I have talked about things like coalescing platform requests on same tick, module federation loading strategies, and implementing scoped web component registries in React (where, by the way, it isn't supported.)

The profession is now less about the detail of implementation, and more about the architecture, the services you provide on your platform, the primitives you provide, and the schemas and APIs you settle on for your data. This is all old school software engineering. We are able to now focus most of our attention on that higher level of abstraction.

At the very same time, communication is quickly being exposed as the major factor of whether you are heard in your organization. Attention truly is scarce, and I've found that how you describe, teach, organize, and explain all matter more now than ever.

I'd also say there is a newer swath of understanding and expertise we need to develop: what is the best way to use these agents now that we have them? I'm finding lots of inspiration from Addy Osmani, Morgan Westlee Lunt, and Qing Wang in their recent writeup on how Anthropic does code review. At the end of the day, we need to understand these tools and how we can best set them up.

If I were to boil it down to a syllabus of what to learn if you want to become or excel at software engineering, the syllabus would look less at language details. But there would be many things kept that I would have included before AI: history of computing, architecture principles, clean code, git and version control, testing architecture, browser fundamentals and APIs...

The core 📎

But let's back up and try to answer the question: how do we know when an engineer is doing a great job? What do we evaluate and consider? In my humble estimation, even while AI might be generating code, an engineer:

These reflections and thoughts are subject to change 📎

When I was a teacher every student had a graphing calculator. When it was time to graph lines, they could put the line equation in the little calculator and the graph magically rendered. I went back and forth. Some years I would force them to graph lines by hand- totally admitting that they could just use the calculators but forcing them anyway, only later allowing them the convenience. Some years I just let them graph on the calculator and leap to the problem solving without the tedium of graph paper.

But the graph paper is how you understand the layer underneath. I found that those who went through the graph paper exercises had a better sense for the concepts. They could feel when something was wrong. They could adjust better when they ran into issues graphing on the calculator. They could communicate to me better what was happening.

I see us now leaping past the graph paper, and I suspect I will be going back and forth on whether this is the best- especially for those new to the field. The graphing calculator speeds us up and sweeps away a whole class of tedium, but we might be better to still earn the understanding hard won through tedious work.

Find me on Bluesky or Mastodon. I also have an RSS feed here

⬅️ Previous Post
Back to top