DEV Community: khurram bilal

Stop Calling Everything a “Bug”

khurram bilal — Tue, 27 Oct 2026 17:02:25 +0000

Episode 4 of the AI-Augmented Parallel SDLC series.
The pillar article laid out the blueprint: discover once, run three workstreams in parallel, converge at one gate. Episode 3 covered what each stream does on day one. This one is about that gate, and the one word in the issue tracker that decides whether the model survives it.

A chef is asked to start cooking while the table is still choosing. To save time, she preps a garlic-butter sauce from the first order. Ten minutes later the table switches to lemon-herb. At the pass, the head waiter tastes the plate and writes it up: “Chef ruined the sauce.”

Nobody argues. The sauce gets remade. But at the next service the chef doesn’t start early. She folds her arms, waits for the order in writing, signed, and dinner arrives two hours late.

I’ve watched this exact scene play out in software teams far more often than in kitchens.

A four-word ticket

In a Parallel Delivery model, analysts, developers and testers don’t queue for handoffs. Everyone starts on Day One, and that is where most of the speed comes from.

On one recent project, that model nearly came apart over four words.

A few weeks into the build, the client adjusted a business rule. It was a reasonable change, the kind good discovery always surfaces. Our analyst logged it. But the developer had already built the feature on Day One against the original rule, exactly as we’d asked him to. When it reached testing, QA spotted the mismatch and filed the standard ticket:

BUG · Incorrect rule behavior · #0412 · QA

He fixed it in a few hours. Nobody complained.

A month later, the same developer had stopped starting early. He was “waiting for the stories to settle” and “cleaning up the environment first.” When we asked why, the answer was short: he was tired of building things twice and having it counted against him.

We hadn’t punished bad code. We had punished speed.

Why “bug” carries so much weight

In sequential delivery, requirements are frozen before anyone writes code. If the software doesn’t match the document, someone made a mistake, and “defect” is the right word for it.

Parallel delivery runs on a different assumption: requirements are meant to evolve while the code is being written. Healthy teams plan for 15–20% of the work to shift as everyone learns, and they carry that buffer in both the schedule and the budget.

Label those planned shifts as bugs and the tracker turns into a permanent record of blame:

Dashboards don’t read comments. Reports and performance reviews count tickets. The note explaining that the client changed direction on Tuesday never makes it onto the chart.
People protect themselves. Engineers notice fast when starting early earns them defects. So they stop, and quietly go back to waiting for full sign-off.

How a mislabelled requirement change trains a team to stop starting early. Nobody decides to slow down; the tracker teaches it.

You don’t lose speed to bad code. You lose it to a tracker that penalises initiative.

The Sync Checkpoint: two questions, three labels

After kickoff, the parallel streams run independently until they converge at a single quality gate, the Sync Checkpoint. That’s where working code, finalised business rules and the automated test suite meet for the first time.

When a test fails there, we don’t default to “bug.” We ask two questions, in order.

Question 1 — Did the rule change after the code was written?

If the feature was committed on Monday and the client updated the rule on Wednesday, it’s a Scope Shift (requirement gap). The fix happens just as fast, but the time comes out of the planned change buffer, not the developer’s track record.

Question 2 — If the rule came first, was the developer actually told?

Sometimes the analyst and client agree a change in a meeting and record it in the decision log, but nobody announces it in the team channel or updates the developer’s ticket. The developer builds on old information. That isn’t a moving requirement, and it isn’t the developer’s fault. It’s a Comms Miss (process gap): our daily broadcast habit broke down.

Only when the rule was locked and clearly communicated before coding began, and the build still doesn’t match, do we call it a True Bug (defect).

The checkpoint triage. Two questions, asked in order, route every failed test to exactly one label.

	True Bug (defect)	Scope Shift (requirement gap)	Comms Miss (process gap)
What happened	The developer had the right rule in time, and the code still broke.	The rule changed after the code was already written.	A decision was made, but nobody told the developer in time.
Who fixes it	The developer who wrote the code.	The delivery team, as normal planned work.	The team fixes the code; leadership fixes the habit.
Who pays	Engineering absorbs the fix.	The planned 15–20% change buffer.	Engineering absorbs it and logs a process fix.
A spike means	Code quality or reviews need attention.	Discovery was too shallow, or the client is pivoting.	Daily syncs aren’t carrying decisions.
Proof needed	Rule shared before the commit.	Rule changed after the commit.	Decision logged, no record of an announcement.

What each label means, who owns it, and what a rising count is telling you.

Timestamps, not opinions

The first question every manager asks: won’t developers just call everything a Scope Shift to look good?

They can’t, because the label isn’t a judgement call. It’s the order in which three things happened.

Same failed test, three different histories. The sequence of decision, announcement and commit decides the label.

When a mismatch surfaces at the checkpoint, three people take a short call: the Business Analyst (who owns the decision log), the QA Lead (who owns the tests) and the Developer (who owns the commits). They work to two ground rules.

Timestamps beat memory. “I’m pretty sure I mentioned it on Slack” doesn’t count. If the decision is newer than the commit, it’s a Scope Shift. If the decision is older but there’s no written trace that it reached the builder, it’s a Comms Miss.
The 10-minute rule. If the three can’t establish the sequence within ten minutes, it’s logged as a Comms Miss by default. If you can’t trace when a decision was made, your record-keeping failed, and that default gives everyone a standing reason to keep the logs clean.

Where AI fits in, without taking over

AI makes the checkpoint much faster, as long as you hold to one rule: AI does the legwork; people make the call.

Faster test runs. AI testing agents can execute thousands of checks in minutes rather than days. A QA engineer still reviews and signs off before any result is official. Waving AI test passes through the final gate is how defects ship.
History in seconds. Instead of three people digging through weeks of threads and commits, an assistant reads the decision log and the git history and hands over a receipt. The trio verifies it in about thirty seconds and moves on.

The AI assembles the evidence and suggests a label. The BA, QA Lead and Developer confirm it. The machine never closes the ticket.

Why clients come to like this

Sorting tickets this way doesn’t only protect morale. It changes the client conversation.

Traditional testing phases tend to turn into a running argument: is this a bug, which is free to the client, or a change request, which is billed? Clear labels settle most of that before it starts, because each bucket maps to an agreement made on Day One.

True Bugs and Comms Misses are ours. The client never pays for our mistakes, whether in the code or in how we passed decisions along.
Scope Shifts draw down the 15–20% change buffer that was already built into the project plan.

Every week the client sees a simple fuel gauge: the rules they changed this week, and how much buffer is left. Extra budget only comes up once they pass 20%.

The change-buffer gauge the client sees each week. Only Scope Shifts move the needle.

Clients rarely mind paying for change when they can watch the meter. What they resent is the surprise invoice.

Reading your team’s health at a glance

Track Scope Shifts alongside True Bugs and you get a quick X-ray of how the team is really working. Either number on its own can mislead you; read them together.

The four combinations each tell a different story. Two deserve a second look. The Illusion of Calm is the one leaders most often celebrate: few bugs, almost no changes, everything green. It usually means the team has gone back to waiting, and the cost is showing up in delivery speed rather than in the tracker. Quality Slip is the newer risk. The labelling is honest, but as AI writes more of the code, review discipline is the first thing to erode.

And if Scope Shifts run well past 20%, don’t tune the checkpoint. The problem is upstream: kickoff discovery isn’t digging deep enough.

Reading True Bugs and Scope Shifts together. The healthy team sits top-left; a suspiciously quiet tracker sits bottom-left.

Change the word, keep the speed

It takes months to teach a team to work in parallel, and one afternoon of mislabelled tickets to undo it. Developers who get burned by the tracker rarely raise it in a retro. They just slow down to protect themselves.

Before your next project reaches testing, change the options in your issue tracker. Separate True Bugs from Scope Shifts and Comms Misses, and settle every one of them with timestamps instead of finger-pointing.

Adjusting to new information isn’t a failure. Treating it like one is.

In this series

The AI-Augmented Parallel SDLC — the full blueprint: discovery once, three parallel workstreams, one gate.

Episode 1: The Handoff Chain — Why Your Team Is Mostly Paying Handoff Debt

