AI Coding Tools Are Not the Problem, Lack of Accountability Is
Just opening a PR without checking AI-generated code is not an issue with AI, it's an accountability issue!
This week’s newsletter is sponsored by Tinybird.
To share what we’ve learned over the last 5+ years running petabyte-sized clusters, we built a free course on ClickHouse®, the underlying database we use in Tinybird.
Tinybird helps companies like Vercel, Canva, and Framer query billions of rows in milliseconds, powering instant analytics and real-time user experiences.
The course is designed for developers who want to master the basics and build faster, smarter data products with production-ready skills.
Thanks to Tinybird for sponsoring this newsletter, let’s get back to this week’s thought!
Intro
Today’s topic is something I have on my mind for quite a while now, and I’m seeing quite a few engineers making this mistake across the industry.
And that mistake is:
Not taking the full ownership and accountability of your actions and decisions, and blaming AI for the output that YOU used.
AI is like any other tool, it’s here to help you, not to do the work instead of you. And we all should treat it like that.
However, I definitely get where the negative sentiment regarding AI tools comes from, and in this article, we’ll do a complete breakdown + I’ll also share my top 5 tips for doing AI-assisted engineering the right way.
Let’s start!
Practical Example of the Mistake Engineers Make When Working With AI Coding Tools
What I am seeing and also hearing happening regularly, especially with less experienced engineers, is the following:
They are assigned a task, and they use a certain AI coding tool, use their agent mode to finish the task, and then they don’t go the extra mile to actually understand what has been changed and ensure the changes are made within the guidelines of the codebase.
They open the PR, and because they didn’t REALLY take ownership and ensure they are delivering good quality code, this puts a lot of pressure on reviewers to find all the mistakes and completely shifts the work on them.
There may be a lot of comments on PRs, and it takes a lot of time to review correctly. And even in some cases, engineers give up and just approve the PR, which makes things a lot worse in the long run.
What happens next is where a lot of teams and people get it wrong. Instead of holding the person accountable for opening a PR full of AI-generated slop, they instead look to “blame” AI coding tools or AI in general.
But, a very crucial thing here is that AI is like any other tool, and it’s here to help us, not to shift the accountability from the person submitting a PR to AI, which should NEVER happen.
For me, personally, if I see a PR opened full of AI-generated slop, that particular engineer would lose a lot of credibility in my eyes. Or even worse, if they mention that the mistake is there “because of AI”.
Every good engineer should know and realize that overall accountability is on them to ensure that good-quality code is delivered and not look to shift the accountability elsewhere.
Of course, I get it, we all make mistakes, but at the end of the day, submitting a full PR of AI-generated slop or blaming AI for a mistake is not a good look.
Now that we completely understand where the issue is and what the desired mindset is, it’s important to take one step back and go through where the reason for the negative perception of AI is coming from.
I Completely Understand the Negative Sentiment Regarding AI in the Engineering Industry
Before we go further, it’s really important to mention that I completely get the negative perception of AI and AI tools in our industry.
This is the reason why that is the case:
Well-known public figures like Mark Zuckerberg, Andy Jassy, Dario Amodei, etc., are sharing sensationalistic predictions regarding AI replacing engineers and everyone else in the workforce.
That trickles down to company leaders feeling FOMO (fear of missing out) regarding AI, thinking it’s a magical tool that will solve ALL the problems, and they enforce the AI usage and AI tools.
And that makes the lives of engineers and engineering leaders really hard, because they need to manage those unrealistic expectations and also work in such an environment.
As we mentioned already in this article: Why 51% of Engineering Leaders Believe AI Is Impacting the Industry Negatively, this is the reason why a lot of engineers and engineering leaders have a negative perception of AI and are feeling less motivated today than 1.5 years ago.
Here is also the full visual presentation:
And being in the engineering industry, it’s tough to be positive about it, when everyone is saying that it’s just a matter of time before “all the engineers get replaced by AI”.
But, at the end of the day, it’s really important to understand that all the sensationalistic takes are said publicly with the incentive to sell their products.
I have already debunked why engineers won’t be replaced anytime soon, so definitely check the article I wrote earlier this year.
The Negative Perception Regarding AI is Not an Excuse to Deliver PRs Filled With AI-Generated Slop
Now that we understand a common mistake engineers make working with AI and also why there is a tendency to start blaming AI for low-quality code delivered, let’s go through one of the posts I saw recently:
There are two important things to mention:
The first one is that ~60 PRs a day made with Devin is just impossible to review correctly, and success shouldn’t be measured by the number of PRs merged.
And the second one is that the team is moving away from AI coding tools, because it’s harder to review AI code than write it themselves.
These two points are completely different radical sides. The first one is complete “vibe coding”, and the second one is completely not using AI anymore. Where in reality, the best case is the middle route, which is AI-Assisted Engineering.
I have shared my opinion in this post:
AI coding tools are not the problem. The problem is accountability.
It's really important to realize that as an engineer, you need to take ownership of your work and not just blindly open PRs without improving and testing the code to fit the guidelines and desired behavior.
Use AI coding tools, but use them to help you, not to do the work instead of you.
Just opening a PR filled with AI-generated slop is a fast way to lose credibility.
This is the most important message I want to get across today. Don’t neglect the importance of good engineering practices, and also use the tools that make you more effective, but don’t shift the accountability elsewhere.
And AI-assisted engineering is the way to go. It means that you focus on good engineering principles while using AI to help you be more productive, where it makes sense.
An engineer doing AI-assisted engineering doesn’t blindly trust the decisions and directions that AI makes via prompts and knows that the ultimate accountability is on them and not on AI.
Now that we understand that the middle route is the best way to go, let me share my top tips for being successful when doing AI-assisted engineering.
My 5 Top Tips For AI-Assisted Engineering
So, the first one, we already mentioned at least a couple of times in the article :)
Make sure to take full accountability and ownership
Treat all AI-generated code as your own responsibility. Test it, review it, and make sure that you completely understand it before submitting. It should never happen that you submit a line of code without knowing what it actually does.
Use AI as a thought partner, and not just blindly trust
Don’t use AI on autopilot, treat it like a co-pilot instead. Ask to explain concepts, generate boilerplate, or explore solutions, but never let it replace your role in critical thinking, system design, or architectural decisions.
Your pragmatism, intuition, domain knowledge, and ability to evaluate trade-offs are irreplaceable. To help you with this, I really like the C.R.A.F.T.E.D. prompt framework → you can use it to help you with common engineering tasks.
Check out also a full guide on Prompt Engineering by Miqdad Jaffer, Product Lead at OpenAI.
Prioritize understanding over speed
Focusing purely on faster delivery can be dangerous if it comes at the cost of a lack of understanding. Your workflow should never look like “copy-paste and pray”.
Take the time to review and internalize what the LLM generates. Rushing PRs just because you can now generate 10 a day leads to technical debt, and what we mentioned above already, reviewers will have a really bad time reviewing these PRs.
There should always be a person responsible, full automation is not a reality in AI-assisted engineering
Don’t aim for full automation. AI in software development should always include human oversight, especially in critical systems.
From planning and design through to implementation and testing, there should always be a real engineer making the final call.
AI amplifies existing practices, so make sure to focus on developing them
This is really important to understand:
“AI tools amplify what you already do.”
If you know how to build the right way, AI boosts your productivity. If not, it magnifies bad habits. Good engineering fundamentals matter a LOT. AI isn’t a substitute for a lack of understanding.
Last words
AI tools can definitely help you move faster and automate the boring parts. But they can’t replace the one thing that makes engineering trustworthy, and that is clear ownership.
As soon as you’re trying to move the ownership and accountability on AI, it’s not a good look for you, and it’s just going to result in loss of credibility.
The right way to go is AI-assisted engineering → use AI to help you be more productive, not to do the work for you and replace your thinking, your pragmatism, and intuition.
Let’s end this article with the following:
At the end of the day, the best engineers are not the ones who generate the most code. They are the ones who can say with confidence: “I understand this. I verified it. I own it.”
You got this!
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.