DEV Community: khurram bilal

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

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

khurram bilal — Mon, 14 Sep 2026 12:27:32 +0000

Episode 3 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 1 put numbers on what the handoff chain costs you. Episode 2 got rid of the handoff at intake. This one covers the question everybody asks first and almost nobody answers properly, which is what actually happens on Monday morning.

The first time we ran three workstreams off a single discovery session, I spent most of the week waiting for the crash.

It was a mid-sized engagement, an invoicing and approvals module, nothing anyone would call exotic. Discovery wrapped on a Thursday afternoon. Friday morning the developers started building, the BA started elaborating scope, and QA started drafting test scenarios, all three at once, working from notes that were less than a day old and a requirements document that did not exist. I checked the dev channel far more often that week than I needed to. On the Tuesday I asked the BA twice, in about four hours, whether anything had changed that the developers needed to know about. She told me the second time that she would tell me if it had.

Nothing crashed. Not that week, not on that engagement, and not since, though I want to be careful here because it took us two more projects before I could explain why rather than just report it.

The explanation has two parts. One of them is a cultural thing that most teams never say out loud, and the other is a twenty-minute exercise with a whiteboard.

The part nobody says out loud

If you ask a delivery lead why development can't begin before requirements are signed, you'll hear something about uncertainty. Unstable ground, wasted effort, building on sand. It's a perfectly reasonable answer and I gave it myself for years.

It also isn't what's really going on.

What's really going on is that in a sequential model, a developer who starts early and builds something that later turns out to be wrong ends up owning that waste personally. It becomes their rework, their velocity dip, their thing to explain in the retro. A developer who waits for sign-off and then builds precisely the wrong thing, on the other hand, is completely covered, because the signed document told them to. Same wasted fortnight, two very different conversations.

So waiting isn't timidity. Given how we've set up the incentives, waiting is just correct, and it will be correct every time until somebody changes the incentives.

I've started calling this the Blame Myth, and I think it's the wall holding up sequential delivery. Those long requirements phases aren't genuinely an attempt to reach certainty, because everyone sitting in the room already knows certainty isn't on offer. What they're really doing is establishing in advance whose fault it's going to be. The document functions less like a specification and more like an insurance policy, which is also why it keeps growing and why nobody ever feels it's finished.

Both models receive the same change request. Only one of them needs somebody to be at fault for it.

Parallel delivery doesn't fix this by asking anyone to be braver. It fixes it by taking the penalty away.

We tell the team, out loud and then again in writing, that the client is going to change their mind. Not that they might. Across our engagements it lands somewhere around 15 to 20% of built scope moving after discovery, and it has been consistent enough that we now put it in the plan and price it. It gets estimated, funded and scheduled in the same unremarkable way that testing or deployment does.

Once rework is sitting there as a line item instead of arriving as an incident, the arithmetic flips for everyone involved. A developer who starts on day one and absorbs a change three weeks later hasn't failed at anything. They've done the thing the plan said they'd be doing, and nobody's opening a defect against them for it.

Stop trying to prevent change. Plan the rework instead.

The client gets velocity and something real to look at early. The engineering team gets to stop being defensive. Those two usually get framed as a trade-off, one bought at the other's expense, and I don't think they are. They both fall out of the same decision.

Monday call, Tuesday prototype

The economics here have shifted recently, and more than people have adjusted to.

Our standard now is that pre-sale notes, early client thinking and whatever half-formed ideas came out of the first conversation get turned into a running build almost straight away. If a client call is confirmed for Monday, we aim to walk into Tuesday's meeting with something they can click. Not slides, not wireframes, an actual interface with their workflow in it.

That's only possible because prompt-to-UI generation has taken the cost of a structural first draft down from about a fortnight to an afternoon. Five years ago "let's just build it and find out" was reckless advice that I would have argued against. The first version is now cheap enough that not building it is the more expensive choice.

The bigger effect isn't the time saved, though. It's what it does to the conversation. Clients are poor at reviewing abstractions and very good at reacting to interfaces. Hand somebody twelve pages of requirements and you'll get typo corrections and a comment about the order of two sections. Put a screen in front of them with their own process half-implemented and you'll get the objection that actually matters, usually inside ninety seconds, and usually the one that would otherwise have shown up at UAT four months later with three sprints of work sitting behind it.

The hatched blocks are handoff debt from Episode 1, drawn to scale. Nobody writes those days down anywhere.

Split by volatility, not by phase

Sequential delivery divides work up by phase, design then build then test, on the assumption that the dangerous variable is time. Work done early is work done on unstable ground, so you stabilise the ground first and then walk everyone across it in single file.

