DEV Community: Mohammad Jodeh

Product Engineering Alignment

Mohammad Jodeh — Sun, 23 Aug 2026 06:31:33 +0000

A feature takes three days to code and three weeks to deliver. The difference is not always engineering capacity.

A developer starts implementation and discovers that an eligibility rule is undefined. Product needs an answer from operations. A missing UX state appears next. Then engineering finds that the requested behavior conflicts with the current data model, which forces a scope decision.

The code may still take three days. The delivery system takes three weeks.
This is where product engineering alignment becomes an engineering leadership problem. The visible work happens in code, but much of the elapsed time happens between decisions: waiting for clarification, resolving constraints, revisiting scope, and discovering assumptions that should have surfaced earlier.

The common response is to improve requirements, add meetings, or demand better estimates. Those actions may help, but they do not address the core issue. Product-engineering alignment is primarily a decision-flow problem.
The useful question is not:

Are product and engineering communicating enough?

It is:

Where does work stop because the person holding it cannot make the next decision?

That question is more useful because it exposes where delivery actually slows down.

Why Product and Engineering Become a Delivery Bottleneck

Product and engineering approach the same feature with different knowledge. Product typically understands the customer problem, business priorities, stakeholder expectations, commercial constraints, and desired outcome. Engineering typically understands architecture, dependencies, operational risk, implementation alternatives, and the cost of changing the system. Neither side has the full picture, that is normal.

The problem begins when the process assumes one side can finish its thinking before the other begins. Consider a requirement that appears simple:

Allow customers to cancel an order.

Engineering cannot implement that correctly without answering several questions:

Until what stage can an order be cancelled?
What happens to a captured payment?
When does inventory become available again?
Can support override the restriction?
What happens after fulfillment starts?
Are some products excluded? Some are business decisions. Some reveal technical constraints. Others may require operations, finance, or support. The issue is not that the requirement was badly written. The issue is that the requirement contains decisions that no single function can complete alone. That is where the queue forms.

The Product Engineering Handoff Is the Wrong Mental Model

Many organizations still operate with an implicit flow like this:

Product defines → Engineering estimates → Engineering builds → Product accepts

The model is appealing because ownership appears clean. It is also misleading. Implementation is not just execution. It is also discovery.
A developer may discover that the data required by the feature has never been stored. A proposed workflow may depend on an external API that cannot support it. A supposedly expensive feature may have a much cheaper technical alternative. Those discoveries change the product decision.
That means the product engineering handoff cannot be treated as a one-way transfer of finished information.

Requirements contain assumptions

A requirement can be detailed and still be wrong.
Suppose product specifies:

Show customers their historical account balance for every month.

The statement looks precise. Engineering investigates and finds that the system stores only the current balance, while historical transaction data is incomplete before an earlier migration. The problem is no longer implementation. Now product must decide whether partial history is acceptable, whether another data source exists, or whether the feature itself should change. The requirement did not fail because it needed more documentation. It failed because an assumption remained invisible.

Technical discovery continues after implementation starts

Trying to remove all uncertainty before engineering begins creates another failure mode: teams spend excessive effort defining decisions that are cheap to change while still missing technical risks that only appear through investigation. The objective should not be zero iteration. The objective should be to avoid expensive late iteration. That requires product engineering collaboration where uncertainty is costly, not everywhere.

Better Product Requirements Are Not Enough

When delivery repeatedly breaks around unclear requirements, the natural response is to demand better PRDs, stricter acceptance criteria, or stronger definitions of ready. Those practices can help. But documentation is not the same as decision-making. A 15-page specification can preserve an unresolved question just as effectively as a three-line ticket.

Suppose a requirement says:

The dashboard must update in real time.

The sentence is clear. The intent may not be. Engineering may find that true real-time updates require significant infrastructure work, while a 30-second refresh would satisfy the actual user need at much lower cost.
If engineering is involved only after the solution is already committed, the conversation often becomes:

Why is engineering pushing back?

If engineering is involved while the solution is still flexible, the conversation becomes:

What is the simplest reliable way to achieve the outcome?

That is a better product decision. Good product requirements should create shared understanding. They should not function as contracts that transfer uncertainty from product to engineering.

How Misalignment Creates Software Delivery Bottlenecks

Poor alignment rarely appears as one dramatic failure. It appears as repeated friction.

Waiting

Engineering reaches a business-rule question and stops. The developer may switch tasks, but the original feature continues ageing.

Rework

Engineering makes a reasonable assumption because no decision is available. The assumption is later rejected. The implementation may be technically correct and still need to be replaced.

Overbuilding

Engineering solves a broader problem than the business actually needs. The team adds flexibility, configuration, or abstraction that never creates corresponding value.

Underbuilding

A business or operational constraint appears late and forces changes to workflows, APIs, storage, or validation.

Scope churn

A feature appears to expand throughout development. Sometimes that is genuine scope creep. Sometimes the original scope was never actually resolved. These are often diagnosed as estimation failures, productivity problems, or engineering communication issues.

But if work repeatedly stops around decisions, adding more developers will not remove the constraint. It will give you more developers waiting for the same answers.

Product and Engineering Communication Problems Are Usually One of Three Things

Before improving communication, identify what kind of problem you actually have. Many product and engineering communication problems fall into three categories.

1. Missing information

Ask:

Does someone already know the answer?

Suppose engineering needs to know whether premium customers can bypass a transaction limit, and product already has an approved policy. That is not a decision problem. It is an information-access problem.

The fix may be:

better documentation
clearer tickets
searchable decision records
easier access to the responsible person

Do not create a meeting to rediscover an answer that already exists.

2. Unresolved decisions

Ask:

Has the organization actually decided this?

Suppose the question is:

What should happen when an order is partially fulfilled?

If nobody has decided, better documentation will not help. The team needs the right people to make the decision. That may involve product, engineering, operations, finance, or another owner.

The key is to recognize the difference between missing information and missing decisions.

3. Hidden assumptions

Ask:

Are both sides working from the same interpretation?

Product may assume "cancel" means before fulfillment begins. Engineering may assume cancellation must work at any point before delivery.
Nobody asks because both sides believe the requirement is obvious.

Hidden assumptions are often more dangerous than unanswered questions because they do not look unresolved.

A useful pre-implementation question is:

What are we assuming in order to build this?

That tends to reveal more risk than asking whether the ticket is clear.

Improve Product Engineering Alignment by Moving the Right Decisions Earlier

"Move decisions earlier" can easily become heavyweight upfront design. That is not the goal. Not every decision deserves the same amount of attention.

A better model is to ask:

What is the cost of discovering later that this decision was wrong?

Resolve high-cost uncertainty early

Investigate early when a mistake could invalidate a large part of the implementation.

Examples include:

whether the required data exists
core business rules
external-system dependencies
regulatory constraints
data ownership
major API contracts
architecture choices that are difficult to reverse
performance requirements that affect system design

If the answer could fundamentally change scope, cost, or feasibility, it deserves early attention.

Keep cheap decisions flexible

Other decisions are inexpensive to change:

copy
minor validation behavior
internal implementation details
small layout choices
whether a confirmation appears inline or in a modal

Trying to freeze all of these before development creates process without reducing meaningful risk.

A practical rule is:

Resolve expensive uncertainty early. Preserve flexibility where change is cheap.

That is one of the most effective ways to improve product engineering alignment without making the delivery process heavier.

Replace Handoffs With Decision Ownership

Reducing handoffs does not mean everyone participates in every decision. That would create another bottleneck. Healthy collaboration still requires clear ownership.

Product owns the problem and priority

Product should be able to explain:

who has the problem
what outcome matters
why it matters now
which constraints are non-negotiable
what can be traded
how success will be evaluated

Product does not need to prescribe every implementation detail.

Engineering owns technical feasibility and trade-offs

Engineering should expose:

architectural constraints
dependencies
operational risks
implementation alternatives
major differences in cost
technical decisions that will be difficult to reverse

Engineering should not hide those choices behind a single estimate.

Shared decisions still need an owner

Some decisions require input from both sides:

reduce scope or delay delivery
choose a temporary solution or a long-term design
accept slower performance or invest in infrastructure
simplify UX to avoid disproportionate implementation complexity

Collaboration improves the information available to the decision-maker. It does not remove accountability. A team can disagree and still be aligned if ownership is clear, the trade-off is understood, and the work can continue.

What Healthy Product Engineering Collaboration Looks Like

Healthy collaboration is visible in delivery behavior, not meeting count. Engineering is involved while important solution choices are still flexible.
Product can question technical complexity without treating engineering estimates as resistance.
Engineers can challenge requirements without being treated as blockers.
Important decisions and their rationale are recorded.
Teams distinguish required outcomes from proposed implementations.
Unresolved decisions are escalated before they sit silently inside tickets.
When engineering discovers something that materially changes the cost or feasibility of a feature, product can revisit scope.
None of this requires permanent synchronization.

The objective is not more communication. It is lower decision latency.

AI-Assisted Development Moves the Constraint Upstream

AI-assisted development can accelerate some implementation work, but the effect varies by task, codebase, tooling, and review requirements. That limitation matters.
Even so, when coding becomes faster for a particular class of work, the surrounding delays become more visible. Imagine an AI coding agent implements a well-written ticket quickly. The implementation passes review. A stakeholder then points out that the ticket encoded the wrong refund policy. The organization has produced the wrong software faster.
The coding tool did not create the problem. The unresolved assumption entered the system before implementation. This is why faster code generation does not automatically remove software delivery bottlenecks.

Approval, prioritization, requirement clarification, architecture decisions, stakeholder input, and ownership can still move at the same speed.

As implementation becomes cheaper in some areas, deciding what to build and validating the assumptions behind it become relatively more important. AI can reduce parts of the cost of producing software. It does not automatically reduce the cost of deciding what software should be produced.

A Practical Way to Find the Real Bottleneck

Engineering leaders do not need to redesign the entire product process to diagnose this problem. Start with one feature that felt slower than it should have been. Reconstruct its path from request to production.

Record:

active implementation time
waiting time
clarification cycles
decision points
scope changes
rework
approval delays
stakeholder rejection

Then inspect every meaningful pause and ask:

Why could this feature not move forward?

Classify the answer.

Technical execution — engineering genuinely needed more time to build or validate the change.
Missing information — the answer existed but was not available to the team.
Unresolved decision — someone needed to make a choice.
External dependency — another team, vendor, or system blocked progress.
Approval — a decision existed but required authorization.
Capacity constraint — the required person or team could not take the work.

Then repeat the exercise across several features.

Do not focus on isolated delays. Look for recurring patterns.
If every pricing change waits for one executive, the bottleneck is decision authority.
If architectural choices queue behind one principal engineer, the bottleneck is technical decision capacity.
If features repeatedly reopen because business rules appear after implementation, the bottleneck is discovery and requirement shaping.
If teams commit dates before investigating external dependencies, the bottleneck is sequencing.

Those are system problems. Asking individual teams to communicate better will not fix them.

Alignment Is About Flow, Not More Meetings

Effective product engineering alignment does not require perfect requirements, permanent agreement, or product and engineering attending every discussion together.

It requires a delivery system where important decisions reach the right people before uncertainty becomes expensive code, rework, or waiting. That changes the leadership question.

Instead of asking:

Why is engineering taking so long?

Ask:

Where did this feature spend time unable to move forward, and what decision was it waiting for?

Sometimes the answer really will be engineering capacity.
Sometimes the architecture is the constraint.
Sometimes the feature is simply difficult.

But when implementation is not the bottleneck, adding developers, expanding PRDs, or creating more status meetings will not increase delivery speed.
Sometimes the fastest way to ship more software is to shorten the distance between a question and the person who can decide it.
Discussion question: Where does work most often stop in your organization: implementation, missing information, unresolved decisions, or approval?

Get $175 Free Claude Code Credits

Mohammad Jodeh — Sat, 22 Aug 2026 05:41:39 +0000

Claude Code is extremely useful for software development, but heavy API usage can become expensive.

If you want to try Claude Code without immediately paying for Anthropic API usage, AgentRouter provides another option.

By registering through my referral link using your GitHub account, you can get $175 in free AgentRouter credits:

👉 Register with AgentRouter using GitHub and get $175 in free credits

You can use your AgentRouter balance with supported coding agents including Claude Code and Codex.

Disclosure: This is my referral link, so I may also receive referral benefits when you register through it.

What Is AgentRouter?

AgentRouter acts as an API gateway between coding agents and AI models.

Instead of Claude Code sending requests directly to Anthropic, you can configure it to send requests through AgentRouter:

Claude Code
     ↓
AgentRouter
     ↓
AI Model

You create an AgentRouter account, generate an API token, and temporarily configure Claude Code to use AgentRouter.

The advantage of using temporary configuration is that it only affects the terminal session where you set it.

Close the terminal, and your normal Claude Code configuration remains unchanged.

Step 1: Register with Your GitHub Account and Get $175 in Free Credits

Open my referral link:

👉 https://agentrouter.org/register?aff=hZk2

When registering, sign up using your GitHub account.

This is important for the signup credit, so do not create the account using another sign-in method if you want to receive the promotional credits through the referral.

After registration, log in to AgentRouter and check your account balance.

You should receive $175 in free credits that can be used with supported tools such as Claude Code and Codex.

Step 2: Create an AgentRouter API Token

After logging in to AgentRouter, create an API token.

It should look similar to:

sk-xxxxxxxxxxxxxxxxxxxxxxxx

Copy the token somewhere safe.

Do not commit it to Git or store it inside your source code.

You will use this token to temporarily configure Claude Code.

Step 3: Install Claude Code

If Claude Code is already installed, you can skip this step.

Otherwise, install it using npm:

npm install -g @anthropic-ai/claude-code

Verify the installation:

claude --version

Step 4: Configure Claude Code Temporarily on macOS or Linux

Open a terminal and run:

export ANTHROPIC_BASE_URL=https://agentrouter.org/
export ANTHROPIC_AUTH_TOKEN=sk-xxx
export ANTHROPIC_API_KEY=sk-xxx

Replace:

sk-xxx

with your actual AgentRouter API token.

Then navigate to your project:

cd my-project

and start Claude Code:

claude

Claude Code will now use AgentRouter for requests made from that terminal session.

The important part is that export only changes the environment of the current shell.

Once you close the terminal, these variables disappear.

