Your New Engineering Teammate
Coding with AI Agents
The first time I gave AI a coding task, it did exactly what I asked.
That was the problem.
I had set it up, pointed it at the work, and it executed. No pushback, no clarification, no hesitation. It did what I asked, but it filled in the gaps with so many assumptions that the output became what I didn’t need. And because it looked right on the surface, I almost missed it.
That moment is what this post is about. Not AI agents as a concept, but what actually happens when you try to use them seriously inside a real engineering team, and what you have to do to make them work.
What has actually changed
A few years ago, using AI for software development meant one thing: you opened a chat, wrote a prompt, and got code back. I did this mostly with ChatGPT. You decided what to do with the output, which was most of the time copy-pasting to the IDE and editing as needed.
AI agents are a different thing entirely.
You give an agent a task, and it does more than just code generation. It reads your codebase, writes a plan, edits files across directories, runs commands, writes tests, and iterates on its own output. It does not respond to a query. It participates in the work. Tools like Claude Code (which I mostly use now) are the clearest example of this. You hand it a task, and it works through the whole thing, not just the code generation part.
That shift sounds like an upgrade. And it is. But it introduces a question that code generation never asked: how do you work with something that can act?
Because here is what the industry has quietly learned over the last year or so.
Out of the box, these agents are capable and fast. They are also inconsistent and context-blind. Drop one into a real project with no preparation, and it will make decisions about your architecture, your standards, and your business logic based entirely on what it can infer. Sometimes it infers correctly. Often it does not.
The work is not in the model. It is in how you operate around it.
Three questions that actually matter
Three questions cut to the heart of what engineering teams are actually struggling with right now.
How do you onboard an agent to a project?
How do you get it to execute work meaningfully?
How do you know whether to trust what it has built?
These are not theoretical questions for me. They come from building enterprise software with agents. Let me work through each one.
01. Onboarding: context is everything
Repo access plus a prompt is not onboarding.
Think about what you are actually asking the agent to do when you start it with no context. You are asking it to make decisions about business intent, architectural constraints, feature behaviour, and implementation standards, with no information about any of them. It only knows how to write code the way it has learned to write code. You have given it the keys and no map.
You would not give a new hire access to GitHub and tell them to get on with it. A new engineer needs a walkthrough, access to the right tools, time with the docs, an understanding of how the system is structured and why, and a clear picture of what working well looks like on this team. An agent needs exactly the same orientation.
What this actually looks like:
The starting point is an initialisation file. If you are using Claude Code, this is a CLAUDE.md. Other agents have equivalents (AGENTS.md, for example). This file gets loaded into the agent’s context every time it runs. It is not a one-off briefing. It is a persistent reference that travels with every single task, keeping the agent anchored to what matters.
But the initialisation file is only the entry point. What it should point to, and what your project actually needs, is a proper knowledge base. Everything a new engineer would need to work confidently on the codebase should be documented and kept current. That means:
Rules and constraints (what not to do, infrastructure limits, absolute boundaries)
Project understanding (overview, glossary, in-scope use cases)
Architecture (tech stack, service boundaries, schemas, integration rules)
Engineering conventions (code style, dependencies, naming, logging)
Delivery and safety (auth rules, compliance, quality gates)
How to work here (local setup, testing, deployment, known anti-patterns)
A good agent file turns project context into working memory. It is not just instructions. It is an operating manual.
The third lever is ticket integration. If your team works out of Jira, connect your agent to it via the Atlassian MCP. Well-written tickets become a structured input channel. The agent gets a scoped, intentional unit of work rather than a vague prompt it has to interpret on its own.
Context does not constrain your agent. It is what makes it usable.
02. Execution: being deliberate about how work gets done
Getting an agent to produce output is not the hard part. Getting it to produce output that is consistent, predictable, and aligned with how your team actually works, that is where most teams struggle.
Here is the problem in its simplest form: ten engineers, ten slightly different agents.
When every engineer on the team prompts the agent differently for the same type of task, you get different output quality, different code styles, different assumptions baked in. The agent becomes a multiplier of whatever each individual brings to it. That is not a standard. It is variance at scale.
The fix: shared skills and commands.
Agent skills are reusable, documented instructions for how specific types of tasks should be executed. Think of them as the team’s standards, encoded. How should a new feature be implemented? What does working a ticket end-to-end look like? What is the expected approach for a code review?
Here is how I use agent skills in practice. For understanding a task, the skill instructs the agent to read the ticket, read the architecture and domain context, explore the codebase, produce an explanation, and answer questions before touching any code. For implementing a new feature, the skill steps through: load context, explore the codebase, write a plan, implement, write tests, run checks and CI, update docs, final checklist. For reviewing a PR: input detection, gather context, pull Jira ticket context, run a coding standards check, format output.
Skills turn a good process into reusable team habits.
Shared commands work the same way. If your team is writing the same prompt repeatedly to get the agent to do something, formalise it. A PR review command that everyone uses means everyone is getting the same bar of output from that review.
Two things teams consistently get wrong:
Permissions and autonomy. Not every task should run with full autonomy. Define clearly where the agent acts freely and where it must ask first. Some actions, running reads across the codebase, fine. Making changes to certain directories or calling external systems, that should require explicit approval. Most agentic tooling lets you configure this at the session or task level. Use it.
Cost management. An agent spinning up long action chains on a loosely defined task is not being productive. It is burning through tokens and API budget. Meaningful execution means tight task scope and defined stopping conditions. This is more operational than it sounds, especially as usage scales across a team.
Standards that apply to humans apply to agents. Shared skills and commands are how you get there.
03. Evaluation: knowing whether to trust what it has built
The agent produced something. That does not mean it is good.
This is the step that gets skipped most often, and it is where most of the risk lives. Here is what actually happens without evaluation: the agent runs, the code looks reasonable, the tests pass, and it gets merged. Over time, the codebase gets shaped by what the agent inferred rather than what you intended. That compounds quietly until it does not.
Four layers of evaluation that actually matter:
Coding standards. Tell the agent explicitly what good code looks like in your project, not just syntactically, but structurally. How should functions be documented? What are the naming conventions, the error handling patterns, and the structure expectations? If you have not told it, it will infer, and it will get some of it wrong.
Prompt evaluation. Most poor output is a prompting problem. Garbage in, garbage out, has not changed because the model got smarter. When I evaluate a prompt, I check six things: what should the ideal output look like? Have I shown examples or pointed to what matters? Is the information structured clearly? How does the result quality score? How does it perform across different models? Are the instructions direct and clear enough? Prompt evaluation is how I turn guesswork into a repeatable workflow.
Unit tests. Non-negotiable in an agentic workflow. The agent changes code continuously, often across multiple files, often in response to evolving instructions. Something that fixed task A broke something in task B. The only reliable way to catch this consistently is a comprehensive, up-to-date test suite. The agent can write most of these tests itself. There is no excuse not to have them, but they have to stay current, or they stop being useful.
Review gates. Before anything gets merged, there should be structured checkpoints where output is evaluated against defined criteria. A PR review that rubber-stamps agent output because the tests passed is not a real review.
And finally: keep a human in the loop, properly. Trust is earned incrementally, not assumed. Start tight, approvals at most steps. Measure the output over time. Extend autonomy selectively, where the evidence supports it. The goal is not to always review everything. It is to know, with evidence, where you can afford to let go.
Evaluation is not a final step. It is the mechanism by which you decide how much to trust the agent next time.
What this is really about
It was never about replacement.
The early fear when agents arrived was that engineers would be out of a job. What has actually happened is more demanding than that. You still need experienced engineers. But those engineers now need to know how to onboard an agent, direct it with precision, constrain it appropriately, and evaluate its output rigorously.
The skills required have gone up, not away.
Three things to take away
Context before tasks. Always. An agent without context is guessing. Give it business intent, architecture, working rules, and task context before it touches anything.
Standards applied to humans apply to agents. Consistent output requires shared skills, shared commands, and defined expectations. The agent multiplies whatever standard you give it.
Trust the output only as far as your evaluation earns it. Tests passing means the code runs. It does not mean the code is good. Evaluation is ongoing, not a checkpoint at the end.
If you are working with agents on your team right now and want to talk through any of this, I am in the comments.