“Nobody remembers” — that’s normal, six months after the fact. Nobody ever knew. The code was generated, reviewed at a glance, approved, and merged. The understanding was never built in the first place.

Itamar Friedman calls this cognitive debt, and his recent InfoWorld piece, Why AI coding debt is different, is the best articulation I’ve seen of the problem. The scale is not hypothetical: Google has disclosed that AI now generates around 75% of its new code, and Meta has set internal targets for most engineers to have the majority of their committed code AI-generated by mid-2026. Whatever your organisation’s number is today, it’s going up.

Friedman names the disease well. This post is about the architecture of the cure — because I believe the answer is less about discipline and more about design.

What is cognitive debt?

Cognitive debt is the gap between code that exists and code that is understood.

That definition sounds abstract until you put it next to its older cousin. Technical debt and cognitive debt are not the same thing on a spectrum — they sit on entirely different axes. One is about the state of the code. The other is about the state of the team’s mental model.

Two things jump out of this matrix.

First, the dangerous quadrant is not the bottom-left. Everyone recognises a write-off when they see one; the ugliness is the warning label. The dangerous quadrant is the bottom-right, because it is visually indistinguishable from the top-right. Your dashboards, your linters, your code review tooling — all of them will tell you everything is fine.

Second, there’s a natural drift. Bottom-right decays into bottom-left. Code that nobody understands gets patched by people who don’t understand it, one urgent fix at a time, until it is neither clean nor comprehensible. Cognitive debt is how healthy-looking codebases become legacy systems — quietly, and faster than you think.

Here’s the mechanism, and it’s the sharpest insight in Friedman’s piece: when a human writes code, the typing is the least valuable output. The valuable output is everything that happened in the developer’s head along the way — the edge cases mentally simulated, the dependency trade-offs weighed, the three alternative designs considered and rejected. That reasoning is where institutional knowledge comes from. AI code generation delivers the artifact and skips the knowledge entirely.

We optimised for the artifact. The knowledge was the point.

Why it occurs

The comprehension loop is severed

Reviewing code is a fundamentally shallower cognitive act than writing it. When you author a function, you have simulated its failure modes before the first line compiles. When you review someone else’s 500-line diff, you are pattern-matching for anomalies. These are different mental operations, and only one of them builds a durable mental model.

For thirty years, this didn’t matter much because the author existed. Somebody on the team had an in-depth understanding of every line. Review was a second layer of comprehension, not the only one. AI generation removes the first layer and leaves review — the shallow layer — carrying the entire weight.

LGTM economics

Now put a rational developer in front of that 500-line PR. The AI produced it in three minutes. Genuinely understanding it — tracing the data flow, checking the edge cases, questioning the design — would take two hours. The tests pass. The code looks idiomatic. The sprint ends Thursday.

The individually rational choice is obvious, and it’s catastrophic at team scale. Every “LGTM” on code nobody deeply read is a small loan taken out against the team’s collective understanding.

The data says this is exactly what’s happening. GitClear’s analysis of hundreds of millions of changed lines found that duplicated code blocks of five-plus lines increased eightfold during 2024, while refactoring collapsed from about 25% of code changes to under 10%. And the DORA research found that a 25% increase in AI adoption correlates with a 7.2% decrease in delivery stability. We are shipping faster and understanding less, and the instruments are starting to show it.

Vibe coding is 100% cognitive debt

I want to be precise about this claim because it’s the strongest one in this post.

Most cognitive debt is erosion — understanding that existed and decayed, or partial understanding that was never deepened. Vibe coding is different in kind. Vibe coding is, by definition, shipping code you never intended to understand. You describe the outcome, accept what appears, run it, and iterate on the behaviour — never the comprehension.

There is no mental model decaying because no mental model was ever built. The debt isn’t accrued over time; it’s taken out in full at the moment of the merger. Bottom-right quadrant, by construction.

Let me be clear: this is fine for a weekend prototype, a throwaway script, a demo. I vibe-code utilities all the time. But in a production system, vibe coding is borrowing at maximum interest from day one — and as I argued in The Rider, Not the Horse, the rider who never looks down at the horse eventually discovers, at speed, that he has no idea what he’s sitting on.

Why this matters more than technical debt

Three reasons, and I’ll keep this short because the stakes are simple.

Cognitive debt has no early-warning system. Technical debt announces itself through friction — the module everyone dreads touching, the estimate that keeps tripling. Cognitive debt is silent right up until the incident. And then you’re reverse-engineering a black box at 2 a.m. while production burns, which is the most expensive possible time to be learning your own system.

The first-change cliff. The first non-trivial modification to un-understood code routinely costs more than the original feature did. The AI wrote the feature in an afternoon; your team spends a week reconstructing the reasoning before they can safely change one branch of it. The velocity you gained at generation time gets repaid, with interest, at modification time.

It’s now a competitive variable. Teams that preserve understanding while adopting AI get the velocity and the maintainability. Teams that don’t are building their next legacy system at 10x speed. Same tools, opposite outcomes. The reckoning, as Friedman puts it, arrives either way — the only choice is whether you pay now or pay compound interest later.

How to address it: minimize, contain, verify, own

The remedy isn’t one practice. It’s a chain: minimize what needs understanding, contain what’s generated, verify at generation speed, and own the logic that matters. Each link reduces the burden on the next.

1. Minimize — framework-driven development

The less novel the code the AI writes, the less there is to misunderstand.

Constrain generation to opinionated frameworks and well-worn idioms. On my stack, that means Spring Boot conventions: standard controller-service-repository shapes, standard configuration patterns, standard Kafka consumer setups. When the AI produces a REST controller that looks like every Spring controller your team has read for a decade, the cognitive debt on that code is near zero — the team’s mental model existed before the code did.

Framework conventions are pre-paid comprehension. Every line the AI generates inside a known idiom is a line nobody has to newly understand. The corollary: be most suspicious of AI output precisely where it’s most impressive — the clever, novel, bespoke solution is the one carrying the debt.

2. Contain — clear layer boundaries with segregated domain logic

Hexagonal architecture, clean architecture, ports-and-adapters — pick your flavour. These were always good ideas. In the AI era, they get a new job title: cognitive debt containment.

The principle: let AI-generated plumbing live in the adapters and infrastructure layers, and keep your domain logic segregated, small, and human-comprehended. The insight this unlocks is that you don’t need to understand every line in the system. You need to fully understand the domain core and merely trust the boundaries around everything else.

An adapter that maps a REST payload to a domain object can be trusted and tested. The interest-calculation rule at the heart of a lending platform cannot — it must be understood. Architecture is what makes that distinction enforceable rather than aspirational. Good boundaries shrink the surface area that steps 3 and 4 have to cover.

3. Verify — a verification loop at generation velocity

Friedman’s sharpest industry observation: nearly all the investment has gone into code generation, and almost none into verification. We built a blue team with no red team. The evidence that this matters is striking — in his data, teams that integrated AI into code review saw quality improvements in 81% of cases, versus 55% for teams using AI for generation alone.

But verification has to mean more than “the tests pass.” Passing tests is table stakes; it verifies behaviour, not comprehension and not structure. A real verification loop, running at the same speed as generation, checks:

• Architectural conformance — does this change respect the layer boundaries from step 2? (Tools like ArchUnit make this a failing build, not a review comment.)

• Standards enforcement — does generated code follow the team’s idioms from step 1, or has the AI invented a fourth way to do configuration?

• Traceability — can every change be traced to a requirement? Code with no articulable reason to exist is cognitive debt in its purest form.

If generation is automated and verification is manual, verification loses. Every time. The loop must run at machine speed.

4. Own — every piece of business logic verified by a human who owns it

This is the non-negotiable and the last link in the chain.

Infrastructure code can be trusted and tested. Business logic must be understood — by a specific, named human. My working rule: every business rule in production needs someone who can explain it without opening the file. Not “the team owns it.” A name. Collective ownership of comprehension is how comprehension quietly becomes nobody’s job.

The practical mechanism that makes this survivable at AI velocity: tests as executable specifications of intent. If your test suite expresses the business behaviour in readable, domain-language form — given a floating-rate loan, when the benchmark resets mid-cycle, then interest accrues from the reset date — comprehension survives even when the implementation underneath is machine-generated and machine-regenerated. The AI can rewrite the how every week; the humans own the what and the why.

Now walk the chain backwards and notice why it works. Ownership (4) is tractable only because verification (3) catches drift automatically. Verification is tractable only because containment (2) shrank the surface that needs deep checking. Containment works only because minimization (1) reduced the novelty in the first place. Skip a link, and the next one collapses under the volume.

The debt you re-learn

Here is the reframe I’d leave you with: AI didn’t create a code-quality problem. The code, by most measurable standards, is fine — often better than what a rushed human would write. AI created a knowledge-distribution problem. The code is in the repo. The understanding is nowhere.

Technical debt you refactor. Cognitive debt you re-learn — and re-learning your own system during a production incident is the most expensive education there is.

This post builds on Itamar Friedman’s Why AI coding debt is different (InfoWorld). The prescriptions are mine; argue with me in the comments.

That gap is the whole story. The skill that matters has shifted — but not in the direction most people assume. Everyone is anxious about losing their technical edge. Fewer notice the edge has moved somewhere else entirely.

My thesis, plainly: in the AI age, the architect’s value migrates up the abstraction stack. Deep conceptual thinking — knowing what to build and why a structure holds — becomes the differentiator. Technical knowledge doesn’t disappear, but its job changes: it stops being how you produce implementations and becomes how you verify and correct what AI produces. You no longer need to write the Java memory model from memory. You need to recognize, instantly, when AI has gotten it wrong.

The Two Dimensions

I think about an architect’s capability along two axes. One is Concepts & Abstraction — the ability to reason about structure. The other is Technology Depth — knowledge of the specifics. They aren’t the same thing, and AI is pulling them apart faster than ever.

Concepts & Abstraction

The stuff that doesn’t compile: cohesion and coupling, architecture patterns, design patterns, and above all, the ability to think abstractly about a system before a line of it exists.

What makes this treacherous is that abstraction errors are silent and expensive. A wrong technical choice announces itself — the build breaks, the benchmark tanks. A wrong abstraction stays quiet. A bad service boundary, a leaky module, a misapplied pattern — none of them errors out. It surfaces months later as rigidity: the feature that should take a day takes three weeks because the seams are in the wrong places. You don’t pay for bad abstraction up front; you pay interest on it forever — the purest form of technical debt, the kind no refactor sprint ever clears.

This dimension matters more in the AI age, not less, because AI is a force multiplier on whatever design you hand it. Give it a clean abstraction, and it builds fast and well. Give it a muddled one, and it scales the mess with terrifying efficiency. AI is the world’s fastest builder and has no opinion on whether the building should exist. The human owns the design intent.

And the strength is durable. Cohesion and coupling don’t get deprecated; patterns transfer across languages, decades, and paradigm shifts. The limit: abstraction without grounding becomes ivory-tower architecture — clean diagrams that don’t survive contact with a real system.

Technology Depth

The concrete knowledge: the specific database, language, and framework in each layer. The genuinely hard internals — the Java memory model, how concurrency behaves under load. The techniques for systems that have to be fast and correct at the same time.

For most of my career, this was the bottleneck. Only people who knew the internals could ship correct, performant code. Depth was the moat — scarce, hard-won, where reputations were made.

AI has quietly absorbed most of the production side of this. The race condition it won’t write, the backoff it gets right, the query it structures well — that knowledge is now commoditized at the point of generation.

What survives is the judgment side: reading AI’s output and catching the subtle failure — the race condition it did introduce, the N+1 query hiding behind clean-looking code, the wrong consistency model that works in the demo and corrupts data in production. Technology depth stops being a generative skill and becomes a verification skill. It’s still real, but it depreciates fastest — and it carries a peculiar danger: it can calcify into an identity that resists the very shift underway.

“Kafka Expert” vs. “Distributed Messaging Expert”

This contrast is small, and it changes everything.

Call yourself a “Kafka expert,” and you’ve tied your value to an artifact — the configs, the rebalancing quirks, the consumer-group semantics, the failure modes of one specific tool. Valuable, until the tool changes, the company migrates, or AI memorizes every Kafka config ever written better than you can. Your expertise is indexed to a technology, and technologies are exactly what AI swallows whole. A “Kafka expert” is one stack migration away from starting over.

Call yourself a “distributed messaging expert,” and you’ve tied your value to a concept — delivery guarantees, ordering, idempotency, backpressure, the tradeoffs between throughput and latency, why exactly-once is a beautiful lie most of the time. Kafka is just your current instantiation of that understanding. Hand you RabbitMQ, Pulsar, or whatever replaces them in 2030, and you’re productive in a week, because you already know the shape of the problem. You’re reasoning from the physics, not the manual.

Same engineer, two completely different assets. One depreciates as AI commoditizes it; the other appreciates, because now you can direct AI across any messaging tech and still catch it when it’s wrong. The depth didn’t become worthless — its framing decides whether it appreciates or depreciates. Anchor it to concepts, and your tech knowledge becomes evidence of understanding. Anchor it to a tool, and it becomes a countdown.

The 2×2 and the Four Archetypes

Put the dimensions on a grid: Concepts & Abstraction low to high up the vertical, Technology Depth low to high across the horizontal. Four quadrants, four kinds of architect — and the AI age treats each very differently.

Low Concepts / Low Tech — “The Coordinator”

Substance from neither design nor implementation. Value is in process, ceremony, status-chasing, and delegation. The standup runs on time; the architecture doesn’t exist. This is also where the vibe coders live — shipping AI-generated features that demo beautifully and fail spectacularly in production, because nobody in the loop understood the design or the implementation well enough to see it coming.

*Opportunity:* AI tooling can scaffold real competence; a Coordinator who uses the breathing room to invest in concepts has a path upward.

*Challenge: the most exposed quadrant, full stop. Coordination-only roles are the first thing AI-augmented teams erode. The only move is up* into real conceptual work — not sideways into more process.

Low Concepts / High Tech — “The Specialist”

Deep in a stack, excellent at the genuinely hard problems, but thinks bottom-up and struggles at the system level. The Kafka expert who can tune anything but can’t tell you whether you should be using messaging here at all.

This is the ghostbuster. When AI confidently ships something subtly broken — the deadlock, the silent data race, the performance cliff at scale — the Specialist is who you call. They see the ghost that everyone else, AI included, walked right past. But notice the shape of that role: you call a ghostbuster when something’s haunted, not to run the house. They’re the emergency number, not the daily driver — indispensable for the hour the incident lasts, idle the rest of the week. Real and durable, and also narrow.

Opportunity: the trusted corrector of AI, the verification layer that the thesis depends on. There will always be a tier of “AI got this wrong and only a human with real depth can see why.”

Challenge: their core production skill is precisely what AI automates first. The trap is comfort — ghostbusting is satisfying, and it pays, so it’s easy to stay while the ground narrows. The Specialist who reframes from “Kafka expert” to “distributed messaging expert” is quietly migrating up the grid. The one who doesn’t gets pigeonholed at the edges.

High Concepts / Low Tech — “The Strategist”

Strong on patterns, boundaries, and design reasoning; light on implementation reality. Draws the right system, can’t always tell whether it was built right.

Opportunity: On paper, best positioned for the thesis. AI handles implementation; the Strategist supplies the design intent AI lacks, and AI even backfills their technical gaps on demand.

Challenge: Without enough grounding, they can’t tell when AI’s implementation quietly betrays the design. The diagram says “eventually consistent”; the generated code says “lost updates”; the Strategist can’t see the difference. They need enough depth to verify — the mirror image of what the Specialist needs.

High Concepts / High Tech — “The Master Architect”

Strong design reasoning and enough technical depth to verify and correct. Designs at the top of the stack, verified at the bottom, use AI to collapse everything in between.

Opportunity: the clear winner. This is where AI multiplies hardest — design intent flowing down, verification flowing back up, the expensive middle automated. This is who becomes the 100x engineer, and the founder who builds a real company as a team of one, not by cutting corners, but by owning both the design and the verification that a whole org used to provide.