Your normal Claude Code configuration is not permanently changed.

Step 5: Configure Claude Code Temporarily on Windows PowerShell

On Windows PowerShell, use:

$env:ANTHROPIC_BASE_URL="https://agentrouter.org/"
$env:ANTHROPIC_AUTH_TOKEN="sk-xxx"
$env:ANTHROPIC_API_KEY="sk-xxx"

Replace:

sk-xxx

with your AgentRouter API token.

Then navigate to your project:

cd my-project

and start Claude Code:

claude

That's it.

Claude Code will use AgentRouter for as long as this PowerShell session remains open.

If you close the PowerShell window, the environment variables disappear.

This means you don't have to modify your system-wide environment variables or permanently replace your existing Claude Code configuration.

Switching Back to Your Normal Claude Code Setup

Because the configuration is temporary, switching back is simple.

Just close the terminal where you configured AgentRouter.

Then open a new terminal and start Claude Code normally:

claude

The new terminal will not contain the temporary AgentRouter environment variables.

This makes it easy to switch between:

Terminal 1
Claude Code → AgentRouter

Terminal 2
Claude Code → Your normal configuration

without continuously changing system settings.

What About Codex?

AgentRouter also supports Codex.

I am not including the Codex configuration here because its setup is different from Claude Code and may change as Codex and AgentRouter evolve.

For the current Codex configuration, follow the AgentRouter documentation directly:

AgentRouter Documentation

The same AgentRouter credits can be used across supported tools, so the $175 signup credit is not limited to Claude Code.

A Security Consideration

AgentRouter is a third-party API gateway.

When you configure Claude Code this way, requests go through AgentRouter rather than directly to Anthropic.

That is important if you are working with:

proprietary company source code
customer information
credentials or secrets
confidential documents
security-sensitive projects

For those environments, review AgentRouter's privacy, security, and data-retention policies before routing sensitive information through the service.

For personal projects, experiments, and non-sensitive repositories, the free credits can be a convenient way to experiment with Claude Code.

Get $175 in Free AgentRouter Credits

If you want to try Claude Code or use AgentRouter with other supported coding agents such as Codex, you can start with the $175 free registration credit.

👉 Register with GitHub and get $175 in free AgentRouter credits

Then the process is simply:

Open the referral link
   ↓
Sign up with GitHub
   ↓
Get $175 in credits
   ↓
Create an AgentRouter API token
   ↓
Temporarily configure Claude Code
   ↓
Start coding

For Claude Code, the temporary configuration is:

macOS / Linux

export ANTHROPIC_BASE_URL=https://agentrouter.org/
export ANTHROPIC_AUTH_TOKEN=sk-xxx
export ANTHROPIC_API_KEY=sk-xxx
claude

Windows PowerShell

$env:ANTHROPIC_BASE_URL="https://agentrouter.org/"
$env:ANTHROPIC_AUTH_TOKEN="sk-xxx"
$env:ANTHROPIC_API_KEY="sk-xxx"
claude

Close the terminal when you're finished, and your normal configuration remains untouched.

Software Team Scaling: Why More Developers Can Slow Delivery

Mohammad Jodeh — Fri, 14 Aug 2026 19:36:07 +0000

A project is six weeks late. The deadline has not moved. Leadership asks:

“How many developers do we need to add to get back on schedule?”

That question assumes the delay is caused by insufficient coding capacity.

Sometimes it is. Often it is not.

A late project may already be constrained by architecture decisions, unresolved requirements, code review, testing, integration, or a small number of engineers who hold critical knowledge. Adding developers increases theoretical capacity, but it also creates more demand on those constraints.

That is the central problem in software team scaling: headcount and delivery capacity are not the same thing.

Before adding engineers, leaders need to answer a different question:

What is limiting delivery, and can another developer remove that limitation without creating more coordination than useful work?

Why Adding Developers Can Slow a Project

A new developer does not enter an existing project as additional net capacity.

At first, they consume some of it.

They need to learn the architecture, domain rules, development environment, deployment process, testing conventions, and the decisions that were never written down.

The people best equipped to teach those things are usually the engineers already carrying the most valuable project knowledge.

Consider a five-person team approaching a difficult release. Three engineers are added.

The new developers need help understanding where changes belong, why certain interfaces exist, how production deployments work, and which parts of the system are dangerous to modify.

The team now has eight developers, but its experienced engineers are spending more time answering questions and reviewing unfamiliar changes.

Headcount went up immediately.

Useful capacity may not.

Coordination becomes part of the work

Growing the team also changes the amount of coordination required to deliver a change.

The familiar expression for possible pairwise communication paths is:

n(n − 1) / 2

It is only an illustration. Real teams do not communicate equally through every possible connection.

But the engineering problem behind it is real: as more people work on related parts of a system, more effort can be spent aligning decisions, resolving dependencies, reviewing changes, and avoiding conflicting implementations.

The relevant question is therefore not how many people can be assigned to a project.

It is how many people can make meaningful progress independently.

Faster implementation can simply move the queue

Suppose the extra developers eventually start producing code quickly.

That still does not guarantee faster delivery.

Imagine twelve engineers producing changes that depend on two senior engineers for approval. Implementation accelerates, but review capacity does not.

Pull requests accumulate.

The organization has successfully increased coding throughput and failed to increase delivery throughput.

The same thing can happen in QA, integration, security review, deployment, or product decision-making.

This distinction matters because engineering team productivity should be measured at the level of completed work, not merely implementation activity.

What Brooks's Law Actually Tells Us

Brooks's law is commonly summarized as the idea that adding people to a late software project can make it later.

Its value is not that it gives leaders a rule to reject additional staffing.

Its value is that it exposes three costs that headcount planning can overlook:

onboarding
coordination
work that cannot be divided safely

The mistake is turning Brooks's law into “never add developers to a late project.”

That conclusion is too broad.

Suppose four external integrations must be completed. Each has a stable API, separate tests, little shared code, and clear ownership.

Those workstreams can run largely in parallel. Adding experienced developers may genuinely shorten delivery time.

The more useful interpretation is:

Adding people helps when the amount of independently executable work grows faster than the coordination required to perform it.

That is the real scaling constraint.

Software Team Scaling Depends on Parallel Work

Imagine two eight-person teams.

The first works on a tightly coupled application. Most changes touch the same shared modules, database schema, test environment, and release pipeline.

The second owns distinct components connected through stable contracts.

The teams have identical headcount. Their ability to work in parallel is very different.

This is why architecture affects organizational scalability.

A well-structured modular monolith may allow teams to move more independently than a poorly designed microservice architecture where one feature requires changes across four services and three teams.

The architectural style is not the important part.

The important properties are:

stable interfaces
clear ownership
limited cross-team dependencies
predictable contracts
tests that can run without coordinating the entire system

A backlog containing 100 tasks does not necessarily contain 100 pieces of parallel work.

A better question for engineering leaders is:

Which of these tasks can proceed without waiting for the same people, decisions, components, or environments?

That tells you much more about scaling potential than backlog size.

Find the Bottleneck Before You Add Developers

Adding developers to projects only solves one class of problem: insufficient implementation capacity.

Before increasing headcount, map the actual delivery flow:

Requirement → design → implementation → review → testing → integration → deployment

Then look for where work waits.

