Ask Kilby.

The question is deliberately extreme, but the framework it forces is the right one. Let me sharpen it.

The math looks identical. The economics are completely different.

Both cost $10M. But the cost structures behave differently under pressure:

100 engineers — fixed cost, sticky, takes months to ramp up and months to unwind. Each person carries fully loaded costs beyond salary (benefits, management overhead, office, tooling — realistically $130–150K per head, not $100K). You also inherit coordination costs that scale super-linearly. Brooks's Law is real: at 100 engineers you're spending a meaningful percentage of your engineering budget on people managing other people communicating with other people.

1 engineer + $10M in AI spend — the token spend is variable cost. You can dial it from $10M to $500K in a month if the business contracts. You can spike it to $15M if you're winning. There's no severance, no morale damage, no institutional knowledge walking out the door. But there's also no judgment, no creative problem-solving in ambiguous domains, and no one to architect systems that don't exist yet.

The real answer is neither extreme. But the ratio is shifting fast.

Here's how I'd actually think about it:

What scales with tokens:
• Repetitive code generation, testing, debugging
• Data processing, ETL, report generation
• Documentation, boilerplate, migration work
• Pattern-matching tasks with clear inputs and outputs
• Customer support triage, content generation
• Monitoring, alerting, basic ops

What still requires humans (for now):
• System architecture and hard design tradeoffs
• Novel problem-solving in ambiguous domains
• Cross-functional judgment calls
• Customer relationships and trust-building
• Managing the AI systems themselves

The practical framework:

For every role in the hiring plan, ask two questions:
1. What percentage of this role's weekly output is pattern-matching vs. novel judgment? If it's 70%+ pattern-matching, that's an AI-first role with human oversight — not a full headcount.
2. Does this role require real-time human judgment where errors are expensive and irreversible? If yes, hire the person. If no, build the agent.

If I had to put a number on it today: a team of 15–20 exceptional engineers with heavy AI tooling will outproduce 100 average engineers and cost less. The 1-engineer extreme is a thought experiment, but the directional insight is right — the leverage per engineer is exploding, and the companies that figure out the right human-to-agent ratio first will have a durable cost structure advantage.

The real risk isn't overspending on AI. It's overhiring humans and building an org structure that's expensive to maintain and slow to adapt. Headcount is the hardest cost to cut and the easiest to justify in the moment. Token spend is the easiest cost to cut and the hardest to justify to a board that doesn't understand it yet.

Hire the fewest people you can who have the judgment to direct the machines. Spend aggressively on the machines.

These two SWIFT return codes are pointing at different problems, so let me separate them before getting to the extension.

AM04 is "insufficient funds" — the counterparty's account didn't have enough cash to cover the delivery. That's a liquidity or funding problem on their side, or possibly a booking/allocation mismatch causing the wrong account to be debited.

AC04 is "closed account" — the cash leg is hitting an account that no longer exists. That's an SSI problem. Either your standing settlement instructions are stale, or the counterparty's bank account changed and your records weren't updated.

The AC04 is actually the more urgent fix — a payment routing to a closed account won't settle regardless of how much liquidity exists. You need to get correct cash settlement instructions from the counterparty or their custodian before anything else moves.

On the Reg T Extension:

For a DTC fail on a US equity where you're unable to make delivery due to the settlement break, the applicable reason codes depend on what's actually blocking you:

The most direct fit here is Reason Code 15 (COD-Fail 35 days) — but only if you're at or past the 35th calendar day from trade date. That gives you up to 14 calendar days, does not count toward the 5-extension limit, and is marked final on the transaction.

If you're before T+35, then look at Reason Code 21 (Exceptional Circumstance) — because a failed DTC delivery driven by an SSI/account defect (AC04) and counterparty funding failure (AM04) isn't cleanly covered by the standard codes. Code 21 gives you up to 14 calendar days, does not count toward the 5-extension limit, and is not final, meaning you can come back again if needed. However, it should only be used when no other code squarely fits.

If the root cause resolves to securities not yet received on your side (a fail-to-receive feeding a fail-to-deliver), Reason Code 5 is worth considering — but that's a 7-calendar-day, final extension that does count toward the 5-extension limit, so use it only if it's genuinely the right characterization.

My recommendation: Fix the AC04 SSI problem first — that's your actual blocker. Get updated cash settlement instructions confirmed in writing from the counterparty, correct your SSI record, and retry the cash leg. Meanwhile, file the Reg T extension to protect yourself on the regulatory clock. If you're pre-T+35, Code 21 gives you the most flexibility. If you've crossed T+35, Code 15 is your vehicle.

What's the trade date? That'll let me confirm which code is actually in scope for you right now.