Ask HN: What's your team's SDLC look like in this AI world? | Hacker News Reader

Ask HN: What's your team's SDLC look like in this AI world?

4 pointsbroAhmed4 comments

Our company is changing its Software Development Lifecycle (SDLC). Curious to hear from others what theirs looks like overall + bottlenecks. Ours:

- 1 week planning/retro, 6 weeks implementation (basically six 1-week sprints).

- Standup now mainly demoing what Engineering/Design is working on, getting quick feedback from teammates.

- Meetings are recorded/transcribed. Agents generate Product Requirement + System Design docs from those meetings.

- Push to have non-engineers be able to commit code, but engineering still responsible for shipping it.

Unsolved issues/bottlenecks:

- Ephemeral test environments (per PR test environments) aren't 100% reliable yet.

- No longer doing capacity planning, but it feels like we need to go back to it.

- Code reviews. They're longer and there's more of them. Even more with non-engineers being able to @Cursor on Slack.

- Design used to have Figma as the source of truth; now that they're heavily leaning on Claude Design, we don't get the linkage of Figma components to code components. We might solve this by moving from Cursor to Claude Code.

Hope-Driven-Development lol

We're growing very rapidly. So honestly, standup meetings now became the most important meeting and "definitely not a standup". A lot of product/customer things are decided during the call, engineers, PMs, and everyone really demos what they've worked on and questions are asked and answered during that call.

Code reviews are gone. We review the coding session itself instead. Everyone shares their coding sessions with whoever is going to review and the reviewer engages with the CLI to ask questions.

Disclosure: I'm building AQ (aq.dev) around exactly this workflow, so I'm biased. Longer write-up of the review approach: https://aq.dev/guides/reviewing-pull-requests-from-ai-agents...

> Hope-Driven-Development lol

I lolled.

Good to hear our standups are sounding like yours.

> reviewer engages with the CLI to ask questions.

Love this.

Read the post and appreciate some of the tips, e.g. looking at tests to check agent's assumptions.

How do you prevent sheer number of code reviews from becoming a bottleneck?

> Ephemeral test environments (per PR test environments) aren't 100% reliable yet

Curious to know what's the exact bottlenecks you have here? fwiw; have worked on this with a few teams so far and built ephemeral environments so it can run for each PR review.

Being a smaller team, our process is a lot simpler, but the "ephemeral test env" is the one bit that's helped us move faster and more confidently

Since it allows us to automate regression testing with visual QA agents that test the app like a real user (mostly through Coldtea, which we build)

P.S: Been meaning to have calls recorded/transcribe. How do your agents retrieve the vast info in these transcripts? By that I mean is it effective?

Reply on news.ycombinator.com