chetanvashistth — writing

How I Slowly Figured Out How to Code With AI — A Journey Over 2 Years

Sun, 30 Aug 2026 00:00:00 GMT

The day I met ChatGPT

I think the model had a few million parameters back then, and ChatGPT was answering everything. My NLP brain was unable to process what I was seeing. I was staring at the responses with my mouth wide open, eyes excited to see what else it could do.

Then I gave it a small document and tried to discuss the nuances. ChatGPT excelled at the task and got 1000/100 from me. I thought — this is the moment.

I also tried some basic programming tasks but was like — okay, this is trivial.

Then came Midjourney

Midjourney was my first dollar spent on AI. I tried many variants of crazy ideas — at least I thought those were crazy.

One was a pigeon fight, where a pigeon was a warrior leading the charge. Another was a cowboy riding a crocodile. And then a bunny who is the ultimate destroyer and villain.

All went well on the first cut. I was even more excited about the future.

Dall-E was the first AI that disappointed me in the series.

The handmade sketch moment

Then came the day I tried giving a handmade sketch of a webpage to ChatGPT. It did a great job and handed me back full working CSS and HTML.

Then I asked how to turn it into a React application — and in those two hours I felt more comfortable with React than I had in over 100 hours of online courses before that. Building something I actually wanted to make, something I was going to showcase to my manager, taught me more than all of that.

My encounter with Anthropic was stupid

I heard that Anthropic had launched an LLM similar to ChatGPT, and I commented — who will use Anthropic when ChatGPT is already there?

I was completely unaware of my soon-to-be companion, Claude Code.

The day I paid USD 20 to Claude, and then paid the remaining balance to reach USD 200 on the very same day, I realised one thing — one should never judge anything too quickly. :D

Sorry Cursor, but you made crazy money from X so I don’t feel bad anymore

I found that Cursor does not check the MAC address or anything machine-specific, and allows a new quota to developers with a new email.

Cursor was the first time I truly realised that the future was going to be exciting and challenging at the same time. I was so confident after Cursor that I started feeling I could build anything over a weekend with a few email IDs.

Then came Claude Code

It has been 16 months now and I am paying USD 200 to Anthropic. Trust me, this is the best investment I have ever made in myself.

I started with Claude Code in Claude Desktop, copy-pasting code into my workspace for four to five days. I thought I had made a mistake buying the USD 200 subscription.

I started looking through forums, on Twitter, and discussed my frustrations with ChatGPT. Then one night, I found the magical tool named Desktop Commander. It gives Claude Desktop access to your repository — Claude can directly read and write your files.

The database incident

On a fine day, at 6 PM, just as I was about to give a demo — and another team was also supposed to be using the same database my application was pushing to — Claude deleted the database instance. We were in the middle of discussing a bug and I wanted to redesign a table.

That day I was forced to learn everything about configurations in Claude Desktop. And that same day I read everything about the claude.md file.

From that day, I spend at least two hours every week just finding new ways to make my framework stronger — and making absolutely sure Claude never plays another game that would force me to type “sorry” a hundred times.

The magic of MCP integration

I was discussing with a friend who was working on some 3D simulation for an architect. I knew Blender is a tool that can build 3D designs using Python scripts, and I thought of giving the prototype pictures to ChatGPT and asking for the Python script I could run in Blender.

I tried and waited for the magic to happen, but I realised that mastering a tool takes time — and if the tool is for modelling, it takes years.

I did not lose hope and kept looking for some clue about how I could use AI for 3D design.

I stumbled upon a post where a founder was promoting a marketplace to generate 3D .obj files. I read everything about that product, watched all the YouTube videos and demo videos, and learned that there is an MCP tool that Claude Code can use — and you just need to run an MCP server plugin (absolutely free) inside Blender.

I designed a 3D room with a sofa, bed, tables, and a chair, and also moved them after loading them on the web. The Z-axis was troubling me a lot — but I got the confidence that I had cracked the jackpot.

What else can be done with MCP is a topic for another day.

Terminal, readme, and the /resume rabbit hole

On a magical day, I decided to set up Claude Code on the terminal and learn the nuances I had been hearing about on Twitter and in YouTube videos. It took two to three days to figure out what workflow actually worked for me optimally. The very first files were readme.md and claude.md, and I started generating whole projects from those.

Then one day I accidentally discovered the /resume tool in Claude Code. It was like another piece of magic — I no longer had to worry about how Claude would get context or how I would summarise all the work from past sessions.

