I want to be honest with you upfront: I was skeptical.
As a Lead Software Engineer, I have seen enough tools arrive with big promises and leave with modest results. Most of them made certain things faster or easier, but none of them fundamentally changed how I worked. I had learned to stay measured until something actually earned a different reaction.
I had tried GitHub Copilot back when it first came out. It was useful — good for boilerplate, decent at code suggestions — but it was not what I would call a shift in how I worked. It was autocomplete with ambition. I appreciated it, but I was not blown away.
Then I started using Cursor with Claude. And something genuinely clicked.
What I experienced was not just a faster way to write code. It was more like having two or three senior developers working alongside me, a couple of architects I could brainstorm with at any time, and a set of peer reviewers available on demand. That analogy might sound like marketing language. I mean it as a practical description of what the workflow actually feels like day to day.
So What Does Agentic Development Actually Mean?
The definition of 'agentic' remains unsettled; therefore, I will describe it through my practical experience rather than relying solely on its technical meaning.
My workflow starts with planning and not coding. I bring the AI into a brainstorming session, work through the problem together, and see what it comes up with. Then I read that plan carefully. I look for missing scenarios, incorrect assumptions, and flows that it has not accounted for. I push back, add context, and we iterate until the plan reflects what I actually want to build.
Only after this planning phase do I proceed to development. As a result, I typically produce functional code with up to 85% unit test coverage, integrated into the process rather than appended at the end.
This aspect was particularly surprising. The tests are not treated as an afterthought; the AI considers them integral to the deliverable. This shift has fundamentally altered my understanding of what constitutes a completed task.
The Part Nobody Talks About Enough: Hallucination in Planning
AI hallucination is often discussed as the model generating information without basis, such as inventing libraries or fabricating facts. In my experience, the more subtle and potentially hazardous hallucinations are less conspicuous.
Here is a real example. I was implementing a new feature flow to sit alongside an existing legacy flow. The whole point was to run the new flow behind a feature flag — so if anything went wrong in production, we could flip a switch and go back to the old behavior instantly. Simple, clean, safe.
Upon reviewing the AI-generated plan, I noticed it included logic to automatically revert to the legacy flow if a network request failed. This behavior was neither requested nor specified in the requirements. The AI inferred it, likely because such fallbacks are common patterns. However, this approach was inappropriate for the current use case, and had I not reviewed the plan beforehand, this logic would have been implemented unnoticed.
This represents the fundamental shift required by agentic development. The primary contribution is no longer code writing, but rather critically evaluating the plan, discerning the AI's assumptions, and identifying plausible yet incorrect elements. This process demands substantial domain knowledge and judgment, and is, in some respects, more cognitively demanding than manual coding.
The Real Numbers — and Where the Time Actually Goes
When all factors align, agentic development can reduce a task that previously required five days to just one. I emphasize this point because it may appear exaggerated, but it is accurate. With clear requirements, an effective plan, and optimal AI performance, the efficiency gains are substantial.
However, it is important to note that these time savings do not necessarily translate to faster delivery.
Accelerated code readiness simply reveals the next bottleneck: the review-and-merge process. My team mandates at least two reviewers per pull request and prefers to keep pull requests open for 24 hours to accommodate developers in various time zones. This is a sound practice, particularly for globally distributed teams. However, these processes were established when code writing was the primary constraint. Now that development is being expedited, the review phase appears significantly longer.
I intentionally keep my pull requests small and manageable, even though the AI can generate larger changes in a single iteration. I explicitly plan how to partition the work to ensure that no individual pull request overwhelms reviewers. This discipline is essential; without it, one risks producing extensive pull requests that are technically functional but practically unreviewable, thereby defeating the purpose of peer review.
A Question I Genuinely Do Not Have the Answer To
I am curious how many other developers encounter this pattern, where tool adoption accelerates individual productivity but existing processes become the primary obstacle.
I am eager to learn whether this is a widespread frustration. Are some teams managing it more effectively? Have any organizations restructured their review processes to align with the increased pace enabled by these tools?
These questions are posed sincerely. This appears to be a critical conversation for the industry, yet it is not sufficiently addressed.
Necessary Changes and a Potentially Unconventional Proposal
Organizations are currently under significant pressure to adopt agentic tools, as leadership is attracted by the potential productivity gains. However, if delivery processes remain unchanged, accelerating engineering output may simply introduce new frustrations, with tools prepared but workflows not.
Here is the idea I keep coming back to, and I will admit it might be too early: what if agents were part of the process? For example, an agent could analyze pull requests, identify conflicts, validate test coverage, and, under careful human supervision, assist with the merge process. The intention is not to replace human reviewers, but to support them by expediting tasks that do not require human judgment, while ensuring humans remain responsible for critical decisions. For such integration to be safe, a robust foundation is essential: comprehensive unit tests, reliable integration tests, and a trustworthy test suite. With high-quality tests, automated assistance in the review pipeline becomes significantly less risky. Tests serve as the contract, the agent acts as the validator, and humans remain the final arbiters, though not the sole gatekeepers. I do not claim this approach is immediately feasible. However, it represents a logical progression, and organizations should proactively consider it before encountering significant obstacles. They have already hit the wall.
For the Architects and Leaders Reading This
The architect's role does not diminish in this context; rather, it becomes increasingly vital. Skills such as precise problem framing, identifying flawed assumptions, decomposing complex systems into manageable components, and maintaining a clear vision of objectives remain irreplaceable by automation. change concerns time allocation: less time is spent on implementation details and more on thoughtful problem analysis prior to commencing work. In my view, this is a beneficial shift..
However, this approach is effective only if organizations combine the adoption of agentic tools with a readiness to reevaluate surrounding processes. Encouraging teams to use tools like Cursor and Claude addresses only part of the challenge; the remainder involves reconsidering delivery processes to keep pace with engineering's accelerated pace.
This question remains unresolved, yet it is arguably the most pressing issue in contemporary engineering.
I sincerely invite feedback from other engineers and architects. Are you encountering similar bottlenecks? Have you identified effective solutions? Please share your experiences, as broader participation will enrich this discussion.
— Vijay Munduru
Top comments (0)