- 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.
knighthacker•25m ago
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...
superpickles789•2m ago
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?