Episode 2: The Joint Discovery Session — Why Five Perspectives Beat One Requirements Document

Episode 3: The Three Parallel Workstreams — How Design, Build, and Test Start on Day One Without Colliding

Next up — Episode 5: The Attention Budget. When AI makes writing code almost free, human review becomes the new bottleneck. Here’s how to spend human judgement where it counts.

Try this, five minutes: open last month’s bug list. How many of those “bugs” were really requirements that moved along the way?

The Software Sales Pitch is Dead. Long Live the Pitch.

khurram bilal — Tue, 15 Sep 2026 18:51:00 +0000

What modern software agencies must sell in the era of AI and Agentic Development

For twenty years, the software agency sales pitch followed a comforting, predictable script. We sit down with the client, unpack their business problem, break it down into neat little modules, and deliver the final verdict: “This will take a team of five about six months, and we’re looking at 1,200 billable hours.”

The client compares our hourly rate against two competitors, haggles a bit, and signs on the dotted line.

That entire commercial model rested on one massive, unspoken assumption: Writing code is slow, difficult, and scarce. Essentially, the client was buying our time.

Today, agentic AI has completely shattered that assumption. When an AI agent can scaffold an app in an afternoon, spin up integrations overnight, and iterate features faster than you can schedule a sprint planning meeting, “hours to build” is no longer a meaningful metric of value.

If you walk into a 2026 sales meeting quoting 1,200 hours for a project the client knows could be prototyped in a week, you don’t just lose the pitch—you signal that your agency is stuck in the past.

So, does the pitch remain the same? Absolutely not. But the reasons clients hire software houses are actually stronger than ever. The value has simply shifted. Here is where it went, and what your new pitch needs to sound like.

The Reality Check: What got cheap, and what didn’t?

To adapt, we have to be brutally honest about what AI actually changed. Code generation became cheap. Software delivery did not.

Even before AI, typing out the code was rarely the hardest part of a project. The truly difficult parts have always been:

Translating what a business asks for into what it actually needs.
Making architectural decisions that won’t collapse under their own weight in two years.
Integrating with messy, real-world legacy systems.
Securing the data and ensuring reliable deployment.
Being the one whose phone rings at 2:00 a.m. when the production server crashes.

Agentic tools put coding on hyper-speed, but they do not replace human judgment, ownership, and accountability. In fact, when code is generated at lightning speed, the cost of bad judgment compounds exponentially. It has never been easier to build the exact wrong thing, incredibly fast.

This asymmetry is the foundation of the new sales pitch.

The Old Pitch vs. The New Pitch

The Old Pitch sold inputs: “We have brilliant developers. Your solution requires X hours at Y rate.”

The New Pitch sells outcomes, speed, and judgment: “We will get you from a business problem to a working, measurable solution in weeks, not months—and we own the results, not just the code.”

To put this into practice, the new tech agency sales pitch stands on five core pillars:

1. Sell Business Outcomes, Not Sweat

The conversation must shift from “how long will it take to build” to “what is this problem costing you, and what is the solution worth?” If a client’s manual data entry process burns $20,000 a month in staff time, don’t pitch an 800-hour build. Pitch this: “We will eliminate 80% of that cost in eight weeks, and here is how we will measure success.”

The Shift: Fixed-price outcome packages, milestone billing, and value-based fees replace time-and-materials.

2. Sell “Speed-to-Value” as Your Headline

Ironically, the very AI that threatens the old agency model is your greatest weapon in the new one. Instead of pitching with a 40-page proposal deck, modern software houses are showing up to pitches with a working demo built directly from the client’s problem statement.

“Because we use agentic pipelines, you’ll see a working version in two weeks, not a requirements doc.” The demo becomes the pitch. Showing always beats estimating.

3. Sell Strategic Judgment (The “What to Build” Premium)

When anyone can build fast, the ability to decide what to build becomes the rarest skill

in the room. Lean hard into discovery, domain expertise, and product strategy. Map the client’s actual workflows. Ruthlessly prioritize the 20% of features that will drive 80% of the value. Be willing to tell a client, “You don’t need custom software for this; use this off-the-shelf tool instead.” Under the old hourly model, that honesty cost you money. Under an outcome-based model, it builds unbreakable trust.

4. Sell Accountability for the “Boring, Hard Stuff”

AI agents can write brilliant code, but they cannot sign contracts, carry liability insurance, pass healthcare compliance audits, or take the blame when things go wrong. Your new pitch makes human ownership explicit. You are selling security reviews, data governance, and enterprise ERP integrations that no slick AI demo video ever shows.

The Message: “Anyone can generate code today. We stand behind enterprise systems.”

5. Sell a Living Relationship, Not a Static Project

Fast building means fast evolving. Software is no longer a one-and-done construction project; it’s a living organism that needs to adapt monthly. Replace the “build and hand over” mindset with continuous partnerships. Offer a managed AI-augmented squad on retainer, or a “Software-as-a-Relationship” subscription for continuous monitoring and improvement. It’s better for the client’s product, and it secures healthy, recurring revenue for your agency.

How the Sales Conversation Actually Changes

When you adopt this mindset, the mechanics of how you sell naturally evolve:

Estimations become Milestones: Clients will always ask, “How much and how long?” Instead of a spreadsheet of person-hours, give them value milestones: “Working prototype in week 2, user pilot in week 5, full rollout in week 9, for a fixed price of $X.”
Proposals become Prototypes: The cost of building throwaway software has plummeted. End your discovery phases with software the client can actually click on. Teams that pitch with working apps will always beat teams that pitch with PDFs.
The Heroes Change: The star of the old pitch was the Senior Developer. The stars of the new pitch are the Solution Architect, the Domain Expert, and the AI Orchestrator—the people who guide the agents and connect the tech to business reality.
Radical Transparency: Don’t hide your AI usage while charging manual-era rates; clients aren’t naive. Lean into it: “Yes, we use AI pipelines aggressively. That is exactly why we can promise this speed and price without sacrificing human accountability.”

The Bottom Line

If you take nothing else away from this shift, remember this:

**The old pitch was, “Pay us for the hours it takes to build.” The new pitch is

, “Pay us for the outcome, delivered at AI speed, with human accountability.”

Software agencies are not being replaced by AI. The only agencies being replaced are the ones still trying to sell hours.

The agencies that thrive will be the ones who realize that the client never actually wanted to buy 1,200 hours of coding—they just wanted their business problem solved. Agentic AI just made it impossible for us to keep pretending otherwise.

— Khurram Bilal

Tech Sprinter

Hiring Is Broken: What to Interview For When Code Is Free

khurram bilal — Tue, 15 Sep 2026 15:51:00 +0000

Episode 6. Your interview loop tests a skill your agents already have. Here are the four that actually predict performance.

Where We Are in the Series

Episode 4 laid out the four pillars of agentic engineering – Context, Judgment, Verification, Orchestration. Episode 5 covered the ladder engineers climb to acquire them.

Both assumed something I never examined: that you can find these people. With the loop most orgs are running, you can’t.

The Arithmetic

In April 2026, Sundar Pichai disclosed that around 75% of new code at Google is AI-generated and approved by engineers – up from 50% six months earlier.

Now run that through your interview. If three quarters of production code arrives generated and the engineer’s contribution is approval, then a loop built around unassisted code production is measuring the shrinking quarter – under a stopwatch, on a puzzle, with the reference material removed.

You are optimising your most expensive process for the part of the job that’s disappearing fastest. The part that’s growing deciding, directing, verifying – appears nowhere in it.

Why the Old Loop Broke

Algorithmic interviews were never about algorithms. They were a proxy for problem decomposition under pressure. Imperfect, but not worthless. Three things killed the proxy:

The skill became a commodity. Any model solves these in seconds. The proxy now separates preparation, not candidates.
It selects for free time. It always favoured people between jobs over engineers who spent three years shipping. Tolerable when the signal was decent.
It’s no longer scoreable. Unproctored take-homes and async code tests have become close to unfalsifiable, and every hiring manager knows it.

What I’d keep: one unassisted round still tells you how someone thinks when nothing is filling the gaps. The mistake isn’t having it. The mistake is having it be the whole loop.

