# А что если наВайб-Кодить? (What If We Vibe-Code It?)

#source

## Source Metadata

- **Date of material:** 2026 (references tweets from March and July 2026)
- **Raw path:** `raw/sources/А что если наВайб-Кодить.md`
- **Source type:** viewer's conclusions from a YouTube video (5:31), Russian; https://www.youtube.com/watch?v=zBcWcignqng
- **Author:** unknown (a developer; his company uses Datadog and pays "literally millions a year" for it)
- **Ingestion date:** 2026-07-29

## Core Claims

1. **Writing code was never the bottleneck — and never the cost.** Developers could always have written their own Jira or Datadog; they didn't because they didn't *want to run the result*. AI removes the writing cost, which was ~zero of the total, and leaves the real cost untouched.
2. **The cost of software is maintenance, not development.** The problem starts after the first user: bugs, regressions, feature requests, logs, monitoring, on-call, uptime responsibility.
3. **An internal service is an internal business.** A company that vibe-codes its own tracker/logger is either switching businesses or running two IT businesses at once — bad for the company (pays for one product, team builds another) and for the developer (two jobs, blamed for both).
4. **"I can write it in a week" ≠ "it's worth writing."** Between those two statements sit years of support. The vendor's price buys the removal of operational load, not the code.
5. **The pendulum case:** two tweets months apart — March 2026, a company builds its own Jira clone and migrates to it; July 2026, back to buying a tracker (Linear) because nobody wanted to carry the in-house product. "Assemble in two weeks — easy; carry it forward — impossible."
6. **A build-vs-buy checklist** for the AI era: size of the dependency (small, non-evolving libraries — fine to rewrite); does it need ongoing support (if yes, it's a separate project); what operational load does it add; is the business ready to open a second IT business inside itself. If the answers are bad, stay on the paid service — even with Claude / Antigravity / Codex at hand.
7. **Self-correction:** the author retracts his own earlier claim that "many services will die because of AI" — he now says he was wrong.

## Key Evidence / Details

- The Jira→Linear pendulum (claim 5) is the source's only external evidence; both tweets are second-hand and the company identification is fuzzy ("the same or a similar company"). Status: tentative.
- The author's own company is living the case study: pays millions/year for Datadog, is building an in-house replacement while also evaluating cheaper vendors — i.e. he criticizes the pattern from inside it, not from abstention.
- The checklist (claim 6) is prescriptive, not observed — the author's recommendation, not a documented practice.

## Connections

- Creates [[maintenance-is-the-real-cost]] — the source's central concept, new to the vault.
- Direct counterweight to [[explosion-of-internal-software]] and [[emacsification-of-software]]: both pages already flagged "maintenance is assumed away" as their weakest point; this source is the first to make that objection its whole thesis, with a named failure case.
- Sharpens the boundary of [[code-as-throwaway]] / [[make-more-cheap-code]]: throwaway code is safe *because it never has users*. The trap begins exactly where code stops being throwaway — the first user makes it a service.
- Agrees with the vault's spine from an unexpected angle: "writing code was never the bottleneck" is the same premise as [[harness]]-over-model and Theo's verification bottleneck — the sources disagree only about *which* non-writing cost dominates (verification vs. maintenance).
- Counters [[thorsten-ball]]'s prediction range: his club app passes the author's checklist (small, no SLA, no external users), but his "teams will remix Riverside" prediction is exactly what the pendulum case punishes.

## Open Questions

- Where is the threshold? The checklist says "small, non-evolving libraries — yes; services with users — no," but the interesting zone is between: a 20-person club app, an internal HR knowledge base, a personal fork in `~/bin`.
- Does the maintenance objection survive agents doing the maintenance? The author assumes ops load lands on humans; the corpus's outer-loop material ([[agentic-loops]], [[async-by-default]]) implies agents could carry some of it. Nobody in the corpus has evidence either way.
- Who is the author, and does his in-house Datadog replacement ship or die? The pendulum predicts die.

## Change Impact on Wiki

- Created [[maintenance-is-the-real-cost]] (new concept).
- [[explosion-of-internal-software]]: the "nobody owns the result" uncertainty upgraded from self-criticism to a sourced contradiction; scoping added (the club app passes the source's own checklist).
- [[emacsification-of-software]]: the "maintenance is assumed away" objection now has a source and a failure case.
- [[code-as-throwaway]]: boundary bullet added — throwaway is safe because unshipped; first user converts code into a service.
- [[thorsten-ball]]: contradiction added (pendulum case vs. his remix-and-build predictions).
- [[overview]]: divergence list and frontier-side bullet updated with the build-vs-buy counterweight.
- [[2026-07-28-webinar-theses]]: scoping note added to T5 (the thesis survives — its examples are checklist-safe — but gains an honest boundary).