Making a Start on AI Coding Tools

Introduction

Takeaway: The reasons to wait were sensible a year or two ago. For AI coding specifically, most of them now have simpler answers.

The worries about adopting AI coding tools were fair: regulatory exposure, copyright, safety, whether the value was real. They’re now better understood: the grey areas have clearer answers in 2026, and tool quality has improved markedly, including the governance controls mainstream tools ship with. There’s also a growing case that holding off is now the riskier choice.

The numbers back this up. Stack Overflow’s 2026 Developer Survey found 73% of developers who use AI coding tools use them daily, up sharply from 51% in 2025. OpenAI’s own numbers, published in How agents are transforming work, tell a similar story: internal Codex usage went from under 10% to over 85% of employee AI usage in a year, spreading well beyond engineering. Adoption is now the default, not the exception.

The good news: starting is easier than it looks, and making a meaningful start is now about as hard as falling out of the proverbial tree. Keep it low-risk and value-oriented, then build out from there. This article covers the essentials; several topics below get their own deep-dive article.

Seven simple steps

This article gives jobs 2, 4 and 6 full treatment — job 6, taking first steps, is the main focus. The greyed-out jobs above get the briefest of mentions, right here:

• People first. Bring your people with you from day one. Skilling up beats standing still, and concerns raised early — about job security, tool safety, anything else — are cheaper to address than ones left unspoken.
• Governance tenets. Keep it to a handful of plain-English tenets on one page, plus a named person to ask. One worth adopting immediately: don’t share data with an uncleared AI tool that you wouldn’t give to a stranger.
• Measuring adoption and value. Whether people are using it and whether it’s helping are different questions with different answers. A simple adoption ladder, a free vendor dashboard, and a quality counter-metric beside every speed metric are a good start.
• From walking to running. Once the basics are comfortable, look for the jobs that accelerate both your people and your agents at once, and strengthen guardrails in step with how much you delegate. More on both further down.

I’d like to give each of these a fuller treatment of its own in future articles.

Choose a first tool (and don’t agonise)

Takeaway: Pick one of the mainstream tools and start. Learning to use any of them well matters more than picking the perfect one.

Too many options lead to analysis paralysis. Start with one of the mainstream offerings: Claude Code, GitHub Copilot and Google Antigravity are all excellent starting points.

Three reasons this is a safe bet:

• Vanilla options are safer. Mainstream tools from larger providers default to safer, more constrained settings. Niche tools can be more aggressive out of the box.
• Skills transfer. What your team learns carries over to whatever you use next — your first choice isn’t a lock-in.
• Open source can wait. In-anger problem solving needs larger models and expensive hardware. Commercial offerings give a clearer picture of value while you find your feet.

Before anyone starts: disallow training on your data (check rather than assume), and cap spend while people are learning. Then run a month-long trial with a short staff training session. I’d like to give data residency and regulated-industry care a fuller treatment in a future article.

Security headlines

Takeaway: A handful of sharp, memorable lines cover most of the day-to-day risk.

Governance tenets are commitments. Security headlines are different — the practical, fast-moving stuff worth knowing cold, since the detail changes as tools do. Pin these somewhere visible, and revisit them often.

• Context is bigger than what you typed. An agent reads whatever you can, in every mode, planning included. Keep secrets out of your working directory, and use least-privilege credentials.
• The page can talk to the AI too. A ticket, web page or email it reads can carry instructions, not just content. Keep approval prompts on while you’re learning.
• A skill is a prompt injection you installed yourself. The same goes for plugins and MCP servers — treat them like unknown executables, and install nothing uncleared.
• A chat window is not a password manager. Never paste passwords or keys into one. A browser tool inherits every login in your browser — give it a separate profile.
• Success-shaped isn’t the same as correct. A confident answer can still be wrong. Check against the source, not against how sure it sounds.

Start simple

Takeaway: Begin with tasks that are read-only, low-stakes or easy to check, and let confidence build.

“Sharp tools cut.” Even truer of AI agents: more tool access makes them more effective, but needs more care. Start with minimal tool and MCP access, and widen only as you get comfortable.

Mainstream tools tend to default to safer filesystem, network and tool permissions, which allows you to increase permissions as you become more comfortable.

Building confidence

Gentle first tasks:

• Read Anthropic’s tips for leveraging Claude Code in VS Code, or your vendor’s equivalent editor guidance.
• Ask it to summarise or document an unfamiliar file or function.
• Ask it to review a local diff, or do some code spelunking on how a file changed over time — both read-only.
• Use planning mode: it proposes, but doesn’t execute, file writes.
• Start in repositories that don’t feed shipping code.

Once you’re more comfortable

• Debug with it. Give it a compile error or log excerpt. I’m continually amazed at how powerful these tools are at iteratively tracking down problems to their root cause.
• Write tests for existing untested code.
• Update documentation to match recent changes.
• Extend quality tooling. Integrating a linter, or adding further checks to CI, is a good fit for an agent. And they’re typically fantastic at rapidly fixing linting errors to boot (remember, linters offer double returns).

Reach further: safe tools and smaller real tasks

Once the basics are comfortable, add a few safe tools and try smaller real tasks:

• Vendor-approved MCP servers (Atlassian for Jira, your chat or source-hosting tools). Check the access each is granted, and start read-only.
• CLI access to tools you already use, like glab.
• Browser automation (e.g. Chrome DevTools for Claude) speeds up web app iteration — make sure it’s isolated from your everyday browser.
• An AGENTS.md or CLAUDE.md file, capturing how the repository works.
• Mind the modes: plan proposes, edit changes with you watching, auto has far fewer checks. Stay cautious while learning.

Then try smaller real tasks: a markdown plan handed over and evaluated, or a ticket implemented locally. Note where it shines and where it struggles.

When the AI is writing most of the code

You’ll likely find the agent doing most of the implementation, and yourself framing tasks and reviewing results:

• Frame the task well. Research bigger work yourself, write notes, have the agent critique your thinking before it plans stepwise implementation.
• Review properly. Read the diff, run the tests, judge it like a colleague’s work.
• Run sessions in parallel with git worktrees, so two agents aren’t editing the same files.
• Isolate riskier work. A devcontainer or sandbox contains the blast radius of untrusted code or fewer approval prompts. Anthropic’s Choose a sandbox environment covers the options.

Full permissions and no approvals is a bet that nothing will go wrong — and sooner or later, that bet spells doom. As confidence grows, so should the active, targeted curation of more guardrails. You can’t free up wider automation without close care over what the agent can touch, modify or affect, and what it can access, internally and externally. I hope to give guardrails a fuller treatment in a future article.

Building your own tools, and finding the jobs that accelerate both people and agents, is where the real compounding happens — another topic I’d like to come back to properly.

Where to from here

Takeaway: A basic start is small: one tool, a few simple rules, some gentle first tasks, and a way to see how it’s going.

• Pick a mainstream tool, switch off training on your data, and cap spend.
• Teach staff the Stranger Principle, name a person to ask governance questions, and keep the security headlines readily accessible.
• Start read-only and low-stakes, then add a few safe tools and smaller real tasks.
• Widen autonomy and strengthen guardrails together, don’t grant the one without bolstering the other.

I hope to give every topic above that only got a brief mention a fuller treatment over time.