Editing Template Code with Claude Code / Codex: From Changing Colors to Adding Features

The EazyOPC idea: after the site is generated, the ongoing polish goes to coding assistants like Claude Code or Codex. You don't need to know how to code, but you need to know how to direct — direct well and everything goes smoothly; direct sloppily and the AI can wreck a perfectly good site. This post is about how to direct.

Step 1: Have the AI read the project first

After opening the whole folder with the coding assistant, don't fire off instructions yet. First have it read the delivery package's START_HERE.md, CLAUDE.md, and AGENTS.md, then have it summarize in one sentence what the project does and what its stack is. If the summary is right, it understood; if it's nonsense, it looked in the wrong place — don't let it change code yet.

Start with the smallest changes: colors, copy, logo

The first time you direct the AI, three changes are enough: primary color, homepage copy, logo. The prompt should name files and scope, like:

Change the site's primary color from the current ink black to dark blue — only touch the theme color variable, don't change layout or spacing. When done, tell me which file you changed.

Constraint sentences like “only change the theme-color variables, don't touch the layout” are crucial. AI assistants default to being enthusiastic — if you don't constrain them, they may “optimize” button radii and font sizes along the way.

How to write prompts so the AI doesn't break things

• ·One thing at a time. Don't put “change the color” and “add a page” in the same instruction — split them into two
• ·Name files or directories. If you know where it is, say so; if not, have it find it first (next section)
• ·Say what not to touch. “Don't change the database schema,” “don't touch payment code” — draw the forbidden zones upfront
• ·Have it verify itself after changing: run the type check (npm run typecheck), and tests if there are any

Before adding a feature, ask it “where to change”

When you want a feature, don't say “add me an XX.” First ask: “In this project, which files hold the code related to XX? Just find them, don't change anything yet.” Only let it touch code after it finds the right place; rephrase if it finds the wrong one. Two extra minutes here saves half an hour of rework later.

What to do when it breaks: don't panic, just roll back

Before touching anything, have the AI commit the currently working version to git (git commit). That's your undo medicine. If the change goes wrong, one rollback command takes you back. The principle: small steps, fast — change a little, verify a little; don't pile up a huge change into one commit.

Have the AI write tests: the safety net for code changes

Many people have the AI change code and only check whether the page looks right. The page may look right while the checkout flow is broken. Having the AI write tests insures your important flows. How: first have it check whether the project has tests and what framework they use, then name the two or three most important flows for it to test — e.g. “checkout succeeds,” “the admin panel is unreachable when logged out.” Have it run them; all green is what counts. Every time you change code after that, run the tests first — red means something broke, caught on the spot instead of waiting for users to yell at you.

Tests don't need full coverage; cover the core flows. For a small personal site, a dozen test cases beat half an hour of manual clicking before every launch. And the tests are written for the AI itself: next time you ask it to change a feature, it runs the tests first and knows on its own if it broke something — you don't have to be its human test machine. The return on this investment is high; the earlier you write them, the better.

Code review checklist: have the AI check these 5 things after editing

• ·Did it touch files it shouldn't have: payment code, database schema — if this task didn't ask for them, don't touch them
• ·Did it run the type check and tests: npm run typecheck and npm test — only all-passing counts as done
• ·Did it leave debug code behind: console.log, temporary comments, fake test data — clean them all out
• ·Is any copy left over: sample text, placeholder English — all replaced before launch
• ·Are edge cases handled: empty data, network failures, user typos — the page shouldn't just go blank

Copy this checklist straight to the AI: “After editing, check yourself against these 5 points, fix any problems yourself, then tell me the conclusion.” AI reviews more carefully than humans — provided you hand it the checklist. After a few rounds you'll find it catches more problems on its own than your eyes catch. The list can keep growing; add a line every time you hit a new pit.

Three prompt templates: changing copy, changing styles, adding logic

Changing copy is the safest — say exactly what and where: “Change the homepage main headline to “Launch your paid site in three months”, the subheadline to “No coding needed”. Copy only — don't touch styles or layout. Tell me which file you changed when done.”

Changing styles is medium difficulty — small before big: “Change the site's primary color to dark blue. Only the theme-color variables; buttons, links, and accents follow along. Don't touch layout, spacing, or font sizes. Run the type check when done and tell me which files you changed.” Remember the constraint “don't touch X” — that's what stops the AI from free-styling.

Adding logic needs the most care — two steps. Step one is find-only: “In this project, which files hold the user-login code? Just find them, don't change anything yet.” Once it finds the right ones, step two: “After successful login, add one line of logic: record the last-login time. Don't touch the login flow itself; run the tests when done.” If it finds the wrong files, rephrase — don't settle.

When a change breaks: how to describe the problem to the AI

When something goes wrong, don't just say “it's broken, fix it.” Give the AI three things: the symptom (which page, what you clicked, what you saw), reproduction steps (first click where, then type what), and the original error text (the red console text, the terminal error — pasted in full). The more complete the info, the faster it locates the problem. The more your description sounds like “it's broken,” the more its fix sounds like “a guess.”

Saving money: don't let the AI idle

Coding assistants bill by their own pricing, so spend the money where it counts. Three money-saving habits: state the requirement fully in one go instead of thinking out loud — the AI asking back and forth burns money too; have it find the code location before changing it — redoing a wrong change costs more than one extra question; do small stuff like copy changes and image swaps yourself — it's faster than delegating everything. The AI is hired for heavy lifting, not for tightening screws.

Big changes: have the AI write a plan first, act only after you approve

For changes touching more than three files, don't let the AI act directly. First have it output a plan: which files, what changes in each, how to verify afterward. You review it, and only say “go” when it looks right. Five extra minutes here saves two hours of rework. If the plan contains “while I'm at it, optimize XX” — send it back. Don't optimize what you weren't asked to.

Roll back: commit before changing

Before the AI touches anything, have it git commit the currently working version. That's your undo medicine — one command brings you back if it breaks. The principle: small steps, fast — change a little, verify a little; don't pile up a big change into one commit. With one giant commit, when something breaks you won't know which line caused it, and rolling back hurts.

Change one page at a time

While changing page A, don't also “optimize” page B on the way. Changing multiple pages together means you can't localize which change caused a problem, and fixing gets harder. One page at a time — verify it, then move to the next. Slow is fast; that saying is especially true for editing code.

Have the AI write comments and docs after changing

After the AI changes code, have it add three things: comments on the key logic, a list of which files changed, and updated docs if the usage changed. You think you'll remember now; three months from now you won't. Docs are written for future you, and for the next AI that takes over — if it can't read how you changed things last time, it will improvise.

Don't let the AI guess: give it the original error

When asking the AI about a problem, don't send screenshots — copy and paste the original error text. It can't read the words in a screenshot clearly; pasted text it can analyze line by line. Give it the three things: symptom, reproduction steps, original error text. The fuller the info, the faster it locates it; say only “it's broken” and it can only guess — and guessing costs your money and time.

Build the habit: write a note after every change

Every time the AI finishes a change, write three lines: what changed, why it changed, what verification showed. Keep it in the project's change log. After half a year you'll understand this project better than most outsourced developers — because every entry is something you personally verified. Next time you change something similar, you can name what to touch without asking the AI from scratch.