One Engineer's Perspective on the State of Vibe Coding, September 2025

[Eugene Chuvyrov]

While Generative AI may be failing to deliver compelling impact on most business operations so far (for example, an August 2025 MIT report states that 95% of all Generative AI projects fail to reach production), it has, without a doubt, forever redefined what it means to be a software engineer. Andrej Karpathy coined the term "vibe coding" in February of this year, and since then we vibed so much that many business leaders now think they no longer need software developers, since “AI will write all the code.”

This post, based on a combination of personal experiences, conversations with peers, learning from the leading AI podcasts and developer blogs, summarizes several key perspectives on where I think we are with AI-assisted coding today. Spoiler alert: engineers are still needed, but we must adapt to the expectations of what it means to be productive in the AI-empowered world of software engineering today and in the future.

1. The extent of how much you "give into the vibes" and just let AI write software for you depends largely on the type of work you do and the systems you touch in your code.

Are you an engineer on an Innovation team at a large technology company (hey, that's me!)? If so, a lot of your work involves creating futuristic, proof-of-concept ideas that could be prototyped by AI almost fully, with little supervision since those PoCs do not carry major penalties for complete code failure. Your main value add comes from futuristic ideas you generate and the unique ways you discover to blend those ideas with existing tools and platform features. Today, our team develops powerful futuristic PoC with Wind Surf and Claude Code, bypassing intermediate static or semi-static prototypes of the past. Similarly, if you are creating a workout/food/etc. logs for personal or community use, the costs of application failures are minimal (i.e, no lives would be at risk) and those projects lend themselves well to be written fully or almost fully by AI, with humans guiding the creation via ChatGPT-like prompts.

On the other hand, if your code gets deployed to production, with SLAs/money balances/lives depending on it, there's still a place for AI, but the loop of code generation and human review has to be much tighter. In depth systems understanding, both technical and operational, is critical in those systems, so while it makes sense to ask AI to generate short snippets of functionality, all that functionality should be reviewed and approved before committing code for testing and production deployments. Many production environments find a sweet spot for AI in generating automated tests for software and functionality they implement; however, those tests should also be reviewed by a human since mistakes are common in AI code generation (despite of how confident AI appears in its own abilities).

There's another set of common guiding principles worth pointing out from personal experiences: the more your code touches external resources, such as OAuth-based authentication to third-party API, database creation or maintenance, or cloud-based resource management and manipulation, the more you would want to keep AI code generation to smaller, manageable chunks of functionality, reviewed and verified by a human. Too many times, we’ve started with ambitious ideas to create all-powerful Agents that will manage the world through the set of API endpoints exposed, only to be literally throttled on the API side, as well as figuratively throttled on the technical ambitions side, to lose momentum and abandon those projects completely. Setting proper expectations and strategically approaching complicated bits of software with the help of AI will have both emotional and business benefits.

2. Application Development Platforms/Frameworks are not all created equal when it comes to their support for AI-driven code generation and tools.

Generally, the more open the platform that you build on, the better the code that AI produces and the more options you have for integrating AI-based coding tools with that platform. Creating React and Next.js applications is a breeze for today's Agentic Coding frameworks; the applications they create are both beautiful and functional (though Point 1 above still applies). On the other hand, support for iOS development could be limited to what's available inside Xcode, although many developers' workflow for iOS development today involves opening a project in Xcode and another AI-based coding environment, with AI generating code, and Xcode compiling and arranging all the necessary artifacts properly. Similarly, other closed systems like Roblox have their own version of AI coding assistants, which, while powerful, are dependent upon vendors updating them together with the rest of their tooling, which can cause them to not be as “bleeding edge” as tools dedicated specifically to AI code generation.

3. Not all programming languages/paradigms are suitable for AI-assisted code development just yet.

When more domain-specific data is available to train AI systems, those systems generally perform better at generating and reasoning within that domain, as deep learning-based AI models require substantial amounts of data. Therefore, there is a higher likelihood of seeing advanced React applications produced by AI than advanced Rust-based implementations of low-level features. This is because there is less publicly available Rust code compared to React code, and Rust typically involves lower-level concepts that are difficult for AI systems to learn given the current volume of training data. Similarly, creating a quantum optimization algorithm in Qiskit or Pyquil presents challenges due to the specialized knowledge required and the additional complexities in executing and verifying such code.

The field of software engineering has made a massive leap in 2025, and it will likely never be the same. By most admissions, AI today writes anywhere between 30 and 90 percent of all the code in the hands of those who use it. However, it's important to understand what kind of code it is most capable of creating, and when and how to bring humans in the loop to improve systems reliability while at the same time improving the velocity of product development and release.

We have made a stepwise productivity improvement in the field of software engineering. There’s an expectation now to create and release noticeably more product features, concepts, PoCs than we have ever created before. Personally, I am excited about creating 10x (how I wish!) more application features both at work, but also at home, where I am in the process of converting a very useful but not very pretty SvelteKit-based app to a native iOS implementation. That’s something I never imagined taking on before, because I didn’t want to spend weeks to both (re-)learn and write Swift code for a single hobby project. But now, with the help of Wind Surf, it will be a joy!