Thought Before Creation: How to Ignore the Vibe

What Does it matter?

When developers use LLMs to produce code, it gets easier to create without thought. Thinking is the basis of creating, from art to engineering. When the thought behind creating is removed, so is the intentionality.

It is easy to “give in to the vibes … and forget that the code even exists” once an LLM is introduced to the code stack. Once this occurs and the developer defaults to vibing, any structure and trust is broken.

The code pipeline of old was that thinking about writing code led to understanding the concepts of the requirements, which allowed for the writing of the code, which allowed for the explaining of the code to one’s peers, which led to the team understanding the code. When a developer gives into the vibes, the understanding chain is lost, and the product starts building an insidious kind of debt: Comprehension Debt.

The Stages of Vibe Coding

Vibe coding is prolific throughout discourse surrounding LLM use in development. This term is often ill-defined, unspecific, and lacking in meaning. I would argue there are stages to coding with LLMs:

Vibes-Based Strategies

Type	Use	Explanation
Pure Vibes	Throwaway tools, proofs of concept	The most negative form of “vibe coding” in which the code simply is never read, examined, and should never be committed.
Generate and Skim	Prototyping, first drafts, demos	Code generated this way is meant to be skimmed in seconds, examined whether the shape looks reasonable, then committed and overwritten later.
Tested and Assisted	Internal tools, small batches of code	It is recommended to read line by line what the code does and run tests on it. The key aspect here is read every line and test every function pre-commit.

Engineering Practices

Engineering via LLM

Taking it one step further, a dev can engineer via LLM. To accomplish this, several steps are taken:

A detailed plan is written and edited before any code is written
Tests are in place for code to pass in order to be committed
Code is written via an LLM coding agent
A second agent is run to check the code via tests, linters, builds, etc
Adversarial review is conducted in a fresh context window
(Optional, but recommended) Write out an explanation of the diff. If you feel unable to explain the diff to a colleague, then you are not engineering, you are vibing.

If all steps are taken seriously and utilized, code engineered via LLM can land in production.

Spec-Driven AI Assisted Coding

Four steps:

Specify: Work on the spec. Develop it before any code is written, then develop it in concert with a human or an LLM in order to perform context engineering to allow for the best spec doc possible. The best spec doc is one that describes what (not how), can be interpreted in as few ways as possible, is concise, is consistent, is updated as requirements change, describes as much of the problem as is possible and practical, and is testable. The second best spec is the one that exists.
Plan: Plan how to mitigate context explosion (LLM reading the whole codebase) and spec-code drift. Plan how you’re going to ensure the code is good code. Plan testing, linting, and builds. Planning is the backbone of coding, regardless of whether the code is human written or generated.
Tasks: Having an agent handle each well-defined task under the spec is a key aspect of spec-driven AI assisted coding. The crux is to have the human pilot the assistant and thus have the assistant check in after every step, which the human reviews.
Implement: Have the AI write the code.

There are two hidden keys:

All code that is written must be explainable by the dev to a peer.
A human reviewer is required on all code which touches auth, payments, and personal data.

Upon completion, this code is regulated and tested, and thus can be placed in high stakes environments.

Ownership

In Thaler vs Perlmutter in the US Washington DC District Court, it has been ruled that artifacts predominantly generated via an LLM without meaningful human authorship may not be protected under copyright. This case was pertaining to AI-art, though this claim may be eventually be extended to code.

Legal

For LLM assisted code to be protected, human input is necessary. Therefore, it is essential to record any sessions conducted with coding agents. It is also important to note that code reproduced from training data can pose a substantial risk.

Accountability

With a huge amount of code being pushed that is not human written, accountability poses a huge issue to fault isolation. If no human wrote the code that fails, who is held accountable? The human that approved the commit needs to be named and held accountable for the code written by an LLM guided by that developer.

Comprehension

Comprehension Debt is the operative term in this space: the gap between a developer’s understanding and the code that has been committed. The issue with comprehension debt is that, unlike technical debt (slows the build, tangles dependencies, causes friction), comprehension debt is silent. The builds still compile, the tests all pass, the syntax is clean and coverage meets standards. What happens when a system fails in production if the whole system was LLM-generated without a single human on the team understanding the code?

Maintenance

If a developer has written the code, then they understand it and can maintain that. If an LLM has generated the codebase, there is no longer a guarantee of comprehension. Maintenance requires comprehension, and thus it is necessary to have performed either code engineering with an LLM or spec-driven AI assisted coding for LLM generated code to be trusted in production.

Stats

90% of organizations have adopted AI in software development
84% of developers using or planning on using AI
Over 1 Million pull requests authored by GitHub Copilot from May to September 2025
80% of new GitHub developers use Copilot within their first week
46% of developers don’t trust the accuracy of AI output
17% point drop in code comprehension for engineers using AI to generate code

What does this mean?

The queue has shifted from writing code to reviewing it. Delivery has not sped up meaningfully. Junior development positions are being axed.

Code reworking needs to be measured, both before and after. If the share of AI generated code is reworked more often than the human written code, then there are inherent issues with the AI generated code (either in process or in construction).

The work that hardened juniors into professionals is quickly being overwritten by AI without a working replacement for the pipeline.

