Agentic Development: My Invisible Dev Team

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 tried GitHub Copilot when it first launched. It was useful, good for boilerplate and decent at code suggestions, but it did not really change how I worked. It felt like autocomplete with bigger goals. I liked it, but it did not amaze me.

Then I started using Cursor with Claude. And something genuinely clicked.

Using it was not just about writing code faster. It felt like having a few senior developers working with me, some architects to brainstorm with whenever I needed, and peer reviewers always ready to help. That might sound like marketing, but it is honestly how the workflow feels every day.

So What Does Agentic Development Actually Mean?

I do not think the term 'agentic' has fully settled yet, so let me describe it through what I actually do, rather than what the word technically means.

My workflow starts with planning, not coding. I use the AI to brainstorm and work through the problem together, then see what it suggests. After that, I read the plan closely. I check for missing scenarios, wrong assumptions, or steps it missed. I give feedback, add context, and we keep refining until the plan matches what I want to build.

Only after that do I start developing. When I finish, I have working code and often up to 85% unit test coverage, built into the process instead of added at the end.

That part surprised me most. The tests are not an afterthought. The AI treats them as part of the deliverable. That alone has changed how I think about what 'done' means.

The Part Nobody Talks About Enough: Hallucination in Planning

Most people talk about AI hallucination as if the model just makes things up, invents a library, or fabricates a fact. In my experience, the more interesting and more dangerous hallucinations are much subtler.

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.

When I read the plan the AI created, it included logic to automatically fall back to the legacy flow if a network request failed. No one asked for that. It was not in the requirements. The AI just inferred it. That kind of fallback is a common pattern, so it made sense, but it was wrong for this case. If I had not reviewed the plan before starting, that logic would have ended up in the code without anyone noticing.

This is the change agentic development asks of you. Your main job is not just writing code anymore. It is reading the plan, understanding what the AI assumes, and catching things that seem reasonable but are actually wrong. That takes real domain knowledge and judgment. In some ways, it is even more mentally demanding than writing the code yourself.

The Real Numbers — and Where the Time Actually Goes

If everything goes smoothly, agentic development can turn a five-day task into a one-day job. I want to be clear about that because I know it sounds like an exaggeration, but it is not. When the requirements are clear, the plan is solid, and the AI works well, the time savings really are that big.

But here is the honest part: that time savings does not automatically mean you ship faster.

Getting the code ready faster just reveals the next bottleneck: the review and merge process. My team needs at least two reviewers for every PR. We also keep PRs open for 24 hours so developers in different time zones can review them, which is a good practice for a global team. I am not criticizing this. But these processes were made for a time when writing code was the slowest part. Now that coding is fast, the review wait feels much longer.

I also choose to keep my PRs small and easy to review, even though the AI could make much bigger changes at once. I plan this out by thinking about how to break up the work before I start, so no single PR is too much for my reviewers. This discipline is important. Without it, you get a huge PR that works but is impossible to review properly, which defeats the purpose.

A Question I Genuinely Do Not Have the Answer To

I wonder how many other developers are seeing this same pattern, where the tool has made you much faster, but the process around you is now the main obstacle.

I would love to know. Is this a common frustration? Are some teams handling it better than others? Have any organizations actually redesigned their review processes to match the new pace their engineers are capable of?

I am asking sincerely, not rhetorically. This feels like the conversation the industry needs to have right now, and I do not think enough people are having it.

What Needs to Change — and a Thought That Might Sound Wild

Right now, there is a lot of pressure from organizations to use agentic tools. Leaders see the productivity numbers and want those benefits. I understand that. But if delivery processes do not change, pushing engineers to move faster just creates a new kind of frustration, where your tools are ready but your workflow is 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 itself, not just the coding?

I am thinking of an agent that can analyze a pull request, find conflicts, check test coverage, and, with careful human supervision, help with the merge. Not to replace human reviewers, but to assist them. It could speed up the parts that do not need human judgment, while keeping people involved for the parts that do.

For this to be safe, the foundation must be strong. You need comprehensive unit tests, solid integration tests, and a test suite you trust. If your tests are good, automated help in the review process is much less risky. The tests become the contract, the agent becomes the validator, and humans remain the final decision-makers, but they are not the only ones involved.

I am not saying this is ready today. I am saying it is the logical next step, and organizations should be thinking about it now rather than after they have already hit the wall.

For the Architects and Leaders Reading This

The role of the architect does not shrink in this world — it actually becomes more important. The ability to frame a problem precisely, spot a flawed assumption in a plan, decompose a complex system into reviewable slices, and maintain a clear picture of what you are building and why — none of that is automated yet. That is still you.

What changes is how you spend your time. You spend less of it on implementation details and more on thinking through problems before starting work. I think that is a good trade.

But this only works if organizations adopt agentic tools and are also willing to rethink their processes. Getting your team to use Cursor and Claude is only half the job. The other half is asking: now that our engineers can move this fast, what should our delivery process look like?

That question does not have an easy answer yet. But I think it is the most important question in engineering right now.

I would genuinely love to hear from other engineers and architects on this. Are you seeing the same bottlenecks? Have you found ways around them? Drop a comment or reach out — this is one of those conversations that gets better the more people are in it.