Claude works best when you don’t use /resume

This advice made my life tough. I was perfectly happy with my workflow — starting with readme and claude files, then going through /resume. Then I watched Andrej Karpathy, who is the ultimate authority on these things.

I left all coding tasks for two days. I promised myself not to use Claude Code again until I figured out an optimal workflow where I was not forced to use /resume.

I still use /resume a lot — but now I know where it helps instead of slowing the agent down. I know where it helps the agent work more accurately instead of hallucinating.

Everything is back to basics

As my professor used to say — you will revisit the core books again and again in your career, and every single time you will learn something new.

I am reading system design a lot. I am reading software engineering principles. I am reading about databases again.

The simple goal is to use Claude Code better. And that is definitely possible if I can:

Make my database design more efficient.
Make my system design modular and follow the single responsibility principle.
Validate the work that Claude has done for me.

That is where I am today. Still figuring it out — just faster than before.

Realistic Productivity Gains from Agentic Coding: What to Actually Tell Your CEO

Fri, 28 Aug 2026 00:00:00 GMT

Indian IT services have a pattern worth understanding before we talk about productivity numbers.

We picked up COBOL when the US had stopped teaching it. Y2K was not a crisis for Indian engineers — it was an entry point into global markets. We rode the dot-com era, survived the bust, scaled through BPO, excelled at cloud, did serious work in machine learning and data science, and handled the blockchain wave with enough pragmatism to come out mostly intact. Through all of it, Indian IT stocks were among the top performers on the market.

After 2023-24, every single IT stock is on a discount.

This time is different — not because the technology is more capable, but because the pace of change has broken the usual adaptation timeline. Every previous shift took eight to ten years to stabilise. Companies had time to retool, retrain, and build new practices before the next wave arrived. Gen AI is not stabilising. Nobody can predict the market twelve months from now, let alone three years. Companies that were planning transformation programmes are now in survival mode — not because the work has disappeared, but because the sentiment has.

The problem is the gap between AI marketing and AI reality

AI tools are genuinely brilliant for one thing: demonstrating an idea. A well-structured Claude Code prompt can produce a working proof of concept in two to two and a half hours that three to four engineers would have taken two months to build. Eight engineer-months compressed into an afternoon. That is not an exaggeration.

That compression is real. It is also what is creating the current problem.

The demo lands, the client sees it, and a set of beliefs locks in that are very difficult to dislodge later:

The customer believes that two in-house engineers with AI tools can handle everything their existing team was doing, at a fraction of the cost. The POC made it look that way.

The CEO is reading reports from analyst firms and press releases from competitors claiming five to ten times productivity improvements. He is now asking his delivery manager to match those numbers.

The development team is the one actually dealing with the consequences. They are not building fresh POCs. They are maintaining systems where vibe coding has drifted the code that was approved two sprint before and now regression bugs are causing failures in production. The problems are real and slow to fix.

Delivery managers feel all three of these simultaneously.

Accepting the reality before calculating anything

Coding agents are here, they are useful, and they will keep getting more capable with every release. Denial is not a strategy.

The right move is to accept what they are good at, understand where the gains actually come from, and set numbers that can be defended — not numbers that sound impressive in a presentation and become credibility problems six months into delivery.

Where the productivity gains actually come from

To calculate a realistic number, start with how effort is distributed in a traditional SDLC.

In large enterprises, coding accounts for roughly 30 to 40 percent of total effort. In SMEs it sits closer to 50 percent. That is the portion where agents can make the most direct impact — and even there, the gain is not uniform across all types of coding work.

Testing accounts for 20 to 30 percent of total effort in a well-run project. Of that, a significant share — roughly half on sizeable projects — is writing automation tests, test data generation, and regression suite maintenance. Agents can accelerate this meaningfully.

The caveat worth keeping in mind: as coding effort shrinks, the weight of system design, low-level design, database design, and validation gates increases. These are not areas where agents currently replace human judgment. The effort does not disappear — it shifts. A productivity gain calculation that does not account for this shift will produce a number that looks good in a spreadsheet and fails in delivery.

Accounting for the shift in coding effort, the partial gain in testing, and the increased weight of design and validation, the realistic productivity improvement available from agentic coding — after six months of structured adoption with a proper framework — sits at 20 to 25 percentage points of total SDLC effort in the first year.

That is not the number you will read in a vendor report. It is the number that holds up after a project completes.

