I think software engineering needs a new commandment for the age of AI, and it is this:
Do not destroy your own value.
And I mean that pretty literally.
It does not matter whether the person telling you otherwise is someone in your management chain, someone in leadership, a staff engineer, a principal engineer, somebody you have known for years, or somebody on the internet. You still have to think very carefully about what actually makes you valuable as an engineer and whether the way you are using AI is strengthening that value or slowly hollowing it out.
Because there is a fun little contradiction happening right now.
The contradiction
On one hand, people clearly recognize that the expertise in engineers’ heads is valuable. We are constantly being asked to feed that expertise back into tools. Give this code review system better feedback. Write more documentation that is being fed into another AI tool. Curate and clean up these docs. Explain your reasoning. Add more comments and give more context to this ticket—yes, we were doing that before, but now folks want more context and explanations than ever before. Or in other words, add more examples so the AI can do a better job next time.
The entire premise is that your professional judgment and experience is valuable enough that people would like to capture more of it.
And at the same time, there is this enormous push toward “AI first,” where the temptation is to increasingly stop doing the things that created that judgment in the first place.
That is the part I think we need to be much more careful about.
Writing code helps you understand code. Reading other people’s code helps you understand systems. Working through why something failed helps you build mental models of architecture, databases, APIs, deployment systems, whatever it happens to be. You do not need to manually type every line forever, obviously, but you do need enough direct contact with the work that the model in your head keeps getting better.
Because eventually the AI is going to be wrong, and sometimes it is going to be wrong in a way that sounds extremely reasonable.
A very reasonable wrong answer
I had a small example of this recently with a code review. Claude suggested a SQL change that, on the surface, sounded like a useful improvement. SQL is not my strongest area, and I was not particularly familiar with the function involved, so I started digging into it. I had Claude explain the recommendation, then explain the function, then explain why the proposed change would improve things. I looked at the code, went through the explanation, and eventually got to the point where I thought, okay, I understand what it is saying and this seems reasonable.
So I passed the recommendation along.
The other engineer came back and said that Claude had told them it would not work because of a detail in the schema… an important detail.
And their Claude was right, while my local Claude buddy had missed that crucial detail entirely.
The more interesting part to me was that even when I was questioning it and asking it to explain itself, it was still confidently explaining a conclusion built on a bad premise. I had not thought to ask, “Before we go any further, did you actually check this recommendation against the schema?”
🤦🏻 Now I will. Even those of us who catch dumb AI mistakes all the time can be tripped up by dumb AI mistakes.
And that is exactly what I mean by professional judgment. It is not some mystical senior-engineer instinct. A lot of it is accumulated experience with all the little ways things can go wrong, including learning which questions you did not previously know you needed to ask.
Preserve your own learning
That is why I think people need to be very deliberate about preserving their own learning while using these tools.
Have AI make the plan. Have it tell you which files it thinks need to change. Have it scaffold things. Have it explain unfamiliar code. Use the leverage, but every now and then, write the code yourself, read the code that is being generated, follow the architecture, and when a reviewer makes a complicated recommendation, make sure you actually understand what it is recommending and why.
And if there is an area where your knowledge is thin, that is not a reason to disengage from it. That is a reason to learn enough so the next time AI says something stupid in that area, you have a fighting chance of noticing.
I also think this changes how we should think about all the requests to feed our expertise back into automation systems.
I am not saying never give feedback. I am not saying refuse to document things or help improve tools. I am saying curate where your effort goes.
Your time is finite, and right now there is an enormous amount coming at engineers: more generated code, more PRs, more automated reviews, more suggestions, more documentation, more tools asking for corrections and feedback.
I would rather spend more of that finite attention making sure I understand the systems I am responsible for, improving the areas where my judgment is weaker, and maintaining the knowledge that lets me tell the difference between an answer that is correct and one that merely sounds correct.
Because if professional judgment is valuable enough that everyone wants to automate it, then it is valuable enough that you should be very careful not to stop developing your own.
Do not destroy your own value.