Knowledge bottleneck

One engineer understands a legacy billing component.

Every change involving billing eventually reaches that person.

Adding four developers who all need that engineer's help increases pressure on the bottleneck instead of removing it.

A better intervention might be pairing another experienced engineer with the specialist, documenting the subsystem, or separating work that does not require billing changes.

Decision bottleneck

Developers repeatedly stop because product rules are unresolved.

Adding people gives the organization more engineers waiting for the same decision.

The solution is not additional implementation capacity. It is faster or clearer decision-making.

Review bottleneck

Developers finish code quickly, but a small number of senior engineers review every important change.

Before hiring more implementers, ask whether review ownership can be distributed or whether boundaries can be changed so every modification no longer needs the same approval path.

Testing or deployment bottleneck

If every feature waits for one shared environment or a manual release process, more implementation may only increase work in progress.

This is why developer busyness is a weak argument for increasing team size.

People can be extremely busy inside a system that still spends most of its elapsed time waiting.

Why Adding Engineers to a Late Project Is Especially Risky

Timing changes the equation.

A developer who becomes valuable over the next year can still be the wrong intervention for a deadline six weeks away.

Late projects commonly have several problems at once: unfinished work, unresolved dependencies, rushed technical decisions, unstable requirements, and overloaded senior engineers.

New developers enter that environment with two clocks running.

The first is time to contribution: how long before they can complete useful work independently?

The second is time remaining: how long before the delivery deadline?

If the first approaches or exceeds the second, adding engineers may improve future capacity without improving the current project.

This is the practical explanation for why adding developers slows projects that are already late.

The benefit is delayed. The coordination cost starts immediately.

When Adding More Engineers Actually Works

Additional capacity is most useful when it can be directed at work that does not create another dependency on the critical path.

Examples include:

a well-defined external integration
a separate migration
an isolated reporting component
test automation that removes manual validation
tooling that eliminates repetitive release work

Specialists can also be more valuable than additional general capacity.

If releases are blocked by database problems, an experienced database engineer may have more impact than several application developers.

If deployments repeatedly fail, strengthening reliability or release engineering may be the better investment.

Internal transfers also deserve different treatment from new hires. An engineer who already knows the domain, systems, and organizational conventions may reach useful independence much faster.

So the staffing question should not be:

“Can we add three developers?”

It should be:

“What capability is missing at the current constraint?”

A Five-Question Test Before Increasing Headcount

Before approving additional engineers for a delayed project, answer these questions:

Where does work spend the most time waiting?

Look beyond implementation. Check decisions, review, testing, integration, and deployment.
Can another engineer own useful work independently?

Identify a concrete workstream rather than assuming the backlog can be divided.
Who will absorb the onboarding cost?

If the answer is the same senior engineers already on the critical path, include that cost in the decision.
Can downstream stages absorb more implementation?

More code is not useful if review, QA, or deployment cannot process it.
Will the added engineer become productive before the deadline matters?

Separate long-term hiring decisions from short-term recovery decisions.

If those answers are mostly positive, additional engineers may help.

If they are unclear, restructure the work first.

If they are mostly negative, headcount is unlikely to fix the current delay.

How to Scale a Software Team Without Scaling Coordination

When growth is necessary, prepare the system to absorb it.

Stabilize interfaces before putting more people behind them. Agree on API contracts, module responsibilities, acceptance criteria, and ownership boundaries early enough that developers can act without repeatedly reopening the same decisions.

Reduce onboarding dependence on individuals. Make local setup repeatable. Document the architecture decisions that actually affect implementation. Keep examples of established patterns close to the code.

Increase downstream capacity alongside implementation capacity. If you grow development while leaving review, testing, security, and deployment unchanged, expect the bottleneck to move.

And when possible, add people gradually.

You are not merely testing whether new engineers can code. You are testing whether the delivery system can absorb additional contributors without increasing queues and dependencies faster than throughput.

AI Makes This More Important, Not Less

AI-assisted development can reduce the time required for some implementation tasks. Developers can often generate boilerplate, explore unfamiliar code, create tests, draft documentation, or implement clearly specified changes faster.

That changes part of the capacity equation.

It does not remove the system around coding.

Requirements can still conflict. Interfaces can still be unstable. Architectural decisions still need ownership. Changes still need validation, integration, and safe deployment.

If implementation becomes significantly faster while those stages remain unchanged, the bottleneck simply becomes easier to see.

Teams adopting AI-assisted development should therefore ask:

If we increase the rate at which changes are produced, can the organization increase the rate at which changes are safely accepted?

Faster coding is useful only when the rest of the delivery system can keep up.

Sometimes the Fastest Scaling Decision Is to Reduce Scope

There is another lever that receives less attention than headcount: reduce the amount of work required before the deadline.

Suppose a release contains ten features, but only six are necessary for the business outcome.

Moving four into the next release may shorten the critical path more reliably than introducing several new developers in the final month.

Other recovery options include:

splitting the release into phases
removing unnecessary dependencies
freezing nonessential work
resolving ambiguous requirements immediately
assigning experienced engineers to critical-path work
automating a testing or deployment bottleneck

The objective is not to keep the maximum number of developers occupied.

The objective is to move valuable software through the delivery system sooner.

Software Team Scaling Is a Throughput Problem

Successful software team scaling is not about maximizing headcount. It is about increasing the amount of work that can move independently through the system.

When a project is late, first find the constraint. Then determine which work can actually run in parallel, reduce dependencies around the critical path, and add capacity where it changes throughput rather than activity.

More developers increase the amount of software an organization could produce.

The structure of the delivery system determines how much of it can actually ship.

When a project falls behind in your organization, what evidence do you use to decide whether the bottleneck is engineering capacity—or the system around it?

Why “Move Fast” Is Not an Engineering Strategy

Mohammad Jodeh — Mon, 03 Aug 2026 13:57:03 +0000

When a release slips, the usual response is predictable: shorten the deadline, add more work to the sprint, and ask engineering to move faster.

That response confuses urgency with strategy.

A team can increase activity without improving delivery. Developers can open more pull requests, managers can increase sprint commitments, and product leaders can mark more work as urgent. None of that guarantees that a useful, reliable change reaches production sooner.

“Move fast” describes a business need. It does not explain how engineering should respond.

A credible software delivery strategy must answer harder questions:

What outcome matters most?
What work should stop?
Where is delivery actually slowing down?
Which risks are acceptable?
Which quality boundaries cannot be crossed?
How will the organization know whether it became faster?

The central argument is simple: engineering speed is a property of the delivery system, not a personality trait of the people inside it.

“Move Fast” Is Too Vague to Guide Engineering Decisions

The instruction to move fast leaves the most important decisions unresolved.

Does the organization need to release more frequently? Validate a product assumption earlier? Recover from incidents faster? Meet a fixed regulatory deadline? Reduce the time required to onboard customers?

These are different problems.

A team trying to validate demand may need a narrow prototype and limited rollout. A team trying to improve reliability may need better observability and rollback procedures. A team trying to deliver a committed roadmap may need to stop lower-priority work.

Using the same response for every form of urgency usually creates the wrong optimization.

Define the type of speed required

Before changing the engineering process, leaders should identify the result they need.

For example:

