Software engineering in the age of AI

Something I've been noticing lately, and honestly been thinking about for a long time: our job has changed quite a bit. People talked about the death of software engineering in the past, but lately I've been thinking that what I traditionally thought of as software engineering, and what a software engineer should do, is no longer relevant and will change dramatically in the future.

The first thing I noticed: in the past, there were quite a few sweatshops of software engineers from cheaper countries like India or the Philippines. With the advent of AI coding tools like Claude Code, these companies sort of became irrelevant. The whole benefit was that they provided engineers at a lower cost than what you typically find in Silicon Valley. Now it's just: can those engineers compete with token costs, or a monthly subscription that's heavily subsidized? So that's one place where I saw those companies sort of go away.

The second thing is the life of a typical software engineer, based on me and the people around me. To be a good engineer, the bare minimum was you just had to write code. That's what you're getting paid to do. That's your main working requirement: write code so you can build more product and more features. Now with AI coding, you're outputting so much code every single day that this core requirement of a software engineer just suddenly got fulfilled by AI. So then you kinda think about what else a software engineer is good for. And I think this is why you still see engineers getting hired; there's no huge mass layoff yet. They're being asked to think about the design, new products, new problems, new features, or to own an area end-to-end. I don't think that's an area AI coding tools can quite replicate yet, because they may not have the domain expertise or the full context. For AI to catch up, it would take quite a few integrations. That basically means embedding AI into every single aspect of your work: Slack, transcripts from every video meeting, even the chats you have in person over the water cooler.

Another thing I've noticed is the pattern of engineers, where they sit at their desks. They kinda look like people playing slot machines in Vegas. They just press enter, enter, enter into their coding agent, and in a non-deterministic fashion get an output that's either good or bad, and keep pressing the button waiting for the huge payout. From what I've seen at my work, walking around the office, at the desks, maybe in the cafes too: people don't even open their IDEs that much anymore. It's straight up the coding tool UI, like Claude Code or Codex, and you're just talking to it. You're talking to the AI. If there's a problem like a merge conflict or some failing tests, you just ask the AI to fix it. This takes a few minutes, sometimes an hour, to complete a feature you asked for, but that's okay because you can do a lot of things in parallel and async. You just have to wait. I have coworkers who go on their lunch break during workdays like, "oh yeah, let me just put something on Claude Code," and then they have lunch with their friends and chat while the AI writes all the code. Then you just check back and see what the AI did.

So from a third-party observer's point of view, you kinda start thinking: why am I paying all these engineers a good amount of money if they're going to sit around hitting enter on a coding tool? It becomes less justifiable to pay for all the perks and salaries of these engineers in Silicon Valley. That kinda worries me a little bit, because is what I was promised in my career progression still going to be around when I get older, due to these AI coding tools?

Another thing I've noticed is the shift in the balance of work in software engineering. Before, like I said, writing code was the bread and butter of a software engineer. But now AI is writing the code, and so much of it. You can have AI spin up 10-15 PRs a day, and a human reviewer on the other side just has to process all the code changes. It's a lot. When you have a team of engineers and they're all using AI to write code, all you're doing is reviewing code. And these AI tools sometimes like to write really long descriptions of the code change, or write the code in a really long-winded way. It's just a lot of information to digest. So if you ask me what my day looks like, it's literally: alright, I'll put up some code using AI. But to give my colleagues the benefit of the doubt, I want to make sure I'm not just sending AI slop directly to them. So I review my own code. I make sure the stuff I write, maybe the summary or the comments, doesn't sound like AI. Then after that, I review all my colleagues' code changes, which they also used AI for. It's literally reviewing code written by AI all day long. Even the design docs are written by AI, and that's even more additional burden to digest what the AI has written. So that's why I'm getting a little bit of fatigue. Are you gonna just put an AI to review these documents and code too? Yes, you can. But then at that point, there's no more auditing, and I think you're just kinda giving up and saying: hey, that really lowers the justification of a human engineer in the loop.

Another thing I've been thinking about is the change in how we do engineering. Take coding languages as an example. Previously, there are a lot of coding languages, and you chose one because a) you were familiar with it, b) it was more human-readable, or c) it was more performant. Now the human readability factor is out the window, because if AI is gonna write all the code, you sorta don't need that aspect anymore. Same goes for familiarity. Some people say Rust is not a famous language compared to JavaScript or Python. But languages like that are type safe, can be written more concisely, and are more performant. So now when you try to choose a coding language for your project or your work, that's the thing you're thinking about, not anything else. If you're an engineer who's an expert in one coding language, it doesn't matter anymore. You better adapt to the new language because that's the better one for the coding tool. For example, I don't write Python as much anymore, although I love the language because it's very versatile. But it's not type-safe, and doing some pedantic stuff to make it work is just an extra hassle that's no longer relevant when you have these natively typed languages that are way more performant and easier for the AI tool to understand and write. So now my tools are Cpp, Golang, and I'm introducing Rust, because it just works a lot better for the AI tool.

And then the last thing I'm thinking about is how to automate this a little bit more. In my opinion, the question is: what can I provide to the AI coding agent? Whenever I try to do something, I ask, can this be encapsulated as a terminal command, a CLI tool? If so, you kinda give the agent a different set of tools to do what you're trying to do. For example, I had a case where I was trying to get an AI agent to check if a couple of domain names were available to purchase. What I realized was, I can use this website called Porkbun and their API, so I wrapped that in a terminal CLI and gave it to the coding agent to try all these different domain names using the API, and see what's available and what the prices are. Before that, it was really tedious for me to go into a website UI like Cloudflare, literally type in a name that pops up in my mind, wait a few seconds to see what's available, and repeat that process over and over again. When I could just automate this with AI. So that's another thing that's changed: I'm a little bit more biased toward giving the tools that make the AI agents successful.