Keep Learning: Bringing New Tools (and AI) Into Real Work

TL;DR Chase every trending tool and you spend hours on things that never touch your work; push one on your team and it can quietly lock bugs into your tests. To introduce a new tool at work, AI included, start from a real gap in your own work, run a two-week pilot on one feature with a baseline and rules, write down the costs as well as the gains, and let the team decide.

Do this: Write down the one thing that slowed you down most last month, and learn only what closes that gap.

Part 3 ended with Pip's evenings back and a new itch: she wants to grow. Brock keeps mentioning an AI tool that writes test cases, and the Admiral's team is talking about it too.

Pip stares at a list of "things every developer should learn this year". Rust? Kubernetes? That AI test tool?

Kit leans over her shoulder. "What slowed you down most last month?"

Dev Voyage: Open Ocean, in six parts:

1. Working With a Difficult Boss Without Losing Yourself
2. Feedback Both Ways: Asking For It and Giving It
3. Say No Without Making Enemies, and Keep Your Energy
4. Keep Learning: Bringing New Tools (and AI) Into Real Work (you are here)
5. Talk to the Business: Working With PMs and Non-Engineers
6. Ask for the Raise: Showing Your Value Without Bragging

Start from what slowed you down

"Refund tests," Pip said. "Edge cases. Two days."

That answer made the list irrelevant. The AI test tool was worth a look because it might close a gap she actually had. Rust could wait.

Pip's learning habit after that was simple:

• One gap from real work, written as a sentence.
• A little learning, twice a week, in the focus block she won back in part 3.
• Used on a real ticket the same week, while it's fresh.
• Shown to the crew in ten minutes. Explaining it is how you find what you didn't understand.

A pilot, not a campaign

The fastest way to make a team hate a tool is to push it on everyone at once. The Thoughtworks Technology Radar sorts technology into rings: assess, trial, adopt, hold. A pilot is the trial: small enough to be safe, real enough to teach you something. Pip asked Kit for two weeks and wrote one page.

Question:  Does the AI tool help us write edge-case tests faster,
           without letting bugs through?
Scope:     One feature only: partial refunds. Two weeks.
Baseline:  Last similar feature: 2 days of test writing, 31 tests.
Measure:   Time spent, tests kept after review, bugs found, bugs missed.
Rules:     Company-approved tool only. No customer data or secrets
           in prompts. A person reviews every generated test.
Decision:  The crew decides together at the end: adopt, change, or stop.

What the two weeks showed

Test writing took about a day instead of two. Pip kept 26 of the 40 generated tests after review. Then, on the last Thursday, Bun shouted across the deck.

The tool had read what the code does and written tests that expect it, bug included. Without Bun's review, those three tests would have locked the bug in.

Public research is mixed in the same way. In GitHub's controlled experiment, developers using Copilot finished a set task 55% faster. DORA's research on AI describes it as an amplifier: it magnifies a team's existing practices, good and bad. Your own pilot, on your own code, is the result that counts for your team.

Pip wrote the result up the way Michael Nygard suggests for architecture decisions: context, decision, consequences.

Got:       ~1 day instead of ~2. 26 of 40 tests kept after review.
Watch out: 3 tests encoded a rounding bug as correct; caught by Bun.
Proposal:  Use it to draft edge-case tests, with two rules:
           1) every expected value comes from the spec, not the code;
           2) a second person reviews generated tests.

The crew voted yes, with both rules. Nobody felt pushed, because the bad news was in the report next to the good. A pilot that ends in "no" is just as useful: the team stops arguing about the tool, with evidence.

Try it

This week:

1. Write down the one thing that slowed you down most last month.
2. Book two short learning blocks and use what you learn on a real ticket.
3. For a tool you're curious about, write a one-page pilot plan with a baseline and rules.
4. Check your company's AI policy before the pilot starts.

The crew adopted the tool, and Ollie was delighted. Too delighted: she wants it on every team, and the Admiral wants to know if it's worth paying for. Now Pip has to explain review rules and rounding bugs to people who decide in money and dates. Part 5, Talk to the Business: Working With PMs and Non-Engineers, is how she translates.

Read this with your AI

Read the post "Keep Learning: Bringing New Tools (and AI) Into Real Work".
1. I'll describe last month's work. Help me find the one gap worth learning about.
2. Draft a one-page pilot plan for a tool I'm curious about, with a baseline and rules.
3. Turn my pilot's results, good and bad, into a short decision record.