An Engineering Executive’s View on Agentic Coding: Why This Time Feels Different
I have been involved in data and software engineering for more than 20 years. I did not start out from AI or startups. I began as a DBA, back when data was basic as opposed to trendy - essential to systems, but not at the point of having your own conference topic.
Over the years, I moved into software & platform engineering leadership. I ran large software and data platforms. When it comes to the adoption of Hadoop, I led the pack at a time when just a few enterprises were ready to move early. Today, I am EVP of Technology and Engineering at a world-leading company.
I have seen every big wave come through - Big Data, Cloud, Agile, Machine Learning, and now LLM. Each of them came with great promises. And each in its own way reinforced the same lesson: most transformations fail in the space between intent and execution.
I learned to be skeptical. If something cannot be run in production to scale and demonstrate real P&L impact, it is simply noise. That way of thinking has helped me not get caught up in chasing hype until now.
The Aha Moment: When Skepticism Broke
My approach was very hands-on and learning-led: with more traditional upskilling ways such as tutorials and boilerplates, I upskilled myself in the ways LLMs can be used, such as RAG, KAG, hybrid approaches, and multi-agent systems. Instead of working on a demo or theoretical exercises, I worked on them on actual problems rather than theoretical ones.
Then I Tried Agentic Coding (Claude Code)
This time, I wasn't using AI for snippets or inline suggestions. I was working with a fully agent-driven setup. I gave the system a real problem, complications were clear and concrete expectations were set, and the system was allowed to operate end-to-end. This was not proof of concept. It was work that I would typically invest a great deal of time and effort into myself.
What was surprising to me wasn't that it worked. It was how fast it worked. In about 48 hours, I reached a point where I normally would spend weeks or even months.
That was the point at which my skepticism broke. I was genuinely excited - it was only because it delivered and not because it promised.
Why I Had to Build It Myself (Production or Nothing)
I could not assess this from the sidelines. Reading posts or watching demos or scanning through benchmarks would not have told me what I needed to know. I have come to see that the only way to judge the value of a new approach - and to understand the change management required to implement that approach in big organizations.
So I did.
I made a pet project that is not a toy. I did it as if it were a real product. It had to run in production. It had to scale. It had to be resilient. And potentially, it had to matter from a business point of view.
The goal was not learning for the sake of learning. The objective was to get relevant context for my current and future Tech executive role in terms of organization transformation. That's where systems break. That's where tools hit their limitations. And that's where real lessons come in.
I use a simple rule. What you can't ship, you can't teach me anything useful. Agentic coding had to pass that test.
The Project Was Not a Toy (Technical Reality Check)
This was not a demo that was built to look pretty in a slide deck. It was built on the same stack that I've worked out over the last 15 years of real production work.
The front end was developed using React, Redux, and MUI. It was multi-tenant from the day it was built and designed for international use. No shortcuts. No single-user assumptions.
On the backend, I have used AWS Serverless with full infrastructure-as-code and CI/CD. Disaster recovery and high availability were designed in, not added on. Agentic coding wasn't limited to one task. It tackled a multi-agent scenario, retrieval using RAG, as well as invoice extraction using pictures. This wasn't isolated logic that was running in a sandbox.
The system is linked to real tools- Google Drive, email, and WhatsApp. I went from a blank repository, and I came out with something that I could ship to customers as an MVP.
This was real engineering. Anything less would not have mattered.
The Pattern I’ve Seen Before — And Why This One Is Different
I've seen this pattern before. Agile. Hadoop. Cloud. Machine learning. Each wave came with big promises and powerful early adopters. And each time, a majority of enterprises chose to wait.
This tactic usually worked. Early pioneers stumbled. Tools matured. Best practices formed. Late adopters hired more people and spent a lot more money, and caught up. The gap existed, but it was a bridgeable gap.
I've been a leader on those catch-up efforts. They were painful, but possible. You might throw the budget at the problem. You could add layers of process and headcount to make up for inefficiency. Over time, results came.
Agentic coding works differently.
This time around, waiting doesn't just slow you down. It alters the form of the competition. Teams using agentic coding aren't just a little bit faster. They work in a completely different mode.
The old playbook assumes inefficiency can be bought away. Agentic coding violates that assumption. The advantage is compounded too quickly. And when that happens, catching up is no longer realistic.
Central Thesis: The Competitive Abyss
This is the point at which agentic coding ceases to be a story about productivity, and it begins to be a story about competition.
Agentic-native companies do not just work a little faster. When designed correctly, they can work 5 to 10 times more efficiently than traditional engineering teams - not because the people involved are better, but because the system is designed differently in the first place.
That efficiency compounds.
Teams ship faster - and therefore they learn faster. Faster learning results in better product-market fit. Better fit leads to adoption and revenue, not years later.
Costs drop at the same time. Smaller teams produce more than larger teams. Lower costs improve margins. Better margins make it possible to invest more into product and experimentation. That reinvestment provides the next cycle of speed.
Decision-making is also changing. When teams are smaller and job tasks are mostly automated, decisions occur fast. There are fewer handoffs, fewer approvals, and less coordination overhead. Agility is no longer a goal, but rather the default.
This isn't a lead that others can close with time or budgets. It's a structural advantage built into the way the company functions.
That's why this is not a gap you can plan to close up later. It's an abyss. By the time traditional organizations begin a serious change agenda, agentic - native competitors are operating on a different curve.
Why You Can’t Catch Up Later (Organizational Antibodies)
Most organizations do not have issues adopting technology because the tools do not exist; the challenge is how organizations are organized to absorb change. Many extant processes were designed to mitigate risk rather than allow for velocity, which can slow procurement, security reviews, and the trip from experimentation to value.
Culture contributes another important dimension. Clear roles, handoffs, and ownership have been historically responsible for bringing stability, but more emerging models, such as agentic development, naturally push those boundaries. That discomfort is not a signal of failure - in many cases, it is the first signal that meaningful change is on its way.
Incentives also play a role. When success is also gauged by team numbers, budget, or control, it is more difficult to appreciate the influence of leveraging and automation. An opportunity to reward outcomes, not just scale, is created by reframing what "impact" looks like.
This is why transformation sometimes looks superficial: tools are introduced, pilots are launched, but there are no changes in basic working assumptions. The opportunity ahead is to move beyond announcements and experiments, and deliberately redesign processes, incentives, and ways of working so new technologies can deliver the potential that they hold.
While this is going on, the outside world is progressing. Investors revise their expectations. Speed, cost, and quality of execution begin to become more important than roadmap promises. Agentic capability becomes a barrier to funding and valuation.
At that point, waiting is not safe. It's a strategic mistake.
The Window Is Closing Faster Than You Think
We've seen this before. There was an opportunity for mobile-first. Companies that got a jump on the game won. Those who waited found themselves redesigning everything under pressure. The same thing happened with cloud native. Early movers were constructed differently. Late converts struggled with legacy for years.
Agentic coding has a window as well. I think somewhere between 18 and 36 months. That window exists because that is changing behaviour fast. New engineers are being taught from day one to work with the agents, writing code with them as a natural part of their workflow; for this generation, it's not a new or risky tool, but the way things work.
At the same time, many of the most disruptive competitors are likely to be born agentic-native, without legacy systems or habits to unwind, able to build their teams, processes, and products around these capabilities from day one, possibly in the startup ecosystem.
Time becomes the critical factor. Not tools. Not talent. Not budget. After the window closes, the rules change. And catching up is such a harder thing to do than most people realize.
The Vision of An Agentic-Native Company
An agentic-native company is constructed with agents at its head and is not added to later as helpers. Work begins with agents doing things end-to-end and people instructing, reviewing, and providing direction.
The configuration is more important than the code. Behavior is molded with rules, guardrails, and feedback rather than endless rewrites. Teams remain small, but they do more because they create leverage built into the system.
These companies learn on the run. They ship early, observe actual usage, and alter quickly. We don't measure success in terms of activity and headcount. It's measured by results.
This model is not fully solved yet. There are still open questions and rough edges - that is, gaps that will need to be filled by people. But for the first time, it's real enough to build around. That's what makes it worth being serious about.
What This Blog Will Deliver
This blog is a place to think out loud, based not on theory, but on real work.
Some posts will be visionary. They'll take a look into where this is going, who's likely to win this and who might get a beating over the next couple of years.
Others will be strategic. They'll examine organization design, leadership decisions, and when to move and when to wait.
There will also be tactical posts. These will include what actually works, what broke, what is more expensive than I thought, and what mistakes I made along the way.
This is not Evangelism, and this is not the vendor content. It is green field learning, subjectively shared and ongoing. The goal is insight, but not jargon.
If you are trying things out in this space - if they worked, broke, surprised you - tell us about it. Post your setups, your failures, the articles that shape your thinking, the talk or video that changed the way you thought about the problem. This is a wide-open field of work, and no perspective is sufficient. We shall learn it more rapidly by absorbing the realities of experience than by telling ourselves stories or experiences into polished narratives.
Personal Stakes and the Direction
This shift feels personal. At one point, I even joked with my son, who's studying software engineering, that he should perhaps change fields. It was half a joke, and it wasn't entirely a joke.
After 20 years of spearheading transformations, I take new shifts in my stride. This time, I am really energized - not because it is easy, but because it is real.
I'm dedicated to making things as fast as possible, learning publicly, and adapting on the way. I don't have all the answers. But I know this is something serious, and I'm willing to put my experience behind that belief.
Build or Be Disrupted
Every company will have to cope with this choice. Some of them will begin to build agentic-native capabilities now. Still others will wait until clearer rules, safer patterns, or broader adoption are introduced.
There's no judgment to that choice. But there are consequences.
If you are building, I would like to learn from you. If you have tried and failed, that is even more important. And if you disagree with the way I take it, I want to know why.
This blog is intended to be a place of sharing real experiences - what worked, what did not work, and what you would do differently next time.
So ask yourself the question straight:
Are you building an agentic - native company or waiting to be disrupted by one?