I Let AI Help Me Code for a Year. The Biggest Lesson Was Not About Prompts.

For the past year, I have been using AI to help me build and maintain a real product.

Not a small demo. Not a weekend side project. Not a page that only needs to look good once.

A real product.

It is an AI customer service SaaS.

SaaS means “software as a service.” In simple words, it means a tool people use through a website, without installing anything.

The product has about 30,000 lines of code.

Code means the text instructions behind a software product. Users do not see it, but the product runs because of it.

My product has a database, a knowledge base, cache, a vector database, and a RAG flow.

That may sound technical, so let me explain it simply.

A database stores normal data. A knowledge base stores documents and information for the AI to read. Cache means temporary storage that helps the product run faster. A vector database helps AI search by meaning, not just by exact words. RAG means the AI first looks up real information, then answers based on that information.

I am not a traditional engineer.

I am more of a product person.

I care about simple things:

Does the feature work? Can users understand it? Will the product break? Can I maintain it by myself?

After one year, I learned something important.

AI can really help a non-engineer build software.

But the hard part is not asking AI to write code.

The hard part is knowing whether the code is actually safe to trust.

Most People Focus on Prompts

When people talk about AI coding, they usually talk about prompts.

A prompt means the instruction you give to AI.

For example:

“Act like a senior engineer.” “Think step by step.” “Write clean code.” “Do not make mistakes.”

These prompts can help.

But they are not enough.

A prompt is like telling someone:

“Please do a good job.”

That sounds nice. But real products are not built only by asking someone to do a good job.

Real products need rules.

Think about a restaurant.

You do not only tell the cook, “Please make good food.”

You also need rules.

Where is the food stored? What must be cleaned? What should not be touched? How do you check the food before serving it?

Software is the same.

In a big company, many people help check the product.

One person writes code. Another person checks the code. A tester checks if things break. A system runs automatic tests. A team controls when the product goes live.

But if you are building alone, those people do not exist.

There is no teammate checking your work. There is no testing team. There is no senior engineer watching every change.

So I had to create my own safety system.

Not a better prompt.

A working process.

AI Does Not Fail Randomly

The biggest thing I learned is this:

AI does not fail in random ways.

It often fails in the same ways again and again.

It guesses before reading the real files. It changes one part but forgets another part. It says “done,” but the real file did not change. It focuses on the new feature and forgets old rules. Sometimes, it edits a long file and cuts off the ending.

That last one is very dangerous.

I call it truncation.

Truncation means a file gets cut off before it should end.

Imagine writing a long message, but the last part disappears. The first half looks fine. But the ending is missing.

This can happen with code too.

AI may edit a long file. The product may still open. The page may still look normal. The main feature may still work.

So you think everything is fine.

But somewhere near the end of the file, something is missing.

Maybe it is a function. A function means a small block of code that does one job.

Maybe it is an important closing part. Maybe it is a path that users do not touch every day.

So the product does not break immediately.

It breaks later.

Maybe after three more updates. Maybe after five more updates.

One day, a user clicks something, and the product fails.

Now the real problem begins.

Because the mistake was not made today. It was made several versions ago.

This is worse than an obvious error.

If the product breaks immediately, you know where to look.

But if it breaks much later, you may blame the wrong thing.

You may think it is the database. Or the server. Or a package update. Or user data.

But the real problem was a file that got quietly cut off earlier.

This taught me one thing:

The most dangerous AI mistake is not always the mistake you see right away.

Sometimes the most dangerous mistake is the one that looks fine today and breaks later.

My product is Chungtair — an AI customer service platform built for Asian SMEs. You can find it at chungtair.com.

My Simple AI Coding Rules

After many failures, I built a simple system.

I call it:

D / A / B / GO / S / P

My D/A/B/GO/S/P workflow for working with AI on real code.

These are not magic words.

They are just rules.

They tell AI when to read, when to talk, when to edit, when to check, and when to save the work.

D Means Download the Real Project

D means download the real project into a sandbox.

A sandbox means a safe test space.

In simple words, it is a place where AI can work without breaking the real product.

This rule matters because AI loves to guess.

If I tell AI, “My product has a knowledge base and a vector database,” it may imagine a common setup.

But my product is not an idea. It is a real product with real files.

So the first rule is simple:

Do not guess. Look at the real files.

A Means Ask First

A means ask first.

Before AI changes anything, it must explain what it understands.

What is the problem? What files may be affected? What is unclear? What does it plan to do?

This step is very important for beginners.

Many beginners ask AI for help, and AI starts editing right away.

That feels fast.

But fast is not always good.

If AI misunderstands the problem, it will quickly do the wrong thing.

So I make AI talk first.

No editing before discussion.

B Means Break Down the Change List

B means break down the plan.

Before AI edits anything, it must list:

Which files it will change. What it will change in each file. What it will not touch. What risks may exist.

Then I confirm.

This prevents AI from doing too much.

Sometimes you ask AI to fix one small button. It rewrites the whole page.

Sometimes you ask it to change one sentence. It changes the whole flow.

AI is not always lazy.

Sometimes it is too active.

So I make the rule clear:

No confirmed list, no work.

GO Means Start

GO means AI can start editing.

But only inside the confirmed scope.

If AI finds a new problem while working, it must stop and ask me.

It cannot quietly change more things.

This saves time.

