Three Months of Vibe Coding: From Development to Maintenance
What you’ll learn
- What three months of change history reveal about development and maintenance work
- The roles of explicit AI instructions, shared rules, and verification procedures
- What change records establish and what additional records are needed to measure effort or effects
Reviewing Vibe Coding Development and Maintenance through Change History
Vibe Coding means building software by describing requirements to AI in ordinary language. AI Learning Playground’s change history from March 22 through June 21, 2026 records changes to articles and documents, the interface and styles, and AI instructions and checks. It shows work on both the created content and its supporting systems, alongside code generation.
This article examines development and maintenance through those three months of records and the mechanisms in the current repository—a place managing code, documents, and change history. By the end, you will be able to decide what to record for maintenance and which effects require separate measurement. Change history alone does not establish which month felt hardest or which work took the most time.
Preparing Conditions, Rules, and Verification for Maintenance
The diagram connects work involved in preparing for maintenance. It is not a measurement of monthly working time or changing importance. The following sections treat technology, design, and operations as areas to examine rather than chronological phases.
Technology: Specify Behavior and How to Check It
The site uses Astro to build the site and Starlight to provide its documentation interface. Supporting Japanese and English pages requires decisions about the source language, page addresses, and what happens when a translation is missing. Shared rules and configuration files record those policies.
For example, a request to “make navigation support multiple languages” requires different behavior depending on which language is authoritative and where each link should lead. Defining both the conditions given to AI and how to check the resulting interface also supports maintenance checks. This illustrates how to frame a request; it is not a record of an earlier conversation.
Design: Shared Rules and Automated Checks Have Different Roles
The repository contains initial instruction files, CLAUDE.md and AGENTS.md, shared rules under shared/, and automated checks for some of those rules. This article calls the combination of AI instructions, procedures, and verification methods a “harness.”
Shared rules preserve policies that other tasks can reference. Automated checks test whether settings or articles meet specified conditions. Writing a rule and checking compliance are different responsibilities. Determining whether reduced explanation or correction work repaid the preparation effort requires a comparison of working time.
Operations: Continuing Changes to Articles, Translations, and the Interface
The history records overlapping changes to articles and documents, the interface and styles, and rules, procedures, and checks within the same periods. Even in the final window, the work was not limited to one category such as articles or configuration.
Current checks also cover article structure, Japanese/English correspondence, internal links, and existing interface rules. Alongside creating new material, there are conditions to verify after changes. The number of recorded changes does not establish how many published defects or instances of rework occurred.
Three Months of Changes Recorded in Git History
The Git history for March 22 through June 21, 2026 contains 148 commits, excluding records created when separately developed changes are combined. A commit is a saved record of changes such as article additions, corrections, and configuration updates. The period is divided into three windows to count which areas changed. The repository also contains earlier history, so the first date in this table is not treated as the start of site development.
| Period in 2026 | All commits | Changed articles or documents | Changed interface or styles | Changed rules, procedures, or checks |
|---|---|---|---|---|
| 03-22 to 04-21 | 48 | 27 | 21 | 20 |
| 04-22 to 05-21 | 23 | 13 | 14 | 9 |
| 05-22 to 06-21 | 77 | 65 | 22 | 33 |
Each category counts commits that changed at least one file in that area. A commit can appear in several columns, so the category counts cannot be added to obtain the total. For example, of the 77 commits in the final window, 65 included article or document changes, 22 included interface or style changes, and 33 included changes to rules, procedures, or checks. The history shows continuing changes to both content and implementation.
The count is fixed to the history inspected on October 13, 2026, with the recorded author timestamps converted to Japan time. The categories cover articles and documents; interface, styles, and site configuration; and AI instructions, work procedures, and automated checks.
These numbers record activity. They do not measure working time, failures, rework, or the contribution of a particular AI. One commit can bundle several corrections or add new articles.
What Change History Establishes and What Requires Separate Measurement
The records establish that updates to articles and documents, the interface, and shared rules and checks continued during the three months. The count does not reveal which month took the most time, how many repeated explanations were avoided, or whether maintenance was harder than development.
The article on the three-layer harness design covers a defect recorded in the lessons log and checks for conditions that could bring it back. To evaluate working time or rework alongside log entries and commits, each task needs separate records of time spent, correction reasons, and the conditions used for comparison.
Summary: Record Conditions, Rules, and Verification for Maintenance
These three months of history show that maintaining the site involves articles, the interface, and rules and checks. Producing code and checking that required behavior and article correspondence remain intact after changes are separate concerns.
Preparation for maintenance means recording the behavior required from AI, reusable rules, verification methods, and where failed work should return. Determining whether those preparations reduce working time or rework requires measurements beyond change counts. Records from this one site do not establish that the same effects will hold for other team sizes or environments.