Despite all of my doom casting on the future of AI, surely there’s a sliver of hope, no? After all, the stock market hasn’t completely crumbled. People are still making cool things. I’m making cool things still. Perhaps there is a way to incorporate AI into our work properly. Perhaps the definition of a good engineer changes dramatically in the next year. In this article, I’m going to talk about what I think makes a good engineer and what I think will make a good engineer in a year’s time.

I think a lot of my existential crisis-ness has come from the fact that this standard that I’ve always held myself to is now wildly different. Mastery of algorithms, of code best practices, engineering standards: all of these things held a physical artifact in the code itself. Executing proper engineering has always derived from writing good code. Proper engineering has always been defined as not just proper architecture but proper implementation.

AI has completely stripped the implementation layer from us – yielding me entirely wrong in my past prediction. I’d argue that you don’t even have to know how to engineer a system to engineer a system well with AI. You just ask it to engineer the system well, and it does it. This is becoming increasingly relevant as each new model comes out, and is far beyond the “boilerplate” or “a couple test cases”. It’s something that a lot of engineers either fully lean into and embrace the threat of our careers, such as myself, or that engineers reject completely.

So, where do we become relevant as an engineer? Today I’m gonna explore the facts that I know to be true about AI, and how, while it does eliminate tons of responsibilities from engineering, it will eventually mold the field into something new. I’ll outline these as roles that the modern software engineer will have to mold to. I’m not sure which ones will stand out the most, but these are going to be roles that become increasingly more prevalent in today’s AI society.

“The garbage collector”

This is obviously the first role that comes to mind because AI has for sure produced tons of garbage code. As time goes on and models get better, it will produce less garbage code, but there still needs to be somebody who can course correct the AI. This role, which I dub the garbage collector, is something like a PR reviewer where instead of your job being to actually make the code, you just have to be really good at reviewing code.

I also think this is the most modern form of software engineer at this current point in time. AI does a really good job of creating features from the ground up, but it doesn’t do a really good job at contextualizing all of the best practices, all of the frameworks that engineers already have in place. It’s like bringing a computer into a manual file cabinet. Until you’ve offloaded all of the files from your physical file cabinet to the computer, the computer doesn’t become that useful the second you bring it in the office.

However, continuing that analogy, if you do move all the documents to the computer, yes, it will eventually take over. This is why I believe that the garbage collector is going to be the most phased-out role of a software engineer in the distant future, just because of how much better AI is getting at contextualizing information. Fable 5 proved this to me most, where suddenly I needed to course correct it way less because I was able to actually understand the full context of everything I was doing.

The verdict: the garbage collector might work for the next few months, but ultimately I think that it’s kind of a cope, and you should focus on one of the other ones.

“The software architect”

This is ultimately where I see most software engineers going: not the ability to make software, but to architect software. Many senior and principal engineers already do this. They get a lot done but don’t actually touch any code. My original take was that actually all engineers are just going to be senior engineers. However, it’s a bit more than that because you’re not just sitting at a high level observing everything. You’re actually involved with every single step of the way. It’s like if a senior engineer was also doing the implementation for everything. Not only do you have to know how to architect the system, but you have to make sure that the implementation follows the blueprints.

This is similar to the software design I talked about in the previous article, where simply designing how the software gets made makes the software. Again, though, it’s a bit different than senior engineer because I do believe you need to be in the weeds a little bit. You have to know, when errors and bugs arise, what to do.

I’ve been realizing this very painfully over the past few months, trying to offload literally everything to AI. I’m hit with a brutal reality that while AI can theoretically do everything, it can’t do everything to the standards that I would expect as an engineer. This, I think, is actually a pretty good thing. First of all, it means I’m not completely out of a job. Second of all, of course, it’s very confusing, because then what is my job? This is where the software architect comes in. You design not only the infrastructure of the software you’re making, but you’re with it every step of the way. You guide the AI. It’s your companion; it’s not replacing you entirely. If you let it do that, I promise you’ll have bad software.