The slow part is not discussion.

The slow part is cleaning up a wrong change that should never have happened.

S Means Self-Check

S is the most important part.

S means self-check.

But not this kind of self-check:

“I checked everything. It looks good.”

That sentence is almost useless.

A real self-check must check the things AI often gets wrong.

For example:

Did the real file actually change? Was a large file silently not saved? Did the file ending get cut off? Does the file length look reasonable? Does the last part of the file end properly? Did old names remain somewhere? Did visible text get written directly into HTML? Did translation files get updated? Did permissions, cache, or data sync get missed?

HTML means the structure of a web page. If visible text is written directly in HTML, it can become hard to translate and maintain.

Translation files are files that store text for different languages.

In my product, visible text must go through i18n.

i18n means internationalization. In simple words, it means a system for managing different languages.

For example, if the product supports English and Chinese, every visible sentence should be managed properly. I do not want random text hardcoded into the page.

Hardcoded means directly written in one place in a way that is hard to change later.

This is the kind of rule AI may forget when it is busy building a feature.

So I put it into the self-check step.

P Means Push One Clean Version

P means push to Git.

Git is a version history system for code.

A commit is one saved version.

Push means uploading that saved version.

I do not want AI to push every small file change one by one.

That makes history messy.

I want one clean commit for one clear task.

Why?

Because when something breaks later, I need to know which change caused it.

A clean history helps me debug.

Debug means finding and fixing the cause of a problem.

The Mistake That Almost Fooled Me

One time, I was discussing with AI whether I should add two more checks to my self-check list.

One check was about async and await.

Async means the program can do other things while waiting. Await means the program should wait for something to finish before moving on.

Another check was about cache and embedding updates.

Embedding means turning text into numbers so AI can search meaning better.

AI told me these checks were important.

It said my product had async code, cache, a vector database, and a knowledge base. So I should be careful.

It sounded very smart.

It sounded professional.

It sounded so reasonable that I almost started doubting myself.

Maybe I had these bugs and just did not know yet.

Then I told AI to stop guessing and read the real code.

The result was clear.

Those problems were already handled.

Cache was already cleared in the right places. Embeddings were already updated with the data. I even had comments in the code explaining why some cache should not be cleared.

So AI did not find a hidden problem.

It created doubt before reading the real files.

This is one of the most dangerous things about AI.

It does not only write wrong code.

It can also speak with confidence and make you question something that was already correct.

The solution is simple:

Do not let AI guess. Make it check the real files.

The Short Version of My Protocol

Here is a simple version of my AI coding agreement.

You can copy it and change it for your own project.

Start:
Download the project into a sandbox.
All changes must happen in the sandbox, not directly in production.

Core rules:
- Only change the parts I clearly asked for.
- If you want to improve something, explain it first and wait for my confirmation.
- If anything is unclear, ask first.
- Do not guess the system.
- If a file is cut off or missing code must be repaired, compare with the original Git version first.
- Do not invent missing code.
- Before adding or updating packages, explain why and wait for confirmation.

i18n rules:
- All visible text must use the translation system.
- Do not hardcode visible text in HTML.
- Translation keys must be added for all active languages.
- Existing text should be changed in the translation file, not directly in HTML.

Tool rules:
- New file: use the file creation tool.
- Existing small file under 50 KB: use a targeted edit.
- Existing large file 50 KB or more: do not rewrite the whole file.
- Large append over 50 lines: append safely.
- After editing, check the real file on disk.
- Do not only trust what the tool says.

Protocol:
D — Download the real project into a sandbox.
A — Ask and discuss before touching files.
B — Break down the change list and wait for confirmation.
GO — Start only after confirmation.
S — Self-check real files, file endings, line count, diffs, old references, i18n, permissions, cache, and data sync.
P — Push one clean commit after checks pass.

This is not perfect.

It is just useful.

Every rule came from a real failure.

What This Means for Beginners

AI is changing who can build software.

Before, if you could not code, you probably could not build a real software product.

Now, AI can help you start.

You can build a website. A tool. An internal system. Maybe even a small SaaS product.

This is a big change.

But the risk does not disappear.

It only changes shape.

Before, your biggest problem was:

“I cannot write the code.”

Now, your biggest problem may be:

“AI wrote the code, but I do not know if it is safe.”

That is the new skill.

Not just asking AI to create.

But knowing how to check what AI created.

You do not need to become a senior engineer overnight.

But you need to understand this:

“Done” does not mean “reliable.”

AI saying “done” does not mean the real file changed. A page opening does not mean the system is complete. A feature working once does not mean it is safe to ship.

Ship means release the product or feature to real users.

If you are a beginner, this is the lesson I want you to remember:

Do not chase the perfect prompt.

Build your own rules.

Every time AI makes a mistake, write it down. If the same mistake happens again, turn it into a checkpoint. Over time, your checkpoints become your safety system.

Short term, people with better prompts may move faster.

Long term, people with better process will build more reliable products.

The future will not only belong to engineers.

It will also belong to people who understand problems, understand users, and know how to use AI carefully.

The real gap will not be between people who use AI and people who do not.

The real gap will be between people who only ask AI to build, and people who know how to check whether the thing AI built can actually be trusted.

A small note: these lessons came from maintaining my own AI customer service product, Chungtair.

Product site: https://chungtair.com/