Three Months of Vibe Coding: From Development to Maintenance
What you’ll learn
- How Vibe Coding challenges change across technical, design, and operational phases
- The role of clarifying conditions for AI and building a harness that supports later work
- What to decide early so development can transition into maintenance, verification, and handoff
Vibe Coding Has Different Challenges in Development and Maintenance
After three months of building AI Learning Playground with Vibe Coding, I learned that being able to build something and being able to maintain it are different. The difference became clearest when I needed to change published pages without breaking them and when the same review finding returned in later work. People following a similar path can decide before launch where verification, reusable rules, and handoff records should live.
By the end of this article, you will have practical criteria for answering “How do challenges change across development, design, and operations, and what should be prepared before launch?” in your own context.
Vibe Coding Shifts the Time-Consuming Work Across Technical, Design, and Operational Phases
About three months have passed since I started building AI Learning Playground. This article looks back at that period of building a site with Vibe Coding and organizes what I learned across three phases: technical, design, and operational.
I cannot say honestly that Vibe Coding is simply easy or simply hard. I will try to describe as specifically as I can which parts took time and which parts went more smoothly than expected.
Technical Phase: AI Writes Code Quickly, but Conveying Intent Takes Time
The first month was the technical phase, where I built out the Astro + Starlight environment together with the AI.
While AI generates code quickly, conveying precisely what I wanted took time. With an instruction like “make the navigation support multiple languages,” the direction the AI took varied slightly each time. I had to work through each prerequisite one by one — which language to treat as the base, how to structure the URL, what to display when a translation is missing — and then build the instruction around those conditions.
What I learned from this experience is to organize the conditions first and then give the instruction in the form of “write code that achieves this behavior under these conditions,” rather than just “please write code.”
Design Phase: Investing Time in the Harness (the set of rules, procedures, and validation that guides AI work in a project) Made the Later Work Easier
The second month focused on building out the “harness” — CLAUDE.md and the shared rule files — that structures how I give instructions to the AI. Progress during this phase was not visible in the same way, and I sometimes worked through it wondering whether it was really necessary.
By the third month, however, the effect of having built the harness became clear. The AI no longer needed to re-confirm the same things every time, and the amount of instruction required decreased. Adding a single note like “this rule is written in CLAUDE.md” became enough for the AI to refer to it and respond correctly.
Investment in design can look like wasted effort at first. But when there is work that repeats over the long term, that investment can be recovered later.
Operational Phase: Maintaining the Site Was Harder Than Building It
Looking back over three months, the hardest part was not building but maintaining.
Writing articles consistently, keeping the harness updated, periodically reviewing the changes the AI made to the code. None of these are things that only need to be done once — they require continuous effort.
Keeping article quality consistent proved more demanding than I had initially expected. Writing a single article to completion can be done in a short time, but keeping consistency across articles, verifying that translations match the originals, and updating information that has become outdated all accumulate.
Expressing Intent Took More Time Than Writing Code
What took the most time with Vibe Coding was not the coding itself — it was improving the precision of the instructions.
Clarifying in my own mind what I wanted to build, conveying that intent accurately to the AI, and verifying that the generated result matched the intent: the quality of this sequence of steps is directly connected to the efficiency of the overall work. I have come to feel that the ability to put into words what I want — rather than the ability to write code — matters more in Vibe Coding.
Summary: Put Maintenance Rules and Verification in Place Before Launch
My main conclusion from these three months is that maintainability in Vibe Coding depends less on code-generation speed than on expressing intent and turning repeated checks into reusable rules. As a first action, choose one check that is likely to recur before launch and record its owner, verification method, and return path when it fails.
- Further develop the harness, especially around automating the review process
- Improve the accuracy of multilingual article handling
- Build a mechanism for reflecting reader feedback into article updates
This retrospective covers three months of operating AI Learning Playground and does not establish that the same effects will hold for other team sizes or environments. I will continue writing from observed experience.