Faster learning: Reduce the time between an idea and evidence from users.
Faster releases: Reduce the time between completed code and production.
Faster delivery: Reduce the full time from an approved need to a usable outcome.
Faster recovery: Reduce the time required to detect and resolve production failures.
Faster response: Reduce the time needed to react to market, customer, or regulatory changes.

A team may improve one while making another worse.

Releasing more frequently does not guarantee faster learning if nobody measures user behavior. Coding faster does not improve recovery time if the system is difficult to observe. Starting more initiatives does not improve delivery if shared dependencies block all of them.

Make trade-offs explicit

Urgent work usually requires a trade-off. The mistake is pretending that no trade-off exists.

A team may reduce scope while keeping reliability requirements intact. It may accept a temporary manual operation to validate demand before automating it. It may choose a reversible implementation instead of a more elegant long-term design.

Those choices can be responsible.

The irresponsible version is allowing teams to infer that testing, security, maintainability, or operational readiness should be reduced because the date has not changed.

Engineering leaders should state clearly:

What can be reduced
What can be deferred
What must remain unchanged
Who accepts the resulting risk

Without this, “move fast engineering” becomes an exercise in hidden risk transfer.

Coding Speed Is Not Software Delivery Speed

Engineering organizations often focus on coding because it is visible.

Pull requests can be counted. Tickets can be closed. Story points can be discussed in planning meetings. Waiting is harder to see.

Consider a feature that requires ten working days of implementation but takes eight weeks to reach production.

The remaining time may include:

Five days waiting for product clarification
One week waiting for another team’s API
Four days waiting for code review
One week waiting for a stable test environment
Several days waiting for security approval
One week waiting for a release window

In this example, asking developers to implement the feature 20% faster saves two days. Removing one approval delay may save a week.

That is the difference between local productivity and end-to-end software delivery speed.

Measure where work waits

A useful delivery review should reconstruct the actual path of completed work.

For a small sample of recent features, record:

When the work was requested
When it became clear enough to start
When implementation began
When the first review was requested
When review completed
When testing completed
When the change became deployable
When it reached production
When meaningful feedback became available

The goal is not to create a perfect measurement system. The goal is to find the largest delays.

This often reveals that the main constraint is not engineering capacity. It may be unclear ownership, unavailable environments, centralized approvals, or too many concurrent priorities.

Use velocity metrics carefully

Story points can help a team plan its own work. They are weak evidence of organizational productivity.

A team can increase reported velocity by changing estimation behavior, splitting work differently, or taking on more predictable tasks. None of those necessarily improve customer outcomes.

Engineering leaders should prefer a balanced view that includes:

Lead time
Cycle time
Time waiting for review
Time blocked by dependencies
Deployment delay
Rework
Release predictability
Production failure patterns
Time to restore service
Evidence of customer or business impact

These metrics should diagnose the system. They should not be used to rank individual developers.

AI Can Accelerate Work and Still Slow Delivery

AI-assisted development changes implementation capacity, but it does not remove the rest of the delivery process.

A team may use AI to generate code, tests, migration scripts, or documentation faster. That can be valuable.

But imagine that the team doubles its pull-request volume while senior review capacity remains unchanged. The review queue grows. Integration conflicts increase. Test environments become busier. More generated code requires architectural validation.

Implementation became faster. Delivery did not.

The correct question is therefore not:

How much code did AI generate?

It is:

Did AI reduce the total time required to deliver a correct, maintainable, production-ready change?

This distinction matters for organizations adopting AI-assisted software development. AI can improve engineering velocity when it reduces a real constraint. It can also move the constraint into review, testing, architecture, security, or production support.

A practical approach is to introduce AI into a specific part of the workflow and measure the effect on the entire path.

For example:

If AI generates tests faster, did review time fall or rise?
If AI drafts migrations, did deployment confidence improve?
If AI creates more pull requests, did lead time decrease?
If AI supports code review, did defect escape increase?
If AI helps with debugging, did recovery time improve?

The benefit should be measured at the system level, not only at the point where the tool is used.

What a Software Delivery Strategy Must Contain

A software delivery strategy should turn urgency into a set of operating decisions.

It does not need to be a large transformation document. It needs to define how work will move from an identified need to production feedback.

1. A clear outcome

Every significant initiative should answer:

What problem are we solving?
Who is affected?
What evidence would show improvement?
What is the smallest valuable result?
Which assumption is most likely to be wrong?

This prevents teams from delivering a large amount of functionality before discovering that the original assumption was weak.

2. A real priority order

If five initiatives are all called critical, none of them is truly prioritized.

Real prioritization requires leadership to decide:

Which work receives capacity now
Which work is paused
Which work is reduced in scope
Which commitments are displaced by new urgent work

Adding a new priority without removing an old one is not prioritization. It is queue growth.

3. Limits on concurrent work

Too much work in progress creates context switching, coordination overhead, and dependency queues.

Suppose five initiatives all need the same platform engineer and the same test environment. Starting all five does not increase throughput. It creates five partially completed streams competing for the same constraint.

A more effective decision may be to finish two initiatives before starting the remaining three.

This can feel slower because fewer projects are visibly active. It is often faster because valuable work reaches completion sooner.

4. Smaller delivery units

Large changes delay feedback and increase the cost of failure.

Teams should look for ways to release:

Thin vertical slices
Smaller pull requests
Backward-compatible API changes
Incremental migrations
Features behind flags
Limited-audience rollouts

The objective is not to split work into meaningless technical tasks. Each slice should either deliver value, validate an assumption, or reduce a known risk.

5. Clear decision ownership

Work often waits because nobody knows who can decide.

A delivery strategy should distinguish between:

Decisions teams can make independently
Decisions requiring consultation
Decisions requiring explicit approval
Decisions that must be escalated immediately

For example, a team may be free to choose an implementation approach within agreed architectural and security boundaries. A change to shared customer data may require broader approval.

This reduces unnecessary escalation without removing governance.

6. Non-negotiable quality boundaries

Teams should not renegotiate basic safety for every deadline.

Typical non-negotiable boundaries may include:

Authentication and authorization
Data integrity
Backward compatibility
Critical automated tests
Monitoring and alerting
Rollback capability
Regulatory requirements

The exact boundaries depend on the system. A marketing experiment and a payment service should not receive identical treatment.

The principle is to match assurance to risk, reversibility, and impact.

7. A feedback loop

The strategy should define how the organization will learn whether the change worked.

Shipping is not the end of delivery. The team needs evidence.

That may include:

Adoption
Conversion
Reduced operational effort
Fewer support requests
Lower failure rates
Faster processing
Improved customer completion rates

Without feedback, the organization can become faster at delivering the wrong thing.

How Engineering Teams Move Faster in Practice

The most useful question is not, “How can the team work faster?”

It is:

What causes work to wait, expand, or return?

That question leads to practical interventions.

Reduce work before increasing capacity

Start by listing active initiatives and assigning each one a clear status:

Continue
Pause
Reduce
Cancel
Complete before starting new work

This is often more effective than immediately hiring more developers.

Additional engineers help when implementation capacity is the main constraint. They may make matters worse when the bottleneck is review, product clarification, architecture ownership, or deployment.

Hiring into the wrong constraint increases coordination without increasing throughput.

Replace large releases with thin slices

