# Vibe engineering

> Source: https://aiwiki.ai/wiki/vibe_engineering
> Updated: 2026-06-07
> Categories: AI Code Generation, Software Development
> From AI Wiki (https://aiwiki.ai), a free encyclopedia of artificial intelligence. Quote with attribution.

**Vibe engineering** is a term for the disciplined practice of building production software with the help of [large language model](/wiki/large_language_model) coding agents, in contrast to the looser [vibe coding](/wiki/vibe_coding) style of accepting AI-generated code without close review. The phrase was popularised by British software engineer Simon Willison in an essay published on his personal site on October 7, 2025, where he argued that experienced engineers who pair LLMs with rigorous testing, planning, documentation, version control, and code review can produce maintainable systems while remaining accountable for the result.[^1] Willison framed vibe engineering as the opposite end of a spectrum from vibe coding (the term coined by [andrej karpathy](/wiki/andrej_karpathy) in February 2025 to describe "fully give in to the vibes" prompt-driven prototyping), reserving the latter for situations in which the human never reads the code.[^1][^2] Within a few weeks of publication the essay drew 654 points and 719 comments on Hacker News and was widely cited in trade press, industry analyst notes, and an ICSE 2026 technical briefing.[^3][^4][^5] By the first half of 2026 the broader practice it described was equally being called "agentic engineering" (Karpathy's preferred label) or grouped under [context engineering](/wiki/context_engineering), reflecting an unsettled vocabulary for what most observers agreed had become a distinct mode of software work.[^6][^7]

## Background

The phrase "vibe coding" entered the software lexicon at 4:17 PM on February 2, 2025, when Andrej Karpathy, a co-founder of OpenAI and former director of AI at Tesla, posted on X: "There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good."[^2][^8] The post described a workflow in which the developer dictates intent to a coding assistant, accepts diffs without reading them, and pastes any error messages back into the model until the program runs. It accumulated more than 4.5 million views and was named Collins Dictionary's word of the year for 2025.[^8][^9]

The reception split quickly. Karpathy himself characterised the original message as "a shower of thoughts throwaway tweet that I just fired off."[^10] Practitioners adopted it both literally (for rapid prototyping) and dismissively (for code shipped to production without verification). Willison, who runs a widely read blog on language models and is co-creator of the Django web framework, used his Mastodon account in October 2025 to argue that "vibe coding is irresponsibly building software through dice rolls, not caring what code is produced," and asked what the field should call the responsible counterpart.[^11] He proposed "vibe engineering" the same day in a thread on X and then in a long-form essay on his site.[^12][^1]

The essay landed during a period of rapid change in coding agents. Anthropic had released [claude code](/wiki/claude_code) in February 2025, [openai codex](/wiki/openai_codex) CLI followed in April, and Google's [gemini cli](/wiki/gemini_cli) in June; by mid-2025 these tools could iterate on code, run tests, and self-correct rather than simply emit suggestions.[^1] Surveys reported that 84 to 92 percent of developers in major markets used AI coding tools at least weekly by late 2025, and a December 2025 analysis of 470 GitHub pull requests by CodeRabbit found that AI-co-authored code contained roughly 1.7 times as many "major" issues as human-only code, including 2.74 times more security vulnerabilities.[^13][^14] The combination of widespread adoption and a measurable quality gap created an opening for a vocabulary that distinguished careful production work from the original vibe coding ethos.

## Origins and definition

Willison's October 7, 2025 essay opens by asking what to call "the activity where experienced software engineers use [ai coding agent](/wiki/ai_coding_agent)s, like Claude Code and Codex CLI, to accelerate the process of building real software." His proposed answer, "vibe engineering," is offered with self-conscious irony: he acknowledges that the "vibes" prefix "feels a little tired" and writes "Is this a stupid name? Yeah, probably."[^1] The substantive claim is that "iterating with coding agents to produce production-quality code that I'm confident I can maintain in the future feels like a different process entirely" from the throwaway prototyping that vibe coding describes.[^1]

The essay defines vibe engineering as the practice where "seasoned professionals accelerate their work with LLMs while staying proudly and confidently accountable for the software they produce."[^1] Two ideas anchor the definition. First, accountability: a vibe engineer signs off on every change, can explain how the system works, and will respond when it breaks. Second, amplification: "AI tools amplify existing expertise. The more skills and experience you have as a software engineer the faster and better the results you can get from working with LLMs and coding agents."[^1] Together these claims position vibe engineering as the inverse of the original vibe coding spirit, in which the developer's deliberate stance is to neither read nor own the generated code.

Willison's framing built on positions he had already taken in public. In April 2025 he had told Ars Technica that "vibe coding your way to a production codebase is clearly risky" and that "if an LLM wrote every line of your code, but you've reviewed, tested, and understood it all, that's not vibe coding."[^15] The October essay names the alternative.

## Twelve practices that LLMs reward

The bulk of the essay enumerates engineering disciplines that, in Willison's reading, become more valuable when coding agents are part of the workflow rather than less. He presents twelve.[^1]

1. **Automated testing.** A robust test suite lets an agent iterate against an objective signal. Without it, agents will report success without verifying behaviour. Test-driven prompting (have the agent write failing tests first, then make them pass) gives the loop a discrete completion criterion.
2. **Planning in advance.** A high-level plan or written specification before unleashing an agent improves the chance that its output is usable. Willison links this to the broader practice of [spec driven development](/wiki/spec_driven_development), though he distinguishes vibe engineering from any single formal methodology.
3. **Comprehensive documentation.** Well-documented APIs let a model understand interfaces without reading the implementation, which is faster and more reliable than relying on the model to infer behaviour from source.
4. **Good version control habits.** Disciplined use of branches, small commits, and bisect lets an engineer rewind, isolate regressions, and hand the agent precise revisions to work on.
5. **Effective automation.** CI/CD, linting, formatters, and deployment scripts all benefit agentic loops because the agent can rerun the same checks a human would and learn from the output.
6. **A strong culture of code review.** Reviewing code becomes the primary creative act when an agent writes most of it. Willison argues that "speed and skill at reviewing code" is among the highest-leverage capabilities a vibe engineer can have.
7. **A "very weird form of management."** Treating the agent as a junior collaborator who needs clear instructions, context, and actionable feedback parallels the skills of managing humans, with the difference that the agent has no memory between sessions and no career incentives.
8. **Manual QA.** Automated tests are necessary but insufficient; humans still need to exercise the product, look for edge cases, and notice the things tests do not check.
9. **Strong research skills.** Knowing how to evaluate competing libraries, read papers, and compare APIs lets the engineer steer the agent toward sound technical choices rather than the first plausible one it generates.
10. **Access to preview environments.** Shipping a branch to a sandbox where a human can click around catches issues that no unit test will, and lowers the cost of letting the agent try a risky refactor.
11. **An instinct for what to outsource.** Not every task is well suited to an agent. Distinguishing the routine, the boilerplate, and the well-specified from the subtle, the novel, and the underspecified is itself a learned skill.
12. **An updated sense of estimation.** The new mixture of agent and human work changes how long things take. Vibe engineers re-calibrate their timelines as they accumulate experience with a given stack and toolchain.

The list is descriptive rather than prescriptive: Willison frames each item as a practice that "good engineers were doing anyway" but which carries an additional payoff when an agent is in the loop. The recurring theme is that the agent's output gets better the more legible the surrounding system is.[^1]

## Comparison to vibe coding

The clearest way to read the term is against the practice it negates. Karpathy's February 2025 description treats reading the code as optional and embraces velocity over comprehension: the developer accepts diffs, ignores error traces beyond pasting them back, and "forgets that the code even exists."[^2] Willison's vibe engineering insists on the opposite. The engineer reads every change, signs off on every commit, maintains a test suite the agent must pass, and treats the model as a peer whose output requires the same skepticism as a human pull request.[^1]

A useful comparison runs across several axes. Vibe coding optimises for first-working-output; vibe engineering optimises for long-term maintainability. Vibe coding suits prototypes, throwaway scripts, and personal hobby work; vibe engineering suits systems that will be on call, audited, or relied on by other engineers. Vibe coding tolerates whatever code emerges so long as it runs; vibe engineering retains the engineer's authority over architecture, naming, and structure. Vibe coding can be done by non-programmers, which is part of why Collins highlighted it as a term that crossed into popular usage; vibe engineering presupposes substantial software engineering experience, because the engineer's expertise is the variable the model amplifies.[^9][^1]

Willison's own one-line summary captures the symmetry: "Vibe coding is irresponsibly building software through dice rolls, not caring what code is produced. What about when engineers at the top of their game use AI tools responsibly to accelerate their work? I propose 'vibe engineering'!"[^12]

## Comparison to spec-driven development

Vibe engineering overlaps with [spec driven development](/wiki/spec_driven_development) but is not the same. Spec-driven development, as practiced in workflows associated with GitHub Spec Kit and Amazon's Kiro IDE in 2025, prescribes writing a structured specification (often a markdown document broken into requirements, architecture, and tasks) before generation, and asking the agent to produce code that implements the spec.[^16] It is a method with named artifacts and a defined ordering.

Vibe engineering is broader and methodologically agnostic. The Willison essay treats advance planning as one of twelve practices, not the entire framework, and does not require the plan to be expressed in any particular document format. A vibe engineer might use a spec-driven approach for a green-field service and a more conversational, test-first approach for a bug fix in a legacy codebase; both fall under the same label. Where spec-driven development describes a recipe, vibe engineering describes a disposition.

The two practices share an underlying commitment to keeping the human accountable for the result and to using the agent's compute budget on the parts of the work that benefit most from it. Several practitioners in late 2025 treated spec-driven workflows as one expression of vibe engineering, rather than a competitor to it.[^16][^4]

## Comparison to agentic engineering and context engineering

Within weeks of Willison's essay, a competing label appeared. Karpathy began using "agentic engineering" in talks and interviews through the autumn and winter of 2025, and by his March 2026 Sequoia AI Ascent presentation was framing it as the canonical term for the same practice.[^7][^17] In December 2025 he stated publicly that roughly 80 percent of the code he wrote was produced by agents rather than by hand, and reported having largely stopped typing code himself, instead orchestrating "fleets" of as many as twenty parallel agents.[^7][^17] Karpathy's gloss on the new term was that "agentic" captured the shift to orchestrating agents rather than typing code, while "engineering" was meant to emphasise that "there is an art and science and expertise to it."[^7]

Willison addressed the competition explicitly. In an October 2025 update at the top of his essay he wrote "It looks like the term 'Agentic Engineering' is coming out on top for this now," and in a follow-up post on his Substack a few weeks later he used "agentic engineering" to title a collection of working patterns.[^1][^18] Both terms refer to the same underlying practice; the difference is rhetorical, with "agentic" emphasising the role of autonomous agents and "vibe" foregrounding the contrast with the original Karpathy coinage.

A separate but related term is [context engineering](/wiki/context_engineering), the discipline of curating the prompts, files, retrieval results, and tool outputs that an LLM sees in a given turn. Context engineering is more narrowly technical: it covers prompt construction, retrieval strategies, the layout of files like AGENTS.md or CLAUDE.md, and the use of standards such as [model context protocol](/wiki/model_context_protocol) to feed external data into an agent. A November 2025 MIT Technology Review piece by Thoughtworks technologist Ken Mugrage described the year as a shift "from vibe coding to context engineering," casting context engineering as the technical substrate that makes responsible AI-assisted development possible.[^6] Vibe engineering and context engineering are complements rather than rivals: a vibe engineer practices context engineering as part of the broader workflow.

## Tools and practices

The vibe engineering label is tool-agnostic, but the practice is bound up with a specific generation of coding agents that emerged through 2025. Willison's essay names [claude code](/wiki/claude_code) (Anthropic, February 2025), [codex cli](/wiki/codex_cli) (OpenAI, April 2025), and [gemini cli](/wiki/gemini_cli) (Google, June 2025) as the immediate trigger.[^1] Each runs as a terminal-based agent that can read and write files, execute shell commands, run tests, and iterate on its own output. Anthropic's Claude Code reached an annualised revenue run rate of approximately one billion US dollars within six months of launch and scored 80.9 percent on [swe bench verified](/wiki/swe_bench_verified) by early 2026, the leading public benchmark for resolving real GitHub issues.[^14][^19]

Vibe engineering also intersects with agentic IDEs. [cursor](/wiki/cursor) (the AI-first editor that hit a roughly nine billion dollar valuation in early 2026 and crossed a two billion dollar annualised revenue run rate by March 2026) and [windsurf](/wiki/windsurf) are the most cited; both ship multi-file edit, agent loops, and rules files (cursor.md, .cursorrules) that let teams encode project conventions for the agent to follow.[^14][^20] [github copilot](/wiki/github_copilot) (Microsoft/GitHub) remained the largest AI coding tool by paid users, passing 4.7 million paid subscribers in January 2026.[^14] Open-source agents such as [cline](/wiki/cline) and Aider, along with research systems such as Magentic-One ([magentic one](/wiki/magentic_one)), populate the rest of the ecosystem.

Practitioners describe a set of recurring techniques that operationalise Willison's twelve practices.

- **Test-driven prompting.** The engineer asks the agent to write failing tests first, runs them to confirm failure, then asks for an implementation that makes them pass. This pattern, sometimes called Red/Green TDD, gives the agent a verifiable target and the engineer a built-in regression test.[^18]
- **Code-review agents.** Many teams use a separate agent (or a separate session of the same agent) to review changes the first agent has authored, on the theory that the reviewer benefits from a fresh context window and a different prompt. Willison's own [claude code review](/wiki/claude_code_review) writeup is one example.[^1]
- **AGENTS.md and CLAUDE.md files.** A short markdown file in the repo root describes the project's conventions, build commands, and review checklist; agents read it on every session start. The convention is spreading across tools and underpins parts of the [model context protocol](/wiki/model_context_protocol) ecosystem.[^6]
- **Parallel agents.** Willison reported in October 2025 that he was "increasingly hearing from experienced, credible software engineers who are running multiple copies of agents at once, tackling several problems in parallel."[^1] Karpathy described running as many as twenty in parallel by March 2026.[^7] The pattern requires the engineer to act as router, reviewer, and integrator across the streams.
- **Preview environments and ephemeral branches.** Each agent task runs on its own branch, deploys to a preview URL, and is exercised manually before merging. The pattern keeps the cost of a failed experiment low and lets the human apply judgement at the merge boundary.[^1]

The role of the human in these flows is consistently described in management terms. Willison calls it "a very weird form of management"; Karpathy describes himself as a "director" of agents; the IBM definition of agentic engineering centres "orchestration."[^1][^17]

## Reception

Willison's essay generated 654 points and 719 comments on Hacker News on October 7, 2025, making it one of the most-discussed posts on the site that week.[^3] The discussion clustered into four positions.

Supporters embraced the framing. A 68-year-old translator described building a multi-LLM translation system in which models critique each other's work; another commenter outlined a workflow of writing specs, enforcing linting and tests, and reminding the agent of best practices each session, summarising it as "quality in, quality out."[^3]

Sceptics objected to the vocabulary. Several commenters argued that "vibe" trivialised serious work and proposed "agentic coding" or simply "AI-assisted software engineering" as alternatives. A 2025 blog post on serce.me, also discussed on Hacker News, was titled "There is no Vibe Engineering" and argued that genuine engineering required tighter specifications than current LLMs could reliably meet.[^21]

A third group focused on professional identity. A widely upvoted comment from a developer named deanCommie argued that the shift transformed coding from "craftsmanship" into "technical middle management," removing the flow state that drew many engineers into the field. Other commenters described fatigue from managing multiple parallel agents and questioned whether the productivity gains held up over a full workday.[^3]

A fourth group disputed the claim of accountability itself. A commenter using the handle pron contended that outputs which still require constant verification eliminate the automation benefit; another, benterix, described abandoning agents entirely after accumulating review fatigue. Willison himself participated in the thread, restating his core claim that "AI tools amplify existing expertise" and that the gap between novice and experienced users widens, not narrows, in agentic workflows.[^3]

Outside Hacker News, the trade press picked up the term within weeks. The New Stack ran multiple pieces on the shift from vibe coding to agentic engineering through late 2025 and early 2026.[^17] MIT Technology Review's November 5, 2025 piece by Ken Mugrage described the year as a transition "from vibe coding to context engineering," citing both Willison's essay and the broader retreat from informal prompting.[^6] Forrester's 2026 predictions wrote that "vibe coding will transform into vibe engineering by the end of 2026," casting the discipline as a structured replacement for prompt-driven development.[^4][^22]

Academic uptake followed. The 2026 International Conference on Software Engineering (ICSE) accepted a technical briefing titled "Vibe Engineering: Software Engineering for Software Makers," led by Keheliya Gallaba (Huawei Canada) and colleagues including researchers from Microsoft and Queen's University, to be presented on April 17, 2026 in Rio de Janeiro.[^5] The briefing introduces a framework called SE4SM (Software Engineering for Software Makers) that splits the activity into "intent engineering" (multi-agent conversations to refine requirements) and "realization engineering" (an autonomous multi-agent execution environment).[^5] Separately, an ICSE 2026 Software Engineering in Practice paper on vibe coding conducted a grey-literature review of motivations, challenges, and outlooks, cementing the academic recognition of the surrounding discipline.[^23]

## Adoption and surveys

By the first half of 2026, AI-assisted coding had moved from a feature to a default. Industry data placed daily AI tool usage among US developers at roughly 92 percent and put the share of code written with AI assistance at around 41 percent across surveyed teams.[^14] Top engineering teams reported daily AI-assistant usage rates of 85 to 90 percent by the end of 2025.[^24] [claude code](/wiki/claude_code) reached approximately one billion dollars in annualised revenue within six months of launch, [cursor](/wiki/cursor) crossed two billion dollars in annualised revenue by March 2026, and [github copilot](/wiki/github_copilot) passed 4.7 million paid subscribers in January 2026 (a 75 percent year-over-year increase).[^14]

The qualitative shift was equally visible. Karpathy reported in December 2025 that 80 percent of his code was produced by agents, and by March 2026 that he had not typed a line of code by hand since the previous December.[^7][^17] He framed the change as personally costly ("it's a bit hard on the ego") but operationally irreversible.[^7] Sequoia Capital's AI Ascent conference in March 2026 hosted his talk introducing the framing of "Software 3.0," in which the context window becomes "the lever" and the LLM the interpreter.[^17]

Quality data tempered the celebration. The December 2025 CodeRabbit analysis of 470 open-source pull requests found that AI-co-authored code contained roughly 1.7 times more "major" issues than human-authored code, with 75 percent higher rates of misconfiguration and 2.74 times higher rates of security vulnerabilities.[^14] A Veracode GenAI Code Security Report published the same year reported that nearly half of all AI-generated code introduced known security flaws.[^25] These numbers were widely cited as evidence that vibe engineering's emphasis on testing, code review, and accountability addressed a real problem rather than a hypothetical one.

## Criticism

The term and the practice both attracted criticism through 2025 and 2026.

Some critics argued the label was unserious. The "vibe" stem, which originated in Karpathy's deliberately casual tweet, struck several commentators as inappropriate for the disciplined activity Willison was describing; Karpathy's later adoption of "agentic engineering" was read as a deliberate retreat from the original brand.[^7] Willison himself conceded the vocabulary was awkward.[^1]

Others questioned whether the practice was distinct enough to merit a name. A position represented in the March 2025 Hacker News thread "There is no Vibe Engineering" argued that vibe engineering amounted to "doing software engineering with a faster autocomplete," and that calling careful engineering a new discipline distracted from existing methods.[^21]

A third strand of criticism focused on the change in engineering work. Commenters described the loss of "flow state" and immersion that came with hands-on coding, and several worried that career paths into the field would be reshaped if entry-level work shifted toward agent supervision.[^3] A widely circulated metaphor compared the change to introducing tractors to a profession of gardeners. The translator who described moving to multi-LLM workflows also wrote that younger entrants to the field might exit it rather than retrain.[^3]

A fourth strand concerned safety and quality. The CodeRabbit and Veracode figures suggested that even disciplined teams could not eliminate the elevated defect rate associated with AI-generated code, and a series of incidents through 2025 (including the discovery of a malicious VS Code extension flagged as "vibe-coded" in October 2025) reinforced concerns about provenance and trust in agent output.[^26][^14]

## Related practices and terminology

Several adjacent terms coexisted with vibe engineering in late 2025 and 2026. "Agentic coding" was sometimes used as a near-synonym, sometimes as a narrower label restricted to running coding agents in a terminal. "Software 3.0" appeared in Karpathy's March 2026 Sequoia talk as a generalisation: software 1.0 is hand-written code, software 2.0 is neural network weights, and software 3.0 is programming through prompts.[^17] "[agentic workflow](/wiki/agentic_workflow)" denotes any LLM-orchestrated workflow, including non-coding domains.

The phrase "AI engineering" was sometimes used loosely to cover the same territory but more often referred specifically to the discipline of building applications on top of LLMs (prompt design, evaluation, retrieval, agent orchestration), as treated in Chip Huyen's 2024 book of that title. Vibe engineering is narrower: it concerns the engineer's own workflow when shipping software, not the construction of LLM-powered products. The two practices intersect because most modern engineers are doing both.

## See also

- [vibe coding](/wiki/vibe_coding)
- [andrej karpathy](/wiki/andrej_karpathy)
- [spec driven development](/wiki/spec_driven_development)
- [claude code](/wiki/claude_code)
- [cursor](/wiki/cursor)
- [windsurf](/wiki/windsurf)
- [github copilot](/wiki/github_copilot)
- [codex cli](/wiki/codex_cli)
- [gemini cli](/wiki/gemini_cli)
- [ai coding agent](/wiki/ai_coding_agent)
- [cline](/wiki/cline)
- [context engineering](/wiki/context_engineering)
- [agentic workflow](/wiki/agentic_workflow)
- [agentic ai](/wiki/agentic_ai)
- [claude code review](/wiki/claude_code_review)
- [claude code subagents](/wiki/claude_code_subagents)
- [model context protocol](/wiki/model_context_protocol)
- [prompt engineering](/wiki/prompt_engineering)
- [swe bench verified](/wiki/swe_bench_verified)
- [cursor rules](/wiki/cursor_rules)

## References

[^1]: Simon Willison, "Vibe engineering", simonwillison.net, 2025-10-07. https://simonwillison.net/2025/Oct/7/vibe-engineering/. Accessed 2026-05-25.
[^2]: Andrej Karpathy, post on X (formerly Twitter), 2025-02-02. https://x.com/karpathy/status/1886192184808149383. Accessed 2026-05-25.
[^3]: "Vibe engineering" (discussion of Willison's essay), Hacker News thread id 45503867, 2025-10-07. https://news.ycombinator.com/item?id=45503867. Accessed 2026-05-25.
[^4]: Marisa Hill, "Top 5 predictions for platform engineering in 2026", Mia-Platform blog, 2025-12. https://mia-platform.eu/blog/top-5-predictions-platform-engineering-2026/. Accessed 2026-05-25.
[^5]: Keheliya Gallaba, Zhiyu Fan, Jiahuei Lin, Filipe Cogo, Benjamin Rombaut, Dayi Lin, Ahmed E. Hassan, "Technical Briefing: Vibe Engineering: Software Engineering for Software Makers", ICSE 2026 Tutorials and Technical Briefings, 2026-04-17. https://conf.researchr.org/details/icse-2026/icse-2026-tutorials/7/Technical-Briefing-Vibe-Engineering-Software-Engineering-for-Software-Makers. Accessed 2026-05-25.
[^6]: Ken Mugrage, "From vibe coding to context engineering: 2025 in software development", MIT Technology Review (sponsored by Thoughtworks), 2025-11-05. https://www.technologyreview.com/2025/11/05/1127477/from-vibe-coding-to-context-engineering-2025-in-software-development/. Accessed 2026-05-25.
[^7]: Andrew Reed, "Vibe coding is passé. Karpathy has a new name for the future of software.", The New Stack, 2026-03. https://thenewstack.io/vibe-coding-is-passe/. Accessed 2026-05-25.
[^8]: "Vibe coding", Wikipedia. https://en.wikipedia.org/wiki/Vibe_coding. Accessed 2026-05-25.
[^9]: Collins Dictionary, "Word of the Year 2025: vibe coding", 2025-11. https://www.collinsdictionary.com/woty. Accessed 2026-05-25.
[^10]: Andrej Karpathy, post on X (one-year retrospective on the vibe coding tweet), 2026-02-02. https://x.com/karpathy/status/2019137879310836075. Accessed 2026-05-25.
[^11]: Simon Willison, post on Mastodon, 2025-10-07. https://fedi.simonwillison.net/@simon/115333498401581242. Accessed 2026-05-25.
[^12]: Simon Willison, post on X proposing "vibe engineering", 2025-10-07. https://x.com/simonw/status/1975570458683834729. Accessed 2026-05-25.
[^13]: Matthew S. Smith, "AI Vibe Coding: Engineers' Secret to Fast Development", IEEE Spectrum, 2025-04-08. https://spectrum.ieee.org/vibe-coding. Accessed 2026-05-25.
[^14]: Lushbinary, "AI Coding Agents 2026: Claude Code vs Antigravity 2.0 vs Codex vs Cursor vs Kiro vs Copilot vs Windsurf", lushbinary.com, 2026. https://lushbinary.com/blog/ai-coding-agents-comparison-cursor-windsurf-claude-copilot-kiro-2026/. Accessed 2026-05-25.
[^15]: Benj Edwards, "Will 'vibe coding' end like the maker movement?", Ars Technica, 2025-04. https://arstechnica.com/ai/2025/04/vibe-coding-explained/. Accessed 2026-05-25.
[^16]: Algustionesa Yoshi, "Beyond Vibe Coding: What is Vibe Engineering?", algustionesa.com, 2025-10-09. https://algustionesa.com/beyond-vibe-coding-what-is-vibe-engineering/. Accessed 2026-05-25.
[^17]: "Karpathy hasn't written code since December: He just directs AI agents now", DEV Community, 2026-03. https://dev.to/htekdev/karpathy-hasnt-written-code-since-december-he-just-directs-ai-agents-now-56b3. Accessed 2026-05-25.
[^18]: Simon Willison, "Agentic engineering patterns", simonw.substack.com, 2025-11. https://simonw.substack.com/p/agentic-engineering-patterns. Accessed 2026-05-25.
[^19]: Eva Roytburg, "Andrej Karpathy, OpenAI founding member and inventor of 'vibe coding,' defects to Anthropic", Fortune, 2026-05-19. https://fortune.com/2026/05/19/who-is-andrej-karpathy-vibe-coding-anthropic-openai-rubiks-cube/. Accessed 2026-05-25.
[^20]: "Cursor vs GitHub Copilot: the $36 billion war for the future of how software gets written", digidai.github.io, 2026-02-08. https://digidai.github.io/2026/02/08/cursor-vs-github-copilot-ai-coding-tools-deep-comparison/. Accessed 2026-05-25.
[^21]: Sergey Tselovalnikov, "There is no Vibe Engineering" (Hacker News thread id 43533539), serce.me, 2025-03-31. https://news.ycombinator.com/item?id=43533539. Accessed 2026-05-25.
[^22]: Forrester Research, "Predictions 2026: Tech leadership will be wild", forrester.com, 2025-11. https://www.forrester.com/blogs/predictions-2026-tech-leadership/. Accessed 2026-05-25.
[^23]: "Vibe Coding in Practice: Motivations, Challenges, and a Future Outlook, a Grey Literature Review", ICSE 2026 Software Engineering in Practice, 2026. https://conf.researchr.org/details/icse-2026/icse-2026-software-engineering-in-practice/15/Vibe-Coding-in-Practice-Motivations-Challenges-and-a-Future-Outlook-a-Grey-Liter. Accessed 2026-05-25.
[^24]: Kanerika Inc, "GitHub Copilot vs Claude Code vs Cursor vs Windsurf (2026)", Medium, 2026-04. https://medium.com/@kanerika/github-copilot-vs-claude-code-vs-cursor-vs-windsurf-2026-c54f8a5cc051. Accessed 2026-05-25.
[^25]: Veracode, "GenAI Code Security Report 2025", veracode.com, 2025. https://www.veracode.com/resources/genai-code-security-report-2025/. Accessed 2026-05-25.
[^26]: "Vibe-coded malicious VS Code extension found with built-in ransomware capabilities", The Hacker News, 2025-11. https://thehackernews.com/2025/11/vibe-coded-malicious-vs-code-extension.html. Accessed 2026-05-25.