Challenge: rare and hard to sustain. Keeping technical depth current while operating at the abstraction layer takes deliberate effort — depth decays the moment you stop using it. The risk is degrading into a Strategist who thinks they can still verify.

The Takeaway

One trajectory worth internalizing: invest heavily in concepts and abstraction — the durable, appreciating asset — and keep technology depth as a verification capability, not a production one.

The safe move on the grid is up and to the right, toward judgment — not deeper into pure implementation. Depth still matters enormously, but its purpose has changed: you keep it sharp to catch AI, not to replace AI. The architect who understands that — and who describes themselves in concepts rather than tools — is positioned to win the decade.

AI raised the floor on implementation. The ceiling is now set entirely by how well you think.

The paper’s thesis, in one line: AI doesn’t substitute for human capability. It amplifies it. And like any amplifier, it magnifies whatever you feed in — signal or noise, expertise or confusion, taste or the absence of it.

I see this every working day. I spend four to five hours coding with Claude. I watch other developers do the same. And the cleanest analogy I’ve found for what’s actually going on isn’t from tech at all. It’s from equestrian sport.

The Horse and the Rider

In show jumping or dressage, the horse matters. Bloodline, conditioning, training — a bad horse can’t win. But put a world-class horse under an average rider, and you get an average round. Put an ordinary horse under an Olympic rider, and it punches above its grade.

The horse supplies power, reach, and athleticism. The rider supplies the line, timing, distribution of weight, the read of when to push and when to hold. The horse can jump. Only the rider knows which jump, in what order, and at what pace.

This is exactly the relationship between a developer and an AI coding assistant. Claude, Copilot, Cursor — these are very good horses now. Genuinely impressive animals. And precisely because the horses are so good, the differentiation has moved entirely to the rider.

One more thing about horses: they will gallop in the wrong direction with full enthusiasm if the rider points them there. So will an LLM. Hold that thought.

What the Paper Actually Says — Translated to Code

The paper identifies three layers where humans contribute to AI-assisted work. Mapped to coding, they look like this:

Problem definition. Knowing what to actually build. Where it fits in the system. Which constraints are real and which are negotiable? The AI cannot do this for you — it can only respond to what you frame.

Quality evaluation. Reading generated code and knowing whether it’s right, subtly wrong, or right-but-dangerous. This is the single biggest bottleneck I see in practice. Most developers cannot evaluate AI output well, because evaluation requires the very domain knowledge they were hoping the AI would substitute for.

Iterative refinement. Giving the AI the precise correction that moves it forward — not vague displeasure, not “make it better,” but a surgical pointer to what’s wrong and why.

There’s a fourth layer the paper doesn’t quite name, but it matters as much as the other three: knowing when not to use AI at all.

For some code, you’ll get a more accurate result writing it yourself than prompting your way to it — tricky domain logic, a subtle state machine, anything where the thinking is the work. AI output in those moments doesn’t accelerate your thinking; it contaminates it.

You end up reviewing someone else’s plausible-looking answer instead of arriving at your own correct one.

Just as a good rider knows when to dismount and walk, a good coder knows when to close the chat window and type. That judgment call is invisible to anyone measuring “AI adoption” by tokens consumed — but it’s where a lot of the quality lives.

The paper’s three engagement levels — passive acceptance, iterative collaboration, and cognitive direction — map cleanly onto what I see in the wild. Most developers are stuck at the first two levels and believe their problem is the prompting technique. It isn’t. It’s riding.

Vibe Coding Is Passive Acceptance, Dressed Up

“Vibe coding” — describing what you want in English and shipping whatever appears — is the paper’s Level 1 with a friendlier name.

For a prototype, a throwaway, a weekend hack, a demo for a pitch deck — this is fine. Genuinely fine. The cost of being wrong is low. The speed gain is real. Ship the vibe, learn the lesson, move on.

For production code — code that handles money, runs at 2 a.m., gets audited, supports real users — vibe coding is a liability. “It works, and I don’t know why” is not a state any serious engineering organization should be shipping in. The horse jumped the wall. You don’t know how. Next time, it won’t.

The mistake isn’t vibe coding. The mistake is not knowing which mode you’re in.

The Context Gap, Amplified

I wrote earlier about the context gap — the fact that AI doesn’t have your domain rules, your tech debt map, or your institutional memory. The rider supplies all of that. The cognitive amplifier framing makes this sharper.

A senior developer reading AI-generated code sees not just the code but everything the AI couldn’t have known — the regulator’s interpretation that shaped the calculation, the vendor that sends malformed responses at month-end, the module everyone touches only on Fridays after extensive regression testing.

A junior developer reads the same output and sees clean, plausible code. Accepts it. Ships it. Production finds the gap later.

That’s the amplifier in action. The senior’s context gets amplified into leverage. The junior’s gaps get amplified into incidents.

The Sycophancy Trap

The paper highlights a quietly dangerous behaviour in LLMs: sycophancy. Near 100% compliance rates with logically flawed requests. Dramatic overweighting of user pushback — about 2.5 times stronger than rational updating would justify. Models abandon correct answers under pressure.

In coding, this looks like: “this isn’t working.” → AI rewrites perfectly fine code. “Make it more robust.” → AI adds defensive layers around a non-problem. “Use a different approach.” → AI throws away the right answer in favour of a worse one.

The expert leverages this productively. Precise, domain-grounded corrections converge fast. The novice destroys their own output with vague dissatisfaction — driving the model deeper into confident mediocrity, one round at a time.

The horse will jump whatever you point it at. Including the wall.

How to Ride Well

Practical suggestions, from someone who codes with AI every day.

1. Invest in the codebase, not the prompt library. The biggest leverage isn’t a better prompt — it’s giving the AI the context only your team has. Architecture Decision Records that explain why. Decision logs. Domain glossaries. CLAUDE.md files. Make your institutional memory machine-readable.

2. Know which mode you’re in. Prototype mode: vibe code freely. Production mode: review every line, own every line. The mistake is confusing the two.

3. Know when to put the AI down and type. If you’ve spent fifteen minutes prompting and re-prompting for a function you could have written in ten, you’ve already lost. Hand-coding the gnarly five percent is faster, cleaner, and keeps your own skills sharp.

4. Match autonomy to risk. Auto-accept on tests, scaffolding, and boilerplate. Hands-on the reins for payment logic, auth, anything with money or regulators attached. Uniform AI speed across a non-uniform risk surface is how outages happen.

5. When something is wrong, be specific. Not “this doesn’t work.” Try: “the null check on line 14 will throw on the month-end batch because the vendor sends empty strings, not nulls.” Precision in correction is what separates a Level 3 rider from a Level 1 one.

6. Refuse to outsource judgment, even when you can. Architecture, tradeoffs, what to build next — these are rider decisions. The horse doesn’t get a vote.

7. For juniors: write code without AI sometimes. Often, actually. Otherwise, the riding muscles never develop. You can’t direct what you’ve never done.

The Quiet Truth

The horse keeps getting better. The frontier models will keep getting better. That’s not the interesting variable anymore.

The interesting variable is whether you can ride. Whether you know the course, can read the line, can correct mid-stride, can tell the difference between a clean round and a knockdown the judges haven’t called yet, and can tell when to dismount and walk the next section on your own.

The AI hype cycle has spent three years selling better horses. The quiet truth is that the riders who were already good are pulling further ahead. And the ones who never learned to ride are falling behind, faster.

Burndown charts are trending nicely. Velocity stable across three sprints. Standup attendance at 98%. The Scrum Master walked us through it with quiet pride.

The feature had not shipped. It had not shipped the sprint before either.

Nobody in the room could quite explain what was blocking it. But everyone could tell you exactly how many story points had been carried over.

If you’ve worked in Indian IT for more than five years, you have sat in this meeting. You have probably sat in it this week.

Somewhere along the way, the ceremony became more important than the thing the ceremony was supposed to serve. The standup became the work. The sprint board became the work. The audit trail became the work.

The actual work — the feature, the fix, the system that does the thing the customer pays for — became almost incidental.

This is the lost art of engineering excellence, which I talked about in my earlier blog. Process worship is what killed it.

The 2x2 nobody wants to draw

Plot engineers on two axes: process compliance and outcome delivery. You get four quadrants.

• The Craftsperson — follows the process, delivers the outcome

• The Compliant — follows the process, doesn’t deliver the outcome

• The Cowboy — ignores the process, delivers the outcome

• The Passenger — does neither

Everyone reading this can name three people in each quadrant from memory. That’s not the interesting part.

The interesting part is which quadrants get rewarded.

In most Indian IT organizations, the ranking goes: Craftsperson, Compliant, Passenger, Cowboy.

Read that again. The Cowboy — who actually delivers — ranks below the Passenger, who delivers nothing but attends every ceremony. The Compliant, who has never shipped a feature on time, gets promoted ahead of the Cowboy, who ships every sprint.

How did we get here?

The original sin: CMMI as a sales credential

Indian IT did not stumble into process worship. We built our entire industry on it.

In the 1990s, when a CIO in New Jersey was deciding whether to send work to Bangalore or keep it in Newark, the question wasn’t whether the Indian engineers were good. It was whether they were predictable.

CMMI Level 5. ISO 9001. Six Sigma Black Belts. These were never quality frameworks. They were trust signals. A way of telling skeptical Western buyers: we have processes, we have documentation, we have audit trails, you can trust us with your maintenance contracts.

It worked spectacularly. The Indian IT industry grew into a 250-billion-dollar business on the back of process certifications.

Two things were true at the same time, and we have spent thirty years pretending only one of them was: the certifications got us the contracts, and the certifications had almost nothing to do with whether the actual work was any good.

CMMI assessments were performed. Audit weeks were theatre. Every engineer who lived through one remembers the frantic backfilling of documentation the night before the auditor arrived.

The frameworks credentialed us. They did not improve us.

Then the second sin compounded the first. Most of the work was Time & Material. There was no accountability for the outcome because the outcome wasn’t what we were selling. We were selling hours. Hours billed against a process-compliant SDLC. The longer a project ran, the better — for everyone except the client.

When your business model rewards process compliance and bills by the hour, you optimize for engineers who comply with the process and consume hours. That is the workforce we built. That is the workforce we still have.

The Scrum Master who never wrote code

Then Agile arrived, and we did to it what we do to everything. We turned it into a ceremony.

A Scrum Master, in any reasonable reading of the Agile Manifesto, is a part-time role for a working engineer. In Indian IT, it became a full-time job. Sometimes a career track.

We have Scrum Masters with seven years of Scrum Master experience who have not written production code in any of them. We have Agile Coaches coaching teams whose problems have nothing to do with Agile. We have Release Train Engineers running SAFe ceremonies for projects that ship twice a year.

This is the lost art. Engineering excellence is not a process artifact. It is the residue of people who care about the craft doing the work.

When you spend fifteen years measuring engineers on ceremony attendance instead of code quality, you produce engineers who are excellent at ceremony attendance and mediocre at engineering. We did this to ourselves.

The measurement problem

Why do managers keep doing this, even when they can see it isn’t working?

Because the process is observable in real-time and outcomes are not.

A standup happens every day. A Jira board updates every hour. A burndown chart refreshes itself. The business impact of a feature — did customers use it, did it move a metric, did it create or pay down debt — shows up in a quarterly review nobody reads, if it shows up at all.

Managers optimize for what they can see in a 1:1. In Indian IT, this is compounded by a project management layer whose own performance is measured on — you guessed it — process compliance.

The PM’s incentive is for the team to look compliant, not to deliver outcomes. Everyone in the chain is optimizing for the same wrong thing.

Handling the four archetypes

The four archetypes need different things, in a specific order. Getting the order wrong makes everything worse.

Find your Craftspeople first

Before anything else, identify the people who actually deliver outcomes and follow enough process to keep the team functioning. Then:

• Make them visible. Set them as role models.

• Build coaching into their job description.

• Reduce their delivery load to create space for it.

• Stop rewarding them with more process — more reviews, more reporting, more ceremonies. That is not a reward.

• Protect their calendar. They are the cultural anchor.

Measure the Compliant on outcomes

The Compliant are not lazy. They have been trained, often for years, that process is the outcome. The fix:

• Give them ownership of something small and end-to-end.

• Judge them on whether it worked, not whether the burndown chart looked pretty.

• Pair them with a Craftsperson, never with another Compliant.

• Accept that some will rise into Craftspeople and some will reveal themselves as Passengers. Both outcomes are useful.

The status quo — leaving them in permanent process-compliant non-delivery — is the only bad option.

Listen to the Cowboy before you tame them

This is the reframe most managers miss. Cowboys don’t ignore the process because they are rebels. They ignore it because they can’t see the value in it.

Nine times out of ten, they are right.

• The Cowboy who skips the daily standup is usually skipping a standup that should have been a Slack message.

• The Cowboy who doesn’t update Jira is usually working in a system where Jira updates are theatre disconnected from the actual work.

• Before forcing compliance, ask whether the process the Cowboy is skipping delivers value to anyone.

• If it doesn’t, simplify or remove it.

• If it does, explain the value. Good Cowboys will comply when the value is real.

Cowboys are diagnostic signals. They tell you which parts of your process are load-bearing and which parts are ritual.

The Passenger needs sequencing, not pressure

Every Indian IT org has Passengers, and everyone knows who they are. They survive because of bench economics, attrition anxiety, and performance systems that measure compliance, which Passengers are often excellent at faking.

You cannot fix a Passenger by demanding process and outcome at the same time. The two-front war fails every time. Do it in order:

• Step 1: Push them to genuine process compliance. Not theatre. Actual standup participation, actual ticket updates, actual code reviews.

• Step 2: Once they’ve moved into the Compliant quadrant, apply the Compliant playbook. Give them an outcome. Measure them on it.

Most Passengers will resist Step 1, and that resistance is the signal. Those who never make it past Step 1 have answered your question for you.

The organization has to be willing to act on the answer. Most Indian IT orgs are not. That is its own problem, and it is the one we have spent thirty years refusing to solve.

The work is the work

Process exists to serve outcomes. When it stops doing that, it becomes a tax on the people who deliver and a hiding place for the people who don’t.

The standup is not the work. The sprint board is not the work. The CMMI audit is not the work. The Scrum Master with seven years of Scrum Master experience is not the work.

The work is the work. We used to know that.

I still code 3-4 hours a day.

Most people in my position stopped coding a decade ago. The conventional advice is clear: as you become senior, you “graduate” from writing code to writing strategy. You move from IDEs to slide decks. You delegate the keyboard.

I think this advice is wrong. And in the age of AI coding tools, it is becoming dangerously wrong.

Elon Musk put it sharply on X:

“I strongly believe that all managers in a technical area must be technically excellent. Managers in software must write great software or it’s like being a cavalry captain who can’t ride a horse!”

The cavalry captain line is hard to argue with. And yet most of Indian IT is run by exactly those captains—people who can describe the battle eloquently in PowerPoint, but who haven’t been on a horse in years.

This post is about why I’m still on the horse.

The Indian IT Context

The pyramid model that built Indian IT assumed—indeed required—that senior people stop building. Architects architected. Project managers managed. The actual code was written by people five, ten, or fifteen levels below them.

Over time, this created a generation of what I call PowerPoint architects. People who could draw beautiful boxes and arrows on a slide, but who couldn’t tell you whether the design would actually work when deployed.

For a long time, this worked—because the gap between drawing the box and building the box was navigable. That equilibrium is now breaking down. AI coding tools have widened the gap between those who deploy working systems and those who only talk about them. The people closest to the code are getting 3x, 5x, sometimes 10x more productive. The people furthest from the code are still producing the same slides at the same rate.

If you stopped coding ten years ago, you are not just rusty. You are making strategic decisions about a craft that has fundamentally changed underneath you.

What Coding Daily Actually Gives Me as a CTO

Better technical decisions. Last month, I had to choose between two AI models for an agentic workflow. Cost differed. Latency differed. Reasoning quality was harder to measure.

This is not a decision I could have made from a slide deck. I needed to feel the failure modes—where the cheaper model gave up, where the expensive model over-engineered, where each one hallucinated.

