The Next Step After Vibe Coding: What It Takes to Move from Building to Sustaining a Site
About This Article
After building a site with Vibe Coding, the maintenance and operations phase introduced problems I had not encountered before. Because the build phase and the maintenance phase presented different challenges, I am documenting the experience here.
The Difference Between Building and Maintaining
During the Vibe Coding build phase, requests to the AI were straightforward. I could say “add this page” or “change this to this design,” the AI would write the code, and if it worked I moved on to the next feature. The cycle was simple enough.
Once I moved into the maintenance phase, the situation changed.
Changes started producing side effects. When I changed the navigation structure in one place, links on other pages stopped working. The AI executes the instruction it receives, but does not always comprehensively check how that change affects the rest of the project.
Content needed continuous updates. As the number of articles grew, pages with outdated information started appearing. Keeping index pages and related links current became more complex as the content grew.
AI context grew. More code means more background information the AI needs in order to act correctly. The cost of explaining “this project has this rule” or “this file must not be changed” at the start of every session increased as the project expanded.
Security concerns appeared. Running a publicly accessible site means dealing with vulnerabilities in dependency packages, paths that should not be exposed, and similar issues on an ongoing basis.
What I Introduced to Make Maintenance Sustainable
A Harness
A “harness” is an automated system that checks whether a change has broken any existing behavior.
Concretely, I prepared scripts that validate content (frontmatter format checks), confirm that internal links exist, and verify navigation structure consistency. Running these every time the AI makes a change means problems can be caught immediately.
I set this up so that npm run harness:check runs all checks together.
A Content Review Process
I set up a checklist to go through before publishing any added or updated article: frontmatter format, citation support, consistency between Japanese and English versions, and whether any prohibited expressions appear.
npm run review:content runs these checks.
Centralizing Constraints in CLAUDE.md
I consolidated the rules the AI must follow into CLAUDE.md. Making constraints explicit—such as “do not run npm run build without explicit user approval” and “do not modify the existing navigation structure”—reduces the risk of the AI making unintended changes.
What I Learned
The build phase centered on deciding what to create. The maintenance phase centers on confirming that changes do not break existing behavior.
Building with Vibe Coding is achievable by chaining requests to the AI. Sustaining what was built requires a system for tracking how changes ripple through the project. Building that system turned out to be more complex to design than implementing features.
As I continued running the site, the distinction became clear: “built it” is a starting point, and whether it can be maintained is a separate question.
Summary
- The AI makes building in the Vibe Coding phase approachable, but the maintenance phase requires a different kind of design
- Problems that appeared in the maintenance phase: change side effects, continuous content updates, growing AI context, security concerns
- What I introduced to address them: a harness (automated checks), a review process, and consolidating constraints in CLAUDE.md
- “Can build it” and “can sustain it” require different skill sets