Most of us are probably using AI the wrong way.
We treat it like an all-knowing senior architect or a slot machine. We type in a vague prompt, pull the lever, and hope it spits out production-ready code.
But AI should speed up implementation, not replace your understanding of the problem.
If you let AI write code you don't understand, you don't really own that code. You're not just moving faster. You're accumulating technical debt.
Think of AI as a fast junior engineer
AI knows the syntax. It can generate code in seconds. It can even suggest solutions that look impressively sophisticated.
But it has one major limitation: it doesn't understand your system unless you give it the context.
You wouldn't let a junior engineer push code straight to main without explaining the architecture, defining the requirements, and reviewing their PR.
You shouldn't do that with AI either.
When you ask AI to implement a feature without explaining your tech stack, existing architecture, or performance constraints, it has to guess. And when it guesses, the result is often generic, fragile, or unnecessarily complicated.
The solution isn't to write longer prompts just for the sake of it.
You need to provide the structure if you want to trust the solution.
Here are three examples of how to put this into practice.
1. Migrating a database
Database migrations are a great example of where blindly trusting AI can get you into trouble.
A vague prompt might look like this:
"Write a script to migrate this database."
The problem? AI doesn't know your migration strategy, table sizes, downtime requirements, or whether the application needs to remain compatible with the old and new schema during deployment.
Instead, start by designing the approach yourself, then use AI to challenge it:
"I am planning to migrate our PostgreSQL schema using the following approach: [describe approach].
Our database has approximately [X] rows in the affected table, and we need to avoid downtime.
What edge cases, locking issues, performance bottlenecks, or rollback risks am I missing? Suggest ways to make this migration safer."
Why this works: You're responsible for the design, while AI acts as a second pair of eyes. It can help you identify edge cases and risks you might have overlooked before they become production incidents.
2. Understanding legacy code
When working with legacy code, the temptation is to ask AI to refactor it immediately.
But rewriting code you don't understand is a great way to introduce bugs while making the code look cleaner.
Instead of:
"Refactor this function."
Start with:
"Explain the business logic of this function.
Identify its side effects, dependencies, and assumptions.
Then suggest how to break it into smaller, more testable functions without changing its behavior."
Why this works: You first build a mental model of what the code actually does. Once you understand its behavior and dependencies, you can make informed decisions about how to refactor it.
AI becomes a tool for understanding the system, not just rewriting it.
3. Writing tests
Writing tests is another area where AI can be particularly useful.
When we write tests for our own code, we tend to focus on the happy path. We already know how the function is supposed to work, so we often overlook unusual inputs and edge cases.
Instead of:
"Write tests for this function."
Try:
"Generate unit tests for this function using Jest.
Focus on edge cases, null and undefined inputs, boundary conditions, invalid inputs, and unexpected behavior.
Identify any assumptions the function makes that aren't explicitly enforced.
For each test, explain what potential bug it is designed to catch."
Why this works: AI can help you think beyond the scenarios you already have in mind. It can generate a broader range of test cases and help you discover assumptions that deserve to be validated.
Of course, you still need to review the tests. A test that simply confirms the implementation's current behavior isn't necessarily a test that verifies the intended behavior.
The real value of AI isn't writing code
AI won't replace software engineers, but it is changing how we work.
The typing part is getting faster. Generating boilerplate, writing straightforward functions, and producing repetitive code are becoming less time-consuming.
But the real engineering work hasn't disappeared.
You still need to understand the system, make architectural decisions, define constraints, and verify that the solution actually solves the problem.
In fact, as AI makes implementation faster, these skills become even more important.
The goal isn't to write as much code as possible with AI.
The goal is to deliver better software, faster, without sacrificing your understanding of how it works.
Use AI to challenge your thinking, explore unfamiliar code, and catch mistakes.
Let it accelerate the work, but never outsource your engineering judgment.
Thanks for reading!