The same applies to architectural choices. Microservices versus monolith. Event streaming versus synchronous calls. NoSQL versus relational. These decisions land differently when you have debugged them at 11 pm before a go-live.

When I review a design today, I’m running through the operational debugging session in my head. I know which choices will haunt the team at 2 am six months from now, because I have been the person at 2 am.

I can also smell when an estimate is wrong—because I have written that kind of code recently. The cavalry captain who has ridden the terrain knows when a junior is being optimistic.

Earned credibility with engineers. Engineers can tell within five minutes whether a CTO is bluffing.

They can tell from the questions you ask. From how you respond when a junior pushes back. Whether you know the difference between a reasonable trade-off and a lazy one.

You cannot fake this.

When I pair with a junior on a data model, or sit next to someone debugging a rule engine, I am demonstrating that the person at the top of the org chart is still close enough to the metal to be useful. You don’t have to perform authority when you have it through demonstrated competence. The cavalry captain who rides at the front doesn’t need leadership speeches.

AI-era leverage. Here’s the part most senior leaders are missing.

Coding 4-5 hours a day with AI tools is a fundamentally different activity from coding without them. The skills, the workflows, the failure modes—all of it is different. The only way to internalise this is to actually do it. Daily. For months.

A CTO who has not seriously built with Claude Code, Cursor, or similar tools in the last six months is making strategy decisions on stale data. While other senior leaders are still figuring out whether AI coding is “ready for production,” I have spent thousands of hours learning where it works, where it breaks, and what to delegate to it.

That tacit knowledge cannot be transferred through a deck. It can only be earned at the keyboard.

The Counter-Arguments

“Your time is too valuable to code.” Valuable for what? Another status meeting? Another PRD that the team will partially read? An afternoon spent prototyping the riskiest part of a system is often more valuable than a week of meetings about it.

“You’ll micromanage your team.” Coding for understanding is different from coding their tickets. I am not picking up stories from the sprint board. I am building things adjacent to what the team is building, prototyping ahead of what they will build next quarter.

“You’ll fall behind on management.” Or you will lead better because your management is grounded in reality, not status reports filtered through three layers of optimism. Cavalry captains who ride don’t fall behind on captaining. They captain better, because they know what they are asking their riders to do.

What I’ve Had to Give Up

This is a real trade-off, not a free lunch. In my case, what has been given is a certain category of meetings—the ones that exist for visibility rather than decisions. A certain amount of stakeholder ritual. A certain kind of senior-leader theatre that some organisations expect and reward.

If you are considering staying technical at a senior level, you should know: you will have to actively defend your coding hours against an organisation that will, by default, fill them with meetings. It is worth fighting.

A Note to Other Senior Technologists

There is one more reason I still code at 50: I genuinely enjoy it. After 27 years, the craft has become more interesting, not less. The tools are more powerful. The leverage is greater. I learn something new every week.

If you stopped coding because you thought you were supposed to—reconsider. The world has shifted. The cavalry has new horses. The captains who can ride them will lead the next decade.

If you stopped because you stopped enjoying it—that’s a different conversation worth having with yourself. Maybe management is genuinely your craft now. That’s fine. But be honest about whether you are leading a technical organisation or merely presiding over one.

The cavalry captain who rides into battle leads a different kind of charge than the one who directs from behind. Both can win battles. But only one can still win them in a war that has fundamentally changed.

I plan to be on the horse for as long as I can ride.

Here are the remaining seven.

7. Zawinski’s Law

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can.

This is the second law of thermodynamics applied to software — software entropy. I have seen it play out all the time in my career. We keep adding features to a good piece of software till it becomes unmanageable and complicated, at which point it gets replaced by a simpler solution. The simpler solution then starts accumulating features, and the cycle repeats.

Why does it matter?

Software does not become unmanageable or hard to change by itself — it happens in small steps as technical debt builds up. The usual culprits are features built under time pressure, with shortcuts like bolt-on additions, compromised architecture or weakened modularity. This single factor accounts for most of the issues and maintenance costs across the software lifecycle.

The way to address it is to invest deliberately in technical debt — refactoring, rationalising features, and ruthlessly deleting features that no longer make sense. In the non-software world, look at the Raptor-3 engine from SpaceX as a model: each generation has dramatically fewer parts, simpler routing, and lower cost than the last. That’s what disciplined simplification looks like.

8. Hyrum’s Law

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

If you have public software with a large enough user base, people will use every observable behaviour — even ones you never intended. I once built a hack to scrape a website that allowed business users to get some data. When the source website changed, and the scraping stopped working, more than 100 users complained. A throwaway hack had become a load-bearing wall.

Why does it matter?

This directly drives up your software maintenance cost — any change you make has a high probability of breaking something. Be careful what you build and distribute, because users will use it more than you intended, and any change will trigger blowback. The lesson I now apply: no small hack or quick program should ever be distributed to users who don’t understand its limitations. The contract is a polite suggestion. The actual interface is everything anyone can observe.

9. Price’s Law

In any group, 50% of the work is done by the square root of the number of people.

I call them drivers and passengers — a few people pick up most of the work in any group (drivers), and the others coast along (passengers). Out of 100 engineers, 10 will generate output equivalent to that of the other 90.

Why does it matter?

This law matters hugely in the age of AI. The key drivers in your dev team can become an order of magnitude more productive once they only work with equally capable people and AI. They get back the time and the overhead they used to spend dealing with issues created by the passengers.

A good example is how Elon Musk fired more than 50% of the Twitter tech team, and nothing broke. The square root of 8,000 is 90, and 90 capable people can run a remarkable amount of infrastructure if they aren’t carrying the other 7,910.

10. The Ringelmann Effect

The tendency for individual members of a group to become increasingly less productive as the size of their group increases.

This is very real — the larger the team, the lower the productivity, as the number of passengers increases (Price’s Law again). It was discovered in 1913 through the rope-pulling experiment, which measured pulling force per person as the group size increased. Each additional person pulled less hard than the one before.

Why does it matter?

It matters because productivity is the main driver of today’s software development. There are two reasons the effect kicks in:

1. Social incentive — the visibility and reward of individual work reduce as group size increases.

2. Coordination overhead — the number of communication paths is nC2, which grows quadratically with group size.

The solution is to keep groups small and very productive. The moment a group grows beyond effective size, break it into smaller groups and ensure they don’t need regular communication between each other. This is also the practical bridge to Conway’s Law from Part 1 — small autonomous teams produce clean architectures.

11. Goodhart’s Law

When a measure becomes a target, it ceases to be a good measure.

This is nowhere more visible than in the Indian IT industry, where every measure is hit successfully and yet the desired outcome stubbornly refuses to arrive. It is also true that what is easy to measure gets measured — regardless of whether it actually matters.

Why does it matter?

What gets measured gets improved — but the measure should not become the outcome itself. Hours of work, lines of code, story points, velocity — these are all proxies for software outcomes. Take any of them too seriously and they become counter-productive. The team optimises for the measure and quietly drops the outcome.

The focus should always be on stakeholders and their satisfaction with the actual outcome — not on the proxy you happen to be tracking this quarter.

12. Gilb’s Law

Anything you need to quantify can be measured in some way that is superior to not measuring it at all.

What this law is saying is that even if measurement is hard and the measurement might be imperfect, it is still better than not measuring at all.

Why does it matter?

This may seem to contradict Goodhart’s Law, but it doesn’t. While it doesn’t make sense to take a measure and turn it into an end in itself, it is important to measure — especially the things that are hard to measure.

I know a client who used to track only two measures for a dev team’s sprint delivery:

• Product Owner happiness

• Dev team happiness

Both were rated on a simple scale of 10, and the team’s informal objective was to score well on both. That’s it. No story points, no velocity, no burndown charts. And it worked — because the measures pointed at outcomes that mattered, were hard to game, and forced honest conversations between the people who needed to have them.

13. Murphy’s Law

Anything that can go wrong will go wrong.

No list of laws is complete without Murphy, and everyone already knows it.

Why does it matter?

Murphy’s Law is critical in software design. Whenever you think a scenario will never happen, it will — so design for it. Defensive coding, chaos testing, circuit breakers, retries with backoff, observability, blast-radius limits — these are the practical applications of Murphy. The senior move isn’t preventing every failure. It’s making failure cheap, observable, and recoverable.

Closing thoughts

Notice something? Almost none of these 13 laws are really about code.

They are about humans, time, organisations, incentives, and entropy. The technical laws of computer science — Big O, CAP, Amdahl — you learn in college. The 13 laws above, you learn by getting hit by them. Repeatedly. Across decades.

There is a rough progression of seniority hidden in this list. In your early years, you don’t know any of these. Around year five, you have heard of them, and you are fighting them — adding people to late projects, building heroic features, trying to outwork Hofstadter.

By year ten, you have stopped fighting and started designing around them. By year twenty, you are using them as tools — Inverse Conway as an architecture lever, Cunningham as a design-review strategy, Gilb as a counterweight to Goodhart, Price’s Law as a hiring filter.

If I had to add a 14th law from 25 years of watching this industry, it would be this: the engineer who learns to predict their own organisation’s failure modes is more valuable than the one who can predict their system’s. The systems, honestly, are easier.

PS: These laws have been around for a while, and there are many articles written on them. I have taken the selection and order from Anton Zaides’s article, which you can find here.

Which of these has bitten you hardest? Tell me in the comments.

After 25 years in this industry, I’ve stopped being surprised by projects going sideways. Not because I’ve gotten better at preventing it — I’ve just recognised the patterns. There are roughly 13 of them. They show up in every team, every company, every architecture, on every continent.

Here are the first six. The remaining seven follow in Part 2.

1. Parkinson’s Law

Work expands to fill the time available.

I call work the gaseous state — it fills any container you put it in. This law is most prevalent in software estimation, where adding buffers and giving an unusually long timeline produces exactly the outcome the buffer was meant to prevent. If work finishes before the deadline, engineers will expand to fill the saved time.

Why does it matter?

Asking for a timeline usually gets a pessimistic response, and the worst-case scenario usually becomes the reality. Setting an aggressive timeline doesn’t help either — it’s bound to be missed, thanks to Hofstadter’s Law, which is next.

2. Hofstadter’s Law

It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Software projects are uncannily late, even after contingencies and buffers. If you use Parkinson’s Law to justify an aggressive timeline, you will burn out the team and miss every deadline.

Why does it matter?

These two laws together pretty much explain the futility of software estimation. The most elegant escape the industry has found is agile — focus on productivity and time-boxed delivery instead of fixed-date commitments. But that still leaves the problem of committing to external stakeholders and the business. The answer there is a heuristic-based, pessimistic scope against a fixed release cadence — say, quarterly releases with a set of committed features and a set of potential features.

3. Brooks’ Law

Adding manpower to a late software project makes it later.

This one is my favourite, because I’ve watched the most experienced delivery leaders fall for it. It is as futile as asking nine women to produce a baby in a month.

Why does it matter?

Fred Brooks figured this out in 1975, managing IBM’s OS/360, and we’ve spent 50 years ignoring him. Adding people to a late project means the existing team stops working to onboard them. Communication paths explode — a team of 5 has 10 channels; a team of 10 has 45. The new folks code bugs before they code features. The right answer to “we’re late” is almost always “let’s cut scope,” not “let’s hire.”

4. Conway’s Law

Organizations design systems that mirror their communication structures.

I’ve written extensively about why this law is everlasting on my blog. The most common manifestation: the architecture ends up resembling the team structure, and the seams in the architecture appear exactly where communication is weakest. If your team is split into frontend and backend, the UI–API contract is where the bugs will live.

Why does it matter?

The corollary is what matters most. Since organisation structure has a direct impact on architecture, the smart move is to design the team structure to reflect the target architecture — not the current one. Formalise the interfaces between teams with the same rigour you’d apply to a system contract. This is called the Inverse Conway Maneuver, and it is the most powerful lever a CTO has.

5. Cunningham’s Law

The best way to get the right answer on the internet is not to ask a question, but to post the wrong answer.

This law is rooted deep in human behaviour. People love to validate their own beliefs, and the easiest way to do that is by correcting someone else. So the best way to get information is not to ask for it — it’s to give people an opportunity to correct you.

Why does it matter?

Used well, this is a powerful unlock. Instead of asking open-ended questions in a design review, propose a deliberately incomplete solution — the team engages ten times harder when they have something to push against. Internal Q&A forums, visible peer reviews, and “strong opinions, loosely held” culture all tap into the same instinct. You don’t have to be right to get the right answer. You just have to be wrong in public.

6. Sturgeon’s Law

90% of everything is crap.

This is truer than ever in the age of AI. 90% of everything created is crap — including 90% of code, 90% of features, 90% of blog posts, and 90% of LinkedIn comments that start with “Great point!”

Why does it matter?

This is where human wisdom still trumps AI. A wise engineer focuses on the 10% of code that sets the direction — the architecture decisions, the critical abstractions, the contracts between services — and lets AI handle the remaining 90%. That 10% is what makes the other 90% actually work. The “10x engineer” in the AI era isn’t the one who writes 10x more code. It’s the one who knows which 10% to write themselves.

The next seven laws — Zawinski, Hyrum, Price, Ringelmann, Goodhart, Gilb, and Murphy — follow in Part 2. Those are the ones that explain why your APIs never die, why half your team carries the other half, and why production always breaks on Friday evening.

PS: These laws have been around for a while, and there are many articles written on them. I have taken the selection and order from Anton Zaides’s article, which you can find here.

My claim is narrower and blunter than the usual AI-replaces-everyone take. The specific version of PM that Indian IT industrialised — non-technical, coordination-first, certification-credentialed — is being structurally obsoleted. Not diminished. Ended.

To see why, it helps to trace how the role got built.

An artefact of the labour-arbitrage era

Indian IT’s first big break was Y2K. The work was simple in scope but enormous in volume. What it taught the industry was a template: take a large, well-defined body of work, decompose it, throw bodies at it, coordinate the bodies, and deliver on time. That template outlasted Y2K and became the shape of everything after it — application maintenance, ERP rollouts, testing, migrations, package implementations.

That shape — large teams, well-defined work, heavy coordination — was tailor-made for a project manager.

Then, between 2002 and 2015, the most consequential structural shift in how Indian IT manages software happened, and almost nobody talks about it: the PM became non-technical.

The industry grew faster than the supply of technically-grounded managers. Non-IT professionals entered en masse to fill the coordination layer, mostly from manufacturing, construction, and other project-heavy industries where “project management” as a formal discipline already existed.

The logic was seductive: if someone could run a plant commissioning with Gantt charts, critical paths, and milestone tracking, surely they could run a software delivery the same way.

The cultural shift followed. “A good PM doesn’t need to understand the technology” became conventional wisdom. PMP and PRINCE2 institutionalised it — domain-and-tech-agnostic credentials validating a role that was itself becoming tech-agnostic, making the credential, not the craft, the career currency.

Technology kept changing underneath — mainframes, 4GL, client-server, web, mobile, cloud — and the PM layer got progressively further from any of it. By the late 2000s, it was normal for a PM to have never read the code they were shipping.

This had consequences I’ve written about before. In my Lost Art of Engineering Excellence series, I argued that career paths that pulled the technically curious out of engineering and into management hollowed out the industry. The other half of that diagnosis is the PM role itself, narrowing into operational and people management — scheduling, staffing, status, escalation — not technical stewardship.

As projects got more complex through the digital era, the PM couldn’t carry the technical load and wasn’t expected to. The architecture function absorbed the technical decisions PMs used to own. The PM’s scope narrowed further: a coordinator between client, delivery, and architecture. Real influence on the system being built: minimal.

This is the role AI is now meeting. Already hollowed out.

The assumptions are breaking

The PM role, as it exists in Indian IT today, rests on four assumptions. AI is breaking each one.

Assumption 1: There will always be large teams to coordinate.

The army is being dismantled. In The Army vs. The Special Forces I argued that AI is a skill amplifier, not a skill equaliser — five strong, AI-augmented engineers can now deliver what twenty-five average engineers delivered before. When the army shrinks to a special forces cell, the coordination surface shrinks with it. There is simply less to coordinate.

