Ramp up SDLC — Reverse Engineer with AI

The problem with traditional SDLC

For many years, the diagram below is our lovely cycle of regular SDLC. The good old “plan first — execute later”. And yes, it has been proven and applied everywhere, except one thing: In your SWE life, there are numerous of time you rework the whole project just because of hidden issue that can only be surface when you are actually working on it.

Legacy SDLC

We say step 1–2–3 (PRD + spike + Solution design) is “gathering requirement” and step 4 onwards is “actual work”. But that’s not really what happens.

The solution design is already engineering work. When the dev writes option A, B, C — they’re not just gathering information. They’re mapping out the pathway, picking the file touch points, deciding the data flow, calling out the feature flag, reasoning about the rollout. That’s engineering. We just don’t label it that way.

The problem: this engineering is done on theory, not reality. We write the SD, review it, ship it and only at step 5–6 when we actually implement, we discover the hidden issues.

• A feature that other teams have and been working on that we don’t know it exist.
• A race condition.
• A migration that won’t fit.
• Clunky user experience or when the “feature” is actually a “problem”
• …

Then we loop back to step 3 and redesign.

This is the tip of the iceberg problem and it is no one fault. We don’t know what we don’t know.

The SD covers what we can see. The bug lives underneath and we don’t know what we don’t know until we touch the code.

This meme is my life

The current flow

1. PRD: PM writes the problem, scope, success criteria.

2. Spike: Dev does light exploration. Reads the code, checks constraints. A few hours to a day.

3. Solution design — options A/B/C (theory)

Dev writes the SD with 2–3 theoretical options, trade-offs, recommended path. This is where the hidden engineering lives. The dev has already built a mental model of the system, mapped the affected files, reasoned about the flow — but only as theory. No code has been touched yet.

4. Review SD: Tech leads and peers review the theory. We catch some issues. We miss the hidden ones because nobody has touched the code yet.

5. Create tickets and start implementing: Break into tickets, assign, start coding.

6. Encounter unseen issues

The iceberg reveals itself. Something in the real code path doesn’t match the theory. Loop back to step 3, redesign.

The loop 3 → 5 → 6 → 3 is expensive. By step 6 we’ve already committed to the SD, reviewers have signed off, tickets are broken down and assigned. Redesigning midway creates rework for PM, design, QA, and dev.

The cost is huge, and it also affects the morale of the engineer who’s working on the SD as they could blame themself on the mistakes which is inevitable.

This meme is my life

Reverse Engineer — The AI game changer

The idea: do the working PoC first, then write the SD. Flip the order. Let the code reveal the iceberg before the SD gets locked in.

AI agents make this cheap and very accessible now. A PoC that took a week in 2023 takes an afternoon in 2026 by AI agents. So we can afford to build all three options (A, B, C) as working prototypes before committing to one.

This is the way

Steps

1. PRD: Same as today.

2. Spike + brainstorm (with AI): Dev uses AI to brainstorm the option space. Still light-touch. Goal: identify 2–3 candidate approaches worth testing.

3. VIBE coding: This is the game changer!

Build each option as a working PoC, in parallel, with the AI doing most of the heavy lifting.

Outcome:

• Working “code” for the feature on each PoC approach
• Final diagram of the exploration
• Pros and cons for each of them
• Benchmark if needed

These are throwaway. The goal is not to ship them. The goal is to feel where the iceberg sits for each option.

Yes, you can build PoCs before without AI helps in the traditional way, but the the cost is too much. Not to mention the effort and morales of the engineer when seeing all of the PoCs going to waste. This is where AI makes it possible in this era.

4. Review and unearth hidden issues

With real code in front of us, review what we learned. Which option broke unexpectedly? Which touched more systems than we thought? Which had migration risk we missed? Which had the cleanest data flow?

At this point, the SD practically writes itself. We already know what works and what doesn’t. The theory is backed by running code.

5. Solution design — based on the PoCs, choose one, start spec-driven development

The SD becomes a recording of decisions already validated, not a speculation document.

Pick the winning PoC, write the spec for production-grade implementation.

6. Review: SD review is now grounded. Reviewers look at real code plus spec, not diagrams and hand-waving.

7. Create tickets: Standard breakdown.

8. AI generates under dev supervise:

AI writes the production code from the spec, dev reviews and steers. Because the hidden issues were unearthed at step 4, we don’t loop back.

Why this is better

1. SD stops being guesswork and less rework. It becomes a record of what we already proved works. Sometime the big feature is just a very small one, and vice versa.
2. The iceberg surfaces early and cheap. Hidden issues show up at step 4 (PoC review), not at step 6 (mid-implementation).
3. We compare real options, not paper options. Trade-offs are measured, not argued.
4. AI does the heavy lifting. Building 3 PoCs in parallel was impossible in the old world. Now it’s a day of work.
5. Early feedback. With the PoC, the internal team can have a look and feel on how the new feature belike. Just like the technical hidden issue, this can also help to surface some weird valid cases that can only be found when you actually use it. And before paying the price to rework everything or even cancelling it at the T minutes, you can solve it forward.

What to watch out for

• PoCs are throwaway. Hard rule. Delete them before step 5 starts. Otherwise someone will ship the PoC and bring its shortcuts into prod. However for some very simple feature that we thought
• Define the PoC “done” bar. Happy path? Edge cases? Scale test? Without a bar, step 4 becomes subjective.
• Not every initiative needs this. For “just build it” work with one obvious option, skip the PoC stage and go straight to SD.
• Cross-system concerns still need SD reasoning. PoCs are usually narrow. The SD still needs to cover things the PoC doesn’t show — auth boundaries, rollback, migrations at scale, observability, cost.
• AI abuse AI does all the PoCs doesn’t mean it’s free. Not only the money pay for the tokens but time consuming and bloating context with unnecessary paths could cause cognitive overload and forgot what the real problems are.

tl;dr: Just use AI for PoC then reverse the working code to the proper solution design and start working on it.