Vibe Coding Is Growing Up - Here's What Changed

Vibe Coding Is at a Crossroads - and the Creator Just Moved On

In early 2025, Andrej Karpathy fired off a tweet that changed how the software world talked about AI-assisted development. He described a mode of working where you "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He called it vibe coding, and the term went viral overnight. Barely a year later, Karpathy is already calling vibe coding "passé." The New Stack reported that as of early February 2026, he is pushing a new concept he calls agentic engineering - a more disciplined, supervisor-style relationship with AI coding agents. So what changed? And what does it mean for developers who are just now warming up to vibe coding?

The short answer: vibe coding works, but only if you treat it with more respect than the name implies. This week delivered a wave of reality checks worth paying attention to.

The Open Source Ecosystem Is Starting to Push Back

The most alarming story this week came from InfoQ, which reported that open-source maintainers are closing their doors at an alarming rate - directly citing AI-generated contributions as a driving force. Daniel Stenberg shut down cURL's six-year bug bounty program after AI-generated submissions climbed to 20% of total reports. Mitchell Hashimoto banned AI-written code from his terminal emulator Ghostty entirely. Steve Ruiz closed all external pull requests to the wildly popular whiteboard tool tldraw.

This is not just grumpy maintainers being territorial. There is economic research behind the concern. According to InfoQ, the underlying model shows a negative feedback loop: as developers delegate more work to AI agents, documentation visits, meaningful bug reports, and community engagement all collapse. The open-source ecosystem runs on that engagement. Fewer human interactions mean fewer contributions, less visibility, and eventually less funding and sustainability for projects that the entire industry depends on.

If you vibe code against libraries you have never actually read the docs for, you are quietly contributing to this problem. Worth sitting with.

The Security Debt Crisis Is Real and Growing Fast

A piece published this week by Towards Data Science laid out one of the clearest arguments yet for why pure vibe coding is risky in production. The core issue is that vibe coding encourages speed and a "just look at the UI" mindset. You describe a feature, the AI builds it, it looks right, you ship it. What you often do not see are hardcoded API keys, unsanitized user inputs, public database access, and SQL injection vulnerabilities hiding underneath a polished interface.

Karpathy himself recently warned that without careful oversight, agents will "just generate slop." The TDS piece draws a useful analogy: you would not let an intern push directly to production without a code review. AI agents deserve the same scrutiny, and right now too few developers are providing it. The recommended countermeasure is spec-driven development - defining security policies before the agent writes a single line. That means requiring the OWASP Top 10 as a baseline, prohibiting hardcoded secrets, requiring parameterized queries, and mandating unit tests for every new feature before it gets merged.

Meanwhile, Red Hat Developer put it bluntly in a piece published just ten days ago: "When you vibe code, your instructions become obsolete the moment code is generated. The code itself becomes the only source of truth for what the software does - and code is terrible at explaining why it does what it does." The fix is not to stop using AI. It is to write better specs before you start prompting.

What Agentic Engineering Actually Looks Like in Practice

The good news is that the developer community is already converging on a more mature workflow. Here is what the emerging best practices look like, drawn from this week's coverage:

• Write a task spec before you prompt. Describe not just what you want to build but the constraints - authentication requirements, database access rules, error handling expectations. Paste the full error message when debugging, not a vague summary.
• Treat diffs seriously. Review every diff the AI produces the same way you would review a junior developer's pull request. The TDS piece is explicit: do not just check the UI and assume the underlying code is clean.
• Automate your security checks. Use tools like static analysis, dependency scanners, and secret detectors as part of every commit. Do not rely on yourself to catch everything manually when you are moving fast.
• Add a SKILL.md file to your project. Google Cloud's vibe coding guide recommends adding a SKILL.md in your project's .agent/skills/ directory to encode your team's standards and workflows so every AI session starts with the right guardrails baked in.
• Know which tool to reach for. As the DEV Community's complete guide notes, developers who thrive are those who understand each AI assistant's strengths and know when to switch between them.

One practical advantage here: if you are using a bring-your-own-key IDE like PorkiCoder, you control which model you route each task to and pay only for actual token usage - no markup, no bundled AI subscription guessing at what you need. Switching between a faster model for boilerplate and a more capable one for security review becomes a deliberate, cost-transparent choice rather than a black box.

The Practical Takeaway for Working Developers

Vibe coding is not going away. The productivity leverage is real, and Karpathy's pivot to "agentic engineering" is not a repudiation of AI-assisted development - it is a maturation of it. The shift in framing is significant though. You are no longer a developer who uses an AI tool. You are an engineering lead supervising a fast but sometimes careless AI team member.

This week's stories paint a consistent picture: the developers who get burned are the ones who mistake fluency for correctness, and a working UI for working software. The developers who thrive are the ones who bring discipline to the prompt - who write specs before they write prompts, review what gets generated, and never ship without running automated checks.

The vibes are fine. The engineering still has to be real.