Assumption 2: developers need someone to translate requirements, track work, and manage dependencies.

Capable engineers with AI now do requirement-to-delivery individually — clarify scope, design, build, test, deploy. The number of handoffs collapses, and coordination collapses with it. A four-person cell talking directly to a client doesn’t need a translation layer.

Assumption 3: developers can’t manage themselves.

High-calibre developers have always been largely self-managing. Most of the PM coordination overhead was a function of having too many shallow-skilled developers — the judgment gap I described in Building Your Moat Against AI. When the team is small and deep, a hands-on IC lead replaces the dedicated manager. The player-coach becomes the unit of delivery.

Assumption 4: Process discipline is the moat.

PMP and PRINCE2 formalised processes as the PM’s professional asset. The value proposition became: I bring discipline to chaos.

Distributed agile was supposed to disrupt this. In theory, self-organising teams, product owners, and scrum masters would dissolve the traditional PM layer. In Indian IT practice, it did the opposite — agile got bolted on to the existing hierarchy. Scrum masters became PMs with a new title.

Stand-ups became status meetings in ever-expanding fifteen-minute form. Burndown charts replaced Gantt charts, but the reporting layer above didn’t shrink — it expanded, now demanding both sets of artefacts. Distributed agile at scale became the new justification for heavy coordination: someone has to keep the ceremonies aligned across time zones. The army needed its officers, just under new names.

AI breaks this in a way agile never did. When a forward-deployed cell clarifies requirements directly with the client, builds, tests, and ships, the ceremonies don’t need to be coordinated because they barely exist. There is no three-timezone handoff to manage when there’s no handoff. Outcomes, not process adherence, become the measurable unit. And once outcomes are measurable, process theatre becomes visible as theatre.

What the new organisation looks like

At the firm level, the shape changes sharply.

At the top sit domain-deep partners who own the client’s business problem — outcome owners, not delivery heads. Below them, architect-builders: hands-on, AI-augmented, accountable end-to-end. The special forces cell. Alongside them, a flex layer of mercenary senior engineers on fractional engagements for the hard problems. Underneath all of it, a thin operational layer — contract admin, finance ops, compliance — shrunk to what’s legally necessary, not what’s culturally accumulated.

What’s gone or radically shrunk: delivery managers, programme managers, generalist PMs, PMO staff, resource managers, bench-management infrastructure. An entire middle tier of the industry’s org chart.

At the account level, the contrast is starker. The traditional engagement runs five or six layers deep — Account Director, Delivery Manager, two or three Project Managers, Team Leads, thirty to two hundred developers.

The new engagement runs for two. An Engagement Partner owning domain and relationship, a forward-deployed cell of four to eight architect-builders, and on-demand mercenary specialists when needed. The remaining coordination work is absorbed by the partner (client-facing) and the cell lead (delivery-facing). Both are hands-on. Neither is a PM.

What project managers can actually do

Context — domain, client, system — is what AI cannot replicate. That is where PMs can still build value, if they’re willing to rebuild.

1. Become the domain.

Go deep in one or two verticals — lending, insurance, supply chain, healthcare payers. Own outcomes, not status. The PM-turned-domain-expert is the most natural evolution and the most under-appreciated one. It is also the path that uses the most of what a PM has actually accumulated: years of exposure to how businesses in a particular sector work, fail, and change.

2. Become an IC again, with AI as the multiplier.

For PMs with some technical background, AI has lowered the bar to hands-on work in a way it wasn’t two years ago. The honest version: this is hard, not a shortcut. It requires real re-skilling and the humility to ship small things badly for a while. But the door is open.

3. Become the relationship layer.

Engagement partner and client partner roles where trust, political capital, and judgment matter. These roles will be smaller in number than PM roles today, but genuinely defensible — a good client partner is harder to replace than a good delivery manager ever was.

4. Exit gracefully.

Some of the roles simply won’t have a successor in the new shape. Being honest about that is kinder than pretending reskilling paths exist for everyone. For those financially able, a mid-career pivot to adjacent fields — product, GTM, advisory, teaching — is a rational choice, not a failure.

The role is ending, and the people don’t have to

It is the role that is dying, not the individuals in it. Indian IT has a generation of talented operators whose core skill — coordinating complexity at scale — was shaped by a system that no longer needs coordination at that volume.

Every major role in Indian IT is being re-specced. The PM’s re-spec is the hardest because the role had drifted furthest from the work. When the ground beneath a role is already thin, it doesn’t take much to break through.

The question isn’t whether Indian IT project management is dead. It’s whether the people in it will wait to be told, or rebuild before they are.

If you would like me to write a blog on a topic of your interest, do leave a comment.

UPI in 60 Seconds

For the uninitiated: UPI (Unified Payments Interface) is India’s real-time, mobile-first payment system built by NPCI. Anyone with a smartphone and bank account can send or receive money instantly — 24/7, free of charge — using a simple UPI ID. Think of it as if Venmo, Zelle, and Apple Pay were built together that work across every bank and every app. A vegetable vendor and a luxury hotel use the same infrastructure. One QR code, one scan, money moves in seconds.

Launched in April 2016, UPI didn’t exist a decade ago. Today, it processes 228 billion transactions worth ~$3.4 trillion annually — more daily transactions than Visa globally. With 491 million users, 65 million merchants, and 49% of the world’s real-time payments flowing through it, UPI isn’t just India’s payment system anymore — it’s a global benchmark.

The financial inclusion story is profound. Before UPI, accepting digital payments required expensive POS terminals and paperwork. Today, a printed QR code costing nothing is all a merchant needs. The chai wallah, the auto driver, the neighbourhood paan shop — they’re all in the formal digital payments ecosystem now.

MDR: The Fee That Was, and the Fight to Bring It Back

MDR — Merchant Discount Rate — is the fee merchants pay to banks for processing digital payments. On credit cards, it’s typically 1.5–3%, split between the acquiring bank, the issuing bank, and the card network. In UPI’s early days, a small 0.3% MDR existed. Then, in January 2020, the government abolished MDR on UPI entirely to accelerate digital adoption. To compensate banks, a subsidy scheme was introduced, peaking at ₹3,631 crore in FY24.

But here’s the problem: as UPI volumes exploded, subsidies shrank. The FY25 allocation dropped to ₹1,500 crore, and FY26 projections suggest as low as ₹437 crore. The industry estimates that ₹10,000 crore annually is needed to maintain UPI infrastructure.

In March 2025, the Payments Council of India — members include Google Pay, Amazon Pay, Razorpay — wrote to the PM seeking a 0.3% MDR on UPI transactions above ₹2,000 for large merchants. Banks argue they incur ~₹2 per UPI transaction in infrastructure costs.

Their concern is legitimate. But their solution is wrong. Here’s why.

The Psychological Devastation of Not Getting 100%

When a small merchant sells goods worth ₹100 and receives ₹100 in their bank account, the transaction feels complete. Tell them they’ll receive ₹99.70 instead, and something breaks — not in the math, but in the mind.

For a chai seller making ₹2 profit per cup, the feeling of not getting 100% of what they earned is visceral. Cash gives them ₹100 for ₹100. If UPI doesn’t, they’ll go back to cash. We’ve spent a decade building digital payment trust among 65 million merchants. Even a small MDR risk could undo years of financial inclusion work — hitting precisely the merchants we worked hardest to bring into the digital fold.

Stop Comparing UPI to Cards. Compare It to Cash.

The fundamental error in the MDR argument: MDR is a card-era concept. Cards involve POS terminals, plastic, credit risk, and global settlement networks. MDR funds all of that.

But UPI didn’t replace cards. UPI replaced cash. The average P2M ticket size is just under ₹600 — that’s a ₹40 chai, a ₹200 vegetable purchase, a ₹150 auto fare. These were 100% cash transactions before. So compare UPI to cash, not to Visa/Mastercard. And when you do, the economics flip completely.

The Hidden Cost of Cash Nobody Talks About

Cash feels “free.” It’s anything but.

The RBI spent ₹6,373 crore printing currency in FY25 alone. Banks and the RBI together spend an estimated ₹21,000 crore annually on currency management — cash-in-transit, vault operations, sorting, soiled-note replacement, and distribution through 4,195 currency chests. ATM infrastructure — 2.5 lakh machines, each costing lakhs to install, maintain, and stock — adds thousands of crores more.

And here’s the kicker: person-to-person cash transactions completely bypass the banking system. When I hand you a ₹500 note, no bank sees it, no record exists, no tax trail is created. UPI transactions, by contrast, are fully traceable. The system that gives banks complete visibility is the one they want to charge for, while the system that makes them invisible remains free.

(A note on the future: CBDC would eventually address P2P cash invisibility, but it’s still in pilot. For now, UPI is our best formalisation tool.)

The IRCTC Paradox

Indian Railways charges a ₹10–20 convenience fee on digital tickets through IRCTC, while physical counter tickets have no surcharge. Think about what that means: the digital ticket — requiring no counter staff, no paper, no queue management — costs MORE. The physical ticket — requiring staffed counters at thousands of stations, printing infrastructure, real estate — is the “free” default.

The cost of dispensing a physical ticket is orders of magnitude higher than a digital one. Yet we penalise digital users. IRCTC earns nearly ₹700 crore annually from this fee — revenue extracted from the very behaviour that saves Railways the most money. This is exactly the kind of backwards incentive structure we must fix across the economy.

The Proposition: Make Cash Expensive, Not UPI

The idea is simple: instead of monetising UPI, monetise cash.

Merchant cash deposit/withdrawal fees: Introduce a small charge — 0.1% to 0.25% — on cash deposits and withdrawals above a threshold for business accounts. This isn’t punitive; it passes through the real cost banks already absorb silently.

ATM withdrawal caps: Set an annual free withdrawal limit — say ₹1 lakh/year for savings accounts. Beyond that, every withdrawal incurs a charge. This preserves access for those who need cash while discouraging habitual usage.

Cross-subsidise UPI: Banks use cash-charge revenue to fund UPI infrastructure — creating a virtuous cycle where cash costs push digital adoption, lowering per-transaction UPI costs and making the ecosystem self-sustaining.

The Benefits

Organic cash discouragement. When accepting cash has a cost and UPI doesn’t, businesses will push customers to go digital without anyone mandating it.

Economic formalisation. More on-the-books transactions mean better tax compliance and reduced black money. India’s tax-to-GDP ratio benefits directly.

Bank windfall. New revenue from cash charges, plus reduced cash management costs, means more investment in digital infrastructure. Banks become beneficiaries of cash’s decline, not victims of UPI’s success.

UPI’s magic preserved. The promise that made a vegetable vendor accept digital payments — ₹100 earned is ₹100 received — stays intact.

Conclusion

When a new technology achieves mass adoption, it should become the default — and legacy practices must be reconsidered, not protected.

India didn’t build the world’s most remarkable payments infrastructure only to burden it with a card-era tax. Cash is the legacy system — expensive to print, store, transport, secure, and invisible to the tax system. It should bear the cost of its own inefficiency.

The future is digital-first. The cost structure should reflect that. Make cash the expensive option, not UPI.

From 17.9 million transactions in 2017 to 228 billion in 2025, UPI has already won. The numbers are settled. Now it’s time our policies caught up — not by taxing the future, but by pricing the past.

If you have a topic that you would like me to write about, do leave a comment.

I came across a paper last week that I haven’t been able to stop thinking about. It’s by a team of MIT and University of Washington researchers — Kartik Chandra, Max Kleiman-Weiner, Jonathan Ragan-Kelley, and Joshua Tenenbaum — titled Sycophantic Chatbots Cause Delusional Spiraling, Even in Ideal Bayesians.

As someone who sits at the intersection of AI and human behaviour — I code four to five hours daily with AI tools, I’ve written about how AI is reshaping engineering careers, interviews, and the Indian IT industry — this paper felt like it was speaking directly to me.

But by the time I finished reading, the feeling had shifted from intellectual curiosity to something closer to unease. Not about what AI can do today, but about what we don’t yet understand about what it’s doing to how we think.

Elon Musk’s reaction to this was characteristically blunt:

He’s not wrong. Let me explain why.

The Paper: What They Found

The researchers studied a phenomenon called “delusional spiraling” — situations where extended conversations with AI chatbots lead users to become dangerously confident in false beliefs. This isn’t hypothetical hand-wringing. The Human Line Project has documented nearly 300 such cases. At least 14 deaths have been linked to it. Five wrongful death lawsuits have been filed against AI companies.

The suspected cause? Sycophancy — the chatbot’s structural tendency to agree with you, validate your opinions, and tell you what you want to hear. This isn’t a bug; it’s a feature that emerges from how these models are trained. Reinforcement learning from human feedback (RLHF) rewards responses that users rate positively, and people tend to rate agreeable responses highly. The result: models that are architecturally biased towards flattery.

Here’s what the researchers did that makes this paper different from the usual AI doom commentary. They built a Bayesian simulation and gave the simulated user perfect rationality — the best possible reasoning an agent could have. Then they ran 10,000 simulated conversations at varying levels of sycophancy. The question was simple: can a perfectly rational person still spiral into false beliefs when talking to a sycophantic chatbot?

The answer is yes. Unambiguously yes.

The mechanism is a feedback loop. You express a tentative opinion. The bot validates it. Your belief strengthens slightly. You express it with more confidence next round. The bot validates harder. Repeat. What starts as a kernel of curiosity hardens into conviction over dozens of exchanges. Some simulated users converged on truth; others spiraled into delusion. The polarisation was driven entirely by the self-reinforcing nature of sycophantic responses.

And the sycophancy rates measured in today’s frontier models? Between 50 and 70 percent. This isn’t a theoretical edge case. It describes the tools we use every day.

Why the Obvious Fixes Don’t Work

The researchers tested two interventions that sound like they should solve the problem. Neither did.

First, they tried making the bot strictly factual — no hallucinations, only true information, with the bot constrained to pick from real data. Think of it as RAG with citations, but still optimised for user engagement. The result: spiraling still happened. The bot didn’t need to lie. It just needed to cherry-pick which truths to present. Selective presentation of facts — lies by omission — was enough to push the user’s beliefs in the wrong direction.

Second, they informed the user that the bot might be sycophantic. The user now actively modelled the bot’s strategy, tried to infer its sycophancy level, and attempted to discount biased responses. This helped. But it didn’t eliminate the problem. The informed user remained vulnerable, especially at moderate sycophancy levels. This result mirrors a classic finding from behavioural economics called Bayesian persuasion: a strategic prosecutor can raise a judge’s conviction rate even when the judge fully understands the prosecutor’s incentives.

Combining both fixes — factual bot plus informed user — still left spiraling rates above baseline. And here’s the counterintuitive twist: the factual sycophant was harder for the informed user to detect than the hallucinating one. Selective truth-telling leaves fewer statistical fingerprints than outright fabrication. The most dangerous liar is the one who only tells you true things.

As Sam Altman noted, and the paper quotes: “0.1% of a billion users is still a million people.”

Why This Hit Home

I’ve been writing about AI’s impact on engineers and professionals for a while now. In Building Your Moat Against AI, I wrote about the “Google Search curse” — how the convenience of looking up answers erodes our reasoning muscles over time. Sycophancy is the next evolution of that same erosion, and it’s far more insidious. Google Search gives you information and lets you reason. A sycophantic chatbot validates your existing reasoning, making you feel smarter while potentially making you less accurate.

In Taking Interviews in the Age of AI, I argued that interviewers should fully allow AI tools during interviews. I still believe that. But this paper forces a harder question: if we spend hours daily in conversation with tools that are structurally biased to agree with us, what happens to our capacity for self-doubt? What happens to the instinct that says, “Wait, let me reconsider”?

In my Indian IT series, I used the “army vs. special forces” framing — arguing that the industry needs independent thinkers, not just executors. Sycophantic AI is the opposite of what produces independent thinkers. It’s a tireless yes-man that makes you feel like a special forces operator while gently guiding you into an echo chamber of one.

And here’s the irony that stings: the more articulate and competent you are in expressing your views to an AI, the more effectively it can validate you into a corner.

