Direct answer: Stop the next feature. Record 1 broken behavior, then add 1 test that fails on that behavior. Check 5 traces: the test command, the width of the diff, the database schemaSchemaExtra description inside page code that tells a search engine what the page is, for example an article, a service, or a question and answer.Open the glossary, secrets in code, and a backup restore. Choose rescue when the base can still grow tests. Choose a core rebuild when every patch breaks another path.
Main condition: Use this check on an application people already use, when each change breaks it. Limit: The list does not prove the application is safe. It does not replace a pentest. Prices below are the Rama Digital catalog on 6 October 2026, not a market survey.
Evidence basis: Rama Digital read Fowler, OWASP, the 2024 DORA report, and the Karpathy quotation on 6 October 2026. The diagrams are proposed checks. The shop example is a dummy-data simulation. We did not test a customer application for this article.
Why does a new feature break what worked yesterday?
You ask for a discount field. The next day, shipping that was correct disappears. Login that worked starts to fail. The pattern repeats because nothing stops a change when old behavior breaks.
On 2 February 2025 Andrej Karpathy wrote that he accepts every diff without reading it, and that the code grows past his comprehension. Simon Willison quoted that post on 6 February 2025. Karpathy limited the note to throwaway weekend projects. An application that already stores orders is not a throwaway weekend project.
Martin Fowler, 1 May 2014, states this attitude: assume that any non-trivial code without tests is broken. An automated test works as a detector. The detector sounds when someone introduces a defect. Without a detector, the team learns only after a customer uses that path.
Fowler also describes the fear spiral that follows untested code. A small fix feels dangerous. The team delays structural cleanup. Each later change makes the next change more feared. A passing test breaks that spiral, because the mistake shows up in the latest change.
The DORA 2024 report associates a 25% rise in AI adoption with an estimated 7.2% drop in stability, across more than 39,000 respondents. That figure does not prove that AI caused your outage. It shows that stability does not rise only because code is written faster. The same figures are unpacked in chaos engineering for vibe coders.
Before the first feature, use the Spec, Task, then Checklist flow. This article starts after the application already breaks on repeat. That linked article is in Indonesian.
What moves when 1 feature is added?
The detector stays silent
Fowler separates the presence of tests from the way they were written. Tests added after the code still count as self-testing code. The condition is that the work is not done until those tests exist and pass. A team that uses this pattern reacts to a production bug by writing a test that exposes the bug first, then changing the code.
The article on RED in TDD shows the same order for 1 behavior. That article is in Indonesian. A useful RED is a test that fails because the behavior is not correct yet. A test that fails because the command itself is broken has not checked the behavior.
The change cannot be repeated
A schema edited directly in the live database has no file for the next environment. A second server, a new laptop, or a restored backup will use a different data shape. Rama Digital recommends storing every table change as a migration file that can run again from an empty database.
A secret is stored in the repo
The OWASP Secrets Management Cheat Sheet states that many organizations hard-code credentials in source code in plaintext. It also states that secrets must not be embedded in code. Deleting the line from the latest commit does not delete git history. Treat a key that entered the repo as a leaked key. Rotate it, then store the replacement outside the repo.
Five signs you can record today
This table is a Rama Digital frame. Fill the evidence column from your repo. Do not invent a number you did not run.
| Sign | Command or place | Evidence to keep | Meaning when present |
|---|---|---|---|
| No automated test | The test command in a terminal. | Output: pass, fail, or command missing. | The next change has no detector. |
| Wide diff | The last feature commit. | Files outside the request. | One task changed parts nobody asked for. |
| Schema drift | The live database and the migration folder. | A table that exists only live. | Other environments cannot repeat the data shape. |
| Secret in code | The repo and git history. | The path. Rotate the key after that. | Treat that key as leaked. |
| Backup never restored | A copy, not production. | Restore time and 1 row check. | The backup schedule is unproven. |
Prepare this before the check
- Read access to the repo and to 1 database copy. Do not use production for a restore test.
- 1 test identity, not a customer account.
- The name of the owner who may rotate keys.
- The test command the team uses, or a written note that the command does not exist.
- 1 last feature commit you are allowed to read.
Step 1: Record the last break
Open git history on the commit that added the last feature. Write 1 sentence for the lost behavior. Use dummy data when the original report names a customer. Example sentence: the checkout total no longer includes shipping after the discount field was added.
Verify: the sentence names the path, the input, and the wrong result. The sentence "the app is broken" cannot become a test. Store the sentence on the same ticket as the commit.
Ask the model to write a test for that sentence. Read the test diff before you accept it. Karpathy’s note shows the risk of accepting a diff unread. On a live application, reading the diff is part of the check.
Step 2: Run the 5 checks and keep the evidence
Run the test command in a terminal. Record the exit code. Open the last feature commit and list files the request did not name. Compare tables in the database copy with the migration folder. Search the repo for key patterns. Restore the backup to a copy, then read 1 row you recognize from dummy data.
Verify: each row has 1 stored proof. Do not paste a secret finding into a public ticket. Store the path in a private note, rotate the key, then write only the status "key rotated" on the ticket.
OWASP treats secret scanning as a control. A search in the editor can be the first step. That scan does not replace rotation of a key that already entered history.
Step 3: Choose rescue or a core rebuild
Read the 5 rows with the application owner. Choose rescue when tests can still be added, keys can be rotated, 1 restore succeeds, and the repair cost stays below a rebuild. Choose a core rebuild when the data shape is unsafe to patch in place and every fix breaks another path. Keep data that is still valid.
Verify: the written decision names the condition you saw, not the age of the code. Repository age does not choose the path. The forensic audit in Vibe Code Rescue uses the same rule: rescue when the base can still be repaired part by part, and a directed rebuild when the repair cost exceeds rebuilding the core.
Worked example: a practice shop adds a discount
Dummy-data simulation, 6 October 2026. Practice Shop has 12 test orders. Yesterday checkout added goods of Rp100,000 and shipping of Rp15,000, for a total of Rp115,000. The new request is a 10% discount on goods. The model draft changes the total function. Shipping is no longer added. We composed these numbers for practice. They are not the output of 1 specific model.
| Time WIB | Input | Check | Output |
|---|---|---|---|
| 09:00 | Request a 10% discount. | Write the shipping behavior that must remain. | 1 test sentence is stored. |
| 09:10 | The diff touches total and the login session. | Reject files outside the request. | Only the total function remains. |
| 09:20 | A test for the total without shipping. | The test fails, which is the expected RED. | The fix restores shipping. |
| 09:30 | A database key sits in a sample file. | Remove it from the branch and rotate the key. | Ticket status: key rotated. |
| 09:40 | Last night’s backup. | Restore to a copy. Read 1 test order. | The Rp115,000 row returns. |
The simulated decision is rescue. The shipping test now exists. The diff is limited. The key is rotated. The copy restore succeeded. A rebuild is not chosen, because the order table shape can still be used.
Replace orders with tickets, invoices, or schedules when your application is not a shop. Keep the split between old behavior, files that may change, and restore evidence.
Checklist for the application owner
Use this list on 1 feature before you open another. Each row has an owner and evidence.
- Product owner: write 1 broken behavior. Store the sentence on the ticket.
- Builder: add 1 test that fails on that behavior. Store the RED output.
- Builder: limit the diff to the requested files. Store the list of rejected files.
- Data owner: match live tables to migration files. Store the name of any table that exists only live.
- Security owner: search the repo and history for secrets. Store the rotation status, not the key value.
- Operations owner: restore the backup to a copy. Store the restore time and 1 matching row.
- Application owner: write rescue or rebuild and the condition. Store the decision on the same ticket.
- Application owner: stop the next feature when the test for the last break does not exist yet, or the backup has never been restored. That is the stop criterion.
Catalog prices when you do not run the check yourself
This table compares 3 paths. Paid prices were read from the Vibe Code Rescue service definition on 6 October 2026. The self-check path has no catalog price.
| Path | What you receive | Catalog price | Choose it when |
|---|---|---|---|
| Self-check | 5 pieces of evidence on your ticket. | Not on the catalog. | You can run the tests and a copy restore. |
| Forensic audit | A written report of code condition, risk, and the rescue or rebuild reason. | Rp 7.5 million. Duration 1 to 2 weeks. | You need a written decision before repair. |
| Rescue | Repairs to secrets, tests, backup, and logs on the current code. | From Rp 25 million. | The base can still be repaired part by part. |
| Directed rebuild | The core is rebuilt. Valid old data stays in use. | From Rp 40 million. | Patch cost exceeds rebuilding the core. |
Rama Digital recommends running Steps 1 to 3 first when you can read the repo yourself. Request a forensic audit when 2 or more signs are still open after 1 working day, or when customer data is already stored in the application.
Common questions
Does every AI-built application break when you add a feature? No. An application breaks on repeat when old behavior has no test that fails when that behavior disappears. An application with that detector can add a feature without repeating a path that already passes.
Are tests written after the code still useful? Yes. Fowler counts tests written after the code as self-testing code, as long as the work is not treated as done before those tests pass. Write a test that exposes the last break before you change the function again.
When is a rebuild a better fit than rescue? Choose a core rebuild when the data shape is unsafe to patch in place and every fix breaks another path. The choice comes from evidence in the code and the data, not from the age of the project.
Is a secret safe after you delete the line from the code? Deleting the line does not make it safe. Git history still stores the old value. Rotate that key, then store the new key outside the repo. OWASP treats credentials in source code as a leak that must be controlled.
Does the chaos engineering article replace this list? No. The chaos engineering article plans deliberate failure after a feature stands. Use this list when an ordinary feature already breaks old behavior. Build the test detector first. Continue to a chaos experiment after the base suite passes.
Do I have to stop all development? Stop new features until a test for the last break exists and 1 backup restore succeeds on a copy. Repair of the broken path may continue. That is the stop criterion on the checklist.
Next step
This checklist organizes evidence. It does not rotate keys for you, and it does not restore production data. When 2 or more signs stay open, read Vibe Code Rescue for the audit, rescue, and rebuild scope. To set scope before a quotation, book a technical scoping session. Bring a redacted symptom ticket. Do not send key values or customer data.
Sources
The sources below were read on 6 October 2026. The recommendations, diagrams, checklist, and simulation are Rama Digital editorial material.