The flaw in that is that scope isn't uniformly unstable. In any feature set there are things the client will never revisit and things they'll change their mind about twice before lunch, and when you treat both as equally volatile you end up parking the entire team to wait for permission that only a handful of items ever actually needed.

So at the end of discovery, before anybody opens an editor, we spend twenty minutes going over the captured scope and asking one question of each item on it:

If the client changed their mind about this next Tuesday, what would it cost us?

You get two variables out of that question, how likely the change is and what it would cost, and between them they sort the scope into four piles rather than the two people expect.

Twenty minutes, a whiteboard, and the four piles that decide how your week goes.

Quadrant	The strategy	What belongs here
Stable core	Build it on day one. Expensive to change, unlikely to change. The safest work in the building.	Domain entities and relationships, authentication and roles, the navigation shell, integration boundaries and data contracts. Nobody wakes up on a Tuesday and decides an invoice shouldn't have a customer.
Decide first	Top of the decision queue, week one. Expensive and likely to change. Get these answered before Friday or parallel work really is a gamble.	Multi-tenancy and data isolation, immutable versions vs in-place edits, audit and compliance obligations, how money is represented.
Volatile edge	Build the seam now, fill it in week three. Likely to change, and cheap to change as long as the seam exists.	Approval thresholds and routing, notification and escalation policy, pricing and fee logic, field-level validation, partial-failure behaviour. Put it behind configuration, a feature flag, or a strategy interface.
Just build it	No ceremony required. Cheap and settled.	Static copy, standard CRUD on settled entities, conventional form layouts, admin and housekeeping screens. Most of what an agent scaffolds in an afternoon.

The decide-first pile is the one that earns the exercise. There are rarely more than four or five things in it, and they're the entire reason the BA keeps a ranked decision queue rather than a flat list of open questions. Everything else can carry on while the client is still making up their mind, which is the whole trick and, in fairness, the only genuinely clever part of any of this.

Day one: what each stream actually does

Every stream launches with one deliverable for the week and one hard constraint. People remember the deliverable. The constraint is the part doing the work.

The bottom row is the one teams skip, which is a shame, because it's the one preventing the collision.

Stream 1 — Development & UX

Ships by Friday: a clickable frontend with real navigation, real screens, real interaction and stubbed data behind it. In practice this is Tuesday's prototype, cleaned up and hardened into the actual product shell.

The guardrail: the application is the design artifact. Designer and developer work on the same running build, in the same repo, in the same week, and no files get exchanged, so there's nothing to drift apart.

Must not do: implement volatile business rules. If somebody is hardcoding an approval threshold in week one, the volatility split didn't work and you've already booked the rework.

Stream 2 — Requirements

Ships by Friday: elaborated stories and rules against the stable core, plus a ranked decision queue with the decide-first items sitting at the top of it.

The guardrail: the BA runs the client back-and-forth exactly as before. Review cycles still take days, the stakeholder nobody mentioned still turns up in round three with opinions, all of it still happens. It just stops holding three other people hostage while it does.

Must not do: treat the running build as the spec. Once the BA starts writing down what got built rather than what was meant, the model has quietly inverted itself, and in my experience nobody notices for about a month.

Stream 3 — Test

Ships by Friday: scenario-level coverage pulled from the QA notes taken during discovery, so risks, boundaries and failure modes, along with test data preparation and automation scaffolding.

The guardrail: write outcomes rather than clicks. "A partial batch failure commits the clean rows and returns an error ledger" will survive every redesign between now and the gate. "Click Upload, then Confirm, then check the toast text" will not survive the first one. The suite stays scaffolding until sign-off, and at the gate it gets aligned to the signed requirement and locked.

Must not do: run executions against un-signed-off stories or unstable builds and log what comes back as defects. This matters more than it sounds like it does. Testing against fluid requirements manufactures churn out of nothing, punishes the developer for having started early, and walks the Blame Myth straight back into a process built specifically to get rid of it. Of all the ways to lose this model, it's the fastest.

Three collisions, three guardrails

Parallel work doesn't fail in unpredictable ways. It fails in three recognisable ones, and none of the fixes is a meeting, mostly because rituals quietly decay the first time a deadline gets tight and structure doesn't.

Three failure modes, three structural answers. Not one of them is a standup.

1. Design drifting from build. The designer produces screens that can't be built at a sensible cost, or engineering invents patterns nobody specified. Drift needs distance to happen, and the file exchange is where the distance comes from. A Figma handoff is still a handoff, it just has a friendlier name. Put both people on the same running artifact in the same repo and whatever gap is left closes in a ten-minute conversation, because the thing being argued about is right there on screen and clickable.

