AI has changed the speed at which I can move through some parts of development.
It can explain an unfamiliar error in seconds. It can turn a rough idea into a first draft of a function. It can remind me of syntax I have not used in months. It can help me compare approaches before I commit to one.
That is useful.
What I do not believe is that usefulness removes the need to understand what is happening.
The more capable AI coding tools become, the easier it is to confuse producing code with engineering a product.
Those are not the same job.
I use AI. I also keep a list in my head of places where I trust it less.
I like AI for getting unstuck on syntax
There are many things I understand conceptually but do not remember character for character.
A regular expression. A particular JavaScript array method. The shape of a configuration file. How a library names one of its options.
In those situations, AI can be faster than jumping between ten tabs.
I can describe what I am trying to do, get a starting point and then verify it against the actual documentation.
That last step matters most when the library changes quickly.
AI can sound certain while using an API from an older version.
Confidence is not version control.
I use it to explain errors, not just remove them
If I paste an error message into an AI tool, I try not to ask only:
Fix this.
A better question is:
What are the likely causes of this error, what evidence would distinguish them, and what should I inspect first?
That changes the interaction.
Instead of getting a random patch, I get a debugging map.
Then I can open the browser console, Network tab, server logs or database and test the explanation.
I want the tool to help me reason faster, not replace reasoning with a code block.
It is useful for boring transformation work
Some development work is necessary but repetitive.
Turning an object into a TypeScript interface. Writing a first-pass validation schema. Creating test cases from a list of expected behaviors. Converting a simple function from one style to another. Generating sample data that does not contain real user information.
These are good places for AI because I can define the expected result clearly and inspect the output quickly.
The risk is low when correctness is easy to verify.
I use AI as a reviewer, but not as the final reviewer
One of my favorite uses is asking for criticism of code I already wrote.
I might ask:
- What edge cases am I missing?
- Where could this create duplicate requests?
- What happens if
dataisnull? - Is there a race condition here?
- Which assumptions should be tested?
- What security boundary is missing?
The answer is not automatically correct.
But it often gives me a second angle.
A human developer can also miss things. The advantage of AI is that I can request another pass immediately: performance, security, readability, failure handling.
The disadvantage is that it can invent problems that do not exist or miss the one that matters.
So I treat it like a fast reviewer whose comments still require judgment.
Where I trust AI less: authentication and authorization
Security-sensitive code gets a higher standard.
If AI gives me a React component that hides an admin button, that does not mean the admin function is secure.
If it creates a Supabase query, I still need to understand the Row Level Security policies protecting the table.
If it suggests storing a privileged key in frontend environment variables, that is a serious problem even if the application “works.”
AI can produce syntactically clean code that violates the architecture's trust boundaries.
For authentication and authorization, I want current official documentation and I want to understand why access is allowed.
I trust it less around payments
Payment-related logic is another category where “looks correct” is not enough.
Money introduces states that simple demos ignore: initiated, pending, successful, failed, reversed, duplicated and timed out.
A frontend success message is not necessarily proof that a payment was finally settled.
If an AI-generated implementation assumes the browser is the authority for payment status, I need to question it.
Any product dealing with money needs stronger server-side verification, idempotency thinking, clear records and careful handling of retries.
That is not where I copy a long answer and hope.
I do not let it invent my database model blindly
AI can create a schema quickly.
The problem is that schemas carry product assumptions.
Should an artist have one profile or several?
Can a seller have multiple shops?
Can a username change?
What happens to related records when an account is deleted?
Which status values should exist?
Those are not only SQL questions. They are product decisions.
If I ask AI to design the whole database before I have thought through the behavior, I can receive a technically reasonable structure for the wrong product.
I prefer describing the rules first and using AI to challenge them.
I verify anything tied to a fast-moving library
Web development moves quickly enough without a model remembering an old API.
When I use React, Supabase, a deployment platform or another actively developed library, I check current documentation before publishing or shipping important instructions.
This is especially important for tutorials.
A tutorial can look professional and still waste somebody's evening because one method changed six months ago.
AI makes producing technical content easier. That gives me more responsibility to verify it, not less.
I do not trust generated code I cannot explain
This has become my simplest rule.
If I cannot explain what the function receives, what it returns, what external state it changes, how it fails and why it is safe, then I am not ready to put it into an important part of a real product.
I can ask the AI to explain it line by line.
I can reduce it.
I can rebuild part of it myself.
But “the model wrote it” is not a maintenance strategy.
The day the code breaks, the product belongs to me, not the chat that generated the first version.
AI is strongest when I keep ownership of the problem
The best sessions I have with AI start with me bringing context.
I know the product.
I know what the user is trying to do.
I know which constraints matter.
I know what I have already tried.
Then the AI helps me search the solution space faster.
The weakest sessions are when I give it a vague instruction like “build my app” and accept whatever architecture appears.
That can create a lot of code before I have created much understanding.
My current rule
I use AI aggressively where mistakes are easy to detect and cautiously where mistakes can affect security, money, private data or long-term architecture.
That means I am happy to use it for brainstorming, syntax, explanations, refactoring suggestions, test ideas, documentation drafts and debugging hypotheses.
I slow down for authentication, authorization, payments, destructive database changes, secret management, production migrations and security decisions.
AI has made me faster.
The skill I do not want to lose is knowing when speed is the wrong goal.
Software is not valuable because code appeared quickly. It is valuable because the product behaves correctly when a real person depends on it.
That responsibility still sits with the developer.