The scenario table

The numbers below assume six months of team training and an established agentic SDLC framework. They are ranges, not guarantees. The conditions column is what determines where in the range you land.

Scenario	Realistic gain	What determines the outcome
Greenfield, cloud, GitHub, experienced lead, documented requirements	40–60% reduction in delivery time	Everything is configured for agents to work without friction
Greenfield, average team, some setup needed	20–35% reduction	Realistic target for most new projects
Brownfield, good documentation, flexible codebase	15–25% reduction	Documentation quality is the ceiling
Brownfield, poor documentation, strict no-modification policy	0–10%, sometimes negative	Setup cost can exceed the gain entirely
Regulated environment, heavy compliance requirements	Measure in months, not percentage	Compliance verification absorbs most of the time saved in coding
New POC, customer wants to validate an idea	500–1000% or more	This is the demo scenario — not a delivery benchmark

That last row is important. The POC number is real. It is also what creates the expectation problem, because clients see the POC and assume the same multiplier applies to the full delivery. It does not. POCs have no compliance requirements, no integration with existing systems, no regression test suites, and no production operations. Full delivery has all of those.

What to tell your CEO

A commitment of 20 to 30 percent improvement in overall delivery time is defensible for a well-prepared greenfield project in the first year of structured agentic coding adoption. If the project is brownfield or the team is new to these tools, 15 percent is a more honest starting point.

Do not commit to more than this until you have completed projects to benchmark against internally. Vendor reports measure individual developer throughput in controlled conditions. Your CEO will be measuring delivery dates, defect rates, and client satisfaction.

Those are different measurements. The commitment should reflect what you can actually control.

A note on the five to ten times claim

When a competitor claims five to ten times productivity, they are almost certainly measuring lines of code written, tasks closed, or pull requests merged per developer. These numbers go up with agents — sometimes dramatically. What does not automatically go up is the speed at which working, tested, compliant software reaches production.

More code, more PRs, more bugs, same delivery speed. The coding step accelerated. The review and testing steps, which were already constraints, got worse.

Indian IT has adapted to every major technology wave for four decades. This one will be no different — but the adaptation requires honesty about what the tools actually do, not just what the marketing says they do.

If you want to have a first hand experience of the Agentic AI SDLC framework then, the Idea Lab is a practical place to start. For a direct conversation about applying an agentic SDLC framework to a specific project, reach out.

Agentic Coding in Practice: Management and Delivery (Part 2)

Fri, 28 Aug 2026 00:00:00 GMT

In the previous part I covered the development side — when to go solo, what not to delegate to an agent, which documents to maintain, and why modularity is non-negotiable. This part is about what happens around the code: how delivery is managed, how PRs are governed, what testing looks like now, and what compliance requires that it did not before.

The context matters: coding has traditionally accounted for 30 to 40 percent of total SDLC effort. With agentic coding that share is shrinking. Low-level design, testing, feedback cycles, and deployment are picking up the weight. The skills that matter most in delivery are shifting accordingly.

1. Ownership has to be explicit

When agents are generating code at high velocity, ambiguity about who owns what becomes a serious risk. Three roles need clear, non-overlapping ownership.

The project manager owns requirements.md end to end. In a services context where there is no dedicated business analyst, this falls to whoever understands the work and faces the customer — whatever title they hold. That person writes the acceptance criteria, validates test cases against requirements, and is available to defend or update requirements when the team challenges them. Requirements that nobody owns drift. Drifted requirements produce working software that does not solve the right problem.

The architect owns HLD, LLD, database design, and deployment. Any deviation from the planned architecture should be known to the architect before it is committed, not discovered in a review. One practical approach: the architect provides the first commit — boilerplate, folder structure, claude.md files per module — so the foundation is set before any agent-generated code arrives.

Beyond that, each developer can maintain a comment file — developername_comment.md — for the architect. It is a defense-and-update stream: the developer records what they did and why. Alongside it, an architect_comment.md on each developer’s branch holds the architect’s ongoing guidance and responses to the developer’s questions. Both files are temporary by nature and refresh with each commit, so there is no benefit in persisting them. Agents can help draft these files, but the architect reviews and owns them before they are shared. The role may be a tech lead or senior tech lead in your context. The title is less important than the ownership being explicit and unambiguous.

Developers own unit tests. No function goes to a commit without a test. This is not new as a principle, but it is more consequential now. Regression testing under agentic development requires a test suite that covers the ground the agent has covered. Without it, a fix to one part of the system can silently break another and there is no automated gate to catch it.