2. Requirements diverging. A rule lands in week three that contradicts something built in week one. You can't prevent this and I'd be suspicious of anyone claiming otherwise. What you can do is make it visible and make it cheap, which takes two things: the seam, so it lands somewhere editable rather than in the foundations, and a broadcast rule, so that any change to shared understanding gets announced on the day it's decided rather than the day it's documented. Silent absorption is what hurts. A BA updating a story quietly because it obviously should have said that all along is how you end up with an integration surprise.

3. The test suite churning. QA writes step-level cases against an interface that's still being designed and then rewrites the suite three times before the gate. The intent never actually moved. Only the steps did.

What replaced the daily standup

We don't run a daily standup across the three streams. We did try, and within about a fortnight it had turned into three people reporting progress to each other with nothing to decide, which is a meeting I've sat in enough times to recognise early now.

What we run instead is a divergence sync, three times a week, capped hard at twenty minutes, with one question asked of each stream.

What changed in your understanding since we last spoke, and who does it affect?

Not progress, not blockers, just deltas in understanding. If nothing changed, that stream says so and we move on, and some weeks the whole thing is over in six minutes, which is a good sign rather than a wasted slot. Anything that can't be settled in the room goes onto the BA's decision queue for the next client session.

Where AI actually sits

Running three streams in parallel used to mean roughly tripling the headcount, which is why the idea stayed academic for about twenty years.

The pillar article split every role into three parts: production, memory and judgment. Agents have absorbed the first two, judgment stayed human and named and accountable, and that split is the only reason any of this is affordable now.

Development & UX: coding agents scaffold the shell, the CRUD, the routing and the stub data, configured with our house conventions. That's most of what a week-one clickable build consists of. The engineer reviews it, corrects it, commits it and owns the commit.
Requirements: a story-authoring agent drafts impact-aware stories in minutes with the prior decisions already in context. It also does something people reliably don't, which is remember in week nine why a constraint was added in week one. The BA reviews and signs off before anything enters the baseline.
Test: an agent proposes coverage from the discovery notes and flags gaps in scenario space. QA reviews it, prunes it and locks it. Later an execution agent runs the first cycle in minutes and QA validates every finding by hand.

The rule is the same in all three and it doesn't bend: the agent drafts, the human reviews and owns. Nothing gets into the baseline, not code, not a story, not a test case, not a test result, without a named person's signature on it.

How teams quietly revert to the chain

Nobody announces they're abandoning this. It decays instead, in a handful of familiar ways, and slowly enough that all the ceremonies stay in place while the thing underneath them stops working.

The design approval gate creeps back in. Somebody asks for sign-off on screens before development carries on. It sounds responsible, which is exactly why it works, and it rebuilds the first link of the chain.
A stream gets borrowed. QA gets pulled onto manual regression for a different release, loses two weeks of parallel prep, and arrives at the gate with nothing. These streams need protected capacity or they're just a diagram in a deck.
"Let's wait for the doc, it'll be ready Thursday." It is always ready Thursday. For a team that spent a decade waiting, waiting is the most natural thing available.
Convergence findings get logged as defects. This is the serious one and it's what the next episode is about. Give a developer a bug ticket every time a requirement legitimately moved and they will stop starting early, not loudly and not in protest, but rationally and permanently. The Blame Myth doesn't come back through the process. It comes back through the defect tracker.

Measure the system, not the people

Four numbers will tell you whether this is actually working.

If you only track one of them, track the last one.

Read the second one carefully, because it's the one people get backwards. You aren't aiming for zero divergence. Zero means the team waited, which is to say you bought certainty with calendar time and then described it as discipline. A stable, predictable band is the healthy result, and a number that swings wildly month to month usually means discovery isn't doing its job rather than that delivery isn't.

The fourth is the early warning system for everything else in this article. If every piece of rework is going into the tracker as a defect, the culture has already reverted, whatever the process documentation still says.

The three streams don't stay aligned because the people running them coordinate especially well. They stay aligned because the work got divided up so that being slightly wrong is cheap, and because nobody gets punished when it happens. Get those two right and parallelism stops being a risk you're managing. It just becomes how you work.

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

Next up — Episode 4: The Quality Gate, and the one word that decides whether your parallel model survives its second quarter, which is why convergence findings have to be logged as requirement gaps rather than defects.

What's the split in your current sprint? How much of what you're building is genuinely volatile, and how much of it has just been waiting for permission?