It's a Great Time to be a Software Engineer

It's been two years of AI use and life couldn't be better.

Published first here.

Here are some thoughts on AI development based on my experience of the last two years. As with any list, these are in no particular order.

1. Get excited. AI is only coming for your job if you treat it as an optional part of your job. It’s here to help you become a better and more efficient software engineer. Embrace it wholeheartedly just like you embraced IDEs in favour of text editors. Using AI doesn’t make you a lesser programmer and not using it doesn’t make you special in any way. In fact, not using it or resisting it makes you look out-of-touch. This is what you have been waiting for to love your job again, and it just might remind you that you got into this business because it feels great to create things, not necessarily code things.

2. Most code (upwards of 80%) should be AI generated at this point. If it’s not, there is something inherently flawed about your workflow. Just put your pride aside, and acknowledge that AI is a better programmer than you. Your coding skills are now worth little, but your software engineering skills are worth a lot more. Invest in the latter, don’t cling on to the former. AI code is still “your” code so you can take the same pride in it as you did before. You just learned how to type faster. A lot faster!

3. SRP, DRY, SOLID and clean design/code should be the focus of the programmer. Guiding AIs to get these right requires understanding the business context in which the software is being used, which AI doesn’t know. How a feature is expected to change in the future, and what trade-offs need to be made there is something you need to be an expert at. Do I create a new module? Is this method named appropriately? Is it taking too many parameters? Am I violating Demeter’s Law? Is this file getting too big? Should I separate these two concerns? What would make this more reusable? These are the decisions you should be spending time on. This requires understanding the product more than you needed to in the past. You’re not only a Software Engineer, you’re a Product Engineer, and that requires a deep understanding of something you may have ignored in the past.

4. Context management (or engineering) is where efficiencies are to be gained. If you find yourself repeating things to a forgetful AI, then that’s a problem to be solved. Simple solutions include Claude Skills and more sophisticated ones include using Beads. Your workflow should be constantly “saving” things to memory to make you more efficient. Sometimes I find myself frustrated by having to remind Claude that it needs to “do X first when it’s doing Y” - those rules should be codified. Don’t treat AGENTS.md or any other instruction file as a static document or it’ll waste your time. How to manage your own context (and your team’s) is something to dedicate time to. If you work in a large company, this is an especially interesting challenge as you have to balance alignment and autonomy, hard rule and guidelines, etc.

5. Everyone should read a book where you build an LLM from scratch. It’s going to be painful and, like me, you’re probably going to have to re-read chapters just to get it through your head (I did, many times), but when it does, you’ll be better off for it. Though chances are you’ll never develop your own LLM and probably use a frontier model most of the time, it helps knowing how things are working underneath the hood. You’ll need to tweak model parameters at some point in your career, and having this foundational knowledge will be the difference between winging it and knowing what you’re doing.

6. Code review is the new bottleneck. The good news is that we already have tools popping up that make this easier (e.g., Code Rabbit). For reviewing code locally, multi-agent workflows work great. Having a separate agent contextualized to reviewing code for correctness, security etc. with rules and guidelines are easy to implement, e.g. claude-code review --aspect "correctness" src/ > /tmp/review_correctness.md. If you’re not using multi-agent workflows, this is an easy place to start. Here’s a couple other candidates: 1) an agent dedicated to providing good commit messages based on git diff, 2) test refactoring agent which gets invoked to clean up tests; shoving test clean up rules into the “development” context may be too much, so having a separate focused agent will work better.

7. There is no excuse not to have clean code. Refactoring is cheap, writing tests is cheaper. If you have code that’s not clean, generate higher-level tests for it, and then ask the agent to refactor. The tests will serve as your guiding light on whether something went wrong. This is especially valuable in brownfield codebases where changes are the riskiest. Having dedicated workflows to “clean up code” is another example of easy to implement multi-agent workflows.

8. Documentation is free. Whether it be inline code documentation, architectural diagrams or Correction of Error analysis, what used to take days now takes minutes. There is simply no excuse not to have comprehensive and up-to-date documentation, both from a product and engineering point of view. Not only should your code describe what it does where clarity is needed, it should also indicate the business rules behind it (whether it be inline or linked to external docs). A programmer reading the code should have a single point of entry to understand both the design decisions and the context in which the customer is using it.

9. Cost optimization is now part of software engineering. Not every task needs Claude Opus, and knowing when to delegate to cheaper AIs is a skill. Even better, a free one like Qwen Code should be installed locally for simple tasks and basic CRUD operations (which is about 90% of all development). Complex refactoring with business context is worth the Opus pricing. You should have mental models about which model to reach for given the problem at hand. Track your AI costs per feature just like you’d track compute costs on AWS so you can optimize your workflow and not just the code. Running expensive models on trivial tasks is wasteful and unprofessional.

10. High-Level System Design is where you are needed. AI will crush implementation details but architectural decisions require human judgment that understands business constraints, team capabilities, and long-term maintenance burden. You need to get better at system design, understanding trade-offs between different architectural patterns, and making decisions that account for factors AI can’t know - like the fact your team hates microservices or that you’re planning to acquire a company next quarter. This is where your value multiplies.