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

> Source: <https://dev.to/darun_karasabir_b79602fd/i-let-ai-write-my-code-here-are-10-things-i-never-let-it-do-without-checking-cbk>
> Published: 2026-08-29 10:05:15+00:00

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:

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.

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:

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.

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:

A package name that sounds professional is not enough.

Always verify dependencies yourself.

`.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.

Authentication code can look simple:

`text`

Login

↓

Check password

↓

Create token

↓

Done

But real authentication involves much more:

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

So whenever AI touches:

I review it carefully.

"It works" is not enough for authentication.

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:

Never treat production data like test data.

Database changes deserve a second look. Always.

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:

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.

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.

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

+

Green checkmark

`

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

I check whether the tests include:

Tests should challenge the code.

Not just confirm the happy path.

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:

I ask:

What could an attacker do here?

That one question often reveals things the first answer missed.

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.

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:

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.**

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:

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

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.

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.

```