Should Engineers Use AI for Coding?
AI can make engineers faster, but only when they keep ownership of the problem, the decisions, and the code that ships.
Last week I watched this video about an engineer who decided to stop using AI for coding altogether. The reasons he presented were:
- Loss of Purpose
- Increasing distance from the code
- Amount of code review
- Stunted professional growth
- Environmental impact
I think we can split them into two categories.
Environmental impact
There are many videos discussing the environmental impact AI is having and could have in the future. Data centres and the power infrastructure that supports them use water for cooling.
But other industries consume water as well, so the main question is: how responsibly are you using AI?
- Are you asking AI about the weather outside when you can stick your head out of the window and see for yourself?
- Are you asking for a weather forecast when you could check a weather site yourself? Does that two-minute improvement make AI worth its environmental cost?
Asking AI seemingly "stupid" questions is fine when you are training or researching, but many people asking them at scale still use valuable compute.
On the other hand, this article reports a claim that saying Please and Thank You to ChatGPT costs OpenAI millions. Does that mean you should stop being polite to save the planet? I do not think so—politeness is still how I prefer to interact with AI tools.
Engineering impact
I totally understand these points, but I think it depends on the kind of engineering work you want to do. If your purpose is to write the code itself and put your heart and sweat into it, it is understandable that you feel a loss of purpose. On the other hand, if your purpose is to deliver a feature or product and coding was the way to deliver it, you will find AI very helpful. In reality, this means shifting toward higher-level roles—engineering architect, staff engineer, or product owner. In those roles, you may care less about the code itself and more about the outcome. You place trust in your employees to deliver what you described: what you want to build, improve, or change.
Your responsibility does not change, only the way you achieve it.
From my perspective, engineers are still responsible for the outcome, which code ultimately produces. As AI produces more code, you may spend more time reviewing it—until strong prompts and guardrails make that review more focused.
QA (Quality Assurance) goes hand in hand with this change. Because AI writes unit tests as well, I often find myself reviewing test scenarios to determine whether they test what they should, more than reviewing the generated code. Once you have all the coding standards in place for your project, the generated code is, in my experience, better than code written by a junior developer.
Then you can focus fully on architectural decisions: how you want API calls structured, code formatted, and the database ORM chosen.
So is your professional growth stunted?
With AI, professional growth is probably shifting in a different direction rather than being stunted. You can feel your growth is stunted if it is not the direction you want to pursue. If that is the case, do not use AI.
So I agree with the conclusion the engineer made in the video - in his case.
You need to know exactly why you do not want to use AI. If your reason is simply, "I don't know how to use it," "I don't like it," or "It's weird," you may miss an opportunity to grow in a direction you have not considered yet.
I have already switched from writing code to delivering outcomes. I have distanced myself from the code, and I am doing more code review and QA while I set up guardrails for coding agents. For me, that is okay. It is the direction I want to go.
So choose your path and think how AI can help. If it can't - don't use it.
See you next Monday.