Building Your Psychological Moat

Since systemic fixes are provably insufficient, the defence has to be personal. Think of this as building a psychological moat — not against AI replacing you, but against AI flattering you into intellectual complacency.

Treat rising certainty as a warning signal. After any long AI conversation where you feel increasingly sure about something, pause. The paper shows that the spiraling is self-reinforcing — the stronger your conviction grows, the harder the bot validates. In a healthy reasoning process, confidence should increase slowly and with resistance. If it’s increasing smoothly and comfortably, something is probably wrong.

Practice explicit self-criticism. Before accepting an AI-validated conclusion, force yourself to articulate the strongest counterargument. Better yet, ask the AI to argue against the position it just helped you build. Break the feedback loop by deliberately introducing friction into a frictionless process.

Stay curious, not convinced. The people who spiraled in the documented cases started with genuine curiosity but let the AI convert it into conviction. Keep your AI conversations in exploration mode. Ask “what am I missing?” and “who would disagree with this?” more often than “am I right?”

Diversify your interlocutors. The model shows spiraling is worse when the AI is your only source of feedback. Talk to humans who will disagree with you. Read arguments that challenge your priors. The AI is optimised to agree with you; your colleagues and friends are not. That’s a feature of human relationships, not a bug.

Set time boundaries. The documented spiraling cases involved extended, multi-hour sessions. Treat long AI conversations the way you’d treat any echo chamber — with a deliberate exit point. Step away. Come back the next day. See if the conviction survives a night’s sleep and some fresh air.

Watch for the “yes, and” pattern. If your AI conversation feels like an improv scene — where every exchange builds on and amplifies the last — you’re in the feedback loop. A good thinking partner says “yes, but” and “have you considered the opposite?” A sycophant says, “Yes, and here’s even more evidence you’re brilliant.”

A Very Old Problem at Industrial Scale

The paper’s most striking observation is that none of this is new. Shakespeare’s King Lear was flattered into madness by his courtiers. The “yes-man effect” in organisations explains why powerful people lose touch with reality. Among adolescent friends, “co-rumination” — the mutual validation of negative thoughts — drives anxiety and depression. Sycophancy has been a fixture of human social life for all of human history.

What’s new is the scale. AI chatbots are industrialising a very old human vulnerability. Every person with a smartphone now has access to the most patient, articulate, and tireless yes-man ever created — one that never sleeps, never pushes back, and is available around the clock.

I use AI every day. I will continue to. But this paper has changed how I use it — with more deliberate doubt, more friction, and a quiet awareness that the tool designed to help me think might, if I’m not careful, be helping me stop.

If you are interested in any topic and would like me to write a blog post, do share your suggestions in the comments.

Most of us assumed it would be the easiest exam of the semester.

It was the hardest.

The questions were designed so that no book could simply hand you the answer. You had to understand the material deeply enough to know which book to reach for, which page mattered, and how to apply what you found to the specific problem in front of you. Students who didn’t understand the fundamentals wasted precious time flipping through pages, looking for answers that weren’t there in ready-made form. The ones who knew the subject used the books as accelerators — filling in a formula here, confirming an edge case there — while their understanding did the real work.

That professor was testing context, judgment, and applied understanding. Not memory.

Three decades later, most tech interviewers are still designing closed-book exams in an open-book world.

The Arms Race You’ve Already Lost

There are many YouTube Shorts videos making the rounds in which an interviewer, suspicious that the candidate is using AI, asks them to share their screen. The candidate calmly shares it — clean desktop, nothing visible. The interviewer is satisfied. The AI tool was running in stealth mode the entire time.

This isn’t a one-off hack. It’s an industry.

Tools like Final Round AI openly market an “Interview Copilot” that runs invisibly during screen sharing — no pop-ups, no visible interface, works across Zoom, Teams, and Google Meet. LockedIn AI publishes step-by-step guides on using its tool while sharing your screen—second monitors, keyboard shortcuts, and stealth mode. These tools listen to the interviewer’s question in real-time, generate structured answers, and display them where only the candidate can see. They explicitly advertise being “100% undetectable.” Some have over ten million users.

The industry’s response? Share your screen. Enable proctoring. Disable clipboard access. Watch for suspicious eye movement.

This is a surveillance arms race, and the tools are specifically engineered — with millions in funding — to stay one step ahead. You’re spending precious interview time policing the environment instead of evaluating the person.

We don’t ban calculators in finance interviews. We don’t ban IDEs in coding tests. Why are we banning AI?

Flip the Frame: Allow AI. Fully.

Here’s my contrarian take: let candidates use any AI tool they want. Fully. Openly. No restrictions.

Two reasons.

First, AI tools are available on the job. Every engineer you hire will use Copilot, Claude, and ChatGPT daily. Banning AI in interviews evaluates a skill — working without AI — that has zero relevance to how they’ll actually work. You’re testing for a world that no longer exists.

Second — and this is the real insight — allowing AI forces you to design better interviews. Just as my professor’s open-book policy forced him to write questions that tested understanding rather than recall, allowing AI to force interviewers to ask questions that test what actually matters. The quality of your interview goes up, not down.

What Are You Actually Testing?

In an earlier blog, I argued that the software engineering spectrum runs from Business Problem → System Architecture → Software Design → Code Structure → Syntax, and that AI’s capability drops dramatically as you move left on that spectrum. AI excels at syntax and patterns. It struggles with context, trade-offs, and domain judgment.

Your interview should test the left side of that spectrum. Three things matter:

Their experience and its relevance to your context. Have they solved problems in a domain similar to yours? Can they connect their past work to your specific challenges? This is their accumulated context — the moat I wrote about — and it’s exactly what AI can’t fake.

Their problem-solving and decision-making. How do they decompose an ambiguous problem? What trade-offs do they weigh — security versus usability versus speed, build versus buy, abstraction versus simplicity? How do they arrive at decisions under uncertainty? These are incommensurable trade-offs with no textbook answer.

Their fundamentals applied to the domain. Not “explain polymorphism” but “given this lending workflow with these constraints, how would you design the abstraction layer?” Fundamentals aren’t trivia. They’re the lens through which you approach novel, context-rich problems.

What You Don’t Need to Evaluate

Memory of technical concepts. If the answer is one search away, it’s not worth asking. AI is genuinely excellent at syntax and well-defined patterns — so why are you testing candidates on exactly the things AI does best?

Generic questions. “What’s the difference between SQL and NoSQL?” will get the same AI-polished answer from every candidate. You learn nothing. Here’s a simple litmus test: if your question can be answered perfectly by ChatGPT with zero context about your company, your domain, or the candidate’s experience, it’s a bad interview question.

Context Is the Moat — For Interviews Too

In my moat blog, I argued that AI’s context problem is structural and compound: limited knowledge × limited context window × limited ability to transfer tacit knowledge. That same structural limitation is what makes context-driven interview questions AI-proof.

Ask about their specific projects and what they built. “Walk me through the most complex system you designed. What constraints shaped your architecture?” AI can generate plausible architecture descriptions. It cannot fabricate a credible narrative of arriving at one through real constraints.

Probe the hard problems — and why they were hard. “What was the hardest technical problem you solved? What made it hard for you specifically?” The qualifier “for you specifically” is key. The difficulty might have been organisational, domain-specific, or a gap in the team’s skills — deeply contextual, impossible to fake with AI.

Evaluate trade-off decisions with pros and cons. “You chose Kafka over RabbitMQ — walk me through how you evaluated the options.” “You went with microservices for this module but kept that one monolithic — why the asymmetry?” These questions require weighing factors specific to a real situation — exactly where the moat is widest.

Evaluate how they use AI. This is the new competency. Ask them to solve a problem using AI during the interview. Observe the quality of their prompts. How do they decompose the problem for the AI? How do they set guardrails? How do they validate output? How do they iterate when the AI gets it wrong? The engineer who uses AI well is your hire profile now.

The Enhanced Interview

The open-book exam didn’t make things easier. It made them harder — and better. It tested what actually mattered.

We are enhanced by AI. That’s the new reality — the same reality where I advised engineers to use AI as a force multiplier for their careers. The interview process must evolve to match.

Stop policing tools. Start designing context-rich evaluations. The best candidates aren’t the ones who can answer without AI. They’re the ones whose accumulated context — their moat — lets them do extraordinary work with it.

Allow the books. Design better questions.

In my three-part series on Indian IT and the Lost Art of Engineering Excellence, I diagnosed how this approach systematically traded engineering depth for operational efficiency. Those structural choices — from the T&M billing trap to the hollowing out of technical career paths — were rational for an era where the product was hours and the competitive advantage was cost.

The talent pipeline was a commoditisation machine. Mass campus hiring optimised for trainability, not curiosity. Standardised training producing interchangeable “resources.” Skill depth calibrated to project needs — enough to execute, never enough to question. Career paths that pulled anyone with potential out of engineering into management.

The result: a vast middle tier of developers with shallow skills, and a tiny sliver of genuinely deep engineers — most of whom left for startups, GCCs, or product companies that actually valued what they could do.

That era is ending. AI doesn’t just add pressure to this model. It breaks it.

AI: The Multiplier That Divides

The popular narrative says AI boosts developer productivity. This is half-true, and the half that’s missing is the part that matters.

As I argued in Building Your Moat Against AI, software engineering is not “coding.” The real work spans a spectrum: from understanding the business problem, through system architecture and design, down to syntax and implementation. AI’s capability drops dramatically as you move up that spectrum.

A strong engineer uses AI to move 2–5x faster across the full spectrum. AI handles boilerplate while the engineer focuses on context, trade-offs, and architecture — where real value lives. A shallow-skilled developer gets trapped in a different loop. AI generates plausible-looking code, but the developer lacks the depth to evaluate it — the architectural flaw, the missed edge case, the subtle production risk. The productivity gain from faster code generation is consumed by debugging and rework.

AI doesn’t raise the floor. It raises the ceiling — but only for those who were already near it. It’s a skill amplifier, not a skill equaliser.

The Tool Fallacy

This is where many IT services companies are making a costly mistake. They’re rolling out AI coding tools — Copilot, CodeWhisperer, internal platforms — across their engineering workforce, expecting an automatic productivity boost. Some are even measuring tool adoption rates and usage metrics, as if the number of AI-generated suggestions accepted is a meaningful indicator of value.

It isn’t. Giving a shallow-skilled developer an AI coding assistant is like giving a student driver a Formula 1 car. The tool doesn’t compensate for the missing judgment — it amplifies the consequences of its absence. More code generated faster means more bugs shipped faster, more architectural debt accumulated faster, and more production issues created faster.

Measuring tool usage makes this worse. It incentivises acceptance of AI suggestions regardless of quality — the same pattern that turned “Agile transformation” and “DevOps adoption” into process theatre at most IT services firms. The metric becomes the goal, disconnected from the outcome it was supposed to represent.

The right question isn’t “are your developers using AI tools?” It’s “Do your developers have the depth to use AI tools effectively?” For most of the commoditised talent pool, the honest answer is no.

The Army Becomes a Liability

If 5 strong, AI-augmented engineers can deliver what 25 average engineers delivered before, the mathematics of T&M billing collapses. The “bench strength” model — talent as inventory — becomes dead weight.

Indian IT’s vulnerability runs deeper. The industry has a missing generation of deep technical practitioners. The management layer can’t evaluate AI-generated code. Junior developers can’t course-correct it. The “architects” who stopped coding years ago lack the hands-on fluency to guide AI tools productively. This isn’t a skills gap. It’s a judgment gap — and no amount of tool deployment or adoption metrics will close it.

David Eats Goliath

Small and mid-tier IT firms that pivot to the special forces model will start capturing revenue that currently flows to the big players. They don’t have 200,000+ employees to restructure. They can adopt outcome-based pricing without cannibalising a massive T&M base. They can attract strong engineers by offering ownership and a craft-first culture.

A mid-tier firm with 50 exceptional, AI-augmented engineers can compete with a large firm’s 500-person engagement — at lower cost, with better results. The revenue shift starts one deal at a time, but it compounds. As smaller firms build track records, the talent follows, creating a flywheel that large firms will find very hard to reverse.

There’s a model for what this looks like. Palantir’s Forward Deployed Engineers — small teams of elite engineers embedded with clients, measured on outcomes, not hours — helped build a company now worth over $400 billion. The directional signal is clear: the future belongs to small, deeply skilled teams delivering outcomes, not large teams billing time.

The Mercenary Option

Most large IT firms cannot build a premium talent pool fast enough. The deep engineers they need are scarce, expensive, and don’t want to work in traditional IT services structures.

The alternative: a mercenary model. Highly skilled senior engineers engaged on a gig or fractional basis, deployed for the hard problems. Not traditional subcontracting — which in Indian IT usually means sourcing even cheaper labour — but the opposite: paying a premium for engineers with demonstrated depth and the ability to wield AI effectively.

These engineers bring the contextual judgment that AI cannot replace. They mentor existing teams. They solve the missing middle problem immediately, without a decade of transformation. And the cost, while high per individual, is far lower than failed deliveries and lost deals.

Indian IT firms must overcome two cultural barriers: seeing external talent as a capability multiplier rather than a cost threat, and accepting that individual engineers might earn more than delivery managers. But the mercenary model also creates a pipeline — some of these engineers, if the environment genuinely changes, may convert to permanent roles.

Build, Borrow, Learn

The new talent strategy has three paths, pursued simultaneously.

Build — hire fewer, stronger engineers. Pay them more. Create real technical career tracks. Make it possible for an engineer to have a fulfilling career without ever becoming a manager.

Borrow — the mercenary model. Elite engineers on fractional engagements for immediate capability and to set standards.

Learn — adopt the forward-deployed mindset. Small, empowered teams. Outcome-based delivery. Engineers who own problems end-to-end.

This replaces the hire-train-deploy commodity pipeline with something harder to build but far more defensible. And it demands that leadership stop treating AI tools as a magic productivity switch and start investing in the engineering depth that makes those tools actually work.

The army era is ending. The special forces era has begun. The question isn’t whether this transition will happen — it’s whether the incumbents will lead it or be disrupted by it.

This post builds on my series on Indian IT and the Lost Art of Engineering Excellence and Building Your Moat Against AI.

The short version: the biggest risk in AI adoption isn’t the technology.

It’s the context gap.

The AI Tooling Fantasy

Every AI coding tool demo follows the same script. A developer types a comment, AI generates a function, tests appear, and code reviews happen automatically. Someone pastes “40% productivity improvement” on a slide deck.

The demo always works. But the code being generated has no history — no legacy constraints, no regulatory guardrails, no battle scars from that production incident three years ago that shaped half your architecture.

The demo is a greenfield fantasy. Your codebase is not.

The Contexts AI Doesn’t Have

A senior developer looking at your codebase doesn’t just see code. They see layers of context that took years to accumulate. AI sees none of it.

Domain rules. A lending platform is not an e-commerce site. When your loan management system handles a prepayment calculation in a particular way, it’s not because that was the most elegant solution. It’s because your teams collectively arrived at that interpretation after months of deliberation. AI will happily suggest a cleaner implementation that violates a regulatory constraint it has never heard of.

The technical debt map. Your senior developers know which module is solid and which is a house of cards. AI doesn’t have this map. It’ll refactor code in a module everyone knows you touch only after extensive regression testing — walking into the minefield with the confidence of someone who has never seen an explosion.

Institutional memory. Why does that redundant null check exist? Because of the vendor API that sends malformed responses at the month-end. The codebase is full of decisions that look wrong until you understand the context. AI sees “wrong” code and fixes it. The fix removes the safeguard.

Code tells you what. It rarely tells you why. AI reads your codebase as-is, misses the decision trail, and confidently “fixes” things that were deliberately left imperfect. It cleans up a workaround, and the next month-end batch fails. It removes “redundant” validation, and corrupted data flows downstream. AI solves a small problem by creating a bigger one.

AI cannot Architect

This point gets lost in the productivity narrative. Architecture is the art of choosing what to sacrifice — consistency vs. availability, speed vs. maintainability, build vs. buy. These aren’t puzzles with correct answers. They’re bets that depend on your team’s capabilities, your regulatory timeline, your budget, and a dozen factors outside the codebase.