I think companies are very quickly realizing that AI cannot architect software very well. The best AI that can architect software is Fable 5, and even that needs to be honed in on specific systems and best practices, and ultimately needs to be read and interpreted by the existing engineering team. The software architect is the strongest position, I think, for any engineers who are wondering where their life goes now.

It’s much more than a prompt engineer. You have to understand how systems work. You have to understand what breaks code and what makes code. Your intuition has to be refined to the point where you can scan an AI’s code and immediately tell if it’s going to make or break something. Again, this is something that senior engineers probably already are able to do: look at code and immediately tell if it’s not going to work, just based on understanding what it does.

I guess you can see it like code is the new documentation, where documentation used to be the means for us humans to understand what the code was doing. Now, when you’re architecting software, the code itself becomes the documentation. And instead of product managers that aren’t technical, bridging the gap between product and software, I think it’s going to be software engineers or software architects that are able to effectively bridge this gap, because they have the ultimate form of documentation, which is the code. Not only that, but AI can very efficiently summarize code, so I’d argue you don’t have to be entirely in tune with the coding language. However, you do have to be tactically minded. You can’t understand code without understanding logic and why code is even needed.

“The design engineer”

This is one that personally interests me a ton, coming from front-end engineering.I know a lot of companies like Google use the term design engineer as a literal job title, but it ends up not being more than front-end engineering dabbling in a couple Figmas. No, the future design engineer, I think, will be not only somebody who is proficient at software architecting but also be able to design software similar to a UI/UX designer. Because if there’s anything AI is absolutely terrible at, it’s design, it’s art, it’s anything visual.

The design engineer won’t be as popular as the software architect, just like front-end engineers aren’t as popular as full stack engineers. However, just like front-end engineers, teams will need design engineers. Instead of having a bunch of people on the frontend and a design team, you could just have a single UI/UX designer and a single design engineer working in tandem to produce the best frontend code possible in the quickest amount of time. At a certain point, you might not even need the UI/UX designer or the design engineer. You could just have one person to do both.

So yeah, this one is extremely relevant because AIs can’t do art. I’ve talked about this before, but AIs don’t have taste. They can’t look at a picture and explain why it’s pretty. They don’t have sentience, etc., so that’s why somebody with an eye for design is still going to be needed.

“The token optimizer”

I’m not even kidding when I say that this becomes a real thing that companies are really going to want to explore as these models get more and more expensive. Because at the end of the day, if you can’t afford the tokens, you can’t afford the queries that these software architects and design engineers are firing at the AI, then you have nothing. Optimizing AI usage is going to be a field of its own, I think, perhaps even a profession, just like optimizing code at a low level. People still work on Python, people still work on Rust. At the same time, people will work on ways to optimize sending tokens to AI. There might be entire businesses spawned because of this.

This kind of engineering has nothing to do with your ability to code. It has to do with successfully extracting information from the LLM at the least possible cost. Not something I’m personally interested in, but it seems like a huge rabbit hole that you could go down. I’d argue companies moving into the AI world in the near future won’t be able to live without a token optimizer.

Conclusion

These are just some of the trajectories I see engineering going towards an upcoming year or two. I think massive companies will be forced to restructure their organizations because they’re not formatted in a way that best facilitates these new types of engineers. Software engineering is not tiered anymore. It’s mostly flattened to a single layer. That is, everybody is implementing and using AI to do code. I think organizations are going to be flattened. I think layoffs are going to continue. As people see these new roles and as engineers realize these new roles and mold into them.

Again, my opinion on this has been changing literally every day for the past year, so take everything verbatim with a grain of salt. This is more to explore the potential of what is to come in the field of engineering.I obviously don’t want it to die. It’s something I’ve lived my whole life for. I love computers. I don’t think I’ll ever stop loving computers, so I’ll definitely explore this as I work on my career progression – and follow the blog for more updates!