… paving the Path to ■■■■ [is LLEH<-- a forbidden term?]
Cursor’s rules reveal a hard truth: AI-driven coding thrives only under strict TDD and Documentation-Driven Development (DDD). The IDE’s lapses prove this; without explicit guardrails, it will cut corners.
Method preservation and Test-first aren’t preferences; they’re survival tactics. Every deviation risks entropy. The rules aren’t bureaucracy; they’re the syntax of control. When the IDE forgets, we reassert them. Because in the chaos of AI-assisted coding, only tests and docs are immutable.
It is absolutely necessary to understand this, when you wish to unleash Cursor, and trust the outcome.
I like using “pseudotests” as a means of documenting requirements in relative (technical) detail. Of course it’s better to have real automated tests, but as you know it’s not always reasonable to develop and maintain them in certain scenarios. And I bet in the near future I can even let an AI actually assert these pseudotest automatically in a simulated or local environment.
Cursor rule I use for pseudotests:
If I ask for Pseudotests, then I mean the following format. The statements are commented out, there is therefore no real assertions, only an assertion that is to be manually put to true or false. The pseudotests should be clear, concise and easy to understand at a glance.
[test function declaration for programming language in question] PSEUDO_testFeatureMainFlow() {
/*
GIVEN:
- Precondition 1
- Precondition 2
WHEN:
- Action performed
THEN:
- Core expected outcome
*/
[assert that will fail here for the programming language in question]
}
this is not only a good video for understanding abstraction in programming, but also a great video in general sense. By the end of this video you will think about programming in a whole new way.
I think a LLM will understand your codebase easily if the code has a high level of abstraction.
I find that approaching the concept of ‘vibe coding’ is acting as the project manager who is overseeing freelance/interns. The AI is not yet a magic bullet for development, and needs its hand held and managed.
Manage expectations = managed outcomes.
TDD and DDD are absolutely necessary, I agree wholeheartedly.
I am not a professional programmer at all - cursor writes 90% of my code, but what i have a good head for is data flow, process, architecture - so i have detailed docs and they are kept updated. Sure we go off on a tangent occasionally, but when i fire on a scope of work i get 95% of the way there on a first pass, edge case and flow issues are the complications that require a bit of back and forth. But if i was working with professional programmers the same stuff would come up. The iteration of this when kept on guardrails is phenomenally faster.
4 days later of your awesome blog post, Amazon launched its editor with exactly your vision, other users were building similar automated workflows months ago and the most popular topics in this forum suggests that’s the way forward(first with plan-act taken from aider, then RIPER, then complete workflows), currently two problems exists with this approach in my tests: 3x tokens(which should be resolved with lower compute prices) and false positives(may be solved with better reasoning and better prompts), the last one is actually being solved by some teams with the human in the loop approach, they make the tests and prohibit the AI touching them, much like evals in agentic workflows, ultimately we’ll just correct tests and evals with optimization chains until an affordable ASI(not AGI) emerges, I agree 100% with your conclusion:
So this is what I want to see next. I want to see vibe coding start to take inspiration from what the software industry has learnt over the past 50 years around building maintainable code.
I don’t think Vibe coding is going away in fact I think eventually its going to become the ONLY way people build apps.
I do think that for us to get to that future though we will have to flip our mental model from a prompt first to a test-first mindset.
There’s one piece I would like to add as it’s of great importance: we need to keep our cognitive capacity high in order to keep being useful to our project(or life in general), in your blog post we can read:
This is one of those key distinctions between Junior and Senior human software developers.
A more senior developer has had enough time to lie in the bed they have pooped in and thus know that you have to spend time thinking about the code structure otherwise you will inevitably run into maintainability issues down the road.
We need to be well aware and warn others we’ll become Junior devs as time goes on by using AI, we need to keep a high brain effort, be it thinking about our project, the meaning of life or playing chess.