Most organisations adopting AI-assisted development skip the assessment phase entirely. They give engineers access to Claude Code or GitHub Copilot, run a pilot on a small feature, and declare success based on lines-of-code velocity. Six months later, the problems surface: a codebase the agent cannot navigate, a branching strategy that breaks under 20 PRs a day, a testing team raising irrelevant bugs, or a compliance flag that nobody anticipated.
The eight questions below are the ones I work through with any team before we commit to an agentic coding approach. They are not a checklist — they are a decision tree. The answer to each one changes what comes next.
1. Greenfield or brownfield?
This is the first and most consequential question, and the answer is often counterintuitive.
Starting from scratch typically takes less time with AI-assisted development than adding 20% new functionality to an existing system. The reason is context. A coding agent working on a new project starts with a clean mental model. An agent working on an existing system has to build that model first — and building it incorrectly is worse than not building it at all.
If your project is greenfield, the remaining questions are mostly about tooling and team readiness. If it is brownfield, continue to question two before making any tooling decisions.
2. Brownfield only: how will the agent understand your existing code?
This breaks into four sub-questions that each carry real cost:
Knowledge transfer time. Before an agent can contribute meaningfully, it needs your architecture documentation, technical design documents, and domain context. If those documents do not exist or are outdated, someone has to write them first. I have seen this take longer than the original feature estimate.
Public agents or local-only? If your codebase handles customer data, proprietary algorithms, or anything commercially sensitive, you need to answer whether it can be sent to a hosted coding agent at all. Claude Code, GitHub Copilot, and similar tools send context to external APIs. If your security policy or contractual obligations prevent that, you are running local models — and the capability gap matters for your timeline.
Design flexibility. Coding agents work best when they can make small structural adjustments as they go — renaming a module, extracting an interface, adjusting a layer boundary. If your team has a strict no-modification policy on existing code (common in regulated environments or legacy systems with no test coverage), the agent will produce technically correct code that does not integrate cleanly. Factor that friction in.
3. PII, GDPR, or other data compliance requirements?
This is a binary gate, not a nuance question.
If your project touches personally identifiable information or falls under GDPR, DPDP (India), HIPAA, or equivalent frameworks, your tooling choice, data handling, and audit trail requirements are constrained from the start. A coding agent that sends code context to an external API is a potential data processing agreement concern. A model running locally removes that concern but changes your infrastructure requirements.
I flag this early because teams frequently discover the compliance constraint after they have already configured their tooling — and unwinding that costs more than asking the question upfront.
4. What is your deployment stack?
Cloud-native deployments (AWS, GCP, Azure) are the lowest-friction path for agentic development. Agents can generate infrastructure-as-code, configure CI/CD pipelines, and interact with cloud APIs in ways that are well-documented and well-understood.
On-premises, hybrid, or VPN-gated deployments add complexity at every layer. The agent cannot self-verify deployments, cannot access tooling directly, and cannot run iterative validation cycles without human hand-offs at each step. This does not make agentic development impossible, but it changes the workflow significantly — and your timeline estimate should reflect that.
5. Which code repository and collaboration platform are you using?
If your team is on GitHub, the agentic development story is mature. Multiple developers running agents simultaneously, branching strategies that accommodate 10 to 20 pull requests per day, automated review tooling, and CI pipelines that can handle high-volume commits — all of this is well-supported.
If your team is on GitLab, Bitbucket, Azure DevOps, or an internal system, most of the above still applies, but the specific integrations and automation options vary. Evaluate what your platform can handle before you commit to a delivery pace that assumes GitHub-level tooling.
6. VPN dependencies or non-standard repository access?
When agents generate thousands of lines per hour, the bottleneck quickly becomes code movement — getting generated code into the repository, reviewed, tested, and integrated.
If your source code lives behind a VPN, requires manual transfer steps, or uses a system without robust API access, that bottleneck becomes a ceiling. I have worked in environments where the theoretical productivity gain from agentic coding was entirely absorbed by the manual overhead of getting code from the agent to the repository. Map that flow before you start.
7. How experienced is your technical lead with AI-assisted development?
This is the question organisations are most reluctant to ask honestly.
Under agentic development, a technical lead is not reviewing one PR per day. They are reviewing one PR per hour — or more. Each PR may be several hundred to several thousand lines. The cognitive model required to assess that volume is different from traditional code review, and the failure modes are different too. An agent can produce code that is syntactically correct, passes unit tests, and still introduces an architectural problem that only becomes visible when the system is under load.
Technical leads who have worked through these failure modes develop judgment about what to look for. Technical leads who have not tend to either over-approve (velocity over quality) or over-reject (paralysis). Neither serves the project.
If your lead is new to agentic coding, budget time for that learning curve explicitly. It is not a weakness — it is a project dependency.
8. How is your testing team equipped?
The final question, and the one most often skipped.
Code generated by agents has different failure patterns than code written by developers. Agents tend to produce code that satisfies the stated requirement while missing edge cases that a developer who understood the context would have caught. The test cases that matter are different.
A testing team that is well-equipped for agentic development knows how to write specifications that are precise enough for an agent to implement correctly, how to identify the class of bugs that agents introduce most frequently, and how to scale their testing throughput to match the higher code volume. A testing team that is not equipped for this becomes the constraint — not the agent.
Putting it together
These eight questions are not independent. The answers form a dependency chain:
- A brownfield project with no documentation and a strict no-modification policy is a high-risk candidate for agentic development, regardless of what tooling you choose.
- A greenfield project on a cloud-native stack with GitHub and a technically experienced lead is a low-risk candidate, and the gains are real.
- Most projects sit somewhere in between, and the framework helps you identify precisely which constraints need to be addressed before you begin.
I am working on a structured Agentic Coding SDLC that addresses each of these constraints with specific process and tooling recommendations. If you want to discuss how this applies to your organisation, the contact section is the right place to start. If you want to work through your specific project constraints before that conversation, the Idea Lab is designed for exactly that.
The question is never whether AI-assisted development works. It does. The question is whether your organisation’s current context — your codebase, your tooling, your team, your compliance requirements — is ready to absorb it without creating new risk in the process of removing old friction.
Top comments (0)