I Let AI Write My Code — Here Are 10 Things I Never Let It Do Without Checking

AI writes a lot of my code now.

It helps me:

• generate components
• write APIs
• fix bugs
• explain errors
• create tests
• refactor old code
• write SQL
• even plan features

And yes, it saves a huge amount of time.

But there is one rule I never break:

AI can write the code. I still have to own the result.

That means I do not blindly copy, run, merge, or deploy whatever it gives me.

AI is fast.

But it can also be confidently wrong.

Here are 10 things I never let AI do without checking first.

1. Run Terminal Commands Blindly

AI may suggest commands like:

npm install some-package

`

or:

bash
rm -rf some-folder


or:

bash
git reset --hard


Sometimes the command is correct.

Sometimes it is destructive.

Before I run anything, I ask:

• What does this command do?
• Can it delete files?
• Can it overwrite work?
• Can I undo it?

If I do not understand the command, I do not run it.

Simple rule:

Never execute a command just because AI says it is safe.

2. Install Packages I Have Never Heard Of

AI can suggest dependencies that look completely real.

For example:

bash
npm install react-super-auth-helper


But is that package actually trustworthy?

I check:

• Does the package exist?
• Is it maintained?
• When was it last updated?
• How many people use it?
• Does it have suspicious permissions?
• Is there already a popular alternative?

A package name that sounds professional is not enough.

Always verify dependencies yourself.

3. Touch My .env File Carelessly

Your .env file may contain things like:

text
DATABASE_URL=
STRIPE_SECRET_KEY=
OPENAI_API_KEY=
AWS_SECRET_KEY=
JWT_SECRET=


These are not normal pieces of code.

They are secrets.

I do not casually paste them into prompts.

And I do not let AI move them into client-side code.

This is especially dangerous in frontend projects.

For example:

javascript
const secretKey = "sk_live_...";


If that ends up in browser code, your secret may become public.

Rule:

Secrets stay secret.

4. Write Authentication Without Reviewing It

Authentication code can look simple:

text
Login
↓
Check password
↓
Create token
↓
Done


But real authentication involves much more:

• password hashing
• session security
• token expiration
• refresh tokens
• rate limiting
• CSRF
• cookie settings
• account recovery
• permissions

AI may generate code that works in a demo but is unsafe in production.

So whenever AI touches:

• login
• signup
• OAuth
• JWT
• password reset
• permissions

I review it carefully.

"It works" is not enough for authentication.

5. Write Database Migrations and Run Them Immediately

This one can hurt.

AI might generate:

sql
DROP COLUMN phone_number;


or:

sql
ALTER TABLE users ...


One wrong migration can destroy real data.

Before running a migration, I check:

• Does it delete anything?
• Will existing data survive?
• Can it be rolled back?
• Has it been tested locally?
• Do I have a backup?

Never treat production data like test data.

Database changes deserve a second look. Always.

6. Modify Large Parts of My Project at Once

Sometimes I ask AI:

"Fix this bug."

And it responds by changing 15 files.

That is where things get dangerous.

A small bug may suddenly turn into:

• renamed functions
• changed APIs
• new dependencies
• deleted logic
• broken tests

I prefer small changes.

Instead of:

"Rewrite the whole feature."

I ask:

"Find the cause first."

Then:

"Show me the smallest possible fix."

Small changes are easier to understand and easier to reverse.

7. Merge Code I Cannot Explain

This is probably my biggest rule.

If AI generates:

javascript
const result = data.reduce((acc, item) => {
// 25 lines of logic
}, {});


and I do not understand why it works, I do not merge it yet.

I ask AI:

Explain this code line by line.

Then I ask myself:

Could I explain this to another developer?

If the answer is no, I am not ready to own that code.

Because someday that code will break.

And when it breaks, AI may not be there to save you.

Never keep code you completely do not understand.

8. Trust AI-Generated Tests Automatically

AI is great at writing tests.

But here is something funny:

AI can write broken code and then write tests that happily approve that broken code.

For example:

`text
Wrong function
+

Weak test

Green checkmark
`

A passing test does not automatically mean the feature is correct.

I check whether the tests include:

• normal cases
• edge cases
• invalid input
• empty input
• failures
• permissions
• unexpected values

Tests should challenge the code.

Not just confirm the happy path.

9. Let It Make Security Decisions Alone

AI can suggest code like:

javascript
if (user) {
return sensitiveData;
}


But maybe the real question should be:

javascript
if (user.role === "admin") {
return sensitiveData;
}


Security bugs often come from missing checks, not broken syntax.

Whenever AI touches:

• permissions
• payments
• user data
• file uploads
• authentication
• admin actions
• API access

I ask:

What could an attacker do here?

That one question often reveals things the first answer missed.

10. Deploy Straight to Production

AI finished the feature.

Everything looks good.

Now deploy?

Not yet.

My basic flow is:

text
AI writes code
↓
I review it
↓
Run locally
↓
Run tests
↓
Check the diff
↓
Test edge cases
↓
Then deploy


This adds a few minutes.

But those few minutes can save hours of debugging later.

Production is not the place to discover that AI misunderstood your request.

The Real Problem Is Not AI-Written Code

I do not think AI-generated code is the problem.

The problem is AI-generated code that nobody reviewed.

AI is extremely useful when it acts like:

• a fast junior developer
• a debugging partner
• a code explainer
• a test generator
• a research assistant

But I do not treat it like an engineer who should have unlimited permission.

There is still one person responsible for the final result.

You.

My Simple AI Coding Rule

I try to follow this:

Let AI do the typing. Keep the judgment.

AI can write 200 lines in seconds.

Great.

But I still want to know:

• What changed?
• Why did it change?
• Is it safe?
• Can it break something else?
• Can I undo it?
• Do I understand it?

If I cannot answer those questions, I am not done yet.

A Simple Workflow Anyone Can Follow

You do not need to stop using AI.

Just add a review step.

text
Ask AI
↓
Generate
↓
Read
↓
Understand
↓
Test
↓
Review diff
↓
Merge


That small habit makes a huge difference.

Final Thought

AI is making software development much faster.

And I love that.

But faster coding does not remove the need for judgment.

If anything, it makes judgment more important.

Because when code becomes easy to generate, the real skill becomes knowing:

What should I trust?

What should I test?

What should I never allow without checking?

Use AI.

Let it save you time.

Let it write boring code.

Let it help you debug.

But do not hand over your brain with your keyboard.

AI can write the code. You still own what happens next.

What is one thing you never let an AI coding agent do without checking first?

I am curious to hear what other developers would add to this list.

`

`