A month ago, Andrej Karpathy, one of the OpenAI founders and ex-director of AI at Tesla posted this tweet:

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. Also I just talk to Composer with SuperWhisper…

— Andrej Karpathy (@karpathy) February 2, 2025

It sparked a lot of attention. Opinions range from harsh fear & criticism to pure excitement. Since I’ve been using Cursor AI with Claude for sometime now, it sparked a couple of thoughts on my end as well.

For example, if we just accept all of the code suggestions without review, how important is the code editor space? 🤔

My vibe experience

I haven’t coded with Cursor AI using my voice as Karpathy did, (although I will try superwhiser next), but I was reckless enough for one of the projects to turn on yolo mode… 😱

So how did it work? In some ways it felt that delivering results was faster and slower at the same time.

• Faster, because Cursor was able to work “alone” in the background for a couple of minutes while I was… reading a book 😅 Magic.
• Slower, because in some cases I knew what was wrong but I’d still prompt Cursor to try fixing it either way. If it worked, great. If not, I’d do it myself, but only if needed (and that was sometimes slower). I became lazy!

I won’t recommend trying it on large brownfield prod systems because that’s not what we are being paid for. But as a thought experiment, PoC, throwaway, one-person side project? Sure.

However, I cannot deny that the entire experience was fun.

Code is a black box

After a couple of hours, I realized that I was spending 90% of the time with the small Composer box on the side of the UI. Of course, I could make it larger, but that’s not the point. The point is that if you’re vibe programming, code is no longer a priority. So I guess it shouldn’t take all of the IDE space then? 🤷

That led me to another thought process. If I’m generating everything and I don’t bother with how the code is written, that also means that code is replaceable black box. I don’t care what’s inside as long as it produces outputs I desire, for the inputs I provide. Or other software provides.

• Is software readable? Don’t care as long as it works.
• Is software written in the wrong programming language? Re-generate in X.
• Is software slow? Re-generate, measure if it is faster, and accept the fast version.
• Is it working correctly? Generate yourself tests based on my feature specification and validate yourself.

Suddenly my code became encapsulated and I only cared if it worked and how well but I didn’t care about the details. Almost like working with a library or external system. Or nicely separated modules.

Currently, Cursor IDE is focused on the black box internals, but how could it look if we focused on what matters in this new context?

Contracts, dependencies, systems

I started to think about AI-assisted IDE almost like orchestrators of modules. Suddenly creating software may be a higher abstraction layer, where we are focusing on interactions between puzzles, but every puzzle is replaceable as long as it fits.

The fitting may be defined by solutions we already have in the business.

• In microservices we are creating contracts. We are focusing on contract tests instead of full e2e tests.
• For communication with external systems or autononmous modules we are using versioned APIs or GQL schemas.
• For infrastructure management we are using IaC.
• For database management we use schemas.
• For frontend/backend communication we can establish data exchange contract before it’s written.
• And so many more…

All in all, we are moving the focus away from feature internals and more to the designing the user flow and letting AI figure out the node details.

Does it remind you something already? 😉

Yay that looks a bit like no-code

If you worked with software like make.com, n8n.io or zapier.com maybe you connected the previous idea with how no-code tools display user flow (or data flow) diagrams. This can vary from a very granular level (if statement blocks) to blocks doing a large bulk of work (integrations with 3rd parties). Example below:

In n8n you can even create your own nodes (see how). You can configure auth, inputs, outputs, and all that jazz.

What does it mean, again?

I think that vibe programmers may need a visual representation closer to current no-code tools (higher level of abstraction and focus) with the interface and flexibility that Cursor already offers. Voice to no-code with the ability to create custom nodes on demand.

Signals that would help us to vibe better

No-code tools already do e2e test flow, usually using dummy data. They check if nodes produce outputs they are out to produce and if contracts are enforced. It’s possible to use Cursor AI right now in a way to enforce specific Rules for AI to optimize how Composer works. However, it’s not designed by default to make sure that software is testable or that our prompts should be reflected in feature specification that later AI can test software against. Some people will prompt it, some won’t.

I’d love Cursor to act as a TDD or BDD developer and use specifications/tests written during work to automatically self-validate for future changes. Essentially - build yourself your little internal CI/CD.

Additionally, I don’t think that by default we have enough observability to know if custom nodes are performant or cost-effective. As such, I’m not sure if detecting bottlenecks or debugging the system is on the right level. Currently, Cursor will use the terminal to debug software, but imagine what it could do if by default it would set up (for itself) tracing, which works between loosely coupled modules. It’s essentially adding debugging visibility to AI as we’d like to give to engineers.

Summary

Interestingly, AI assistants getting better and better shifting us more towards the idea that code may be disposable, and replaceable. If that’s true, it may change entirely how our IDE will look like and what will be our job in the future, what will be important. My predictions are:

• Vibe programming and no-code tools may overlap more because they both abstract/encapsulate the “code” part
• IDEs with AI assistants will enforce more testable, spec or AI-rules-driven software to increase quality and reduce chances of regressions
• IDEs will create interfaces to enable easier observability for AI agents, which will result in faster/easier debugging, performance monitoring and efficiency