What 6 months of AI Systems did to my dev team
Derek reflects on six months of AI use: experimentation, meaningful checks, easier access to repository knowledge and signals that help him decide where the team needs support.
The YouTube player loads only when you choose Play. YouTube then processes data under its own policies. Watch directly on YouTube ↗
The main idea
Build a repeatable loop around work you understand, check the output, and keep experienced people involved.
Key takeaways
- Learn one useful AI task yourself, then give the team room to experiment. Watch at 0:27 ↗
- Check real application behavior as well as lint and test results. Watch at 2:17 ↗
- Treat repository analysis as a first pass for people with business context to review. Watch at 5:00 ↗
- Use stale-work signals to start a conversation about what would help. Watch at 7:19 ↗
- Start with a small read-only email summary loop and correct its mistakes. Watch at 9:06 ↗
Episode breakdown
0:00 How six months of AI systems changed the team ↗
These are Derek's personal observations of changes in contribution and leadership attention, rather than a controlled productivity study.
0:27 Give engineers room to experiment ↗
Model useful experimentation and make room to learn, including attempts that produce no immediate value.
1:18 Start with work people want off their plate ↗
Start with documentation, maintenance, logs or email: recurring work where people understand what a useful result looks like.
2:17 Build checks into the AI workflow ↗
A package upgrade needs checks of behavior, tests and, where relevant, the interface. Build those checks into the process.
2:44 Coding standards, linting, and useful tests ↗
Linting gives specific feedback, but a passing test can still miss broken behavior. Keep someone responsible for evaluating the actual need.
4:11 Faster learning for new engineers ↗
A new engineer could produce useful repository documentation sooner while continuing to work with a mentor.
5:00 Understanding a legacy repository ↗
AI drafts documentation and diagrams, a separate model checks for gaps, and a team member reviews the business meaning. Experienced people explain the history behind the code.
6:47 How AI changed my attention as a leader ↗
Morning summaries helped Derek decide where to spend attention instead of trying to retain every detail himself.
7:19 Find blocked and stale work ↗
Blocked or stale tickets prompt investigation. Discuss dependencies, scope and decisions before inferring why the work has stalled.
9:06 Build one small email loop ↗
Use permitted email in read-only mode. Compare the summary with the messages, explain corrections and repeat the next day.
10:03 What to watch next about time management ↗
Continue with the related time-management episode to decide what to delegate or decline.
AI in practice: a small email loop
The closing exercise is a read-only email summary loop using information you are permitted to share. This is spoken guidance, rather than an on-screen software tutorial.
Tool: An AI tool you are allowed to use
- Start with read-only access to permitted email.
- Explain your responsibilities and how you communicate.
- Ask for a summary and the most important item requiring your action.
- Compare the summary with the actual messages and explain corrections.
- Repeat the next day and review whether the result improves.
The leader’s review
Check the underlying information and the reasoning. You remain responsible for the decision and any communication.
These steps summarize spoken guidance in the final video; no verbatim prompt or downloadable skill is supplied.
Try it with your team
Try the email loop described from 9:06. Keep the first attempt small enough that you can check every relevant message.