Why Vibe-Coded Apps Script Turns Into Trash After Three Months

Conclusion first: Vibe-coded Apps Script becomes unmaintainable within three months due to name collisions, undefined scopes, absent execution logs, and deleted test functions. Applying a clasp-based folder layout, explicit appsscript.json, test function conventions, and deployment notes extends maintainability beyond twelve months.

Project Layout Standard

Separate files under src/ by feature. Keep appsscript.json, .clasp.json, README.md, and deploy-notes.md at the root.

src/
  main.gs
  utils/
    logger.gs
    retry.gs
  triggers/
    onEdit.gs

Naming Conventions

Use verb+noun for functions, UPPER_SNAKE_CASE for constants, and underscore prefix for private helpers.

Type	Example	Reason
Function	processInvoiceRow	Action is explicit
Constant	MAX_RETRY_COUNT	Single change point
Private	_validatePayload	Prevents external calls

clasp and appsscript.json Management

Minimize scopes in appsscript.json before clasp push and declare timeZone. Record scope diffs in git commit messages.

Logging Strategy

Emit JSON containing Execution ID and input values instead of plain Logger.log. When logs truncate inside the six-minute limit, split transmissions following the retry-backoff note.

Test Function Rules

Place test_ prefixed functions at the end of each file, isolated from production code. Validate with clasp run test_ in CI pipelines.

Permission and Scope Failure Modes

Excessive scopes cause installed triggers to enter the installed-not-working state. When service-invoked-too-many-times errors appear, review when-to-leave-gas.

Handover Documentation

Record deployment URL, trigger IDs, and last execution results in deploy-notes.md. Document rollback steps referencing the no-gradual-rollout note.

When Not to Use This Approach

For sheets exceeding one million rows, sub-second real-time API SLAs, or multi-user concurrent edits, consult spreadsheet-inventory-limits and lockservice-concurrency then evaluate alternative platforms.

Final review criteria

The useful question is not how many features the automation has. It is whether the workflow can be understood, recovered, and safely rerun after something goes wrong.

• Raw input is separated from the human-facing working view.
• Each run records success, failure, processed count, and error message.
• Replaying the same input does not create duplicate results.
• Permission changes, quota errors, and external API failures are visible later.

For low-risk internal tasks, that may be enough. For customer replies, booking confirmation, inventory updates, payments, or legal records, the threshold is higher: compare Apps Script against a dedicated SaaS or a small server-backed system before relying on it.