Suppose a team plans a three-month customer onboarding redesign.

Instead of releasing the entire flow at once, it could first release one improved step for a limited customer segment. That may reveal whether the expected drop-off point was correctly identified.

The result informs the rest of the investment.

This is a concrete way to improve delivery speed without sacrificing quality: reduce the size of the decision, not the level of care.

Move routine decisions closer to the team

If every security, architecture, and deployment question requires a committee meeting, work will wait.

Create reusable boundaries:

Approved implementation patterns
Standard threat checks
Defined data classifications
Deployment templates
Service ownership rules
Clear escalation triggers

The team should not need executive involvement for a decision it makes repeatedly.

Automate the path that blocks delivery

Automation should be selected based on delay, not enthusiasm.

If deployments are manual and risky, automate deployment and rollback.

If developers wait days for environments, automate environment creation.

If a slow test suite delays every pull request, improve test execution before adding more coding tools.

If product clarification causes repeated rework, automation is not the first answer. Better decision-making is.

Review the system regularly

Once per month, select a few completed and delayed items and examine:

Where they waited
Why they returned for rework
Which dependencies blocked them
Which decisions arrived late
Which controls added value
Which controls added delay without reducing risk

Then improve the largest current constraint.

Do not launch ten process initiatives at once. The improvement system can suffer from the same excessive work in progress as the delivery system.

How to Move Fast Without Breaking Things

The phrase “move fast without breaking things” is sometimes treated as unrealistic.

It is realistic only when “without breaking things” does not mean eliminating every failure.

Complex systems will fail. The practical goal is to reduce the probability, impact, and recovery cost of failure.

Teams can do this by making changes:

Smaller
Easier to observe
Safer to reverse
Continuously validated
Released to limited audiences first

A small change behind a feature flag can be tested with a limited group and disabled quickly. A large tightly coupled release has a wider failure surface and fewer recovery options.

Quality and speed are not automatically aligned. Poorly designed quality gates can create delay without reducing meaningful risk. Weak quality practices can also create incidents and rework that destroy delivery speed.

The engineering task is to apply the right level of assurance to the specific risk.

What Engineering Leaders Should Say Instead

Leaders do not need to remove urgency. They need to make it actionable.

Instead of saying, “Move faster,” ask:

What is the main constraint on this work?
What should stop so this becomes the priority?
What is the smallest valuable release?
Which assumption should we test first?
Where is the work waiting?
Which dependency requires leadership intervention?
Which risks are reversible?
Which quality boundaries cannot change?
How will we know the outcome was achieved?
What did we learn from the last delayed initiative?

These questions convert pressure into decisions.

They also make accountability clearer. Engineering owns technical execution and risk. Product owns problem clarity and value. Leadership owns priority conflicts, organizational constraints, and accepted trade-offs.

Speed improves when those responsibilities are explicit.

Conclusion: Do Not Ask for Speed Before Finding the Constraint

“Move fast” is a valid expression of urgency. It is not a plan.

A strong software delivery strategy does not begin by asking developers to produce more. It begins by identifying why valuable work is not reaching production sooner.

Sometimes the answer is implementation capacity.

Often it is something else: unclear priorities, too much concurrent work, late decisions, shared dependencies, unstable environments, manual release processes, or feedback that arrives too late.

The practical sequence is straightforward:

Define the outcome.
Map the delivery path.
Find the largest delay.
Improve that constraint.
Measure the end-to-end effect.
Repeat.

Before asking an engineering team to move faster, find the place where the work has stopped moving.

Discussion question: What is the largest source of delay in your delivery system today: implementation, decisions, dependencies, validation, or release?

The Hidden Cost of Starting Development Too Early

Mohammad Jodeh — Fri, 31 Jul 2026 17:53:24 +0000

On Monday, a feature moves to In Progress.

By Tuesday, the repository has a new module, a database migration, and a set of endpoints. On Wednesday, the first pull request is open. By Friday, the happy path works in a demo.

The work looks healthy. The board is moving. Code is accumulating.

But the team still has not agreed on what should happen when a request is repeated, a dependency times out, an event arrives out of order, or a user changes state halfway through the operation.

That is not a small planning gap. It means implementation began before the product's behaviour was defined.

Early coding often creates an illusion of progress because it produces visible artifacts: commits, screens, endpoints, and passing tests. At the same time, it quietly converts unresolved decisions into implementation assumptions.

And code is one of the most expensive places to store ambiguity.

A ticket can be detailed and still not be decision-ready

Many tickets describe the shape of a feature without defining its behaviour.

Consider a seemingly simple operation:

POST /subscriptions/{id}/activate

202 Accepted

That contract looks implementable. It is not—not yet.

The endpoint says nothing about the questions that determine the real system:

Is activation synchronous, asynchronous, or eventually consistent?
Is the operation idempotent? What happens when the client retries after a timeout?
Can a subscription be cancelled while payment is pending?
If payment.succeeded arrives after cancellation, which transition wins?
Are events delivered at most once, at least once, or without an ordering guarantee?
Which service owns the authoritative state?
What does the caller observe during partial failure?
What evidence proves the feature is accepted?

Two experienced engineers can implement the same ticket correctly and still build incompatible systems because each filled in those blanks differently.

The problem is not coding ability. The problem is that a product decision was allowed to masquerade as an implementation detail.

Four agreements should exist before production implementation

A team does not need a hundred-page specification before writing code. It does need enough shared precision to prevent each engineer from inventing a different product.

At minimum, four things should be agreed.

1. Behaviour

Behaviour defines what the system does from the user's or caller's perspective.

For stateful features, prose is rarely enough. Make the transitions explicit:

draft -> pending_payment -> active
                    |          |
                    v          v
                 cancelled   suspended

Then challenge the diagram:

Which commands are valid in each state?
Which transitions are reversible?
What happens on duplicate, late, or out-of-order events?
Which outcomes are visible to the user?

If the team cannot answer those questions consistently, the behaviour is not yet ready to encode.

2. Constraints

Constraints are the invariants and operating limits the implementation must preserve.

They include business rules—such as plan limits, permission boundaries, and legal restrictions—but also system properties such as latency budgets, data residency, transaction boundaries, availability targets, and compatibility requirements.

A technically correct implementation can still be unusable if it violates a constraint that surfaced too late. Discovering after development that an operation must be atomic across two stores, complete within 200 milliseconds, or run without transferring data across regions is not refinement. It is redesign.

3. Integration contracts

An integration contract is more than a request and response schema.

It should define ownership, versioning, failure semantics, timeout behaviour, retry policy, idempotency, ordering guarantees, and compatibility expectations. For event-driven systems, it should also answer who may emit an event, what makes it unique, how consumers recover, and how schema evolution is handled.

The happy-path payload is usually the cheapest part of an integration. The expensive part is everything that happens when the network behaves like a network.

4. Acceptance criteria

Acceptance criteria should make success observable and falsifiable.

“The user can activate a subscription” is a summary, not a testable criterion. Stronger criteria describe the initial state, the action, the expected outcome, and the important failure cases.

For example:

Given a subscription is pending payment
And the user has cancelled it
When a delayed payment-success event is received
Then the subscription remains cancelled
And the payment is queued for refund exactly once
And the decision is visible in the audit trail

