I help dev teams be insanely productive with AI. Courses: https://xitter.cf/t.co/D5emROQHUh & https://xitter.cf/t.co/6L1fD89GbP Consulting: https://xitter.cf/t.co/Qfp4TfpB8N ⚛️
Kansas City
Joined January 2009
- Tweets42.5K
- Following841
- Followers168K
- Likes27.2K
"Release planning" meetings are a process smell.
A typical release shouldn't need ad-hoc planning, batching, negotiations, outside approvals, or custom processes.
I’ve seen many teams struggle because their tickets are too big.
I’ve never seen a team struggle because their tickets are too small.
I spent 25 years getting good at web dev.
I memorized syntax, browser APIs, accessibility techniques, and performance optimizations, security patterns, and learned dozens of libraries and frameworks.
Now I'm trying to decide what knowledge still has value.
I’m working with a team that's “all in” on agentic coding. Lots of skills, instructions, subagents, hooks, etc.
But I just noticed they’re not running their tests on CI.
Takeway: AI makes it easier to do stuff. But it doesn’t assure you’ll do the right stuff, or do it well.
That’s still your job.
This post outlines an interesting new approach that AI unlocks: Non-code automated tests.
For example, QA doesn’t typically have the tech chops to write and maintain code-based tests.
But they can certainly ask Claude to click around for them!
Before you launch anything, have Opus 5.5 send 5 subagents in as your first users.
Paste this into Claude Code:
"Act as my launch QA lead. Spin up 5 subagents, each a different first-time user:
1. The impatient one: skims, clicks the first button, quits at the first error
2. The skeptic: reads pricing, terms and privacy before signing up
3. The mobile user: does everything on a 375px screen on slow 3G
4. The non-native English speaker: only follows what the UI literally says
5. The breaker: pastes junk into forms, hits back mid-flow, double-clicks everything
Each one opens the app in a real browser, goes from landing page to first success, and screenshots every moment they get confused, stuck or annoyed.
Merge everything into one list ranked by how many users hit it. Fix it all in one pass, then rerun the 5 users to prove it's fixed."
Your first 100 real users won't tell you why they left. these 5 will.
(Works best with a browser MCP connected, Playwright or Chrome DevTools)
I speak at 1-2 dev conferences each month.
AI talks are packed. Other sessions on frameworks and languages are often near empty.
For example, last week I presented "Automating Quality with AI". Standing room only.
But talks unrelated to AI felt thin in comparison.
The difference is wild. And it's new. Session attendance used to be pretty balanced. It's super lopsided now.
People are hungry for all things AI... and relatively disinterested in everything else.
Nice code review idea I’m seeing more teams adopt: Classify changes.
If it’s low risk, just do automated review.
If it’s high risk, then require 1-2 humans to review.
Claude writes about 90% of Claude Code's code.
From June to September, merged PRs more than doubled while the share reverted fell by more than 40%.
We wrote about how we changed code review to get there, and how to adopt it:
claude.dev/blog/solving-code…
I keep talking to developers at conferences who seem genuinely depressed about what AI is doing to their career.
People are genuinely worried, and they miss the “old days”.
It’s concerning.
Still doing human code reviews? Then focused PRs are more important than ever.
If the PR contains many unrelated changes, then for every line I have to first determine what the change is for.
If the PR is focused on *one* thing, I know the general intent of each line before I even start reading.
Good news: AI is good at splitting big PRs into small, focused, stacked PRs.
I’m pairing with QA to help them write automated tests using Claude.
Benefit: They don’t have to manually test the app anymore. So, they can focus on exploratory testing instead.
Downside: QA doesn’t understand the test code that Claude is generating, and their tests run separate from the CI test suite.
I’m torn if this is a good idea.
Should QA collaborate with devs on writing automated tests instead of creating their own tests? I’ve never seen such collaboration, but in theory could work…
Waiting for stand-up the next day to announce "I'm blocked" is such a bad look.
Don't wait for stand up. Reach out immediately.
Be proactive.
I’m tired of worthless stand up meetings. Most people share useless info.
“I’m working ticket 123”.
That’s what the Kanban board is for.
Standup is for *novel* info.
With AI, it’s tempting to create big tickets because AI can handle big tasks, and it generates code so quickly.
But the benefits of small, focused tickets remain relevant in the AI era.
- Get feedback quicker.
- Avoids context bloat / compacting.
- Less chance of spending a bunch of time going in the wrong direction.
- Leads to small PRs, which are easier to review.
- I’m more likely to understand a small ticket, and to notice gaps, inconsistencies, and logical issues in the requirements.
- Small tickets lead to smaller releases, which reduces risk.
