A codebase ready for agents
Structure, documentation, instructions and dependencies. We check whether the agent gets the information it needs to work within the project's boundaries.
ENGINEER THE WAY YOU BUILD
AI in Software Development: Coding Agents and QA
The agent writes. The team stays accountable.
We help teams manage context, split up work and verify what coding agents produce. Instructions, repository structure, tests and evidence come together into a development process you can trust more.
Talk about AI in Engineering & QATHE RIGHT FIT
This is a fit if…
- Teams using Claude Code, Codex or Copilot.
- Leaders who want AI adoption to go beyond individual experiments.
- QA teams assessing the quality and traceability of AI-assisted code.
A CLEAR DELIVERABLE
What you get along the way.
An agreed workflow
Planning, task breakdown, review and testing. We define what the agent can do and what the team needs to approve.
Quality backed by evidence
Tests, requirements traceability and findings you can trace back to their source. We separate deterministic checks from judgment calls that need a human.
HOW WE MOVE FORWARDWe map the path.
We map the path.
Then we move.
- 01
Review of how you work and your repository
- 02
Identifying gaps and setting team rules
- 03
Applying it to a real task
- 04
Reviewing results and handing over the method
THE FULL PICTURE
Bringing AI into software development is not a matter of buying licenses. On most teams someone already works with GitHub Copilot, Claude Code or another coding agent, but each developer does it differently, with no shared rules and no way to tell whether quality is going up or down. This page explains how to turn coding agents into a team way of working: what to prepare, in which stages, how to protect your code and how to measure the result.
What AI adoption on a development team involves
A coding agent does more than complete a line. It reads files, runs commands, edits several files at once and proposes a pull request. That is a lot of power, which is exactly why it needs a framework. Without the right context the agent guesses, and without a review process the team gets a lot of code nobody really read.
Adopting AI tools for developers covers three things at once: the tools and how they are configured, the codebase the agent works on, and the team's workflow around the agent. Most of the difficulties teams run into do not come from the model. They come from a repository that is hard to understand, missing or conflicting instructions, and no agreement on what the agent may do on its own.
In an organization the questions widen: how licenses and settings are managed centrally, which repositories are open to agents, how the tools connect to existing systems such as GitHub or Azure DevOps, and how a new team gets the same framework instead of starting from zero. That is how a GitHub Copilot rollout or Claude Code for the enterprise turns from a personal tool into shared infrastructure.
It is not a prompt-writing course either. Good phrasing helps, but the real difference comes from what the agent knows about the project, what it can verify by itself and how a person approves the result.
When a team needs help adopting AI tools
Many teams reach this point after a period of initial excitement. The tools look great in demos and small tasks, but once they meet a real codebase, with history, dependencies and unwritten rules, results become inconsistent.
The question is not whether to use AI, but whether your current usage helps the team or just moves the work somewhere else. A few signs it is time to stop and build a method:
- You have licenses for GitHub Copilot or another tool, but only a small part of the team uses them regularly.
- Review is getting heavier: larger pull requests, changes that are hard to follow and less time to check each one.
- The agent keeps repeating the same mistakes, such as using the wrong library or ignoring project conventions.
- Every developer keeps their own instructions and config files, with no shared version that gets updated.
- Nobody is sure what may be sent to AI tools: customer code, secrets, sensitive data.
- Leadership asks what the investment delivered, and there is no data to answer with.
- The QA team receives AI-assisted code and does not know where to focus testing.
Five layers of working with coding agents
Adoption that works is built in layers. You can start from any of them, but every missing layer will be felt later.
The layer most often skipped is repository readiness, and it is where the impact shows up fastest. An agent that gets one test command that works and short, accurate instructions wastes less time guessing, and its output is closer to what the team would have written itself.
- Tools and policy: which tools are approved, with which organizational settings, what may be sent to them and which actions require approval. The criterion is fit for the team and environment, not the brand name.
- Repository readiness: a clear structure, build and test commands that work on the first try, and agent instruction files such as CLAUDE.md, AGENTS.md or copilot-instructions.md that explain the rules, the layout and what must not be touched.
- Workflow: planning before code, splitting work into small reviewable tasks, reasonably sized pull requests, and clear lines between what the agent executes and what a person decides.
- Tests and quality: automated tests the agent runs before presenting a result, CI that verifies every change, and review guidelines suited to AI-assisted code.
- Security and oversight: secrets kept out of code, restricted permissions for agents, limits on risky commands, and traceability of who changed what and why.
AI for QA: where it helps and where to be careful
AI for QA can save a lot of repetitive work: deriving test scenarios from requirements, scaffolding automated tests, analyzing logs from failed runs and suggesting edge cases nobody thought of. A QA team that works well with agents can spend more of its time on testing that needs judgment.
Existing test automation benefits too: an agent can help update tests after an interface change, find duplicate or flaky tests and suggest consolidating them, with a person approving every change.
There are well-known traps too. An agent that writes both the code and the tests may write tests that confirm the bug instead of catching it. Tests with weak assertions always pass and give a false sense of safety. And a failing test may get fixed by the agent changing the test rather than the code.
So adoption in QA includes simple rules: tests are derived from the requirement, not from the implementation; every finding links back to its source; and changing an existing test requires an explanation and approval. That keeps deterministic checks the machine runs separate from assessments that need a person.
The adoption process, step by step
The goal is to move from individual experiments to a team way of working without stopping development. That is why the work is done on real tasks, with a scope that grows gradually. Throughout the process the team keeps working on its regular tasks, and adoption builds on them instead of creating extra work.
A good pilot runs long enough to cover several types of tasks and to see failures too, but not so long that the team loses interest. It ends with an informed decision: expand, adjust or stop.
Map the current state
Review which tools are in use and how they are configured, look at the repository and CI, and talk to developers and QA about what works and what frustrates them.
Choose a pilot
Pick one team and one repository, and define the tasks, success criteria and baseline in advance.
Prepare the codebase
Fix build and test commands, write agent instruction files, remove secrets from code and clarify structure and dependencies.
Set team rules
What the agent does on its own, what needs approval, what a good pull request looks like and what to check when reviewing AI-assisted code.
Work on real tasks
The team works with the agent inside the new framework, with me alongside: refining instructions, improving tests and documenting recurring failures.
Measure and expand
Compare against the baseline, decide what to keep and what to change, and roll the method out to more teams using the materials built in the pilot.
What you get and how impact is measured
Deliverables live in your repositories and evolve with the code: agent instruction files, a team working agreement, CI configuration and tests that verify what the agent produces, an AI tool usage policy and a rollout plan for the other teams.
Beware of metrics that are easy to inflate. Lines of code, accepted suggestions or writing time alone do not tell you whether the team reaches production faster and with fewer bugs. So measurement combines data from CI and task tracking with feedback from the people using the tools.
Good measurement looks at the whole path to production, not just how fast code gets written. Metrics worth tracking:
- Time from opening a task to merge, compared with similar tasks before adoption.
- Review time and the number of revision rounds per pull request.
- Bugs found after merge, especially recurring ones.
- The share of agent-proposed changes that were discarded or rewritten.
- Actual usage over time, and feedback from developers and QA on working with the tools.
How to choose who guides the rollout, and common mistakes
The common mistakes look similar everywhere: buying licenses for everyone and hoping usage follows, choosing a tool before defining what you want to improve, giving the agent broad permissions with no boundaries, skipping review because the code looks fine, and measuring success by lines of code written.
Another mistake is treating adoption as a one-off project. The tools change quickly, and instructions and rules need to keep up. That is why the method must stay with the team, not with the vendor.
A good provider will also tell you when not to use an agent: tasks where the context is too sensitive, the requirements are unclear, or checking the result takes more effort than writing it yourself.
Questions to ask before choosing a consultant or provider:
- Are they tied to a specific tool, or do they earn from selling licenses?
- Do they use coding agents themselves on real projects, or only demo them?
- How do they approach security, secrets and exposing code to AI tools?
- How will success be measured, and what would count as a failed pilot?
- What stays with the team at the end, and how will it keep the method up to date without them?
Why work with me
I am an AI Solutions Architect: I design and build end-to-end AI solutions, such as RAG pipelines, agentic and multi-agent workflows and LLM-based organizational platforms, and take them from concept to production. Coding agents are part of my daily work, not something I know only from demos.
Before that I worked in automation and DevOps: I started as an automation developer, led automation development technically in C# along with CI/CD pipelines, and worked as a DevOps engineer. That background matters here, because AI in development and testing rests on the same foundations: reliable tests, pipelines that verify every change and a process you can trust.
I work independently and take no commissions from tool vendors, so a recommendation for Copilot, Claude Code or anything else is based only on what fits your team. I taught as an assistant lecturer in a software engineering course at Ariel University, and I build each rollout so the team understands the method and can carry it on alone.
WHO YOU WORK WITH
Who works with you.
Bechor Simhaev · AI solutions architect & DevOps
I take an AI idea and turn it into a system running in your organization: RAG over your knowledge, agents and agentic workflows, and LLM-based platforms. From discovery to production.
The difference: I don’t stop at the demo. Hands-on experience in DevOps, Azure, Kubernetes and on-prem clusters in closed environments with EKS Anywhere and OpenShift means the solution is built from day one to run in your environment, with its security and permissions. And I’m independent, with no commissions and no preferred tool, so the recommendation rests only on what is right for you.
Do we need to switch tools?
Not necessarily. We start from your existing tools and process and look at which changes actually help.
How do we measure whether it helps?
We pick tasks and criteria in advance: review time, output quality, recurring failures and the ability to reproduce work. Lines of code is not the metric.
Does the agent replace code review?
No. An agent can help surface findings, but responsibility for code, decisions and releases stays with the team.
What drives the cost of AI adoption on a dev team?
Cost depends on the number of teams and repositories, the current state of your tests and CI, security requirements and how much hands-on support you need. A focused pilot with one team is usually the right starting point. Scope and deliverables are defined after the mapping stage.
How long until we see results?
In a focused pilot, first signals usually show up after a few working cycles on real tasks. Rolling out across several teams takes longer, because rules and instructions need to fit each codebase. Setting a baseline in advance makes it clear what actually changed.
Is our code exposed to the AI vendor?
Yes, AI tools send code and context to the vendor's service in order to work. That is why you should check each tool's terms and organizational settings for what is stored, for how long and whether it is used for training. Part of adoption is defining which tools and plans are approved, and which files or repositories must not be sent.
How do we stop an agent from leaking secrets?
First, take secrets out of the code and the repository and manage them in a dedicated service. Then restrict which files and commands the agent can access, and add secret scanning to CI. An agent that never sees a secret cannot copy it.
GitHub Copilot or Claude Code: which should we choose?
There is no single answer. It depends on your development environment, the kind of tasks, security requirements and what you already have. Sometimes more than one tool makes sense for different needs, and the principles of a ready repository and clear team rules apply to all of them.
What are agent instruction files, and why do they matter?
Files such as CLAUDE.md, AGENTS.md or copilot-instructions.md tell the agent how the project is structured, which commands to run and what the rules are. Without them the agent guesses from scratch on every task. They should be short, accurate and maintained like any other code.
Can we start small?
Yes, and that is usually the right way. Start with one team, one repository and one type of task, such as writing tests or small bug fixes. Once the method works there, expanding is much easier.
What if some developers do not want to use the tools?
It helps to understand why: sometimes it is a bad experience with a tool that had no context, sometimes a legitimate concern about quality. Working on real tasks with clear rules and visible results persuades more than a top-down mandate. And even a developer who chooses not to use an agent benefits from a cleaner repository.
How do we know quality is not slipping?
Track bugs after merge, changes that were discarded or rewritten, and the number of review rounds. Also make sure CI runs tests on every change and that agent code cannot be merged without human approval. If these signals get worse, it is time to pause and fix the method.
Can an agent run on its own in CI and open pull requests?
Yes, and it can fit well-defined tasks such as dependency updates or small fixes. But then permissions, action boundaries and tests become even more critical. Start with narrow permissions and widen them only after the process has proven itself.
Can a QA team without a coding background use agents?
Yes, for example to derive test scenarios from requirements, analyze results and write simple tests. You still need someone who understands the code and the test environment to approve what goes into the codebase. The rollout defines who reviews what.
What happens when tools change or we switch vendors?
Most of the work is not tied to one tool: a clean repository, good tests, review rules and a security policy stay relevant. Instruction files are also very similar across tools. So investing in the method survives a change of tool.
LET’S MAKE IT REAL
Let’s find the right step for you.
Have an idea, a need or a question that hasn’t settled yet? Let’s work out together what’s right to do.
Let’s talk A direct conversation. A clear direction. A step that fits you.