The More I Develop with AI, the Less I Skip the Process

I use AI to work on my blog now: features, styling, translation and deployment all involve it.

It is genuinely convenient. But the more I do this, the clearer one thing becomes: AI can write the code; that does not make the development process optional.

On Weiyi, cramped typography means changing the type. A table cut off on a phone means fixing the table. Those changes are straightforward, and opening the page afterward tells me a lot.

Multilingual content, analytics and backend APIs are different. A normal-looking page does not prove correct behavior. A successful build does not prove production is fine.

Where I am unsure, I do not let AI invent the answer

A six-language blog sounds like translating Chinese into five other languages. There is much more to it.

Existing Chinese URLs must stay unchanged. Each language needs its own address. Switching languages should open the corresponding article, not send readers back to the homepage. Search, categories and sharing prompts need localization too. Arabic needs right-to-left layout, with code and English model names handled correctly inside it.

Without those requirements, AI might still deliver a “multilingual website.” Its definition of finished just would not match mine.

So I set the boundaries first: what must stay, what needs changing together, and what I will check for acceptance. No fifty-page document is needed. A few clear requirements save a lot of detours.

A vague request is a poor trade for a pile of specific but possibly wrong code.

Optimization means knowing the tradeoff

My analytics scripts are a good example.

They were previously delayed to reduce the initial loading burden. That makes sense if performance is the only concern. Analytics has other needs: someone who leaves quickly may leave before the script runs, and installation checks may misread the setup.

Baidu Analytics and GA4 were later restored to asynchronous loading in the page head.

That made me more careful about asking AI to “optimize” something. Optimize what?

Loading speed, measurement coverage, search performance and maintenance cost do not always improve together. Without a clear target, AI can chase one local metric.

Scores are useful references; the site still has to work well for readers. Likewise, saving a little loading work should not mean losing visits that should be recorded.

And finding a script in live HTML is not the same as confirming that the analytics dashboard received real events. Passing the first check does not settle the second.

I prefer smaller changes

Fast coding makes it tempting to add more: fix mobile while you are there, clean up old code, refactor the API too.

Each request sounds reasonable. Together, they make faults harder to locate and changes harder to reverse.

I prefer one goal at a time. For typography, check reading comfort. For tables, check different screens. For analytics, check loading behavior and production results.

A DORA analysis from March 2026 notes that time saved generating code is often spent again on review and verification.

That fits my view. Fast output does not mean equally fast understanding. With dozens of changed files, simply working out what happened takes effort.

Small changes do not waste AI capability. They keep my verification costs manageable.

“Done” needs evidence

AI can sound very reassuring: completed, tests passed.

I care more about which tests ran and what they establish.

A passing build rules out some problems, not a clipped table on a phone. A healthy API response does not prove that a reader can complete the whole interaction through the page.

Anthropic’s work on long-running agents describes a similar failure: marking features complete without adequate testing. Its approach added feature lists, progress records and end-to-end verification.

AI can execute the work. Acceptance criteria need to exist beforehand.

For my blog, local edits, a passing build, successful deployment and live verification are distinct states. Success in the first few does not excuse skipping the last.

A lightweight process still needs safeguards

I do not want a large company’s approval machinery for a personal blog.

A font adjustment needs no review meeting. URL structure, backend APIs or data deserve another question: what is affected, how do I check it, and how do I recover if it fails?

That is enough.

I use AI to reduce repetitive work and tackle things that previously felt too cumbersome—not to create more code in a project I become afraid to touch.

So I judge development less by how fast AI finishes and more by whether the requirements are met, the changes are understandable, production is checked and future maintenance remains manageable.

Let AI write more code. Do not skimp on the judgments and checks that matter.