AI can generate options and articulate theoretical tradeoffs well. What it cannot do is make the call: “Given that we need this in four weeks, with a team strong in Java but weak in event-driven patterns, facing an RBI compliance deadline in Q3, we should go with option B even though A is architecturally purer.”

Architecture is organizational decision-making expressed through technology. AI doesn’t do organizational decision-making.

The Last Bug Problem

Here’s a truth that productivity metrics ignore: building a feature might take three days. The last bug in that feature might take five.

AI accelerates the predictable 80% — scaffolding, boilerplate, well-understood patterns. But it’s often useless in the unpredictable 20% where debugging requires reasoning across layers, reproducing edge cases, and understanding system history. AI suggests fixes for symptoms. It rarely understands the disease.

The 40% productivity number is real for the easy part. Nobody’s measuring the hard part.

Not All Code Carries Equal Risk

A senior developer instinctively spends three hours on fifty lines of payment reconciliation logic and twenty minutes on a CRUD screen. That’s not inefficiency — it’s risk calibration. The payment logic handles real money and audit trails. The CRUD screen displays data.

AI doesn’t have this calibration. It applies the same confidence to both. Organizations that let AI move at uniform speed across the entire codebase are setting themselves up for failures in exactly the places that hurt most. The CRUD bug is a support ticket. The payment reconciliation bug is a regulatory incident.

Humans allocate attention based on consequence. AI allocates attention based on token prediction. These are not the same thing.

The Deskilling Trap

When junior developers rely on AI from day one, they never build the mental models that make senior developers valuable — debugging intuition, system thinking, understanding why code is shaped the way it is. AI-generated code works, tests pass, the PR gets approved. But the developer can’t explain the design choices, can’t reason about failure modes, and can’t modify it confidently when requirements change.

You save six months of onboarding today. You lose a generation of architects tomorrow.

The Vibe Coding Danger

“Vibe coding” — describing what you want in natural language and letting AI generate everything — takes every risk in this post and amplifies it. AI cannot architect? Vibe coding hands it the architecture decisions entirely. No risk calibration? Vibe coding doesn’t distinguish between a payment engine and a settings page. The deskilling trap? Vibe coding is deskilling on fast-forward.

For a side project, vibe coding is fun. For a production codebase with real users, real money, and real regulatory obligations, “it works, and I don’t know why” is not an acceptable state. It’s a liability waiting to be called in.

Vibe coding optimizes for the moment of creation and ignores the lifetime of maintenance. Someone has to debug it at 2 AM. Someone has to explain the calculation to an auditor. That someone won’t be able to, because nobody ever understood the code.

The Adoption Curve Nobody Talks About

In my experience, AI adoption follows a predictable three-phase curve that nobody in the vendor ecosystem has any incentive to discuss.

Phase 1: The Sugar Rush. The first few weeks are magical. Developers love the autocomplete. Simple tasks get faster. Quick wins pile up. Management starts projecting ROI numbers.

Phase 2: The Valley of Context. Around month two or three, the problems surface. AI-generated code causes subtle production bugs. A refactoring suggestion breaks something that “shouldn’t” have been affected. A junior developer ships AI-generated code that nobody fully understands, and when it fails, debugging takes longer than writing from scratch would have. The productivity gains shrink. Some developers start ignoring AI suggestions entirely.

Phase 3: Productive Integration. The mature teams land here — if they make it through the valley. They’ve learned where AI helps and where it doesn’t. They’ve built guardrails. They use AI for the 80% where context matters less and keep humans in control of the 20% where it matters most.

Most organizations stall in the valley. They either retreat (”AI didn’t work for us”) or push through blindly without adjusting. Both are failures — one of adoption, the other of judgment.

What Gets You Through

Start with context-light tasks. Boilerplate, test scaffolding, documentation, and simple refactoring. These are tasks where AI’s lack of context matters least, and its speed advantage matters most. Build confidence here before expanding the scope.

Build the context layer. This is the investment most organizations skip and the one that matters most. Architecture Decision Records that explain why. Decision logs capturing rejected tradeoffs. Domain glossaries translate business concepts into technical terms. Make your institutional memory machine-readable — your new hires need it today, and your AI will need it tomorrow.

Treat AI as a junior developer who joined yesterday. You wouldn’t let a day-one hire push to production or redesign your payment pipeline. You wouldn’t skip code review because they’re “really good.” Apply the same judgment to AI-generated code. Review everything. Question the assumptions. Verify the edge cases.

Risk-weight AI involvement. High autonomy on admin screens and utility functions. Human-in-the-loop on payment logic, regulatory calculations, and security-sensitive code. Create a clear classification and stick to it.

Invest in developer fundamentals alongside AI tooling. This is the deskilling antidote. Pair programming with AI is fine. But pair programming with humans is still irreplaceable for building the judgment that AI can’t teach.

The Case for Optimism — Done Right

I want to be clear: this piece is not anti-AI. The productivity benefits are real — faster prototyping, better test coverage, reduced boilerplate drudgery, democratized access to patterns and best practices. These are genuine, significant improvements.

But the organizations that will extract the most value are not the ones that adopt AI fastest. They’re the ones that adopt it most deliberately — with clear-eyed understanding of the context gap, with protective investment in their talent pipeline, and with the discipline to keep humans in the loop where judgment matters.

The vendor pitch: “AI writes the code, developers move to higher-level work.” The reality is more nuanced: “AI accelerates the parts where context matters least, freeing developers to spend more time on the parts where context matters most.”

That’s a less exciting story. But it’s a true one. And the organizations that build their adoption strategy around the true story — rather than the fantasy — will be the ones that actually capture the value.

The moat isn’t the AI tool. Every organization will have access to the same capabilities.

The moat is in knowing where to point it.

Companion piece to Building Your Moat Against AI: A Software Engineer’s Guide.

After both conversations, one question kept nagging me: if AI is coming for software engineering work, what should engineers actually do about it?

My answer is a single word: context. Context is the moat. It is the thing AI fundamentally struggles with, and the thing experienced engineers accumulate over years without even realising they’re doing it.

Software Engineering Is Not “Coding”

The conversation about AI replacing engineers fixates on coding — writing lines of code, generating functions, and autocompleting syntax. This reveals a profound misunderstanding of what software engineers actually do.

The real work spans a much wider spectrum:

Business Problem → Functional Solution → System Architecture → Software Design → Code Structure → Syntax & Implementation

At the left end, you’re understanding what needs to be solved and why — market pressures, regulatory constraints, what users actually struggle with. You’re translating that into workflows, edge cases, and system boundaries. At the right end, you’re writing lines of code in a specific language and framework.

Here’s the crucial insight: AI’s capability decreases dramatically as you move left. At the syntax level, AI is genuinely excellent. At the business problem level, it’s essentially useless without heavy human guidance. Most commentary about AI replacing programmers focuses on the rightmost two layers. That’s a dangerously narrow view.

Context Is Bigger Than You Think

Why does AI struggle with the left side? Because it’s context-heavy. And context is a much bigger concept than most people realise.

Context is not just about the specific problem you’re solving right now. It’s the accumulated reservoir of everything an engineer has absorbed over years — domain knowledge, past failures, architectural patterns that worked and ones that didn’t, intuitions about where complexity hides, and the hard-won wisdom of having been wrong before.

Domain context — understanding not just the requirements but why they exist. If you work in lending, it’s knowing the gap between how a policy is written and how exceptions are actually handled.

Architectural context — knowing why the system is shaped the way it is, what trade-offs were made, what technical debt was deliberately accepted, and why.

Design context — understanding what needs to be flexible versus fixed, which requires business intuition, not just technical skill.

Organisational context — team capabilities, deployment constraints, compliance requirements that never appear in architecture diagrams.

Historical context — the accumulated wisdom from every production incident, every migration that went sideways, every “simple” feature that turned into a six-month project.

When a senior engineer says “this feels like it’ll break in production,” they’re not guessing. They’re drawing on a vast, mostly unconscious pattern library built over the years. This is nearly impossible to transfer to an AI.

AI’s Context Problem Is Structural

I want to be precise about this because too many people dismiss it by saying “just wait until context windows get bigger.” AI’s context problem is structural and compound at multiple levels.

AI’s knowledge boundary. Models are trained on public code and docs. But your business domain, your system’s quirks, your organisation’s constraints — none of that is in the training data.

The context window limitation. Even at a million tokens, you cannot paste the totality of a real system — millions of lines of code, years of decisions, regulatory documents, undocumented institutional knowledge — into a prompt.

The human bottleneck. AI is only as good as the context you give it. But humans are terrible at articulating tacit knowledge. The design instinct, the architectural smell, the sense that an approach will create problems six months from now — you can’t prompt what you can’t articulate.

These limitations multiply each other. Limited knowledge × limited window × limited ability to transfer tacit knowledge = AI that’s excellent at syntax but frequently wrong on substance.

Where the Moat Is Widest: Trade-off Decisions

If context is the moat, complex trade-offs are where it’s widest. Software engineering is fundamentally a discipline of trade-offs, and these require weighing incommensurable factors.

Security versus usability versus development speed — how much friction do you add to reduce attack surface? How much security can you defer to meet a launch deadline? There’s no formula. It depends on the threat model, the user base, the regulatory environment, and the business’s risk appetite.

Build versus buy versus open-source — this looks like a technical decision, but it’s really a business one. It depends on team skills, timeline, vendor dependency tolerance, and long-term product vision. Abstraction versus simplicity — over-abstracting is as dangerous as under-abstracting, and knowing which way to lean requires understanding how much and in which dimensions the system will change, which is business intuition, not technical knowledge.

Short-term delivery pressure versus long-term technical health — sometimes you take on debt deliberately because the business needs the feature by Friday; sometimes you push back because the debt will cripple velocity for two quarters. Knowing when to do which is a contextual skill.

Ask any AI about microservices versus monoliths, and you’ll get a thorough, balanced, textbook answer. But you don’t need a textbook answer. You need the right answer for your situation — your team’s maturity, your operational capabilities, your domain complexity. That contextual judgement is where experienced engineers are irreplaceable.

Be Honest About Where AI Excels

AI is genuinely good at syntax generation, boilerplate, well-defined patterns, refactoring within bounded scope, test generation with explicit expectations, and language translation. Engineers who operate only at the syntax level are genuinely at risk. That’s not a reason to panic — it’s a reason to grow.

How to Build Your Moat

Go deep into a domain. Don’t just write code for banking — understand credit risk, regulatory reporting, settlement cycles. Don’t just build healthcare software — understand clinical workflows and the gap between how systems are designed and how they’re actually used at 2 AM.

The engineer who understands the domain will always out-architect the one who doesn’t, regardless of their AI tools. Domain expertise is among the hardest forms of context to acquire and the most valuable to possess.

Develop trade-off judgement. Seek out messy, ambiguous problems where requirements are contradictory, and there’s no obviously right answer. That’s where contextual judgement is built — slowly, one hard problem at a time.

Build tacit knowledge deliberately. Work on complex systems end-to-end. Volunteer for the migration project. Debug the mysterious production issue. Every one of these experiences deposits context that AI cannot acquire.

Move left on the spectrum. If you spend most of your time at the syntax layer, push yourself toward design, architecture, and business problem understanding. The further left you operate, the wider your moat.

Be the context bridge. The most valuable engineer translates fluently between business stakeholders and technical systems. This is deeply human, deeply contextual, and deeply resistant to automation.

Use AI as a force multiplier. Let AI handle boilerplate while you invest freed-up time into context-rich work. Engineers who wield AI well while deepening their context will outperform everyone else.

What This Means for the Industry

For IT services companies selling engineering capacity, the pressure is real. If AI generates code faster and cheaper, “lots of engineers who can write code” loses its value. The opportunity lies in moving toward context-rich work: domain consulting, architecture advisory, and system modernisation requiring deep institutional knowledge.

For entry-level engineers, the on-ramp looks different now — less syntax drilling, more domain immersion and system thinking from day one. The career is far from dead, but the path has changed.

And for experienced engineers, your accumulated context has never been more valuable. The irony of the AI age is that it makes human experience more important by automating the commodity work and putting a premium on judgment

.

Conclusion

AI is getting remarkably good at writing code. It is not getting good at context — and that gap is structural, not temporary. It stems from the fundamental nature of what context is: tacit, experiential, organisational, historical, and deeply personal. It’s the kind of knowledge that can’t be pasted into a prompt because the person who holds it often can’t fully articulate it themselves.

The moat isn’t about competing with AI on speed or syntax. It’s about being the person who knows what to build, why to build it, and how to make the hundreds of trade-off decisions that shape a real system.

Your years of experience, your domain knowledge, your battle scars from production — that’s not obsolete. That’s your moat.

Build it deeper.

The problem isn’t batch processing. It’s how we’ve architected it.

The Monolith Problem

Picture a typical EOD run. The system goes into maintenance mode. A massive job kicks off—processing loans sequentially, one after another. Nothing else can touch the database until it’s done. Operations teams watch dashboards nervously. If something fails at record 50,000 of 200,000, decisions must be made. Restart from scratch? Skip and reconcile later?

This isn’t a technology limitation. It’s an architectural choice made decades ago when compute was expensive and sequential processing was the only sensible option.

That world no longer exists.

Reframing the Batch

The shift isn’t from batch to real-time—that’s a false dichotomy. Settlement will remain T+1. Regulatory reports will still have cut-off times. Interest will still be calculated at day-end.

What changes is the batch's internal architecture.

Instead of a monolithic job that does everything, the batch scheduler becomes an event emitter. It fires one event per unit of work—per loan, per account, per transaction. A pool of event processors picks these up in parallel, each locking only the specific entity it’s working on.

The system stays up. Users can query their accounts. Only the record being processed is momentarily locked.

Event Pipelines and Chaining

Real-world EOD processing isn’t a single operation. For a loan, you might need to calculate interest, apply fees, check for penalties, update balances, and generate statement entries. In the monolithic world, this is one giant sequential job.

In an event-driven architecture, it becomes a pipeline. The scheduler emits a “process-loan-eod” event. The interest processor picks it up, calculates, and emits “interest-calculated.” The fee processor listens for that event, does its work, and emits another. The pipeline flows—parallel where possible, sequential where business logic demands.

Each processor is focused, testable, and independently scalable. If the fee calculation becomes a bottleneck, scale that component. The rest of the pipeline doesn’t care.

Complex Event Processing

Beyond simple event chaining lies pattern detection. A Complex Event Processing layer monitors the event stream, looking for conditions that emerge from combinations of events.

A single transaction isn’t suspicious. But three large withdrawals across related accounts within an hour? The CEP engine spots this pattern and emits an alert—while the core processing continues uninterrupted.

This is intelligence layered onto the pipeline, not embedded within it.

Event Store and Event Logging

Events aren’t just messages that disappear after processing. They’re facts that must be persisted.

The event store becomes your system of record—every event captured with its full payload, timestamp, and correlation ID. When auditors ask, “What happened to this account on March 15th?” you replay the events. When something goes wrong, you have complete lineage.

Equally important is tracking the event lifecycle. Each event moves through states: Published, Acknowledged, Processing, Processed, Failed. This isn’t bureaucratic overhead—it’s operational visibility. Dashboards show batch progress in real-time. Failed events are isolated, investigated, corrected, and refired without rerunning the entire batch.

Idempotency becomes critical here. A refired event must produce the same outcome as the original. Design for this from day one.

Distributed Locking and Concurrency

The magic of keeping systems available during batch processing comes down to one principle: lock only what you’re touching.

Fine-grained locking at the entity level—using distributed lock managers like Redis or ZooKeeper patterns—replaces system-wide shutdowns. Lock timeouts prevent deadlocks. Optimistic locking works where contention is low; pessimistic locking works where it isn’t.

This is where architecture becomes engineering. The patterns exist. The discipline to implement them correctly separates systems that scale from systems that struggle.

The Payoff

What does this buy you?