Testers own the CI/CD pipeline. Agents sometimes change files that were not part of the stated task — an undeclared modification to pass a failing test or resolve a stubborn bug. This is one of the more subtle failure modes of agentic development, and it is not always visible in the code itself. A tester tracking which files changed per commit, and why, is the check on this. The tester having final control over the CI/CD pipeline is what gives that check actual weight.

2. The PR volume problem is a process problem

A lead or architect in a traditional team handles three to four pull requests per week, perhaps two or three per day on a busy sprint. A developer working with an agent can push ten to twenty PRs in a single day.

Manual code review at that volume is not feasible for most people. The response is not to slow the agents down — it is to structure PRs so they can be evaluated efficiently.

Every PR in an agentic development workflow should include: which files changed and why, with a reference to the requirement if possible; what was built, linked to the relevant requirement; the status of tests at the time of the PR; and any known limitations or deliberate deviations from the plan.

A PR that arrives without this information puts the entire review burden on the reviewer. A PR that arrives with it reduces the review to a verification task rather than an investigation.

The format and milestone rules for PRs are the architect or lead’s responsibility to define before development starts, not to negotiate after the volume problem has already appeared.

3. Testing is now a gatekeeping role

Testing was always important. What has changed is the nature of the risk.

In a human-paced development team, the scope of change in any given commit is bounded by how fast a person can write code. An agent is not bounded in the same way. It can go back to an early part of the system and change it to resolve a problem that appeared much later. By the time that change surfaces in testing, it may have been layered over by several subsequent commits.

A tester in an agentic development context needs to be vigilant about scope — what changed, not just whether the feature works. Using an agent specifically to validate whether a file change was actually necessary is a legitimate and useful technique. It brings an independent perspective to a question that the coding agent has an interest in answering a particular way.

On the question of which agent to use for testing: if the development team is using one agent family, the testing team should use a different one where possible. If that is not practical, use different models within the same family. This is not a minor point. Agents have biases toward their own outputs. An agent from the same family that wrote the code is more likely to find the code acceptable than one that did not. Using a different family for testing removes that bias. The same principle applies to local models: use different model families for writing and for testing.

Unit test results should be run and reviewed before functional testing begins, not alongside it. The sequence matters — a functional test that passes on top of failing unit tests is not a reliable signal.

4. Compliance cannot be managed with prompts

This is the section most teams learn the hard way.

The instinct when working with agents is to manage access and restrictions through prompts — telling the agent what it is and is not allowed to do. This does not work as a compliance mechanism. Prompts are instructions, not enforcement. An agent operating under a prompt restriction can still take the restricted action if the access exists. Controlling access through prompts is, as a practical matter, asking the agent politely not to do something it has the technical ability to do.

The correct approach is to remove access at the infrastructure level. If an agent should not use a particular tool, API, or resource, do not give it access to that tool, API, or resource. Prompts can communicate intent. Infrastructure enforces it.

The compliance layer built around agents is not a one-time configuration. It requires ongoing maintenance in the same way that security tooling does. The ways an agent can bypass a guardrail are not static — they evolve as models change and as the systems around them change. Treat the compliance layer as something that needs regular review and updating.

On secrets: a .env file should be treated as plaintext for security purposes. The fact that it is excluded from version control does not make it safe. If you are working in a cloud environment, keep secrets in the platform’s secret management service and access them from there. If you are developing locally, load secrets into the environment explicitly each time they are needed rather than storing them in a file that persists on disk. An agent that has file system access can read a .env file. Assume that it can and plan accordingly.

The two parts together cover the full picture of what agentic development requires in practice — from the individual developer’s workflow to the team’s management and delivery structure. The technical decisions and the organisational ones are both load-bearing.

If you are thinking through how this applies to a specific project or team structure, the Idea Lab is a good place to work through the constraints before committing to an approach. For a direct conversation, contact me.

Agentic Coding in Practice: What I Have Learned Working Solo and With a Team (Part 1)

Thu, 27 Aug 2026 00:00:00 GMT

These are notes from actual work, not theory. I have used coding agents on projects ranging from solo builds over a few weekends to team environments with multiple developers working in parallel. Part 1 covers four lessons that have held up across both contexts.

1. Go solo if you have the option

If you have a genuine choice, working alone with an agent is faster than working in a team with agents. Not marginally faster — significantly faster.

