Coding with vibes in 2026

It’s very rare that you get to pen your thoughts on a topic. And the post can become obsolete within a couple of months. With that optimistic reminder,

Let me give a realistic teaser: I am not going to list “top 10 tips” to become a vibe coding super star. There are posts from better engineers almost every day. Instead, I list directionally what I am doing these days:

I’ve been an engineer for 15 years. Been vibe coding ever since Claude Code came out. 95% of my coding today happens via vibe coding. Whatever that says about me, I will leave that to you. But I do believe this is the next exciting iteration of our craft.

1. Read the code (including vibed code).

It’s irresistible to give a task to a coding agent, validate the results, and move on. But we are losing the important feedback loop. You need to read the code that got generated. That’s how you understand the nuances.

What system design is being created? How are different files linked together? What code is being written in a single file?

Our mind needs to go through the painful process of reading and re-reading to know which one’s right and which one’s wrong. Eventually, the mind will get better at this. It will figure out what to skip.

To learn a new language, one proven way is to consume content (movies, podcasts, books). Even if you don’t understand a single thing. Eventually, your mind will form the association. It’s the same principle.

Read the PRs. Read the tool calls that coding agents write. Read system design docs. Just read, even if you don’t understand a thing. Make your brain feel the pressure.

I learnt from reading vibed code that the priorities of coding agents and ours, the engineers, are different. Ex: writing clean code at a repo level is important for us. For a coding agent, it’s important only at a task level.

2. You’ll write more English. Not less code.

One wrong expectation is that you are going to write less. Not true.

We have to write in a different language. English. If LLMs are smart interns (or PHDs), our project descriptions/ design docs/ task descriptions are what that intern uses to produce results. The more we write, the smarter we write. The smarter we write, the richer the result.

Sending two sentences to a coding agent → expecting the result in the exact way you wanted → would not work. This is not a new paradigm. It never worked. We always operated in strict environments with compilers, rules, and syntax (even if JavaScript made you think otherwise :P). Types matter. Compiling matters. We can’t write “a plus b” and expect “a + b”. The error was immediate.

It’s similar in vibe-coding. There are 10 ways to create a Slack integration. If you just ask the LLM to integrate Slack, it will do so in a version that comes up first in its training data. Not necessarily the one that suits your requirements.

3. IDE is no longer just the editor.

My first program ever was written in gedit. Then came sublime, Atom, IntelliJ, VSCode, Cursor, and I ended last year with CLI. This year, I use a mix of kanban, CLI, and VSCode.

No one knows what the next coding editor is. But it’s clear it’s not going to be the same IDE.

And when I mean IDE, it’s not just the editor, it’s also the extensions you bind with, the “skills” you pull, and the workflow you use. Git worktrees are a thing now. It didn’t work for me (I am a multi git clone guy.) But it might work for you. Kanban is super visual and helpful to me. You might prefer coding in a chat interface like ChatGPT.

Go ahead. Experiment. Even better, build your own IDE. Customize. Be part of the change and start forming the mental patterns.

4. Plan first. Vibe next.

Vibe coding reminds me so much of the early days of coding. Before coding guidelines, abstractions, and SDKs came in.

There’s child-like wonder in just writing something without planning and seeing the result immediately. But you will soon find yourself faltering. Bad code stacks, compounds, and hurts. To implement something durable, you need to start with strong foundational patterns.

It’s the same in vibe coding. Once you are past the “wow” arena, you want to plan first before handing it off to the agent. This will save you loads of painful debugging time. It will save you those follow up prompts where you uppercase and shout at the agent. It will save you the internal monologue of wondering if vibe coding is slowing you down or if it is actually helpful.

I am not asking you to plan every single feature. There’s a nice balance. I found it helpful to plan for medium and long features. You will figure out your own rhythm. Just keep this in the back of your mind.

5. Context management is a challenge.

It’s an evolving topic. LLMs have fundamental issues - context rot, hallucination, and so on. And large-scale coding clearly requires a smarter way to deal with this.

Industry seem to play around AGENTS.md, Sub agents, slash commands, and tools. Skills are the latest entrant, and they have real potential to stay for a long time. Be aware of context management as a principle. Currently, the baseline I would recommend knowing is:

• Sub-agents → separate context window. The main prompt instructions are copied to the context window. Has separate tools.

• Skills → brings in additional context to the main agent when required. Ex: Best practices. If there are scripts, it brings in the IO of the script instead of the script itself.

Another player that’s part of your context management is external integrations. Ex: MCPs

Integrations will amp up your vibe coding experience. I use web search, pen testing, Notion, and Linear MCPs so far. There’s real value. But they are slow and not straightforward. We will figure it out. But it’s something to watch out for.

6. Learn to work on multiple tasks at once.

It’s clear we are going to work on multiple projects/ features/ todos at once. That’s the end-game promise of vibe coding. But the concept is still pretty new. We have always worked on one task at a time because that was honestly the only way to get work done. You couldn’t code on two projects at once. The switching costs were very high. But that cost is coming down drastically.

Some patterns here can be found by watching senior/ staff engineers and engineering managers. They are seeing the first value of parallelization because they always orchestrated multiple features at once. Now every engineer can do this. We just need to practice.

7. New engineers: don’t rely completely on vibe code.

Atleast not yet. Even though it seems that you wouldn’t need to code in the traditional sense two years from now. We are not yet there today. Your mental patterns to understand concepts at a system design level didn’t form. If a bug happens, you still need to get your hands dirty.

I recommend only using coding agents for max 50% of the code. Ideally, ask the coding agent to tell you the changes, and you do it yourself. Your brain requires the feedback loop.

Btw, this was always a fast-moving industry. You should have a certain personality for the industry to resonate with you. Welcome to our fastest iteration of the craft :)

8. Pro engineers: it’s ok to grieve. But there are far more reasons to be excited about.

It might seem daunting that an AI is able to code something in minutes that would take us days. That someone else is stealing the act that was part of our craft. Take time to grieve. It’s a valid emotion. But,

The way I see it, the purpose of the art and the art itself didn’t change much.

Coding has always been a fast-moving industry. We as a species were never happy. I remember when I coded in a single 5K line jQuery file to power an entire e-commerce checkout flow. It was replaced within months by React. I never touched jQuery post that. Our code gets written, rewritten, and deleted so often to replace it with something better. We were the frontiers of finding better abstractions. This is literally part of the craft.

I see that coding as an art form is part of a hero’s journey. A customer has a pain point, and we solve it with code. That hero didn’t change. That intent didn’t change. The fun in figuring out how to make the hero succeed faster with a reliable solution didn’t change.

Tools changed. The impact that we can create changed. Instead of helping the hero with a smaller problem, we can help them solve much bigger problems.

The hero might take time to realize how much they can do. There will be fluctuations. Designers will become design engineers. Sales might become sales engineers. Engineers might become forward-deployed engineers. There might be more entrepreneurs than ever before.

We don’t know what's going to happen. The transition might be painful. But if you stick with the craft because you love it, we will reach the new island together. It’s going to be an exciting place wherever we reach.

One of my favorite authors said this about AI and art… the art is not the final piece we deliver. That’s just a token of work done. The art is the process, and the art is the person who puts in the effort. Art is us.