This single scenario aligns product behaviour, the domain state machine, integration semantics, idempotency, and observability. It removes far more uncertainty than another day of speculative implementation.

Why early coding feels faster

Implementation has a psychological advantage: it is concrete.

A team can count pull requests, story points, endpoints, components, and passing tests. Agreement work produces fewer visible artifacts, even when it removes the uncertainty most likely to delay delivery.

That makes it easy to confuse activity with progress.

Early implementation also tends to move quickly because engineers choose convenient defaults for every unanswered question. The first version may look efficient precisely because it has not yet encountered the decisions it postponed.

Tests can reinforce the illusion. A test suite proves that the code behaves as its authors expected. It does not prove that those expectations were shared, complete, or correct. If the team never agreed on the behaviour, green tests may simply preserve the wrong assumption more rigorously.

The branch is moving. The decision graph is not.

Rework grows across surfaces, not files

The cost of an unresolved decision is not limited to rewriting a function.

A useful engineering heuristic is:

Expected rework ~= unresolved decisions
                  x affected surfaces
                  x cost of reversal

Suppose the team initially treats subscription activation as synchronous, then later agrees that it must be asynchronous and resilient to duplicate delivery. That decision can change:

the domain state model;
database schema and existing records;
public API responses;
event schemas and consumer logic;
client-side loading and error states;
retry and idempotency mechanisms;
tests and test data;
metrics, alerts, and operational runbooks;
analytics definitions and support documentation.

At that point, calling the work “a refactor” understates it. The team is reversing a distributed decision that has already propagated through the system.

This is why a small ambiguity at the start can become a large delivery cost later. The ambiguity stayed constant; its blast radius grew.

The answer is not heavyweight specification

The alternative to premature implementation is not months of analysis or a demand for perfect certainty.

The goal is a decision-ready slice: the smallest set of artifacts that lets engineering start without inventing product behaviour inside the codebase.

For many features, that can be lightweight:

a few concrete examples covering the main and failure paths;
a state transition sketch for stateful behaviour;
explicit invariants and non-functional constraints;
versioned request, response, or event schemas;
documented timeout, retry, and idempotency semantics;
testable acceptance criteria;
a short list of remaining unknowns, each with an owner.

These artifacts should be reviewed together, not produced by separate functions and thrown across handoff boundaries. Product, design, engineering, and dependent teams need to see the same behaviour from their respective angles.

The objective is not to eliminate learning. It is to decide which uncertainty is acceptable before the cost of changing it multiplies.

Exploration code and commitment code are different

Sometimes coding early is exactly the right move.

A time-boxed spike can test whether a library supports a required protocol, whether a query can meet the latency budget, or whether an external API behaves as documented. A prototype can expose usability questions faster than a meeting.

But exploratory code needs an explicit contract of its own:

What question is it answering?
How long will the exploration run?
What evidence will it produce?
Is the code disposable?
What decision must be made before it becomes production implementation?

Without those boundaries, prototypes have a habit of becoming foundations. Temporary assumptions acquire users, data, and dependencies. The team then has to preserve decisions it never consciously made.

Exploration code can start early. Commitment code should wait until the team knows what it is committing to.

A practical start-development gate

Before a feature enters production implementation, I would expect the team to answer these questions:

Can we describe the user-visible outcome in the same words?
Are the important states and transitions explicit, including retries and out-of-order events?
Are business and technical invariants documented?
Do integration contracts define failure semantics, not only payloads?
Are acceptance criteria objective enough to become tests and observable enough to operate in production?
Are the remaining unknowns named, owned, and deliberately accepted?

If the answer is no, the next step is not necessarily “stop.” It may be a short behaviour workshop, a contract review, or a targeted technical spike.

But it should not be production code pretending the decision has already been made.

Shipping sooner starts with deciding sooner

Starting development early can improve a schedule on paper while making the real delivery date less predictable. The first week looks fast because the team is borrowing time from later weeks—when assumptions collide, interfaces change, data must be repaired, and tests have to be rewritten.

High-performing teams do not delay implementation for ceremony. They delay irreversible commitments until the relevant decisions are explicit.

The best time to discover that two teams mean different things by “activated” is before both definitions are running in production.

The gap between intent and implementation—where behaviour, constraints, contracts, and evidence either align or drift—is the problem space I am exploring with Lopeline. I will share more about that soon.

Teaching Agents to Slow Down Where It Matters

Mohammad Jodeh — Sun, 19 Jul 2026 09:20:53 +0000

Say "fable-mode" (or "operate carefully," or "high-judgment mode" or "think like fable") in a Claude Code or Codex session, and one line buried in the skill file does most of the work: "Never promote 'plausible' to 'confirmed' in your summary." That single rule is the whole philosophy in miniature — don't let something that merely looks right pass as something that was checked.

Fable-mode is not a tool, a model swap, or a set of new commands. It's a behavioral overlay — a skill file at ~/.claude/skills/fable-mode/SKILL.md or ~/.codex/skills/fable-mode/SKILL.md or any other agent you use, that gets loaded into the turn and changes how the agent scopes work, verifies its own claims, and reports results. Nothing about what Agents can do changes. What changes is the discipline around using it.

What actually changes

The skill is organized into seven blocks, and each one targets a specific failure mode that shows up in normal agent use:

Judgment before action. The first move is classification: is this a question, a problem description, or a change request? For the first two, the deliverable is an assessment — investigate and stop, don't start editing files nobody asked you to edit. Irreversible actions (deletes, pushes, overwrites) require a stop-and-confirm, and specifically: "before deleting or overwriting anything, actually look at the target."

Verification as the non-negotiable core. This is the section that does the heavy lifting. Every "done" claim needs evidence produced after the last edit — a test run before your final change proves nothing about your final change. Claims get graded on a three-tier scale: Confirmed (you ran it and saw the result), Plausible (the code reads right but you haven't executed it), Assumed (inherited from the user's description). The rule is that you report the grade you actually earned, not the one that sounds better.

Reasoning habits. Hold two hypotheses before committing to a diagnosis. Treat your memory of a library's API as a prior, not a fact, and check the installed version when correctness depends on it. When a result contradicts what you expected, that's flagged as "the most information-dense moment of the task" — chase it instead of smoothing over it.

Anti-patterns as hard stops. Eight explicit bans, including "declare success without a post-change verification run," "fix a bug you can't explain," and "hedge a known failure ('should work now') — either you verified it or you report it as unverified."

The skill closes with a five-item checklist the agent is meant to run before ending any turn — essentially a self-audit against the rules above.

Advantages

Verification stops being optional. The "read before you write" and "check you didn't break the neighbors" rules mean the agent greps for other callers of a function it just changed instead of assuming the diff is self-contained.
Reports get honest, not optimistic. The Confirmed/Plausible/Assumed grading forces a specific kind of intellectual honesty that's easy to skip under normal operation, where "should work" and "verified working" tend to blur together in the final summary.
Scope stays tight. "Prefer the smallest change that fully solves the problem" combined with "expand scope without flagging it" being a hard stop means less unrequested refactoring riding along with a bug fix.
Root-cause bias. The rule that a fix needs a one-sentence causal explanation before it's applied catches the class of fix that happens to make a symptom disappear without addressing why it occurred.
Effort matches stakes. "A one-line fix does not need a design document. A schema migration does not get done on vibes" — the skill explicitly scales its own overhead down for trivial tasks, so it isn't uniformly slower.