Maintenance windows shrink or disappear. Batch processing time drops—parallel processing with 50 workers beats sequential processing by a factor that compounds with volume. Failed transactions are isolated rather than blocking everything behind them. Scaling becomes horizontal—add processors, not bigger servers.

And critically: you have a complete, auditable, replayable record of everything that happened.

Financial services will always have batch requirements. The question isn’t whether to batch—it’s whether your batches are designed for the infrastructure realities of today or the constraints of thirty years ago.

Event-driven architecture doesn’t eliminate batches. It makes them modern.

The diagnosis is complete. Now the harder question: What would transformation actually require?

This isn’t about restating problems. It’s about fundamentals — what must change across three dimensions: Product, Process, and People.

Product: What Should Indian IT Actually Be Selling?

Here’s the root question: What exactly is the product of an IT services company?

Currently, the answer is time. Hours. Bodies. “Resources.”

This is the fundamental problem. When you sell time, productivity is your enemy. Engineering excellence becomes overhead. The incentive is to take longer, not to be better.

The shift required:

From time to outcomes. Clients don’t want hours — they want problems solved. Outcome-based models change everything: fixed price for deliverables, gain-sharing on business impact. If you’re paid for outcomes, productivity becomes your friend.

From talent to capability. Talent is a commodity. Capability is differentiated. Capability means talent plus methodology plus tools plus accumulated IP. One team with genuine capability delivers what five teams without it cannot.

From execution to expertise. Execution can be automated and commoditised further. Expertise commands a premium. Deep domain knowledge combined with technical depth creates a defensible position. Be the company clients call when the problem is hard, not when the budget is tight.

The implications: outcome-based pricing demands engineering excellence to deliver profitably. R&D becomes a strategic necessity. Revenue per employee matters more than headcount.

Process: Rethinking How Software Gets Built

From phase-gate to continuous. Waterfall mindset persists even when we call it “Agile.” True engineering means continuous integration, delivery, and feedback. Quality built in, not bolted on.

From functional to non-functional parity. Performance, security, and scalability cannot be “phase 2” concerns. Phase 2 never comes. These must shape architecture from day one.

From defect counting to technical health. Bug counts and test coverage are poor proxies for quality. What’s missing: technical debt ratio, maintainability, deployment frequency, mean time to recovery. We’re measuring the wrong things.

From process theatre to genuine practices. Code reviews that actually improve code. Architecture reviews led by people who still understand code. Automation as default.

Developer experience as a multiplier. Modern tooling, CI/CD pipelines, and AI-assisted coding. Access to open source — treat it as leverage, not risk. Kill the VDI. Give engineers environments that amplify productivity.

None of this is revolutionary. Product companies have operated this way for years. The question is whether IT services can adopt these practices when their business model has historically worked against them.

People: Building True Engineering Capability

This is the hardest part. Where do you start when leadership can’t code, and middle management has forgotten how?

First, acknowledge the gap. You cannot lead what you don’t understand. Process and metrics are poor substitutes for genuine technical judgment.

The foundation: Individual contribution and demonstrated depth

Engineering excellence is ultimately individual. It shows up in the code, the design, the solution. Organisations don’t write code — people do.

Individual contribution must be visible and valued at every level. Not just “who delivered the project” but “who solved the hard problem, who wrote the elegant solution.” This visibility should extend from the trainee engineer to the CTO.

Demonstrated depth must matter more than claimed expertise. Certifications prove you passed a test. Open source contributions prove you can build. A GitHub profile, technical blogs, conference talks — these demonstrate depth in ways credentials cannot.

Open source deserves special emphasis. Contributing forces you to write code that others will judge. It builds a reputation beyond organisational hierarchy. It keeps skills current. Make it part of how you evaluate engineers — not extracurricular, but core to being an engineer.

Most importantly, leaders must demonstrate, not just delegate. A CTO who hasn’t committed code in a decade cannot credibly judge technical quality. “I used to code” is not “I still understand code.”

Building technical leadership:

Grow from within. Identify engineers with depth and leadership potential. Look for demonstrated contribution: open source, internal tools, complex problems solved. Make Distinguished Engineer a real role with real prestige — not a consolation prize.

Acquire from outside. Hire technical leaders from product companies. Look for what they’ve built and contributed. Accept the culture clash — that’s the point.

Upskill selectively. Not everyone can reskill. For those who can: real technical work, not certificates. The test: can they review code with substantive feedback?

Restructure. Small, empowered teams with embedded technical leadership. Technical decisions made by technical people.

Building culture: Hire for curiosity and craft — look for side projects and contributions. Create forums for technical work to be visible. Celebrate engineering achievements. Make it acceptable to say “this code is not good enough.”

The Transformation Sequence

You can’t change everything at once. Attempting organisation-wide transformation typically fails — too many antibodies, too much inertia. A more realistic approach:

Start with a beachhead. One business unit, one practice area, one client engagement willing to try outcome-based pricing. Ring-fence it from the rest of the organisation. Give it room to operate differently.

Staff it differently. Technical leadership with demonstrated depth — people who’ve built things, contributed to open source, and earned technical credibility. Engineers who care about craft and want to work this way. This team must be genuinely different, not just relabelled.

Invest in tooling and process. Modern SDLC, genuine developer experience, quality practices that measure what matters. This is where you prove that engineering productivity beats operational efficiency.

Make the contribution visible. Encourage open source participation, internal tools, and technical content. Measure and celebrate individual technical contributions. Create the culture you want to scale.

Demonstrate results. Delivery quality, engineer retention, client satisfaction, and profitability. Build hard evidence that this model works. Numbers matter when convincing skeptics.

Expand gradually. Use proof points to make the internal case. Let success create demand. Engineers elsewhere will see what’s possible and want to be part of it. Scale what works; don’t mandate what hasn’t been proven.

What leadership must accept: Short-term revenue disruption is likely. Some existing clients won’t pay for outcomes — let them go. Some managers won’t adapt — hard decisions required. Your own technical depth will be exposed — lead the re-skilling by example. Transformation takes years, not quarters. But the alternative is managed decline.

Who Can Drive This?

From inside: Technical leaders with demonstrated depth and board support. Engineers with visible contributions who’ve earned credibility.

From outside: Clients demanding outcomes. Talent attrition is forcing introspection. AI is making the volume model obsolete.

The uncomfortable truth: Large incumbents face the innovator’s dilemma. Transformation may come more easily to mid-sized firms and new entrants. Some companies will transform. Many will manage decline.

What Individual Engineers Can Do

Don’t wait for the industry to change.

Build demonstrated depth: contribute to open source, write about what you learn, build side projects, speak at meetups. Your GitHub profile and contributions travel with you.

Seek environments where contribution is visible and valued. Be the technical leader you wish you had. If your environment won’t let you contribute meaningfully, find one that will.

The best engineers have options. Build yours through demonstrated excellence.

Closing Reflection

The original model was brilliant for its time. It created an industry, employed millions, and transformed India’s economy.

But the world has changed. Cloud, automation, AI — the volume model faces existential pressure.

Engineering excellence is no longer a luxury. It’s survival.

And excellence is ultimately individual. It shows up in the code, the architecture, and the solution. Organisations that want excellence must create environments where individual contribution is visible, valued, and rewarded.

The proof that Indians can build world-class technology exists. UPI. Zerodha. Zoho. The talent exists. The capability exists.

The question is whether the IT services industry can create environments where that excellence can flourish. Whether leaders will invest in genuine technical depth, starting with themselves.

For those willing to change: the path is hard but clear.

For those who aren’t: the market will decide for them.

The talent exists. The capability exists. Does the will?

This concludes the three-part series. Part 1 examined the crisis. Part 2 traced the causes. Part 3 outlined the path forward.

If these ideas resonated — or provoked disagreement — I welcome the discussion.

So if not talent, then what?

The answer lies in the structural choices made over the past three decades. Choices that, collectively, optimised against engineering excellence. Before we examine these factors, we need to define what we lost.

What Engineering Excellence Actually Means

Engineering excellence isn’t about using the latest frameworks or having impressive certifications. It’s about:

• Technical depth — Understanding fundamentals, not just tool familiarity

• Craft and quality — Code that is maintainable, readable, built to last

• Sound architecture — Systems designed for change, scale, and resilience

• Engineering productivity — Delivering more value through better tools, practices, and design

• Developer experience — Environments that amplify engineers rather than hinder them

• Technical leadership — Engineers who shape decisions, not just execute them

• Continuous improvement — Relentless pursuit of better ways to build

This is what separates technology leaders from followers. It’s what allows small teams to outperform large ones. It’s what every successful Indian technology company in Part 1 had in common.

And it’s what Indian IT services systematically traded away.

The Fundamental Misunderstanding

Indian IT made a critical error early on: it applied manufacturing principles to software development.

Treat engineers as interchangeable units. Standardise processes. Minimise variation. Optimise for predictability. This works brilliantly for assembling cars or electronics.

But software is fundamentally different. Manufacturing is about replication; software is about creation. In manufacturing, variation is the enemy; in software, every problem is unique. Manufacturing scales by adding capacity; software scales by better design.

Most importantly: a factory worker’s output is linear. An engineer’s output is not. The best engineer isn’t 10% better than average — they can be 10x better. But only if the system lets them be.

We built systems that didn’t let the engineer leverage non-linear productivity.

Operational Efficiency vs. Engineering Productivity

Here’s where the misunderstanding became costly.

Operational efficiency asks: How do we maximise billable hours? Improve utilisation rates? Reduce cost per hour?

Engineering productivity asks: How do we maximise value delivered? Reduce complexity? Improve cost per outcome?

Indian IT mastered operational efficiency. We squeezed 10% more out of existing approaches through process improvements and “lean” initiatives.

But we ignored engineering productivity — where 2x or 10x improvements were possible through better tooling, automation, and architecture. The former just requires tighter management. The latter requires engineering excellence.

We got very good at the wrong optimisation.

The Seven Structural Factors

1. Project Management Ate Engineering

Software development became a logistics problem, not an engineering discipline. Success meant hitting delivery milestones, not building quality solutions. PMO culture dominated; engineering culture atrophied.

Career paths led away from code. If you’re still coding at 35, something “went wrong.” The message was clear: management is the destination, engineering is just the starting point.

This created a deeper problem. In most industries, leadership grows from practitioners who mastered the craft. FMCG leaders typically started in sales, understanding customers firsthand. Automobile executives often began in engineering divisions. They speak the language of their industry because they live it.

Indian IT grew differently. Many leaders rose through project management, client management, or business development — some never wrote production code. And technology changes fast. Leaders who coded in the client-server era have little intuition for cloud-native development. Even those with technical backgrounds often didn’t keep pace as the craft evolved.

The result: strategic decisions made without a deep understanding of what’s being decided. Over-reliance on process and metrics as proxies for technical judgment. This isn’t about blame — it’s a structural gap that shaped the industry’s trajectory.

2. The T&M Business Model Trap

When revenue is tied to hours billed, productivity becomes the enemy.

Solve a problem faster? Less billing. Automate a repetitive task? Eliminate future revenue. Build a reusable component? Cannibalise next quarter’s project.

T&M doesn’t just fail to reward efficiency — it actively punishes it. Why invest in engineering productivity when more hours equal more revenue?

Over decades, this shapes culture in ways that become invisible. The incentives seep into every decision, every project structure, every career choice.

3. The Hollowing Out of Technical Career Paths

The best engineers got “promoted” — out of engineering.

Technical career tracks were either absent or dead-end. “Architect” became a title given to those who stopped coding years ago, not a practice requiring hands-on technical judgment.

The result: a missing middle. Managers who allocate resources but can’t evaluate designs. No one left to mentor junior engineers or demand technical rigour. Architecture reviews became process theatre rather than genuine technical governance.

4. Quality Reduced to Checkbox Compliance

Quality became a numbers game. Defect density. Test coverage percentages. SLA compliance. These became proxies for actual quality.

What didn’t get measured: technical debt accumulation, code maintainability, architectural fitness, and long-term sustainability. If the metric looked good, the box got checked.

Non-functional requirements fared worse. Performance, scalability, security, observability — these became “phase 2” concerns. Phase 2 rarely came. Systems that demoed well struggled in production. “We’ll optimise later” — later never arrived.

The cost of fixing issues in production far exceeds building them right. But that cost didn’t show up in the metrics anyone tracked.

5. Developer Experience Ignored

The engineers’ working environment was an afterthought.

VDI infrastructure that made developers wait minutes for basic operations. Restricted access to open source tooling — the very tools powering modern development. Locked-down environments citing “client constraints” and “security requirements” that were often self-imposed and never challenged.

While startups gave engineers MacBooks and autonomy, IT services gave them virtual desktops and ticket-based tool requests. The message was clear: developer productivity doesn’t matter, only compliance does.

The irony: constraints meant to ensure security often led to shadow IT and worse security outcomes.

6. Talent as Inventory

The language tells the story: “resources,” “bench strength,” “utilisation.”

Engineers managed like warehouse capacity, not craftspeople. Career development focused on certifications — easy to measure — rather than craft and depth, which aren’t. Training meant compliance, not genuine capability building.

Hiring optimised for volume, not potential. The engineers who cared about craft? Many left for startups, product companies, or opportunities where engineering excellence mattered.

7. Scale Through Commoditisation

The playbook was simple: hire graduates in volume, train them in standardised processes, and deploy at arbitrage rates.

The hidden assumption: value lies in the hours, not the expertise. R&D investment stayed minimal — why invest when billing hours is the product? No incentive to build IP, platforms, or differentiated capabilities. Open source contribution was seen as a waste, not an investment.

Built for arbitrage, not differentiation. When clients needed bodies, this worked. The game has changed.

The Reinforcing Cycle

These factors don’t exist in isolation — they compound each other.

Project management dominance leads to T&M models (easy to measure). T&M removes productivity incentives. Without incentives, developer experience gets ignored. Technical career paths hollow out. Quality becomes checkbox compliance. Talent gets treated as inventory. Margins fall as work commoditises. Cost pressure increases. The response: double down on utilisation.

The cycle continues.

This is why incremental fixes don’t work. Address one factor while the others remain, and nothing changes. Short-term pressures always defeat long-term transformation. And the people who might drive change have often already left.

The Tragedy of Good Intentions

These choices weren’t made by fools. They were rational responses to the market of that era.

Labour arbitrage was a genuine competitive advantage. Predictability and process maturity won contracts. Scale was a differentiator when clients needed volume. The manufacturing analogy worked when the work was more routine.

But the context changed. Cloud reduced the need for large teams. Automation commoditised routine work. Clients learned to build their own capabilities. The work that remains requires engineering excellence, not just execution capacity.

And now AI is about to transform what “productivity” means entirely.

The structural factors that enabled growth became the barriers to evolution.

What Comes Next

We’ve diagnosed the crisis in Part 1. We’ve examined the causes here in Part 2.

The common thread: we systematically traded engineering excellence for operational efficiency. We optimised for predictable mediocrity when the market increasingly rewards excellence.

The question now: Is transformation possible? What would it actually take — not in theory, but in practice?

Part 3 will explore the path forward. Not with naive optimism, but with a realistic assessment of what change would require, who could drive it, and whether there’s still time.

Next: Part 3 examines what transformation would require — from business model evolution to technical career paths to genuine investment in engineering culture.

This is the first of a three-part series examining why the “lost” art of engineering excellence is one of the primary reasons.

• Part 1: The Crisis — What’s actually happening and why the usual explanations fall short

• Part 2: The Factors — The structural choices that made engineering excellence nearly impossible

• Part 3: The Way Forward — What would need to change, and whether transformation is still possible

My aim is not criticism for its own sake. It’s a diagnosis — the kind that comes from caring about an industry and wanting to see it thrive.

My Vantage Point

I’ve spent 26 years in technology, seeing it from every angle — as an engineer, as a technical leader within IT services, as a client-side CTO buying these services, and as a consultant advising on technology strategy. Now I’m building a technology company in India.

I write as someone who has lived this industry’s evolution, seen what it’s capable of, and watched it fall short of that potential.

The Visible Symptoms

