Using AI to help you code has been around for a while. IDEs introduced basic autocomplete features as early as the late 1990s.

By late 2022, ChatGPT made it possible to describe what you wanted in plain English and get working code back in a chat window, sparking massive interest in leveraging LLMs for coding applications.

Now we have gone beyond chat. The current generation of AI coding tools like Cursor, Claude Code, Windsurf don't just write code but it can navigate your codebase, execute commands in your terminal, and communicate using MCPs and APIs to other tools. These agents carry out "actions" through your computer's terminal or through "skills" that connect to APIs and MCPs. The OpenClaw/Moltbot/ClawdBot frenzy has brought this further to life: pair an LLM with cron jobs, webhooks, and skills that let it access your email, scroll on X, or make calls on your behalf.

Satya Nadella, CEO of Microsoft, in his recent talk in Davos explored an interesting parallel of how our use of computers has evolved:

Steve Jobs said computers were a bicycle for the mind.

Ivan Zhao, the CEO of Notion, has said we can now be managers of infinite minds.

That shift, from tool to collaborator, is the backdrop for a term that's gone mainstream in the past two years: vibe coding.

But here's the thing: software engineering is not the same as coding. Coding is only one component of engineering, and while I still believe those who are really competent at writing code will have a big advantage, there are levels of software engineering that can be achieved without being fluent in any programming language.

Broadly, I believe that learning to use AI for coding is a superpower, but I would encourage people to learn a broader set of skills and use specific strategies to really unlock some incredible development capabilities and not just vibe code, but “vibe engineer”.

I have taught myself some coding languages, but I am by no means fluent in any. Just like learning an actual spoken language, you forget the syntax if you don't practice constantly. Instead, I've focused on learning the best principles of development architecture and trying to understand conceptually how all the pieces fit together ( frontend, backend, databases, API connections). That approach, paired with tools like Cursor to fill in my technical gaps, has led to real results.

By succeeding some times, and failing a lot more times, I compiled a list of the strategies to improve your vibe engineering.

1. Map Out Your Architecture

Before you write a single prompt, figure out your stack. What's your backend? Your frontend? Your database? Is this a quick tool you'll host on Streamlit, or a full production application with a hosted backend, hosted frontend, and its own database?

Using Cursor's plan mode, you can explicitly ask the model to visualize your current or proposed architecture. This is where a human has the highest leverage in the development process: making sure the proposed structure makes intuitive sense and aligns with your business objectives.

Nailing down the optimal architecture before you start developing will save you enormous headaches down the road and help you avoid the tedious "refactoring" that happens when you want to make a change that isn't compatible with what's already built.

2. Create Plans

Use plan mode whenever you're working on a major feature. Even if you don't read the plan in full (which you should), plan mode forces the model to devote more time to thinking through the task, and asking you clarifying questions. It also forces the model to create an organized to-do list, which helps it stay on track through complex implementations.

One pattern I've seen work well: have one instance of the model write the plan, then spin up a second instance to review it as if it were a staff engineer. This forces a layer of scrutiny before any code is written. Plan mode isn't just for the initial build, I use it to create testing plans to verify the functionality of previously generated code.

3. Create Context Files, Rules, and Skills

Context files and rules are how you give the model persistent memory and guardrails across sessions.

In Cursor, you can setup rules that will be passed on to the system prompt of each interaction with a model by creating a .cursorrules. Here you should be storing the identity of your agents: constraints, style, and core principles. In my case, I like pushing the model to adhere to modularization architecture best practices, and an implementation that adheres to Occam's’ razor.

I also like creating a context.md file that stores business context, institutional knowledge and the overall challenge I am trying to solve which can be referenced easily by the model for it to develop greater contextual understanding.

A powerful habit: after every correction you make, end with "update your rules so you don't make that mistake again." The models are surprisingly good at writing rules for itself.

Think of these files as encoding identity: objectives, constraints, and institutional knowledge. Well-structured rules files include sections for core principles (simplicity first, no laziness, minimal impact), verification standards (never mark a task complete without proving it works), and task management workflows (plan first, verify plan, track progress, document results).

4. Build in Pieces

Even if it seems simple, trying to achieve your overall objective in one prompt isn't ideal. Break the objective into smaller features or tasks and approach each one step by step. Better yet, ask the model to break down the steps for you

5. Switch Between Models Strategically

Using Cursor, you can switch between models even within the same conversation. Here you can have some meaningful cost savings while also being mindful that not all tasks need complex reasoning and should favor speed.

6. Solve for the Root Cause

While building any software you will encounter bugs and errors. Especially when it's a hard problem, you'll find models prefer to be "lazy" by adding print statements and debugging logs instead of trying to figure out what the root cause of the issue actually is.

By asking the model explicitly to "solve for the root cause" I've seen meaningful improvements in its ability to fix bugs in one iteration, instead of burning through credits and cluttering your files with debugging statements that obscure the real problem.

7. Keep Documentation and Keep It Current

While the model will often create documentation unprompted, you should be strategic about what you keep. For major architecture decisions, prompt the model to store information about the choices made and the approach taken. This documentation is key for future models to iterate on your codebase more efficiently without trying to reason all of the architecture choices and implementation by reviewing every line of code.

But if documentation gets created that isn't important long term, delete it quickly.

Keep this bloat at a minimum. Large Language Models are typically presumed to perform uniformly. In reality, the closer your model is to its context limit, the worse its accuracy and performance.

8. Create Identities for Your Agents

This is where vibe engineering points toward the future. What makes agents powerful isn't just their ability to execute tasks it's the ability to encode identity. Each agent can have its own objectives, context window, permissions, and institutional knowledge

I see a future where you can have companies with individual “employees”, each with their unique context window, permissions and identity. This means you aren’t juggling hundreds of chats but rather replicating the experience of working with actual coworkers.

9. Use AI to Learn, Not Just Build

One of the most underrated applications of AI coding tools is using them as a learning environment. A few strategies worth adopting: encourage explanatory or learning-oriented output styles to have the model explain the why behind its changes, not just the what. Ask the model to generate visual HTML presentations explaining unfamiliar codes. Have it draw ASCII diagrams of new protocols and codebases to help you build mental models.

The more you understand what's being built, the better your prompts become, and the better your prompts become, the better the output. It's a compounding loop.

The people who invest in learning the engineering principles like architecture, planning, documentation, debugging and learn how to best manipulate the models will compound their advantage with every generation of AI.

Oh, and the website you are reading this on, I built using these principles.

SINGULARITY

Get new memos by email