Disadvantages

It's a self-reported discipline, not an enforced one. There's no external checker validating that the agent actually ran the test it claims to have run — the whole system depends on the model correctly following its own instructions and honestly grading itself. A model that misjudges "confirmed" vs. "plausible" produces the same failure mode fable-mode was meant to prevent, just with more confident-sounding labels attached.
More tool calls per task. Verifiable increments, post-change re-runs, and neighbor-checking all mean more intermediate steps than an agent optimizing purely for speed. On tasks where the user genuinely wants a fast, rough pass, this overhead is friction, not value.
No built-in tool selection guidance. The skill is explicit that it "governs how work is scoped, verified, and reported — not what tools to use." It won't tell the agent which agent, MCP, or command to reach for; that judgment still comes from elsewhere.
Depends on activation. It's opt-in per session via trigger phrase. A user who forgets to say "fable-mode" on a high-stakes task gets none of it — there's no persistent always-on variant described in the file.
Checklist compliance can become theater. A five-item checklist run by the same agent that did the work is a weaker guarantee than an independent review pass; it catches self-aware gaps, not blind spots the agent doesn't know it has.

What to actually expect

Turn fable-mode on for the tasks where being wrong is expensive: schema migrations, auth changes, anything touching shared code, or a bug you don't yet understand. Expect the final report to distinguish what was actually tested from what merely compiles, expect fewer "while I was in there, I also…" surprises in the diff, and expect the agent to stop and ask before anything destructive rather than assuming consent. Don't expect it to make trivial tasks faster — for a one-line CSS fix, the skill's own "match depth to stakes" rule means it should behave close to normal anyway. The gain isn't speed; it's a report you can trust at face value, on the tasks where that trust is worth paying the extra verification steps for.

Skill File to download

fable-mode

Feel free to contribute

Why faster typing rarely produces faster delivery

Mohammad Jodeh — Sat, 18 Jul 2026 08:55:32 +0000

A developer finishes the change on Tuesday. The customer sees it three Tuesdays later. What happened in between is the real story of software delivery.

When delivery slows, the instinct is almost always the same: push the engineering team to move faster. Increase velocity. Add developers. Introduce another coding assistant. Reduce the estimate. Ship more story points.
It sounds rational because code is the most visible artifact in software development. But code is only one station on a much longer line. Most delays happen before the first line is written or after the last pull request is merged.

The delivery flow from idea to impact:
DEFINE (Clarity) -> DECIDE (Approvals) -> BUILD (Code) -> CONNECT (Dependencies) -> PROVE (Validation) -> RELEASE (Ownership).

Only one stage is primarily about typing code. Every stage can slow delivery.

The keyboard is rarely the constraint
Imagine a feature that requires two days of focused development. It waits three days for a product decision, four days for another team to expose an API, two days for review, and five days for a shared test environment. Making the coding twice as fast saves one day. Fixing the surrounding flow can save fourteen.
That is why teams can become better at producing code without becoming better at delivering outcomes. They optimize the activity while leaving the system untouched.

CLARITY

Unclear requirements are rework in disguise

The team starts moving before everyone agrees where it is going.
A vague requirement does not disappear when development begins. It simply changes form. It becomes a Slack thread, an assumption embedded in the code, a late design debate, or a feature that technically works but solves the wrong problem.
This creates the illusion of progress: tickets move, commits appear, demos happen. Then the questions arrive. What should happen in the edge case? Which system owns the data? Who is the real user? What does success look like? The team rewrites what it already built because it began with motion instead of clarity.
A short, difficult conversation before coding is often faster than a long, expensive correction afterward.

DECISIONS

Approval delays create a hidden queue

Work can be complete and still be nowhere near delivered. A security review waits for a specialist. A product decision waits for a meeting. A pull request waits for someone with the right context. A release request waits for a change window. None of this looks like active engineering work, yet all of it belongs to the delivery timeline.
Most delivery dashboards are excellent at counting activity and poor at measuring silence.
They show how long a task was in development, not how long it sat untouched between people. But customers experience the whole clock, including the waiting.

DEPENDENCIES

Local speed cannot defeat a system dependency

One team finishes. The outcome remains blocked. Modern software is a web of services, data contracts, platforms, vendors, environments, and specialist teams. A team may complete its part quickly and still wait for an API, a schema change, infrastructure capacity, legal language, or a partner release.
This is the trap of local optimization: every group can report that its own work is on track while the customer-facing outcome is late. Delivery speed lives in the handoffs. Define contracts early, reduce unnecessary coupling, and make escalation paths explicit.
The better question
How much time did the work spend moving - and how much time did it spend waiting?
That ratio reveals more about delivery performance than typing speed or story points.

REWORK

The fastest first draft can still be the slowest route

Work returns because feedback arrived after commitment.
Rework is not merely another edit. It reopens design, implementation, review, testing, documentation, and approval. The team pays for the same decision several times because the right people or the right evidence appeared too late.
The aim is not to make the first version perfect. It is to make it directionally correct - by testing assumptions early, reviewing thin slices, exposing risks before they harden into architecture, and letting users react before the solution becomes expensive to change.

OWNERSHIP

Work slows down in the space between teams

When everyone contributes but nobody carries the outcome.

Who resolves conflicting requirements?
Who owns the integration?
Who decides whether a defect blocks release?
Who notices that the approval has been waiting for four days?

When those answers are unclear, work becomes organizational luggage left between gates.
Ownership does not mean one person performs every task. It means one person remains accountable for the journey: clarifying the next decision, surfacing the blocker, finding the owner, and keeping the outcome from becoming an orphan.

VALIDATION

Late validation turns feedback into a bottleneck

Testing at the end makes learning expensive.
When quality assurance, security, accessibility, compliance, and user acceptance are treated as final gates, they become queues. The team discovers fundamental problems only after the solution feels finished. Every finding now threatens a deadline and triggers a larger cycle of rework.
High-flow teams pull validation forward. Acceptance criteria exist before development. Automated checks run while code is changing. Security and operations review risky choices early. Stakeholders see small increments. Releases are observable and reversible. Earlier feedback is not extra process; it is less expensive process.

Optimize the journey, not the keystrokes
If leaders want faster delivery, they need to manage the flow from idea to customer impact. That means looking beyond sprint velocity and asking where time, confidence, and accountability are being lost.

WAIT Where does work sit untouched the longest?
DECIDE Which decisions repeatedly arrive after implementation has begun?
DEPEND Which handoffs or dependencies create the most uncertainty?
RETURN Why does supposedly finished work come back for another cycle?
OWN At what moments does nobody clearly own the next move?
PROVE Which validations happen only when change is most expensive?

AI coding tools can accelerate implementation. More engineers can add capacity. Better development practices matter. But those investments create meaningful speed only when coding is the constraint. Otherwise, they simply send more work into the same queues faster.
THE LEADERSHIP SHIFT

Typing is an activity. Delivery is a system.

The fastest teams create clarity early, make decisions quickly, manage dependencies deliberately, assign ownership visibly, and shorten every feedback loop.

Before asking developers to code faster, follow one feature from idea to production. The keyboard may be the easiest part of the journey.