Or am I missing something?

Guys, let's talk honest about AI SDLC orchestration.

Has anyone here actually successfully moved AI-driven software development from "cool local demo on a senior engineer s MacBook" into governed enterprise-grade SDLC system?

Went looking for why a service got slow and found four ways of making an HTTP request in it. A fetch wrapper, axios, and two hand rolled retry loops. Nobody added them in one sitting. Each one arrived in a different session, in a diff that was correct on its own, and I approved all four.

That's the failure mode I didn't see coming with agents. They're good at the task in front of them and they have no opinion about what the repo already does, so every session starts from a blank slate even when the codebase doesn't. Bad code you catch in review. A second correct implementation of something you already have reads fine in a diff, and it only shows up later when a change has to be made in four places.

With AI writing the majority of first drafts now, I've noticed something shifting in how engineering teams work, the bottleneck isn't writing code anymore, it's reviewing it.

A few things I've been thinking about:

• Most devs I know got good at coding by writing a lot of it. But we never really trained to read it the same way.

• Code review culture is getting worse, not better, as AI output volume increases. People are rubber-stamping PRs they don't fully understand.

• The bugs that make it to production aren't from bad writers, they're from missed reads.

Curious if others are feeling this. Do you actively practice reading code, or is it just something you pick up passively? Has AI changed how carefully you review code before merging?

I'm a veteran and solo founder with no formal coding background. Spent the last few weeks directing Replit's AI agent (with Claude as a strategic/QA partner) to build a real production app, entirely from my phone.

The part that surprised me: the "vibe" is the easy 20%. The other 80% was the same discipline any build needs catching bugs by hand (missing auto-capitalization, a timezone off-by-one, a file upload limit rejecting real phone photos), refusing to accept "it's fixed" without proof, running full walkthroughs section by section, chasing root causes instead of patching symptoms.

That's made me rethink what "vibe coding" even means. It's not skipping the engineering discipline it's relocating it. Instead of writing code, you're writing precise instructions, reviewing output critically, and doing QA like a hawk. If anything it demands more discipline, not less, because you can't rely on catching mistakes by reading your own code you have to actually test everything.

For others who've directed an AI agent instead of hand-coding: has your experience matched that, or did you find a different bottleneck? What ended up being the hardest part for you the instructing, the reviewing, or something else entirely?

Heya

I m thinking of building a simple, unbiased comparison platform for products, services, tools even technical stuff like frameworks, APIs, and AI tools to help you decide faster with clear side-by-side insights.

Personally, I often find myself deep in Amazon reviews, YouTube videos, and scattered blog posts when trying to choose something new. While some comparison sites exist, I ve never found a complete or truly comprehensive solution. The same goes for developers when exploring new frameworks or libraries with similar alternatives, a quick, focused comparison could really help clarify things.

Before going further, I d love to hear from you: Would you find this useful? Your feedback will help shaping what I build next.

Lately it feels like every week there s a new AI-powered SaaS launching.

Same landing page formula.
Same promises.
Same 10x productivity pitch.

And what s interesting is the number of products keeps increasing but I m not sure demand is increasing at the same rate. It feels like we re repackaging the same value just slightly different positioning.

New UI.
Different niche angle.
Built for X .

Had a moment this week where a bug showed up in a part of the app I didn't write by hand, my agent did, and when someone asked me why it broke, my honest answer was "I'm not totally sure yet." That's a weird sentence to say out loud as the person who's supposed to own the code.

With code I wrote myself I can usually reason about a bug from first principles even before I open the debugger. With vibe-coded stuff I sometimes have to re-read the whole file like a stranger before I can explain anything, and the explanation ends up being "here's what I found after digging" instead of "here's why this happens."

Do you just wait, work on something else, or review the changes as they happen?

For me, every commit tells a story. To really understand the code, I first need to understand why each change was made and how it fits into the bigger picture.

That s why I try to stay involved while the agent is working reviewing the diff, creating a issues, following the logic, and making sure it s heading in the right direction.

I asked an AI assistant to review a repo before shipping it.

It came back with a clean report, a confident tone, and a long list of passes. Then I checked one of the lines it cited.

The line said something else. The mistake itself didn't bother me that much. What bothered me was that there was no shape in the output for "I don't know."

Everything was either a problem or a pass. And the passes were doing a lot of unearned work.