LLMs are tools to make our lives easier. If we are not mindful in how we use this tool, we will forget how to do the task which the tool can do for us. If we allow ourselves to be consumed by comprehension debt, we will be buried under the bloated weight of AI-slop codebases. If instead we utilize thought and careful planning, then we will keep comprehension debt to a minimum and allow our lives to be made easier via this new tool.

Do not allow yourself to embrace the vibes. Do not accumulate comprehension debt. Be thoughtful in all creative pursuits.

Sources

Every figure below was checked against the primary source on 2026-08-10.

Stats

Claim	Source
90% of organizations have adopted AI in software development	2025 DORA State of AI-assisted Software Development — n≈5,000, up 14 points YoY
84% of developers using or planning on using AI	Stack Overflow 2025 Developer Survey — AI — up from 76% in 2024
Over 1 million pull requests authored by GitHub Copilot, May–Sept 2025	GitHub Octoverse 2025
80% of new GitHub developers use Copilot within their first week	GitHub Octoverse 2025
46% of developers don’t trust the accuracy of AI output	Stack Overflow 2025 Developer Survey — AI — up from 31% in 2024. 33% trust it; only 3% “highly trust”
17% drop in code comprehension	How AI Impacts Skill Formation, arXiv 2601.20245 — Shen & Tamkin. RCT, 52 developers learning an async library, 26 per arm. Quiz scores 19.85 vs 24.0 out of 27 — the authors’ own phrasing is “a 17% score difference or 2 grade points” (Cohen’s d = 0.738, p = 0.010). Debugging showed the largest gap, code reading the smallest. No significant speedup: 19.5 min vs 23 min, not statistically significant

Quotations and cases

“You fully give in to the vibes … and forget that the code even exists” — Andrej Karpathy, February 2025. Context and the distinction from production work: Not all AI-assisted programming is vibe coding — Simon Willison.
Thaler v. Perlmutter — US District Court for the District of Columbia. The case concerned AI-generated artwork (the “Creativity Machine”), not code; it established the human-authorship requirement. The consequence for code is an inference from that principle, not a holding — which is how it is stated above. Legal treatment: Who Owns the Code Claude Wrote? — O’Reilly Radar.

Supporting the argument

“Delivery has not sped up meaningfully” — METR, July 2025: 16 experienced developers, 246 tasks, 19% slower with AI; their own estimate afterward was 20% faster. A follow-up design change was published Feb 2026.
“The queue has shifted from writing code to reviewing it” — Faros AI, 10,000+ developers across 1,255 teams: 21% more tasks completed, 98% more PRs, 91% longer review time. CircleCI’s 2026 State of Software Delivery puts the median team at +15% feature-branch throughput against −7% main-branch throughput — work accumulating before the merge (via Dev Interrupted).
“Code reworking needs to be measured, both before and after” — GitClear AI Code Quality 2025: churn rose from a 3.3% pre-AI baseline to 5.7% (2024) to 7.1% (2025). Refactored/moved code fell from ~25% of changed lines in 2021 to under 10% in 2024 — the first year copy/paste exceeded moved code.
Comprehension debt — the term and its framing: Comprehension Debt — Addy Osmani, also on O’Reilly Radar.
Code reproduced from training data — the specific exposure is license contamination: copyleft obligations travelling into a codebase without the developer knowingly accepting them, with liability regardless of awareness. Security exposure is separate and measured: Veracode 2025 GenAI Code Security Report found 45% of AI-generated code failed security tests across 80+ tasks and 100+ models, Java worst at 72%.
Named accountability for the approving human — AI Didn’t Break Accountability. It Exposed the Gap. and Assisted-by: provenance for AI-assisted commits — Barista Labs.
Spec-driven development, and “vibe engineering” as the production-grade counterpart — Vibe engineering — Simon Willison and Agentic Engineering Patterns — Simon Willison.
“Junior development positions are being axed” — the measurement is solid and names this job specifically. Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence — Brynjolfsson, Chandar and Chen, Stanford Digital Economy Lab, 13 November 2025, built on ADP payroll records rather than survey responses:
- Employment for software developers aged 22–25 fell nearly 20% from its late-2022 peak by September 2025.
- Early-career workers (22–25) in AI-exposed occupations saw a 16% relative employment decline after controlling for firm-level shocks, while employment for experienced workers in the same occupations held stable.
- Adjustment came through headcount rather than pay, and concentrated in occupations where AI automates rather than augments.
Corroborated on a different dataset by Generative AI as Seniority-Biased Technological Change — Hosseini and Lichtinger, 62 million workers across 285,000 firms, 2015–2025: firms adopting generative AI cut junior headcount while senior headcount kept rising, driven by slower hiring rather than layoffs.

Attribution is contested, the numbers are not. Both papers measure a real decline; whether AI caused it is disputed, and cost-cutting is the competing explanation — the same firms were shedding experienced staff and closing graduate schemes in the same window. Worth stating the effect and naming the debate rather than asserting the cause.
The apprenticeship problem — AI Won’t Kill Junior Devs — But Your Hiring Strategy Might, Addy Osmani. The routine work that trained juniors — scaffolding, first drafts, debugging your own mistakes — is exactly what agents now do. Note this piece argues against treating the decline as inevitable, so cite it for the mechanism, not for the headline.

Full research file, including sources not cited here: docs/research/code-ownership/code-ownership-vibe-coding-2026.md