tl;dr
AI didn’t replace developers; it collapsed roles. A single engineer can now draft a product slice, validate it with users, write acceptance criteria, generate a first pass, test it, and ship—often in the same afternoon. The devs who thrive will be those who think in problems, users, and narrative first, and only then in libraries and frameworks.
Spec → Tests → Generate → Review → Ship loop below to turn “vibe” into repeatable results.You don’t have to stop coding to start leading. You just have to code like a PM: with a crystal‑clear “why,” guardrails, and feedback loops.
Well, pun intended, of course.
I’m not implying that Product Managers are bad or that they are not good at their job. Although I have seen my engineer friends hating on Product Managers and Testers all the time 😄. Being a Product Manager with a technical background, I have seen both sides of the coin. Luckily enough, when I was a tech lead, my PM also had a technical background. Instead of tension, there was mutual respect and even inspiration.
If you ask me, I have a perspective on it. So if a Developer is a Pokémon, they might evolve into a Manager and later a Technical Lead and then a VP of Engineering—if they like being founders too. But this doesn’t mean all of us will, or even should.
Then here comes the AI and the irony…
If you think about it, vibe coding has not only shifted the tech landscape but also turned the tables, hasn’t it? Suddenly you might find yourself in the shoes of a tester 😅, and writing a good prompt feels exactly like writing a detailed user story.
You are now wearing three hats: Product Manager + Tester + Developer. 🤯
I don’t want to be Baba Vanga or something, but the tech job exodus is on the horizon now. When my old mentees ask me for advice, I tell them that they’re great developers, but it’s time for the Pokémon to evolve. I tell them to develop product sense. But the question is—can everyone adapt to it?
If I have to categorize developers, I would put them into three broad categories:
Signature traits: You naturally think like a user. You write stories before code. You notice friction, propose better flows, and often pre‑empt bugs with thoughtful tests.
For example: You may have seen the OG OSS developers—yes, I’m talking about them. They relate to a problem at a user level. Most OSS developers (from my experience) are trying to solve a problem for themselves. So planning comes easy; defining user stories is easy. A few of them have good design sense, and they end up creating loved and viral products. Not just solving problems, but solving problems with style. They are like Michelin‑star restaurant owners, baking a good experience along the way.
🤔 What it looks like at work: You push a story from “works” to “feels right.” Testers rarely find surprises.
✨ Why this thrives now: AI supercharges people who give it crystal‑clear specs.
🚀 Trajectory: PM/Tech Lead comes naturally—you’ve been doing the job without the title.
Signature traits: You love hard problems, patterns, and clean solutions. LeetCode is your playground. UI polish isn’t always your first instinct, but you can flex when needed.
🤔 What it looks like at work: You crush tricky tasks, sometimes under‑invest in UX.
💊 Hard pill: If you don’t evolve into clear spec + user lens, you’ll be arm‑wrestling AI that’s getting better at pure problem‑cracking.
🚀 Trajectory: With a bit more user empathy and end‑to‑end testing, you’ll drift into Category 1.
Signature traits: You ship volume but miss acceptance criteria, hand off bugs to QA, and treat stories as tickets rather than user outcomes.
Sadly, these developers are more in number, thriving in big corporate environments. They don’t care to read user stories and often miss the acceptance criteria. These are basically junior developers with fancy job titles, which they got just because of their time in the industry. They have no motivation to evolve and are sadly milking big cash because they have been like this for 5+ years. God knows why companies value numbers over quality. They are valuable because there is an ecosystem that supports them: bad coder → more testers → longer product timeline → more money to milk from the client. So everyone wins except the client of these companies (sorry for my rant there 😅).
🤔 What it looks like at work: Projects stall, cycles stretch, and quality debt grows.
🤷🏻 Reality check: This model won’t survive long.
🚀 Trajectory: Start with specs, acceptance criteria, and your own test checklist— or themarket will do the sorting for you.
If you never stop learning, you’ve already tilted the odds in your favor.
Evolving is part of human existence, but today it has become more than that—it’s about survival.
Vibe coding: using AI with rich context and clear specs so models produce predictable, testable output.
AI performance rises or falls with how clearly you define the problem. And that’s not just for coding—check my article on context engineering (for prompting win with AI).
But this mindset might not come easy for everyone, and that’s why vibe coding tools are themselves shifting your attention there. Product‑Minded → formalize with Spec Kit; Problem Solver → narrate user acceptance with Agents.md; Job Holder → enforce acceptance criteria with Kiro before coding.
A few notable ones include:
Pick one tool and run a 1‑sprint pilot. Start with a 5‑minute spec template, then compare bug counts and review cycles before/after.
Some may say a product mindset is an inbuilt feature for most people, but I disagree. With hard work, everything can be learned and mastered.
The first step is simple: OBSERVE. Every day we interact with countless apps and products as users. Your learning can start there. These apps are filled with hidden gems. Ask: Why do you love a product over its competitors? What feature do you love and why? What design choices are ingenious? That’s where you develop a sense of what might work and what doesn’t.
Observe → Frame → Test → Ship → Measure
Observe: Screenshot two moments you loved or hated in apps you used today and write one sentence on why.
Frame: Turn each into a problem statement and a desired outcome.
Test: Draft acceptance criteria (Given/When/Then) so “done” is unambiguous.
Ship: Build the smallest coherent change that proves the idea.
Measure: Pick one HEART metric (Happiness, Engagement, Adoption, Retention, Task success) and watch it for two weeks.
Lastly, build an OSS of your own—a problem personal to you and a hinge that others want a tool or app for. Launch it on Product Hunt and ask users for feedback. In no time, you will develop the product mindset—and who knows, you might build a business around it too.
Principles to steal: Start with the problem. Think big, start small, learn fast. Ship often.
1. **User story:** Who is the user? What pain? What job‑to‑be‑done?
2. **Acceptance criteria:** Given/When/Then, including edge cases.
3. **Tests first:** Red → Green → Refactor. (Even one tiny test!)
4. **Generate:** Ask AI for the smallest implementation to satisfy the tests.
5. **Review:** Read the diff like a PM—does this match the **intent**?
6. **Ship & measure:** Add analytics or a measurable **proxy for value**.Spec checklist
- User → Problem → Outcome in one sentence.
- 3–5 **acceptance criteria** with edge cases.
- Non‑goals (what this won’t do).
- Observability (how we’ll know it works).
- Rollback plan (what if it fails?).Prompt checklist
- State **role** and **constraints** (language, style, deps).
- Provide **examples** (tests, input/output).
- Ask for a **diff** or single file, not essays.
- Request **assumptions** and **uncertainties** explicitly.
- Cap scope (“only implement X to make tests pass”).The safest path is evolution: widening your impact beyond code so your career compounds.
🤞 Here’s why I’m optimistic: Developers have a tactical advantage in this age of AI. If they understand the product, test it, guide the AI to fix an issue in code—or fix it themselves—they can be a solo force‑multiplier. They will ship better products, faster, and create more jobs in the market. SaaS will be built and iterated like fast fashion—short cycles, rapid feedback, constant remix.
Open source and local‑first are accelerating; smaller teams can ship meaningful fixes faster. Pick one OSS you use, close a small bug this month, and document before/after in a 5‑line changelog.
Evolve your lane: formalize specs (Product‑Minded), narrate acceptance (Problem Solver), or enforce criteria (Job Holder)—then ship.
💪 30‑Day Challenge: Become a Product‑Minded Dev (While Still Coding)
May the force be with you.
Choose your lane today: formalize specs (Product‑Minded), narrate acceptance (Problem Solver), or enforce criteria (Job Holder).
Pick one, ship one, learn one. Evolve, don’t wait. ⚡️