WebinarNotes/wiki/sources/2026-07-29-what-if-we-vibe-code-it.md

А что если наВайб-Кодить? (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).