---
title: "Keep Learning: Bringing New Tools (and AI) Into Real Work"
author: "Harry"
published: 2026-10-31T04:50:12.378Z
updated: 2026-10-31T05:08:26.152Z
category: "Career & Teams"
tags: []
canonical: "https://fxblog.dev/posts/how-to-introduce-a-new-tool-at-work-ai"
---

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

## Key takeaways

- Pick what to learn from a real gap in your work, not from a list of trends.
- Learn in small, regular doses and use it the same week; teaching it to the crew makes it stick.
- Introduce a tool through a pilot: one feature, a baseline, a time box, and rules agreed up front.
- Measure the costs as well as the gains; AI-written tests can copy a bug from the code into the expected values.
- Write the result and the decision down, failures included, so the team decides together instead of by enthusiasm.

> **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.

```text
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.
```

> **Warning**
>
> Check your company's policy before you paste anything into an AI tool. Secrets and customer data stay out unless the tool is approved for them.

![A tool pilot: one feature, a baseline, two weeks with rules, then measure; if the result is mixed or bad, write it down and stop or change it; if it is good, the crew decides to adopt it](https://fxblog.dev/media/01a1904a-ff1d-707e-9b87-f81ce6c3d4cc/1600)

_A pilot with a baseline, rules and an honest end_

## 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.

> **Note**
>
> **Bun:** Three tests say the rounding bug is correct!
> **Pip:** It copied the code, not the rule.

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.

```text
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.

> **Tip**
>
> Write the costs into the result as plainly as the gains. "The tool writes. We decide." went into Pip's report in bold.

## 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

```text
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.
```

> **Success**
>
> You can choose what to learn from your own work, and bring a new tool in through a fair, measured pilot. Next: **Talk to the Business: Working With PMs and Non-Engineers**.

## FAQ

### How do I convince my team to try a new tool?

Do not ask them to adopt it; ask for a small pilot on one feature for two weeks, with a baseline and an agreed measure. A short written result, good and bad, convinces more people than a demo.

### Is it safe to use AI coding tools at work?

Check your company's policy first, never paste secrets or customer data into a tool it has not approved, and have a person review every line the tool writes. Treat its output as a draft.