The Industry Already Moved – And Is Split

Canva has expected candidates to use AI in technical interviews since June 2025, and rewrote its questions to be ambiguous enough that one prompt can’t finish them. Meta added an AI-enabled coding round in late 2025 while deliberately keeping an AI-free one alongside it. Shopify asks candidates to integrate AI output into unfamiliar codebases. Google is adding a code-comprehension round that explicitly grades prompt quality and output validation.

But Amazon and Anthropic both keep AI out of the live round – and Anthropic sells an AI assistant. They’re not laggards.

The split isn’t a disagreement about whether AI matters. It’s a disagreement about what a single round can isolate. Both positions are defensible. What isn’t defensible is running only the old kind of round and being surprised your hires can’t operate agents.

The Four Signals

Mapped to the four pillars. Each one has a format and a question that’s hard to fake.

1. Context – can they set an agent up to succeed? Unfamiliar repo, deliberately vague ticket, AI encouraged. Watch the first fifteen minutes and stay quiet. Strong candidates gather before they generate and ask what’s out of scope. Weak ones paste the ticket in and press enter. Beware the fake tell: enormous prompts are volume, not context engineering. → “What did you decide not to give it, and why?”

2. Judgment – can they decide what shouldn’t exist? Hand them a 300-line PR that works, passes tests, and is architecturally wrong. Say “review this.” Strong candidates reject it and price the rejection – what it costs in eighteen months, and what the forty-line version looks like. Weak ones approve with naming nitpicks. → “What would you delete?”

3. Verification – can they catch a confident failure? Give them agent output with a subtle bug that passes the supplied tests. Strong candidates read before they run and check the diff against the requirement, not the test suite. This round predicts on-call performance better than anything else in the loop. → “How do you know it did what it said it did?”

4. Orchestration – can they decompose for parallel work? Ask them to split a feature into pieces three agents could run in parallel without colliding. Strong candidates name shared state as the risk immediately and define contracts before tasks. Weak ones split by file and assume the merge is trivial. → “What happens when two of them disagree?”

A Loop You Could Run Next Month

Round	Time	Tests
Retrospective conversation	30 min	“Something you shipped and later regretted”
Live agentic build (real repo, seeded bug)	90 min	Context + Verification
The rejection review	45 min	Judgment
Decomposition design	45 min	Orchestration
Fundamentals, AI-free (optional)	45 min	Raw reasoning – weight it at a fifth, not four fifths

Three rules: score the process, not the artifact; put the AI policy in the invite; and calibrate on three of your own strong engineers first. If your best people score badly, the rubric is wrong – not them.

The Junior Problem

The apprenticeship ladder ran on juniors doing the small work seniors didn’t want. That work was never valuable in itself , it was the tuition through which judgment got paid for. Agents do all of it now, so a lot of orgs have quietly stopped hiring juniors.

That’s a defensible one-year decision and a bad five-year one: you’re consuming a supply of senior engineers you’ve stopped producing. Interview juniors for reading appetite, verification instinct, and how they respond to correction mid-interview – then build the tuition back deliberately, because it no longer arrives as a byproduct.

Closing Thought

A legacy interview loop isn’t a decision. It’s institutional memory , a record of what used to be true. Nobody chose to keep testing binary tree inversion in 2026. It’s that no one owned the decision to stop.

Hiring last year’s engineers for next year’s work is the most expensive mistake available right now, because every hire made through the old loop is a five-year commitment to the old paradigm.

Don’t redesign everything. Add one round. Put a wrong-but-working PR in front of your next three candidates and ask what they’d delete. You’ll learn more in forty-five minutes than the current loop tells you in four hours.

Then run it on your existing team, and see what that tells you.

Earlier: Ep 1 · Ep 2 · Ep 3 · Ep 4

Khurram Bilal

www.linkedin.com/in/khurrambilal

New Curriculum for Software Engineers in the Agentic Era

khurram bilal — Tue, 15 Sep 2026 12:51:00 +0000

Not syntax. Not algorithms. The four disciplines that decide whether your org gets value from AI or just generates more code, faster.

Where We Are in the Series

In Episode 1, I wrote about what it actually takes to move agentic AI from POCs to production and why individual productivity gains rarely translate into system-level outcomes. In Episode 2, we looked at the Product Ownership layer how intent, requirements, and acceptance criteria become first-class inputs into agentic workflows. In Episode 3, we walked through the autonomous QA loop the shift from script-followers to strategy-makers.

Each episode answered a different version of the same question: how does work change when agents are doing the doing?

This Episode 4, answers a more uncomfortable one.

If agents are writing the code, running the tests, and filing the tickets, what exactly is the engineer’s job

The honest answer is: the job didn’t disappear. It moved.

It moved up the stack, into four disciplines that almost no engineering team has formally trained for, hired for, or measured against.

I’ve started calling them The Four Pillars of Agentic Engineering:

Context Engineering
Product Sense & Judgment
Validation & Quality Assurance
Workflow Orchestration

These are the new core curriculum. Not syntax. Not algorithms. Not framework-of-the-month. The skills that decide whether agentic AI becomes a force multiplier or a very expensive autocomplete. Let’s go through each one.

Pillar 1: Context Engineering

Your prompt and your context window are your levers.

The first thing you learn when you start building real agentic systems is that the model is rarely the bottleneck. The context is.

Two engineers can use the same model, the same tools, and the same task and get wildly different output. The difference isn’t intelligence. It’s what they put in front of the agent before they asked.

Context engineering is the discipline of deliberately curating:

What the agent knows : repo state, prior decisions, domain constraints, business intent
What the agent can see : files, schemas, logs, tickets, screenshots, traces
What the agent should ignore : stale docs, dead code paths, irrelevant noise
What the agent should remember : across turns, across sessions, across teams

In the pre-agentic era, “good prompting” was treated as a soft skill. In the agentic era, context engineering is a hard engineering discipline with patterns, anti-patterns, observability, and failure modes of its own.

Most teams discover this the hard way. They give an agent a vague task on a 2-million-line monorepo and are shocked when it hallucinates a function that doesn’t exist. The agent didn’t fail. The context did.

What this looks like in practice:

Treating prompts and context bundles as versioned artifacts, reviewed like code
Building context retrieval pipelines: not just RAG, but task-specific retrieval shaped by the work being done
Designing memory boundaries : what persists, what resets, what’s scoped to a session
Measuring context efficiency : how much of the window is signal vs. noise

If your org doesn’t have anyone whose job it is to engineer context, your agentic outputs are accidents. Sometimes good ones. Mostly not.

Pillar 2: Product Sense & Judgment

The agent fills the blanks. You decide what is worth building.

This is the pillar most engineering leaders underestimate and it’s the one that’s about to matter most.

When the marginal cost of generating a working implementation drops to near-zero, the scarce resource isn’t building. It’s deciding what to build, what to keep, and what to throw away. That’s Judgement.!

Judgement is the senior engineer who looks at a perfectly functional 400-line PR and says, “This shouldn’t exist. We don’t need this feature.” It’s the architect who chooses the boring solution because it knows what the exciting one will cost in two years. It’s the staff engineer who can tell you, in thirty seconds, why a generated abstraction is wrong even though every test passes.

Agents are extraordinary at producing plausible options. They are terrible at knowing which option is worth shipping in your system, for your users, under your constraints.

What Judgement looks like as a discipline:

Knowing the difference between correct and right
Recognizing when an agent’s solution is technically valid but architecturally wrong
Choosing simplicity over cleverness, even when the agent offers cleverness for free
Saying “no” or “not yet” to features, to abstractions, to optimizations
Understanding the long-term cost of code that exists, vs. code that doesn’t

Product. sence used to be the silent superpower of senior engineers hard to teach, hard to measure, easy to undervalue. In an agentic org, it becomes the most leverage-dense skill on the team.

The implication for hiring and career ladders is significant: we have spent decades rewarding people for output. We’re entering an era where the highest-paid engineers will be rewarded for discernment.

Pillar 3: Validation & Quality Assurance

The agent is fallible. You are the last line of defense.

Every agent fails. Quietly, confidently, and often in ways that look exactly like success.