The reason is coordination overhead. The moment you have more than one developer, you have pull requests, branch conflicts, review queues, and the cognitive cost of understanding each other’s agent-generated code. A solo developer with an agent sidesteps all of that.

This is not always feasible. Large projects, enterprise environments, and work that requires specialised knowledge across multiple domains will still require teams. But if you are scoping a project and solo is a viable option, take it. The productivity difference is real.

2. Never outsource requirements, system design, or database design

This is the rule I hold most firmly, and the one I see violated most often.

Coding agents are capable of doing a plausible version of all three. That capability is exactly what makes it dangerous to hand them over entirely.

Requirements. Use the agent’s grill-me capability — there are well-documented prompts for this across Claude Code, Copilot, and other tools — to build a thorough requirements document through interrogation. But read that document in full before you proceed. Every word of it. The agent is extracting your requirements, not inventing them. If the document does not match what you intended, the problem is yours to fix before any code is written.

System design. You should own the low-level design. Ask the agent to contribute, challenge your decisions, and surface options you have not considered. But the decisions should be yours. If you understand your system design less well than your agent does, you will not be able to evaluate what it builds, catch what it gets wrong, or explain it to a client or a colleague. That is a problem at every stage of delivery.

Database design. The same principle applies with one practical exception: agents are often better than humans at index optimisation and normalisation mechanics. Use that. But you should know your schema, your relationships, and your access patterns better than the agent does. The agent can optimise the plumbing. You need to own the structure.

The thumb rule is simple: you should know your requirements, your design, and your database better than your agent does. If that is not true at any point in the project, stop and fix it before continuing.

3. Generate the five documents and keep them current

This is the part of agentic development that most teams skip because it feels like overhead. It is not. It is what makes the entire approach sustainable across sessions and across team members — human or agent.

requirements.md — the output of the grill-me session. Written in user story form. This is the base from which modules, tasks, and subtasks are derived. Everything downstream traces back to it.

readme.md — the standard repository readme. Its primary audience is whoever comes to the repository next, human or agent, with no prior context. If a new agent session cannot orient itself from the readme alone, the readme is not doing its job.

plan.md — modules, tasks, subtasks, and the logical sequence connecting them. This document also carries a remarks section for human-readable notes, and a status field for every task. It is both a planning document and a live view of where the project stands.

progress.md — append-only. Every task entry records a start timestamp, an end timestamp, the commit hash, and remarks if needed. Over time this becomes a productivity record, a debugging aid, and a reference that future sessions — human or agent — can use to understand what happened and when. Do not edit existing entries. Only append.

claude.md (or the equivalent for your agent) — the rulebook. This captures your coding preferences, folder structure conventions, commit message format, access rules, and any hard constraints like no emoji in code or mandatory unit test coverage. Write this yourself. Never delegate it to an agent. It can live at the system level, the project level, or the module level — or all three.

One rule to add to every claude.md: with every commit, update requirements.md, readme.md, plan.md, and progress.md. This keeps the document layer current without requiring a separate maintenance pass. The agent does it as part of the commit, not as an afterthought.

4. Modularity is not optional anymore

Modularity and the single responsibility principle have always been good practice. In agentic coding they are non-negotiable.

The reason is context. A coding agent works best when it can focus on one well-bounded problem without needing to hold the entire codebase in mind. Tightly coupled modules create dependencies that span that boundary. The agent has to understand more to do less, and the risk of it getting something wrong increases proportionally.

There is a practical test for whether your modules are modular enough: can your agent start a fresh session with only the documentation — requirements.md, readme.md, plan.md, claude.md — and pick up the work correctly, without needing memory of previous sessions?

If yes, you are in a good position.

If the agent needs memory of previous sessions to function correctly, your modules are too tightly coupled, your documentation is not capturing the right things, or both. Either way, that is a risk that compounds over time. An agent dependent on accumulated context will eventually produce code that drifts from what the documents say — and at that point, the documents are no longer the source of truth.

Keep the modules independent. Keep the documents current. Let every session start clean.

Part 2 will cover branching strategy under high PR volume, testing team readiness, and what happens when agentic development runs into compliance constraints.

If you are working through any of these challenges on a current project, the Idea Lab is a good place to think it through before committing to an approach. For a direct conversation, the contact section is there.

A Decision Framework for Adopting AI-Assisted Development in Your Organisation

Sun, 23 Aug 2026 00:00:00 GMT

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.

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.