You can still become a senior engineer in vibe coding era

There is this growing fear right now: if junior devs use AI to write code (or just vibe code), they will never become senior (or more experienced) engineer.

We have already seen this notion floating around on X. In a recent conversation with a friend:

I have been tinkering around this from quite some time. In fact more around how junior devs can bring up a taste if they are just getting started.

If you look it more closely, the problem is more about outsourcing judgement than AI-assisted coding itself.

A junior engineer can vibe code (or even code manually) and still stay junior for years if they never learn how to reason about tradeoffs, debug production issues, and improve code health over time.

A senior or more experienced engineer, on the other hand, can use AI heavily and still be very much senior because the seniority is more about taste, judgment, and responsibility. A good number of L5s and CTOs do not write code often.

---

I think it is subjective to each individual how they want to approach building software and think about systems.

In this article, I am increasingly pushing towards a middle path. Let’s call it lazy coding.

The first question which arises here is what differentiates it from vibe coding and standard coding and how it balances the same.

It is not vibe coding where you only throw prompts about your ultimate goal and hope it comes out to be true.

It is also not traditional coding where you think too much and might over engineer the first draft. That can slow down the process of building.

What you need to do

Always have a self belief that you will be learning a lot on the fly.

Try to write a rough version yourself. Even if you do not know, learn to write a rough version. It helps a lot, at least in understanding fundamentals of building software.

Think about systems. Treat it like a black box which you are going to nurture with a lot of iterations.

One tip here is “documenting dot md”. Ask your model to keep it running while you are doing changes in code. Review it often.

Use models to handle the repetitive parts: refactors, edge cases, tests, cleanup, docs.

That rough code is often a better spec than English sometimes. It gives AI context in the format it understands best because your prompt can be vague for the model. But you still own the thinking.

And that ownership is what grows you.

---

The manual effort in building software is changing by an order-of-magnitude and we can expect this trend will continue.

But here is a thing.

Every startup, big tech company, and research lab still needs great engineers with experience building systems. And they will need them for a long horizon of time.

As builders and researchers, we are supposed to build a system. You can term it as a product, tool, or a complex application.

Talking with great engineers, collecting insights, and reflecting on my own experiences led me to some habitual thoughts that feel pragmatic:

• Explain before you accept. This might be tiring, but put a count. You will be reviewing at least 6 out of 10 times.
• Try to debug manually at least once. It is a strong learning experience.
• Read the diff. Tiring, but it is what a strong code review does.
• Think about system design, the data model, and the failure modes. Own this. Ask the model to help, but keep a mental model of the architecture.

I think there are small things we can do to elevate ourselves until AGI is there. This article is a kind of personification of the same.

I am still thinking we can add more steps or methodologies here. Would love to know your thoughts.