This is not a flaw to be eliminated. It is a permanent feature of probabilistic systems. The orgs that internalize this build for it. The orgs that don’t get burned by it usually in production, usually under audit.

Validation is the discipline of designing systems where agent output is treated as a hypothesis, not a result, until something or someone has confirmed otherwise.

We touched on this in Episode 3 [https://www.tech-sprinter.com/blog/from-script-followers-to-strategy-makers ] the autonomous QA loop is, fundamentally, an industrial-scale verification machine for application behavior. But verification isn’t just QA’s problem. It runs through every layer of agentic engineering:

Did the agent change what it said it changed? (diff verification)
Does the change actually do what the requirement asked for? (intent verification)
Did it break something it wasn’t supposed to touch? (regression verification)
Are the assumptions it made about the system still true? (context verification)
Does the output meet our standards, not just the model’s standards? (QA)

What QA verification looks like in practice:

Layered checks: automated tests, agent-on-agent review, human-in-the-loop sign-off — proportional to risk
Trust budgets per agent and per task type, how much autonomy has this agent earned for this kind of work?
Verifiable artifacts : every agent action produces evidence: diffs, traces, logs, justifications
Failure-mode libraries : known patterns of agent error, treated like security CVEs
Replayability : being able to reconstruct why an agent did what it did, weeks later

In a non-agentic org, verification is something QA does at the end. In an agentic org, verification is everyone’s job, all the time, and it’s the core of how senior engineering judgment is expressed at scale.

If your only verification mechanism is “I’ll review the PR,” you do not have a verification strategy. You have hope.

Pillar 4: Orchestration

Multiple agents in parallel. You coordinate.

The first time you successfully run one agent on one task, it feels like magic.

The first time you successfully run seven agents on seven tasks at the same time, on the same codebase, without them stepping on each other, it feels like system design, because that’s exactly what it is.

Orchestration is the new system design.

It’s the discipline of decomposing a unit of work into pieces that agents can execute in parallel, defining the contracts between them, managing shared state, resolving conflicts, and merging the results into something coherent.

If that sounds like distributed systems engineering, that’s because it is. The actors just happen to be reasoning entities instead of microservices.

What orchestration covers:

Work decomposition : splitting a problem into agent-sized, independently verifiable units
Coordination patterns : fan-out/fan-in, pipelines, supervisor trees, debate loops, planner-executor splits
Shared-state management : branches, worktrees, feature flags, scratch spaces so agents don’t clobber each other
Conflict resolution: what happens when two agents disagree, or produce overlapping changes
Backpressure and budgets : token budgets, time budgets, retry budgets, escalation paths
Human checkpoints : where the loop pauses for judgment, and where it doesn’t

The teams getting real leverage out of agentic AI today are not the ones with the best prompts.They’re the ones with the best orchestration patterns, repeatable, observable, debuggable workflows where agents do most of the work and humans intervene at exactly the right moments.

This is where the next decade of engineering tooling will be built. And it’s the pillar where most orgs are flying completely blind.

Why This Is the Curriculum, Not Just a Skillset

Here’s the part that matters at the org level.

Every one of these four pillars used to be a peripheral skill , useful, but not central. Context-shaping was something good engineers did intuitively. Judgement was a vibe. Verification was QA’s job. Orchestration was for distributed systems specialists.

In an agentic org, all four become central, simultaneously, for every engineer.

That has cascading implications:

Hiring rubrics still optimized for LeetCode and framework trivia are testing for the wrong things. The new interview signals are: how do you frame context, how do you exercise judgement under uncertainty, how do you verify, how do you orchestrate?
Career ladders built around lines-of-code, ticket throughput, or PR volume will reward exactly the wrong behavior in an agentic org. Output is cheap now. Judgment isn’t.
Performance reviews need new instruments. “Shipped X features” is a metric for an era that’s ending. “Designed the verification strategy that prevented Y class of regression” is a metric for the era we’re entering.
Training and L&D budgets are still mostly aimed at syntax, frameworks, and certifications. The actual gap is in the four pillars and almost no formal curriculum exists for them yet.
Org structure itself shifts. Roles like Context Engineer, Verification Lead, Agent Orchestration Architect aren’t science fiction anymore. They’re emerging job titles in the orgs that are actually shipping agentic systems at scale.

The orgs that re-skill around these four pillars will out-ship, out-quality, and out-hire everyone still optimizing for the old curriculum.

The ones that don’t will spend the next two years confused about why their “AI productivity initiative” isn’t showing up on the P&L while their best engineers quietly leave for places that take this seriously.

What I’ve Learned So Far ?

A few things that have become clearer to me with every iteration:

The four pillars are not sequential. They’re simultaneous. You don’t graduate from context to product judgment to verification to orchestration. You exercise all four on every meaningful piece of work.
Tools matter less than disciplines. The frameworks will churn. The pillars will not.
Senior engineers were already doing all four (implicitly). What’s new is that the bar is now explicit, and it applies to everyone.
The biggest blocker is not technical. It’s organizational. Most orgs know how to buy tools. Very few know how to redesign their hiring, ladders, and reviews around new disciplines.
You can’t outsource any of the four. Especially product sense and verification. Those are where your org’s identity lives.

Closing Thought !!!

We started this series with a simple observation: there’s a big gap between agentic AI’s potential and what’s actually showing up in production.

Each episode has been a different angle on closing that gap, production engineering, product ownership, autonomous QA.

This episode is the underlying claim that ties all of them together:

Agentic AI is not a tool you adopt. It’s a discipline you train.

The four pillars: Context, Product sense, Verification, Orchestration , are the new core curriculum for that discipline. The orgs that treat them seriously will compound advantage quarter over quarter. The orgs that treat them as a slide in a strategy deck will keep wondering where the ROI went.

Until next time : pick the pillar where your team is weakest, and start there. That’s almost always the highest-leverage move you can make this quarter.

If this resonated, the earlier episodes are here:

Episode 1 : Production-Ready Agentic AI Systems
Episode 2 : From Prompt to Production
Episode 3 : From Script-Followers to Strategy-Makers

— Khurram Bilal

Why Your Startup Needs a Fractional CTO (Not a Full-Time One)

khurram bilal — Tue, 15 Sep 2026 09:51:00 +0000

A fractional CTO is a senior technology executive who works part-time — typically 10–40 hours per month — providing the same engineering leadership as a full-time CTO at a fraction of the cost. Instead of $20–25k/month for a full-time hire, fractional CTO services typically cost $3–5k/month, making it the default choice for startups from pre-seed through Series A that need cloud architecture decisions, AI strategy, and software development leadership without the full-time overhead.

The $300k Mistake Most Startups Make

Hiring a full-time CTO too early is one of the most expensive mistakes a startup can make. You're paying $250–350k in salary plus equity for someone who, at the seed stage, spends 60% of their time in meetings and 40% writing code that a senior engineer could write.

The math doesn't work. And yet founders do it every day because they think they need a "technical co-founder" to be credible.

What You Actually Need at Each Stage

Pre-seed / Seed: You need someone who can make fast cloud architecture decisions, hire the first 2–3 engineers, set up CI/CD pipelines, and keep the tech from becoming a liability. That's 10–20 hours a month, not 160. A fractional CTO handles software development process decisions and keeps your stack from becoming technical debt.

Series A: You need someone who can own the technical roadmap, evaluate AI architecture options, talk to investors, and build the engineering culture. This is also when process transformation matters most — moving from ad-hoc development to structured sprints and reliable deployments. Still not necessarily full-time — especially if your product isn't deeply technical.

Series B+: Now you probably need a full-time CTO. You have 15+ engineers, multiple product lines, and real cloud infrastructure complexity. Your fractional CTO can help you hire and transition to a full-time replacement.

What a Fractional CTO Actually Does

A fractional CTO isn't a consultant who writes reports. They embed into your team and provide hands-on engineering leadership:

Joining your standups and sprint reviews
Making real cloud architecture and AI architecture decisions with real consequences
Interviewing and hiring engineers alongside you
Evaluating vibe coding tools and AI-powered development workflows for your team
Sitting in board meetings and investor calls
Owning the technical roadmap end-to-end
Driving process transformation from ad-hoc to structured software development

The difference is they do this across 2–3 companies simultaneously, which means their pattern recognition is sharper than someone who's been inside one company for 3 years.

The ROI Is Immediate

A full-time CTO at $280k/year costs you $23k/month. A fractional CTO at 20 hours/month costs $3–4k/month and delivers the same strategic output.

The savings fund two senior engineers. Those engineers ship product. Product gets you to the next funding round.

When to Make the Switch

You'll know it's time to hire full-time when:

Your engineering team exceeds 12–15 people
You have multiple concurrent product lines that need dedicated technical leadership
Your CTO needs to be in the office daily for culture and coordination reasons
You're post-Series B with the runway to support the hire

Until then, fractional is almost always the smarter move.

AI-Native Architecture: What It Actually Means to Build for Agents

khurram bilal — Tue, 15 Sep 2026 06:51:00 +0000

The Difference Between AI-Enabled and AI-Native

Most companies adding AI to their products are AI-enabled. They've bolted an LLM onto an existing system — a chatbot on top of a legacy CRM, a summarization feature on top of a document store. This is not AI architecture. This is a band-aid.

AI-native means the architecture was designed from the ground up assuming that autonomous agents will be first-class actors in the system. Not a feature. Not a layer. A core participant. Getting this right requires deep AI architecture expertise — the kind of strategic thinking a fractional CTO brings to early-stage companies navigating the agentic AI landscape.

What Changes at the Architecture Level

1. Data as Agent Fuel

In a traditional system, data is stored for humans to query. In an AI-native system, data is structured for agents to consume. That means:

Embeddings stored alongside raw data
Metadata rich enough for semantic retrieval
Event streams that agents can subscribe to in real time

2. Tool-First API Design

Your internal APIs need to be designed as tools that agents can call, not just endpoints that frontends hit. This means:

Strict input/output schemas (agents can't handle ambiguity)
Idempotent operations wherever possible
Clear error messages that an LLM can reason about

3. Observability for Non-Deterministic Systems

Traditional monitoring tracks errors and latency. Agentic systems need a different layer:

Trace every agent decision and the context that drove it
Log token usage per task, not just per request
Alert on semantic drift, not just technical failures

4. Human-in-the-Loop by Design

The best agentic systems aren't fully autonomous — they know when to pause and ask. Build escalation paths into your architecture from day one. An agent that can't escalate is a liability.

The Stack We Recommend

For most startups building agentic products in 2026, the right cloud architecture and AI architecture choices compound over time:

Orchestration: LangGraph or custom state machines for complex multi-step agents
Memory: Combination of vector store (Pinecone/Weaviate) + structured DB for working memory
Models: GPT-4o or Claude for reasoning, smaller models for classification/extraction
Observability: LangSmith or Arize for agent tracing
Infrastructure: AWS Lambda for stateless agent tasks, ECS for long-running agents
Development: Vibe coding workflows with AI-powered development tools for rapid iteration on agent logic

The Mistake to Avoid

The biggest mistake we see is teams building monolithic agent pipelines — one giant prompt that tries to do everything. This breaks at scale and is impossible to debug.

Build modular agents with single responsibilities. Compose them. Test them independently. The same principles that make good microservices make good agentic systems. This is where process transformation matters — moving from ad-hoc AI experiments to structured software development practices for agentic systems. Teams that treat AI architecture with the same rigor as cloud architecture ship reliable AI products. Teams that don't ship demos that never make it to production.

How to Cut Your AWS Bill by 40% Without Touching Performance

khurram bilal — Tue, 15 Sep 2026 03:51:00 +0000

The Average Scale-Up Wastes 35–50% of Their Cloud Spend

We've audited dozens of AWS environments for Series A and B companies as part of our cloud architecture consulting. The average waste we find is 38%. Not because engineers are careless — because cloud infrastructure grows organically and nobody has time to clean it up. This is one of the first things a fractional CTO addresses: getting visibility into where money is going and stopping the bleed.

Here's the systematic approach we use.

Step 1: Get Visibility First

You can't optimize what you can't see. Start with:

AWS Cost Explorer — enable it if you haven't, tag everything by service/team/environment
Compute Optimizer — AWS's own tool that flags over-provisioned EC2, RDS, and Lambda
Trusted Advisor — free tier gives you basic rightsizing recommendations

Spend one week just tagging and categorizing before touching anything.

Step 2: Kill the Obvious Waste

In every audit we do, these are the first things we find:

Idle resources: EC2 instances running at <5% CPU for weeks. RDS instances nobody queries. Elastic IPs not attached to anything (you pay for those).

Over-provisioned databases: A db.r5.2xlarge running a dev environment. A Multi-AZ RDS setup for a staging database. These are common and expensive.

Forgotten snapshots and AMIs: Old EBS snapshots accumulating for years. Each one costs money. Run a cleanup script monthly.

Data transfer costs: Moving data between availability zones, regions, or out to the internet adds up fast. Audit your NAT Gateway costs — they're often the biggest surprise.

Step 3: Rightsize Compute

Once you have visibility, rightsize in this order:

EC2 → Graviton: Moving from x86 to ARM-based Graviton instances gives you 20–40% better price/performance with zero code changes for most workloads.
Reserved Instances / Savings Plans: If you have predictable baseline load, commit to 1-year Savings Plans. Typical savings: 30–40% vs on-demand.
Spot for non-critical workloads: Batch jobs, CI/CD runners, dev environments — all good candidates for Spot. 70–90% cheaper than on-demand.

Step 4: Optimize Storage

S3 is cheap but not free at scale:

Move infrequently accessed data to S3 Infrequent Access or Glacier
Enable S3 Intelligent-Tiering for data with unpredictable access patterns
Review and tighten S3 lifecycle policies

For EBS: audit volume types. gp2 volumes should be migrated to gp3 — same performance, 20% cheaper, and you can tune IOPS independently.

Step 5: Cloud Architecture Changes for Long-Term Savings

The biggest savings come from cloud architecture changes — this is where engineering leadership pays for itself:

Serverless for spiky workloads: Lambda + API Gateway is dramatically cheaper than always-on EC2 for workloads with variable traffic
CloudFront for everything public: Reduces origin load and data transfer costs
RDS Proxy: Reduces database connection overhead, lets you use smaller instances
AI-powered monitoring: Use agentic AI tools to continuously scan for cost anomalies and auto-recommend optimizations

What to Expect

A typical 3-month engagement on a $50k/month AWS bill:

Month 1: Tagging, visibility, kill obvious waste → 15–20% reduction
Month 2: Rightsizing, Reserved Instances → additional 15–20%
Month 3: Architecture optimizations → additional 5–10%

Total: 35–50% reduction, sustained.

This kind of process transformation — from reactive cloud spending to strategic cloud architecture management — is exactly what a fractional CTO engagement delivers. The savings typically pay for the engagement itself within the first month.

Software Engineers Who Will Thrive in the AI-Powered Future

khurram bilal — Tue, 15 Sep 2026 00:51:00 +0000

Why the role of engineers is shifting from writing code to designing systems in the age of AI.

“AI writes messy code”

If you’ve spent time in developer communities recently, you’ve probably heard this more than once. And to be fair, there’s some truth to it.AI-generated code can sometimes be verbose, inconsistent, or unreliable. It may miss edge cases, introduce subtle bugs, or produce solutions that don’t always hold up well in real production environments.But focusing only on the quality of AI-generated code misses the bigger shift happening in software engineering.

The real question isn’t how good AI code is.
The real question is how AI is reshaping the role of engineers.

The Reality of AI-Generated Code

AI coding tools have improved rapidly over the past few years, but they still have clear limitations.Developers often notice that AI-generated code can:

Miss edge cases in more complex scenarios
Produce inefficient or overly verbose implementations
Introduce hidden bugs
Lack awareness of the broader system architecture
Generate inconsistent patterns across a codebase

For engineers who care about scalability, performance, and long-term maintainability, these issues are easy to spot.

But there’s something important that often gets overlooked in these conversations. Messy code isn’t new.

Large production systems have always contained:

Legacy code written years ago
Quick fixes implemented under tight deadlines
Inconsistent coding patterns across teams
Technical debt accumulated over time

So the existence of messy code isn’t the real disruption.The real difference today is speed.AI can now generate code faster than ever before.

The Shift in Software Engineering

Because AI can accelerate implementation, the value engineers bring to a project is gradually moving beyond simply writing code.

Instead of spending most of their time creating boilerplate or repetitive implementations, engineers are increasingly focusing on higher-level responsibilities such as:

Designing system architecture
Reviewing and refining AI-generated code
Making decisions about scalability and performance
Ensuring long-term reliability and maintainability

In many ways, AI behaves like an incredibly fast junior developer. It can produce solutions quickly, but it still requires direction, context, and careful review. Engineers who deeply understand systems are the ones best equipped to guide these tools effectively.

Why Experience Still Matters

Despite its growing capabilities, AI still struggles with the kinds of problems experienced engineers solve every day.

For example:

Designing scalable architectures
Evaluating performance trade-offs
Debugging complex system failures
Managing distributed systems
Anticipating subtle edge cases

These challenges require context, judgment, and real-world experience qualities that AI still cannot fully replicate.That’s why human expertise remains essential, especially in complex production environments.

The Engineers Who Will Thrive

The engineers who will thrive in the AI-powered future are not the ones who ignore AI. They are the ones who learn to work with it effectively.

Instead of viewing AI as a threat, they treat it as a powerful tool that accelerates development and allows them to focus on bigger challenges.

These engineers will spend less time simply writing code and more time:

Thinking about system design
Improving product impact
Building scalable solutions
Guiding AI toward better implementations

In other words, the role of the engineer is evolving – from code writer to system builder.

Final Thoughts

AI may not replace software engineers entirely, but it will likely replace engineers who choose not to adapt.

Throughout the history of technology, every major shift has changed how developers work. From version control to cloud computing to automation, the engineers who embraced new tools early gained a clear advantage, while those who resisted eventually fell behind.

AI-assisted development is simply the next step in that evolution.The engineers who will thrive in the AI-powered future won’t just be people who write code. They will be problem solvers engineers who understand the bigger picture, think in systems, and design end-to-end solutions.

Instead of focusing only on implementing code, they will focus on understanding problems, designing scalable architectures, and guiding AI tools toward better outcomes.

In other words, the future belongs to engineers who move beyond being just code coders and become system thinkers and solution designers.

#SoftwareEngineering #ArtificialIntelligencce #AIinSoftwareDevelopment #SystemDesign #FutureOfWork #Developers #TechInnovation #TechCareers

https://www.tech-sprinter.com/blog/software-engineers-who-will-thrive-in-the-ai-powered-future

Software Engineering Beyond Today

khurram bilal — Mon, 14 Sep 2026 21:51:00 +0000

by: Khurram Bilal

The Future of Software delivery

In the world of software engineering, transformation rarely happens by accident. It emerges when we imagine boldly, design intentionally, and empower teams to build with clarity and purpose.

The future of engineering isn’t just about writing better code, it’s about rethinking how we work, how we deliver value, and how technology can elevate human potential.

A Vision Rooted in Innovation and Intent

Every transformational journey begins with a spark – a belief that things can be better. That spark, combined with strategic action, leads to meaningful change.

The engineering evolution we are stepping into today is the result of that blend: courageous imagination paired with deliberate execution. It hasn’t been the easiest path, but it has undoubtedly been the most rewarding. Each milestone proves that the future we envision is well within reach and more exciting than ever.

The Future of Engineering: Intelligent, Empowered, and Human-Centric

As we look ahead to 2026–27, the direction is clear:

Empower people to do their best work while intelligent systems handle the repetitive, operational, and predictable tasks.

This shift is not just technological- it’s cultural.

It transforms how teams collaborate, innovate, and deliver.

Key pillars shaping this future include:

1. Smarter Product and Project Operations

By integrating intelligent tooling and streamlined structures, teams can move with clarity and confidence -reducing overhead and unlocking more time for strategic work.

2. Engineering Excellence Through Focus

Developers thrive when they can focus on complex problem-solving, architecture, and innovation. Automation and AI support systems will free their time from low-impact tasks.

3. AI-Driven Engineering Capabilities

AI engineering is no longer a separate function -it’s becoming a foundational layer across the software lifecycle. From planning to testing to delivery, intelligent agents will guide and support teams at every step.

4. A Unified Structure for the Future

Modernizing Product, PMO, Development, and AI Engineering functions ensures teams stay aligned, agile, and future-ready. This synergy strengthens innovation and accelerates value delivery.

This Is Not Just a Roadmap – It’s Engineering, Elevated

The journey ahead is more than a list of initiatives.

It’s a transformation in mindset, structure, and capability.

🔮 It’s engineering amplified by intelligence.

🔮 It’s value multiplied.

🔮 It’s a future where teams think bigger and build smarter.

We are not just preparing for what’s next – we are defining it.

The Exciting Road Ahead

The progress so far is only the beginning. With every improvement, every iteration, and every bold decision, we move closer to a future where engineering is more innovative, more efficient, and more human-empowering than ever.

The road ahead isn’t just achievable – it’s inspiring. And the best part? We’ve only just begun 🚀

AI #EngineeringRoadmap #Productivity #ContinuousDelivery #Automation #CloudNative #DevOps #AIignEngineering #FutureReady #Innovation #softwareengineering

Scaling Engineering Teams for Global SaaS Delivery

khurram bilal — Mon, 14 Sep 2026 18:51:00 +0000

Delivering SaaS globally is not just about writing code. It is about managing cultures, timelines, languages and expectations at the same time. Over the past 15 years I have led end-to-end software engineering and implementation efforts across 7 countries, including Korea, China, Saudi Arabia, Thailand and Singapore.

Here is what actually held up across all of them, and what I would tell anyone building high-performance engineering teams that have to scale, adapt and deliver regardless of geography.

Understand Local Business Culture First, Not Just Requirements

One of my clearest takeaways from onsite implementations — Mercedes Benz Korea and Hyundai Auto Finance China among them — was the importance of local business etiquette.

Requirements documents travel well. Working norms do not. Agile rituals, approval chains and tech stack preferences all differ by market, and a team that ignores those differences spends its first month being quietly corrected instead of shipping. Aligning with local practice is not a courtesy. It increases velocity and stakeholder trust, because the people who have to approve your work recognise the way you are working.

The practical move is to build a localized roles-and-responsibilities matrix early. Clarify who owns what, and match those roles to cultural expectations rather than to your own org chart. Do it before the first sprint, not after the first escalation.

Build Core Teams Around Agility, Not Just Skill

During my leadership at ARVO and NETSOL, I did not simply hire the best developers available. I hired adaptive learners who could rotate between roles as the work demanded.

That distinction matters more at distance than it does in one office. A distributed team cannot reshuffle informally over a desk. When a market goes quiet or a compliance deadline pulls three people onto one workstream, you need engineers who can move without a reorganisation. Specialists give you depth in a role. Adaptive learners give you a team that survives the roles changing.

Agile practices, daily standups and cloud-based workflows kept those teams aligned across time zones. In practice that meant Azure Boards and Azure DevOps for delivery, JIRA for tracking, Git branching strategies to keep parallel work from colliding, and Trello where lightweight project management was enough.

The measurable result was a 40% reduction in onboarding time and improved cross-team collaboration metrics. Onboarding is the number worth watching, because in a team that rotates roles you pay it repeatedly rather than once.

Let CI/CD Absorb the Complexity

Rolling out SaaS products across multiple markets means frequent updates, and every additional market multiplies what a release has to satisfy. A robust CI/CD pipeline built on Azure DevOps is what kept that manageable. It gave us:

Weekly code merges, so divergence never had time to accumulate
Automated testing across locales, rather than one canonical locale and hope
Staged deployments for compliance-heavy clients such as Saudi Aramco

That last point is the one teams underestimate. Compliance requirements do not slow you down because they are strict. They slow you down when they are handled manually, per release, by whoever remembers them. Encoding them as deployment stages moves that knowledge out of people's heads and into the pipeline, where it runs the same way every time.

The approach maintained velocity and quality without compromising regional requirements — which is the whole trick, because in global delivery those two goals are usually presented as a trade.

Close the Tech-Business Gap With Tooling

The last gap is not technical. Stakeholders who cannot see delivery status will ask for status, and answering them by hand is a tax paid every week by the people you least want interrupted.

With certifications in PL-600, PL-200 and Power BI, I have built apps and dashboards that let business users track project KPIs across regions, visualise resource performance, and automate progress reporting themselves.

Those tools reduced manual reporting by 60% and let non-technical stakeholders stay in sync with delivery timelines without routing every question through an engineering manager. Across 7 countries, that is not a reporting convenience. It is what stops a delivery lead in one region becoming a bottleneck for executives in another.

What Actually Scales

Looking across all 7 countries, the parts that transferred were never the technology choices. They were the decisions that removed a human bottleneck: a responsibilities matrix agreed before the work started, engineers who could change roles without a reorganisation, compliance encoded in a pipeline instead of remembered, and reporting that answered itself.

Skill is what gets a team hired. Adaptability, and the systems that stop good people becoming single points of failure, is what lets that team deliver in a market it has never worked in before.

The Joint Discovery Session: Why Five Perspectives Beat One Requirements Document

khurram bilal — Mon, 14 Sep 2026 15:51:00 +0000

September 4, 2026

A requirements document captures what one professional lens notices. A joint discovery session lets five disciplines hear the client firsthand—and reveal ambiguity before it becomes rework.

Episode 2 of the AI-Augmented Parallel SDLC series. The pillar article introduced the full model: discover once, run three workstreams in parallel, and converge at one quality gate. Episode 1 explained how queues and lost context create handoff debt. This episode shows how to remove that debt at intake.

The idea in 30 seconds

One conversation: the domain expert, BA, designer, developer, and QA attend together.
Five lenses: each person records what their discipline is trained to notice.
One outcome: contradictions surface while they are still cheap to resolve.

In this article

Why documents lose context
How five roles hear one sentence
Why disagreement is useful
How AI organizes the notes
The economics
A six-step protocol

Most software delivery methods begin with the same quiet assumption: someone interviews the client, then writes the document everyone else will work from.

We have spent decades polishing that ritual: better templates, stricter sign-offs, and more elaborate traceability. All of it optimizes the artifact. Very little of it questions what the artifact removed.

The more useful question is not “How do we improve the requirements document?” It is “Why does one document have to mediate the conversation at all?”

The inherited answer is “so everyone shares the same understanding.” In practice, the document replaces several firsthand understandings with one secondhand summary—and distributes that compressed version through the team.

A joint discovery session removes that filter. The domain expert, BA, designer, developer, and QA join one live conversation under a simple rule: every discipline captures its own notes through its own professional lens. No master scribe and no “definitive” summary. Five perspectives, one source.

This is not about putting everyone in the same room. A remote or hybrid session works just as well. What matters is simultaneous, firsthand access: every discipline hears the same words, can interrupt, and can ask the question its craft makes visible. A recap, recording summary, or requirements document cannot recreate that moment.

Five sets of notes may sound like duplication. They are not. They are coverage.

One lens compresses the conversation into a projection. Five parallel lenses capture it as a survey.

A requirements document is a lens, not a record

The first fidelity loss in requirements engineering does not happen during a handoff. It happens at capture.

When a BA listens to a stakeholder, they naturally filter for business rules, entities, and scope boundaries. That is expertise, not negligence. But the resulting document is still a projection through one professional lens. What falls outside that lens is not mistranscribed; it may never be captured.

Then the projection is projected again. The designer extracts screens, flows, and states from text that may have lost spatial nuance. The developer derives data contracts from the resulting interface. QA reconstructs expected behavior from all of it. Compression stacks on compression.

It is the semantic telephone game—and the first loss can occur before the first handoff.

A document authored by one discipline can only capture what that discipline was trained to see. No review cycle can validate what was never recorded.

One sentence, five professional readings

Consider one sentence an operations lead might casually mention during discovery:

“Users can usually edit an invoice after it’s sent.”

It sounds harmless. Yet each specialist hears a different risk because each discipline is trained to find a different class of problem:

One sentence, five parallel analyses — each preventing a different downstream failure.

In a sequential chain, that discussion rarely happens at once. The sentence is flattened into one line—“Invoices are editable post-dispatch”—while the unanswered questions reappear later as change requests, redesign, schema rework, or defects.

In a joint session, the team can unpack the sentence while the domain expert and the original context are still present.

The discrepancies are the deliverable

The obvious objection is that five sets of notes will contradict one another.

They will. That divergence is not a failure mode; it is useful evidence.

If the engineer writes “edits create an immutable version” while the designer writes “edits update fields in place,” the session did not create a conflict. It exposed an architectural contradiction that already existed—early enough to resolve it in minutes with the client present.

A sequential chain hides that contradiction inside the artifact. Each discipline resolves the ambiguity independently until the interface, API, and test expectations collide during integration.

Divergent notes don’t manufacture disagreement. They reveal misalignment that was already there — while resolution costs minutes instead of sprints.

“Won’t five perspectives create noise?”

Cross-functional discovery does create more questions. The key is that they arrive while the people who can answer them are together—not weeks later in separate review queues.

The alternative is not silence; it is deferred disagreement. When the BA and client work alone, an early workflow suggestion can harden into an approved requirement before technical feasibility, interaction states, or failure modes have been explored.

That is how a business problem quietly turns into a prescribed solution. The client describes a pain point; the BA documents the most visible workflow; and a provisional idea becomes “the requirement.” A developer joining later may recognize a much simpler native capability, but by then the longer path has scope, screens, and sign-off attached to it.

By the time the document reaches development and QA, challenging the path can feel more expensive than building it. The developer reads it and thinks:

“Are we solving duplicate payouts, or do we need an auditable record of who authorized them? If it is the latter, an event log and notification may replace this four-step form.”

Asked live, that question can save a backlog. Asked after sign-off, it can trigger re-education, redesign, and a formal change request. Many teams take the path of least resistance and build what was written.

What useful interruption looks like

Put design, engineering, and QA in the same live session as the client, and the dynamic changes:

Engineering tests the proposed mechanism. The developer separates the business outcome from the suggested implementation and offers a simpler route where one exists.
Design exposes invisible states. The designer asks what a person sees before, during, and after an exception—not only on the happy path.
QA defines the boundary. For a “simple batch upload,” QA asks: “If row 4,000 of 10,000 fails, do we roll everything back or process the clean rows and return an error ledger?”

The facilitator’s job is to keep these interventions short, decision-oriented, and tied to the user or business outcome. The result is not a design-by-committee session. It is faster access to the questions that would otherwise interrupt delivery later.

How AI keeps five note streams usable

Five raw note streams create an obvious operational cost: someone must structure them, preserve their provenance, and compare them. If that work falls back to one human editor, the old bottleneck returns.

This is where AI changes the economics. The pillar article separates each role into three kinds of work: production (drafting the artifact), memory (retaining decisions), and judgment (deciding what is right). AI can lower the effort of production and memory. Judgment—and accountability—stay with named human owners.

Keep each stream distinct. BA notes can seed user stories, design notes can seed flows, engineering notes can seed contracts, and QA notes can seed test scenarios. The agent drafts; the discipline owner reviews and approves.
Compare without flattening. A reconciliation pass flags conflicting assumptions across the streams and turns them into a decision agenda. The output is a Reconciliation Matrix, not a new master summary.
Preserve the source. With explicit participant consent and appropriate access controls, the transcript can retain the rationale behind decisions. A later question can be answered from the original context rather than a thirdhand paraphrase.

Agents structure each stream separately and diff across all five. No stream is ever collapsed into a master document.

AI does not replace attendance, authorship, or accountability. It makes the five perspectives affordable to maintain. The humans spend judgment in the session; the agents reduce the clerical work needed to turn that judgment into durable, reviewable artifacts.

The economics of cross-functional discovery

The cost objection is reasonable: five specialists in a half-day workshop consume roughly 20 person-hours. The relevant comparison, however, is not a one-person meeting. It is the end-to-end cost of sequential clarification.

Compare the two paths:

Joint discovery: about 20 person-hours invested up front, followed by immediate discipline-specific work.
Sequential discovery: interviews, drafting, reviews, clarifications, and handoffs spread across calendar time—while downstream roles wait or work from partial context.

Twenty person-hours up front versus weeks of queues, sign-off latency, and compounding rework.

Your numbers will vary, so measure them. Track time from the first discovery conversation to the point when development, design, and test preparation can all begin. Then add the hours spent clarifying or rebuilding misunderstood behavior. That is the real baseline.

Beware the consolidation reflex

A common regression appears a few sprints in: a well-meaning lead asks the BA to “clean up” the separate notes into one definitive master document.

That restores the single-lens bottleneck. Keep a shared decision log, but preserve the source and owner of each perspective. Alignment should happen through explicit reconciliation and quality gates—not by crowning one set of notes as the only truth.

How to run your first joint discovery session

Pilot it without changing your whole process

Choose one medium-sized feature with real domain complexity. Run one 90-minute joint session, preserve the five note streams, and compare the next two weeks against a similar feature. Measure clarification loops, blocked days, late scope changes, and rework—not meeting sentiment.

The best handoff is the one you remove

The joint discovery session removes the most damaging handoff: the one between the client’s intent and the people who must design, build, and test it. Every key discipline hears the same source, asks its own questions, and leaves with firsthand context.

You still need durable artifacts. What you do not need is a single perspective pretending to be the entire truth.

One set of notes is a summary. Five professional perspectives create coverage—and make the missing decisions visible.

In this series

The AI-Augmented Parallel SDLC — the full blueprint: discovery once, three parallel workstreams, one gate.

Episode 1: The Handoff Chain — Why Your Team Is Mostly Paying Handoff Debt

Next up — Episode 3: The Three Parallel Workstreams: How Development & UX, Requirements, and Test Launch Simultaneously on Day One Without Collision.

The Handoff Chain: Why Your Team Is Mostly Paying Handoff Debt

khurram bilal — Mon, 14 Sep 2026 12:51:00 +0000

Episode 1: The AI Augmented Parallel SDLC

Audit a delivery pipeline honestly. Not the Gantt chart, the actual clock.

What you find is uncomfortable: most of a feature’s lead time isn’t spent building the feature. It’s spent between people. The PRD sits in a review queue. The Figma file waits for sign-off. The build waits for a QA slot.

Lean practitioners have measured this for decades and the number barely moves: well over half of total lead time, often 70% or more, is queue time. Nobody is working on the thing. Everybody is waiting for permission to.

We ran a chain like that for years. And for years we did what most delivery organizations do: tighter SLAs, better templates, more detailed tickets, one more sync meeting. It took us embarrassingly long to notice we were tuning the chain when the chain itself was the problem.

The handoff debt is really two debts, and only one of them shows up on the books.

The first debt: the queue trap

The visible debt is idle time. Every discipline’s start condition is someone else’s finish condition, and the blocking isn’t partial. It’s total.

Watch what each seat is doing while “requirements sign-off” is in progress:

Development can’t start. Scope is officially fluid, so any code written now is “at risk.” The rational move is to wait.
QA is blocked twice over. Every test case has to trace to a signed requirement, so QA can’t design a single case, prep test data, or build automation scaffolding. And even after sign-off, they can’t execute anything until a build exists.

So test prep, which should be the most thoughtful work in the pipeline, gets crammed into the final weeks under deadline pressure. Meanwhile the most expensive people in the organization spend the front of every engagement contractually idle.

And sign-off isn’t a moment. It’s a loop.

Draft one goes out. The client takes days to review; they have a business to run. Comments come back stripped of context. A clarification meeting gets scheduled. New stakeholders show up with new opinions. Version two goes out. Three to five cycles of this is normal, and every round-trip adds elapsed days while often subtracting clarity.

We’ve watched two to six weeks pass this way. Zero code, zero tests, an entire team parked behind a document playing ping-pong.

Here’s the part that took us longest to accept: none of this is a discipline problem. The queue isn’t caused by anyone underperforming. It’s a structural property of serialized work. Toyota figured this out on factory floors seventy years ago. Batch handoffs are the waste.

You cannot manage your way out of a queue that your process is designed to create. You can only redesign the process so the queue never forms.

The second debt: the semantic telephone game

The hidden debt is worse, because nobody logs it. Every handoff is a translation, and every translation loses something.

Client intent becomes a BA document becomes screens becomes code. By the time QA verifies the build, they’re verifying a fourth-hand account of what the client actually meant. And the mismatches get filed as “bugs” against a developer who faithfully built exactly what the document said.

What decays isn’t the happy path; everyone remembers the happy path. It’s the material nobody wrote down because it felt obvious at the time: the edge cases, the validation rules, the reason a constraint exists at all.

Three handoffs later, the assumptions are the requirements.

We’ve known this for 70 years. Why is it only fixable now?

Nothing in the diagnosis is new. Concurrent engineering attacked serialized phases in the 1980s. Lean software named queue time as waste in the 2000s. The Agile manifesto was written against handoffs. So why did the chain survive every reform?

Because every reform attacked the process while the cost structure underneath stayed put. Three costs held the chain in place, and no methodology could vote them away:

Rework was human-priced. Starting before sign-off meant a human might build the wrong thing twice, at full cost. Waiting was rational insurance.
Parallel scaffolding was manual. Mocks, stubs, contract tests, synthetic data, all hand-built by the same scarce engineers, often costing nearly as much as the real thing.
Context could only live in people or documents. The BA-as-translator role existed because there was no other storage medium for intent. The telephone game wasn’t a flaw in the chain; it was the chain.

Agile shortened the chain into two-week loops. But inside most sprints the mini-waterfall persisted: signed, then built, then tested. Smaller batches, same physics.

What AI changed isn’t the diagnosis. It’s the arithmetic.

Agents make production near-free, so a 15-20% requirements divergence flips from budget hole to budgeted band. Starting early flips from reckless to rational.
Agents generate mocks, contract tests, and test-case drafts in minutes, so the scaffolding that made parallelism unaffordable now costs almost nothing.
Agents hold project memory that never forgets, never resigns, and never summarizes away the edge case that felt obvious in the moment.

The chain was never a process mistake. It was the optimal answer to an old cost structure. Change the costs, and the optimal process changes with it. That’s not a criticism of anyone running it. It’s arithmetic.

One warning: dropping AI coding agents into an unchanged sequential process just speeds up the 30% of time that’s actual work, while the 70% of queue time sits untouched. Total delivery improves about 15%, and the organization concludes AI is overhyped. They benchmarked a component. The debt lives in the system.

What replaces the handoffs

The chain’s front end collapses into one joint discovery session: client, BA, designer, developer, and QA in the same session, each taking notes through their own lens. The designer hears a screen flow, the tester hears an edge case, the developer hears a data model, from the same sentence, firsthand, at the same time. Zero handoffs where fidelity matters most, because everyone was at the source.

Then three workstreams run concurrently:

Development and UX have a working frontend within days.
The BA elaborates requirements as a parallel track, not a front gate. The client back-and-forth still happens; it just no longer holds anyone hostage.
QA drafts test cases from discovery notes while the build is in flight, then aligns and locks the suite at sign-off instead of starting from a blank page.

The handoffs don’t get faster. They stop existing.

The one metric that tells the truth

Flow efficiency: active work time divided by total elapsed lead time.

Most sequential teams, measured honestly, sit at 10-15%. That number is the size of your handoff debt, stated plainly. Story points and velocity all look fine while the system starves in queues. Flow efficiency only moves when the waits between phases die.

The handoff debt compounds in a currency that never appears on a timesheet: elapsed time and lost meaning. The teams that escape it aren’t the ones who made their handoffs faster. They’re the ones who made their handoffs unnecessary.

This is Episode 1 of a series on the AI Augmented Parallel SDLC. Next up: the Joint Discovery Session, and why five people taking five different sets of notes from one conversation beats any document ever written.

What’s your team’s flow efficiency, honestly?

Leasrn more: https://www.tech-sprinter.com/blog/the-ai-augmented-parallel-sdlc