Double Returns: Finding Your AI Force Multipliers

Introduction

Takeaway: Target work that pays for itself once and then keeps paying out, for free, for your people and your agent alike.

My guide to making a start with AI coding tools is about making a start, not about reaching the levels of internal automation reported by OpenAI, Anthropic or Google — that’s a much longer journey, and this article is the first leg of it, not the whole map.

As you explore, look for jobs where an agent can do the work in a wink and the result makes both agents and people more capable going forward. A better test suite, cleaner docs and a tidier codebase all speed up your human engineers directly, but they also give the agent a faster, more trustworthy feedback loop next time it touches that code — a genuine double return, not a one-off chore ticked off. These are often the tedious tasks nobody has had time for, and they are your force multipliers.

They matter most where they’re hardest to find the time for. If your organisation has years of tech debt, patchy tests and documentation nobody trusts, an agent doesn’t get bored clearing it — it’s a shot in the arm those codebases have never had, and the backlog is exactly where the double return is biggest.

Most of what follows is stuff your team already knows is overdue — that’s exactly why it’s worth starting there.

Leverage free quality tooling

Whether free or paid-for, adding these benefits your agent and your colleagues alike.

Lint for free quality

• Linters are precise about where and what they’ve found, and usually link straight to the specific rule they’re flagging.
• That gives an agent — even a smaller, cheaper model — very tight context on exactly what to fix.
• It can work through hundreds of warnings in no time, and plenty of them are real bugs, or future ones, hiding in plain sight.
• Human review and a healthy test suite are still a must.
• …but the barrier to entry has all but disappeared.

No linter yet? That’s the easiest win on this list — ask your agent to set one up; it’s about as low-risk and cheap as this work gets.

Tighten type checking

• Python code benefits the same way linting does: adding type hints and running mypy or pyright gives an agent a second, different kind of free quality gate — one that catches whole categories of bug a linter never sees.
• TypeScript already has types, but plenty of codebases run loose — any scattered everywhere, strict mode off. Tightening that up is the same job, just starting from a different baseline.
• An agent can iterate on this on its own: add or tighten annotations, run the checker, fix what’s safe to fix, and flag anything genuinely ambiguous for a human to decide.

Extend linting to SAST and DAST

• A lot of SAST (Static Application Security Testing) is just linting with a security-shaped rule set, and some of it is already bundled into the linter you’re running. For Python, Ruff’s S rules are flake8-bandit’s checks (shell injection, hardcoded passwords, unsafe pickle use, and more), running as part of your normal lint pass for free. For deeper coverage, Bandit itself is still worth adding alongside Ruff — more AST-level checks, plus severity and confidence scoring Ruff’s S rules don’t carry over.
• Java (SpotBugs plus Find Security Bugs) and JavaScript/TypeScript (ESLint security plugins, or deeper taint analysis via Semgrep or CodeQL) follow the same pattern.
• Gitleaks or TruffleHog are worth bolting on separately — hardcoded secrets are exactly what vulnerability-focused SAST tools tend to miss.
• DAST rounds this out: dynamic scanning against the running app is the same well-specified, easily-checked work, worth rolling out early for the same reason — an instant win for both the humans and the agents on the team.
• An agent can do the legwork on all of it: wire the tooling in, run it, fix what’s safely fixable, and flag the rest for a human to triage.

Add unit tests

• Closing a coverage gap is exactly the well-specified, easily-checked work an agent is suited to — usually the first thing a team thinks to delegate.
• Point it at the parts of the codebase with the worst coverage and the most churn; that’s where the payoff compounds fastest.

Add UI tests, with an agent driving the browser

• Pairing an agent with a browser-automation plugin like Chrome DevTools MCP and a framework like Playwright is one of the most powerful combinations going.
• Record a messy manual click-through once, then let the agent tighten it into a proper test and iterate against the browser and a sandboxed backend until coverage is wide — in a fraction of the time it’d take by hand.
• A bonus along the way: positional selectors like “the tenth widget along” are a classic source of UI test fragility — the test breaks the moment someone reorders or adds a widget, even though nothing about the feature changed. Have the agent flag these as they crop up during the iterate-and-record loop, and fix the cause rather than the symptom: give the element a proper accessible name, then point the test at that instead. The same fix makes the test more robust and the UI more accessible — one job, two wins.

Keep docs honest

Docs rot the moment code changes under them, and nobody budgets time to fix them — exactly the kind of tedious, well-specified work an agent clears in passing, as part of the same change that made them stale.

They also capture intent that’s useful for agents and people alike. If you don’t have that captured anywhere, spending some agent time writing it up is a sense check in its own right — working out how to explain a decision is often how you find out whether it still holds up. Architecture Decision Records are a good format for this: they catch work that cuts against a choice the team already made, and give both the agent and the engineer something concrete to loop back to and ask whether that decision is still germane.

Crib notes and stationery for your agent

• Write (or have the agent draft) an AGENTS.md or CLAUDE.md for the repo: the processes, tooling and gotchas nobody wants to relearn the hard way.
• It stops the agent making the same mistake twice — write the gotcha down once, in the one place it’ll actually read, rather than rediscovering it every session.
• It helps new human starters just as much — a gotcha the agent tripped over today is one a new hire would’ve hit next month, now already written down for them.
• The crib sheet is only half of it — stationery is the other half: writing and sharing skills and tools for team-specific workflows compounds the same way, and cuts token costs too, since a well-scoped skill beats re-deriving the same process from a long prompt every time.
• Treat any skill or tool from outside your own team as untrusted code before you let an agent run it — the same scrutiny you’d give a new dependency, not a free pass just because it looks like a prompt.
• Best of all, it ends up remembering things you forget to check.

Build the quality gates behind them

Takeaway: The better your test coverage and checks, the more trust you can extend to the agent — and the same checks pay that trust back to your engineers too.

The better your test coverage, linting and SAST/DAST checks, the more trust you can safely extend to the agent, because the same checks catching its mistakes are catching everyone’s. Where coverage is thin, use the agent to build it first. Your engineers get the better end of the same deal: bugs caught earlier, and delivery that moves faster because less has to be caught by hand, late, under pressure.

Keep two things distinct. Quality gates are the checks — tests, linting, review, CI/CD — that catch bad or low-quality work before it ships. Guardrails limit what the agent can touch at all, whatever the quality of its output. Raise both together; I hope to give guardrails a fuller treatment of their own elsewhere, since “how much to widen access” is a different question from quality.

Beyond the basics above, a solid CI/CD pipeline that can spin up isolated test environments matters, as do disposable per-branch environments: a clean stack with seeded data that can be created, tested against and thrown away is what turns “the tests pass” into “the system works.” And real peer review matters — a merge request that only triggers CI, with nobody reading the diff, is a missing quality gate, not a working one.