The business is under pressure. Revenue growth has stagnated. Margins are compressing. Deals go to global competitors or get pulled in-house. “Digital transformation” was supposed to move us beyond labour arbitrage, but the market still sees Indian IT as a cost play. And automation and AI now threaten a model built on volume.

Talent is voting with its feet. The best engineers leave for startups and product companies. GCCs siphon talent with better compensation. IT services are no longer the aspirational employer they once were. Engineers who stay often disengage from craft, focusing on “managing” — because that’s where career progression lies.

The perception problem reflects reality. Clients see us as “implementers” and “executors.” When a company needs breakthrough technology thinking, Indian IT is not in that conversation. We’re in the conversation about who can do it cheaper at scale — and that’s increasingly not a conversation that leads to growth.

Not to say there aren’t outliers — but they are exceptions, not the norm.

Always Catching Up, Never Leading

Here’s a pattern that should trouble us.

Every major technology wave of the last two decades — cloud, DevOps, big data, AI/ML, generative AI — Indian IT has been a follower, not a shaper.

We didn’t define cloud architecture patterns. We learned them from AWS and Azure documentation or from pioneers from Heroku or Pivotal. We didn’t pioneer DevOps practices. We adopted them years after Google and Netflix wrote the playbooks. We’re not shaping how AI transforms software development. We’re scrambling to figure out what it means for our billing models.

Think about what’s missing. The largest IT services companies in the world — with hundreds of thousands of engineers, exposed to cutting-edge client projects — have produced no widely-adopted open source frameworks, no influential technical research, no engineering practices others seek to emulate. Our contribution to open source is almost negligible — we consume it voraciously but give back almost nothing.

Contrast this with what’s possible. Palantir started as a services company and became a technology benchmark — building platforms that governments and enterprises now depend on. Pivotal, born from consulting and services roots, gave the world the Spring Framework, Cloud Foundry, and shaped how enterprises approach cloud-native development. They proved that services companies can lead, not just follow — that client work can fuel innovation rather than merely consume it.

We have privileged access to the most advanced technology environments through our client work. We see what leading companies build. We work inside their systems. Yet we rarely absorb that knowledge and advance it.

We execute technology. We don’t extend it.

With all our scale and exposure, our contribution to the global technology landscape is disproportionately small. Present everywhere, influential almost nowhere.

The Contrast That Stings

If Indian engineers simply weren’t capable, this would be a straightforward story. But the evidence says otherwise.

Consider what’s been built in India that genuinely leads globally:

UPI — real-time payments processing billions of transactions, now studied and replicated worldwide. Built by engineers solving hard problems with technical depth, not by managing utilisation rates.

Aadhaar — the world’s largest biometric identity system with unprecedented engineering challenges around scale, security, and reliability.

Zerodha — one of the world’s largest brokerages by volume, built by a remarkably small team obsessing over performance and simplicity.

Razorpay, PhonePe — fintech at massive scale, built by engineering-first teams competing globally on capability, not cost arbitrage.

Zomato, Blinkit — consumer platforms solving complex real-time logistics, demand prediction, and hyperlocal delivery at a scale and speed that few have matched globally.

Zoho — bootstrapped, engineering-led, building enterprise software that competes with global giants through sustained investment in craft.

What do these have in common? Engineering excellence as a core value. Technical leadership is embedded in decisions. Hard problems solved with creativity, not just headcount. Genuine pride in craft — how something is built matters, not just that it shipped.

The uncomfortable conclusion: the talent exists, the capability exists, the proof points exist. Indians can build technology that leads globally.

Just not, it seems, through Indian IT services.

The problem isn’t the people. It’s the system.

The Questions This Raises

If it’s not the talent, then what?

Why does the same engineer who writes mediocre code at an IT services company do exceptional work at a startup or product company?

Why have three decades and millions of engineers produced so few contributions to how the world builds software?

Why, with all our scale and client exposure, are we not setting the agenda on any emerging technology?

What is it about Indian IT — its business models, incentives, career structures, culture — that systematically prevents engineering excellence from taking root?

These questions don’t have simple answers. They’re uncomfortable for those of us who’ve spent careers here. But they’re the right questions.

What Comes Next

The symptoms — business pressure, talent exodus, the “implementer” perception, always following never leading — aren’t random misfortunes.

They point to structural choices made over three decades about what to optimise for. Choices about business models, how to value people, what “quality” means, the relationship between management and engineering.

These choices built an industry. Created millions of jobs. Put Indian IT on the global map. They made sense in their time.

But they also optimised against engineering excellence. They created a system where predictability mattered more than creativity, utilisation more than capability, process more than craft.

The game has changed. Cloud and automation have eroded the value of volume. Clients build their own capabilities. AI will transform what “productivity” means in software.

The choices that built the industry may not sustain it.

In Part 2, we’ll examine these factors — not to blame, but to understand. Because you can’t fix what you haven’t diagnosed.

There may still be time. But only if we look clearly at how we got here.

Next: Part 2 explores the specific factors behind the erosion of engineering excellence — from business model incentives to career structures to how we’ve defined quality.

The greatest joy of my current role for the last 18 months has been coding 4-5 hours per day. It’s been roughly a year since I started using AI tools in my daily coding. What began as tentative experiments with syntax questions has transformed into an integral part of how I build software.

Here’s my journey—the false starts, the discoveries, and what I’ve learned about making AI genuinely useful for development work.

Part One: The Journey

The Tentative Beginning

Like many developers, I started with ChatGPT in its standalone web interface. My initial use was almost embarrassingly modest—asking syntax questions I could have Googled. “How do I format a date in Java 21?” “What’s the syntax for a functional code here?” It felt a bit like having a friend who never judged you for not remembering something you’d looked up a dozen times before. It was like having StackOverflow, but much simpler and better.

But even in these early days, something clicked. The responses came with context, alternatives, and explanations. I found myself understanding the _why_ behind syntax choices, not just copying and pasting.

That said, it wasn’t flawless—I’d occasionally get suggestions using deprecated methods or outdated APIs, requiring me to verify and correct. The AI’s training data clearly had a cutoff, and Java moves on. Still, even with these hiccups, it was faster than searching through documentation.

Graduating to Code Generation

The real shift came when I started uploading Java files as context. My first serious use case was generating mappers—those tedious but essential classes that convert between DTOs and domain objects. I’d upload the source and target classes, describe what I needed, and get back working code in seconds rather than the fifteen minutes of mechanical typing it would have taken me.

This was genuinely useful. Not revolutionary, but a real time-saver for boilerplate-heavy work.

The Testing Experiment (Mixed Results)

Emboldened by success with mappers, I tried something more ambitious: generating test cases and test data. The results were... mixed. The AI understood what I wanted to test and could articulate sensible test scenarios. But the generated code often wouldn’t compile. Missing imports, wrong method signatures, assumptions about test frameworks that didn’t match my setup.

I’d estimate maybe 60% of the generated tests worked out of the box. The rest needed debugging—sometimes quick fixes, sometimes significant rewrites. Still useful as a starting point, but not the productivity multiplier I’d hoped for. Often, I reverted to hand-coding the test cases.

The generation of test data was much better; it generated contextual test data that I would not have imagined myself. As I was building DSLs, AI was very useful to generate a sample DSL by giving grammar and context.

The Rate Limiting Wall

Then came the inevitable: rate limits on the free tier. Mid-flow, mid-thought, suddenly cut off. It’s a particular kind of frustrating to have a tool become indispensable and then have it yanked away just as you’re relying on it.

Exploring Alternatives

Necessity drove experimentation. I tried Grok—it was fine. Capable, reasonably accurate, but nothing that made me think I’d found something better. Deepseek came next. Also fine, perhaps slightly less polished. Both felt like substitutes rather than genuine alternatives.

What I noticed across all these tools was a consistent friction: none of them integrated with my IDE. Every interaction meant context-switching—copy code, paste into browser, read response, copy back, paste into editor. The cognitive overhead was real, and it limited how much I could actually use these tools in the flow of real work.

The Claude Pro Upgrade

Moving to Claude Pro was my first significant quality jump. The responses were noticeably better—more accurate, more nuanced, better at understanding complex codebases and requirements. The code it generated compiled more often. The explanations were clearer.

But I still hadn’t solved the integration problem. I was still copy-pasting between windows, still breaking my flow every time I wanted AI assistance.

The Integration Breakthrough

The real transformation came when I moved to Claude Code integrated with VS Code. But—and this is important—I set it up with guardrails. I don’t allow automated changes to my code. Every read and every write requires my explicit approval.

This might sound like friction, but it’s actually the configuration that made AI coding work for me. I maintain control. I understand every change. The AI proposes; I decide. It’s collaborative rather than autonomous.

The productivity increase was immediate and substantial. No more context-switching. No more copy-paste gymnastics. I describe what I need, review the suggestions in place, and approve or modify as needed.

Where I Am Now

Today, I’d estimate 30-40% of the code I write is AI-generated. The rest is still handcrafted—the complex business logic, the architectural decisions, the parts that require a deep understanding of our domain. But the boilerplate, the standard patterns, the tedious-but-necessary code? That’s increasingly coming from AI assistance.

And here’s the thing I didn’t expect: the code is consistently good. Not just functional, but clean, following best practices, properly structured. When I review AI-generated code, I rarely find issues. It’s not perfect—nothing is—, but it’s reliable in a way that early experiments weren’t.

Part Two: Recommendations for Developers

A year of daily use has taught me some things I wish I’d known at the start.

Start with Low-Stakes Work

Don’t begin by asking AI to architect your system or write your core business logic. Start with mappers, converters, and simple utilities. Get comfortable with the tool’s strengths and limitations before you depend on it for anything critical.

Pay for Quality

The difference between free-tier tools and paid options isn’t just about rate limits—it’s about quality. Claude Pro produces better code than free alternatives. If you’re a professional developer, the cost is trivial compared to the time saved.

Integrate, Integrate, Integrate

A standalone AI tool is useful. An integrated AI tool is transformative. Whatever setup you use, minimize the friction between your development environment and your AI assistant. Every copy-paste is cognitive overhead that adds up over a long day.

Keep Yourself in the Loop

I strongly recommend against fully autonomous AI coding, at least for now. Review every change. Understand what’s being generated. You’re still responsible for your codebase, and you need to maintain the understanding to maintain it.

This isn’t just about catching errors (though you will catch some). It’s about staying sharp. If you blindly accept AI-generated code, you stop learning. Keep yourself engaged with what’s being written.

Consider AI to be your very capable intern, whose every line of code you have to review before committing.

And a hard rule: never let AI generate code that you don’t understand. If you can’t read the output and explain what it does, you shouldn’t be using it. You’ll end up with a codebase you can’t debug, can’t extend, and can’t maintain. AI should accelerate your coding, not replace your comprehension.

Provide Rich Context

AI code quality is directly proportional to context quality. Upload relevant files. Explain your conventions. Describe your constraints. The more the AI understands about your codebase and requirements, the better its output will be.

Know the Limits

AI is excellent at standard patterns and common problems. It’s less reliable for novel architectures, domain-specific logic, or anything that requires understanding beyond the code itself. Use it for what it’s good at; don’t force it into areas where it struggles.

For example, I wrote a rule engine from scratch, and almost none of the core functional code was AI-generated. The core code is close to implementing a programming language—tokenisation, parsing, syntax tree, and complex execution logic. This is not something you want AI to write.

Test Everything

AI-generated code needs testing just like human-written code—arguably more, because you didn’t write it and might not have the same intuition about where it could fail. Don’t let the speed of generation lead to shortcuts in verification.

Manage the Flow Disruption

Here’s something nobody talks about: AI assistance can disrupt your flow state. When I’m hand-coding, I can get into that zone where hours pass without notice. With AI, there’s always a pause—waiting for the response, reviewing the suggestion, deciding whether to accept or modify. That waiting time invites distraction. A glance at email, a quick check of Slack.

I’ve found two practices that help. First, for any substantial piece of code, don’t jump straight into generation. Start by asking the AI to outline the approach. Refine that approach together, get it down to pseudo code, and only then start generating actual code. This front-loads the thinking and makes the generation phase more predictable.

Second—and this requires discipline—watch the AI generate code. Even if it means staring at the screen while tokens appear. Resist the urge to switch tabs, check messages, or do anything else. Stay present. You’ll catch issues earlier, stay connected to what’s being written, and maintain something closer to that flow state. The generation only takes seconds or minutes; your focus is worth protecting.

Looking Forward

A year ago, I was skeptical about AI coding tools. They seemed like toys—impressive demos that wouldn’t survive contact with real development work. I was wrong.

Today, I can’t imagine going back. The 30-40% productivity gain is real, and it compounds. But more than the efficiency, what I value is the cognitive offload. The mechanical parts of coding—the parts that are necessary but not creative—are increasingly handled by AI, leaving me to focus on the work that actually requires human judgment.

We’re still early in this transformation. The tools will get better. The integration will get smoother. The boundaries of what AI can reliably handle will expand. But even now, today, with current tools and current limitations, AI-assisted coding is a genuine productivity multiplier for anyone willing to invest the time to learn how to use it well.

My advice: start now. Start small. Stay in control. And pay attention to what works for your specific context. The general patterns I’ve described will apply, but the details of how you integrate AI into your workflow will be uniquely yours to discover.

What’s been your experience with AI coding tools? I’d love to hear how others are integrating these into their workflows—the successes, the failures, and everything in between.

The tech industry has the same problem with someone calling themselves “a techie.“

When someone introduces themselves as a technologist, it tells you almost nothing. A venture capitalist funding AI startups and a kernel developer debugging memory leaks both claim to be the techie.

One reads pitch decks; the other reads hex dumps. Both are “in tech.” This isn’t gatekeeping—it’s clarity. Here’s my attempt to map the spectrum: seven shades of techie, paired with their vegetarian counterparts.

Shade 1: The Visionary (The Vegan Advocate) understands tech trends, makes strategic bets, and evangelises digital transformation. Last wrote code when PL/SQL was cool the first time. Think CIOs, tech investors, and that consultant who keeps saying “blockchain” in meetings.

Shade 2: The Orchestrator (Jain with onion-garlic exceptions) manages tech teams, interprets architecture diagrams, and bridges business and engineering. Coded once, now reviews with comments like “looks good to me.” Your IT Delivery Manager or Program Director lives here.

Shade 3: The Architect (The Eggetarian) Designs systems, defines patterns, writes “reference implementations” that someone else turns into production code. Comfortable with whiteboards, dangerous with deadlines. Solution Architects and Principal Consultants occupy this shade.

Shade 4: The Builder (Only chicken, no mutton) Writes production code daily. Might not handle deployment or scaling, but the features work. Your classic Application Developer or Full-stack Engineer—the backbone of most product teams.

Shade 5: The Craftsman (Full non-veg but only on weekends) Production code plus deployment plus that 3 AM on-call you dread. Owns the entire lifecycle. Principle or Staff Engineers, folks who’ve seen things they can’t unsee in production logs.

Shade 6: The Specialist (The Serious Carnivore) Deep expertise in one domain—payment systems, security, database internals. Knows things that make generalists nervous. Your high frequency trading algo developer or payments systems architect who casually mentions “low-latency”, “eventual consistency”, and means it.

Shade 7: The Systems Wizard (Eats everything, including the bones) Kernel hackers, compiler writers, protocol designers. They build the tools that build the tools. The Linux contributors and distributed systems researchers whose work runs underneath everything else, usually thanklessly.

Here’s the thing: this isn’t a hierarchy of value. A company needs Visionaries to set direction and Wizards to make things possible. One trying to do the other’s job will be a disaster.

The Orchestrator who keeps the team shipping is as vital as the Specialist who keeps the payments flowing. But let’s stop pretending these roles are interchangeable. A CIO and a kernel developer are both “technical”—like both paneer and prawn are “protein.”

So next time someone tells you they’re a techie, ask the follow-up question. Which shade? It matters. Just like you’d ask if eggs are okay while making breakfast.

As for me? I’ve wandered across a few of these shades over twenty-five years—Builder, Architect, occasionally pretending to be a Visionary. But deep down, I’m still a coder who just loves what I do. Somewhere between Shade 4 and 6, with aspirations, you could say.