DEV Community: Jacques Montagne

AI is an Amplifier. Are You Amplifying Engineering or Dysfunction?

Jacques Montagne — Tue, 10 Feb 2026 20:37:13 +0000

Dave Farley recently shared results from a controlled study of 150 developers using AI tools. The data confirms a hard truth that the "vibe coding" crowd ignores: AI is a multiplier, not a magic wand.

The study revealed that while AI increases coding speed by 30-55%, it doesn't inherently fix code quality. In fact, the outcome depends entirely on who is holding the tool.

The "Slop" Myth vs. Economic Reality

We hear constantly that AI creates unmaintainable "slop." Farley’s data shows this is false—but with a catch.
For experienced developers, AI actually improved maintainability. Why? Because seasoned engineers don't let the LLM drive the architecture. They use AI to generate boring, idiomatic, and predictable code that fits into a rigorous design.

However, for those without strong engineering discipline, AI simply accelerates the creation of technical debt.

Automating the Dysfunction

This brings us to the core problem in the Enterprise.
If your organization currently lacks:

A culture of TDD (Test-Driven Development),
Modular architecture boundaries,
Strict Code Review processes...

...then introducing GenAI won't make you "agile." It will just make you produce bad software 40% faster. You are automating your dysfunction.

The "Cognitive Debt" Trap

The biggest risk Farley highlights isn't the code itself—it's "Cognitive Debt."
When junior developers rely on AI to write logic they don't fully understand, they lose the ability to reason about the system when it inevitably breaks.

In my work modernizing legacy systems (Banking/Insurance), "fast" is often a trap. The dominant cost of software is maintenance (50-80% of TCO). Saving 2 hours on typing today is irrelevant if it costs 2 weeks of debugging next year.

The Strategy: Safe Modernization

To use AI safely in an enterprise environment, we must invert the hype:

Architecture First: Define the module boundaries and contracts before opening the chat window.
Constraint-Based Coding: Use AI to fill in the implementation details of a strictly defined interface, not to "invent" the solution.
Infrastructure as Code: If the AI suggests a console click, reject it. If it’s not in Terraform/OpenTofu, it doesn’t exist.

Conclusion

AI is a powerful amplifier.
Before you roll it out to your entire team, ask yourself: "Do we have an engineering culture worth amplifying?"

If the foundation is weak, speed is the last thing you need.

The 'Sprint' Illusion: 3 Bosses, 0 Tech Leads, and the 'AI-Generated' Debt

Jacques Montagne — Mon, 02 Feb 2026 16:31:50 +0000

The 'Sprint' Illusion: 3 Bosses, 0 Tech Leads, and the 'AI-Generated' Debt

There is a pathology spreading through engineering organizations. It manifests as missed deadlines, unexplained production incidents, and a revolving door of developers who "just couldn't keep up." Leadership diagnoses it as a talent problem. It is not.

It is a structural failure. And it is killing your codebase from the inside.

1. The Diagnosis: The Inverted Pyramid

Consider the reporting structure of a typical mid-level developer in 2024:

The Engineering Manager: Handles performance reviews, headcount, and "career growth."
The Shadow Manager: A senior manager or director who "checks in" on critical projects.
The Project Manager: Owns the Jira board, the sprint commitments, and the stakeholder updates.

Now count the technical mentors in this structure.

Zero.

This is the Inverted Pyramid anti-pattern. The developer has three people asking when the work will be done. They have no one helping them determine how it should be done.

The Tech Lead role—once the shield between business pressure and engineering reality—has been eliminated, redistributed, or reduced to a title without authority. Architecture decisions are made by committee. Code reviews are optional or perfunctory. Technical debt is invisible until it becomes a production incident.

The pyramid has inverted. Administrative overhead at the top. Engineering support at the bottom.

2. The Symptom: The 45-Minute Daily

You can observe this dysfunction in any sufficiently compromised standup.

What should be a 15-minute synchronization ritual has metastasized into a 45-minute interrogation. The format is predictable:

Developer mentions a blocker.
Manager asks for "more context."
Developer attempts to translate "race condition in the message consumer" into language that will not trigger a risk escalation.
Project Manager asks for a "revised ETA."
Developer provides a number. Any number.
The number becomes a commitment.

This is not Scrum. This is performance theater.

The cognitive load is immense. Developers are not problem-solving during these sessions. They are practicing organizational self-defense. Every technical statement must be sanitized, simplified, and stripped of nuance to avoid triggering management anxiety.

The irony: the meeting intended to remove blockers has become the blocker.

3. The Mechanism of Failure: Silent Compromises

Here is how deadlines actually work in the Inverted Pyramid:

Developer: "This feature requires 10 days. We need to implement retry logic with exponential backoff, add circuit breaker patterns, and write integration tests against the payment gateway's sandbox."

Project Manager: "Stakeholders need it in 5 days. What can we cut?"

Developer: "We could skip the circuit breaker and use a simple retry loop. It's not ideal, but—"

Project Manager: "Great. Let's do that."

This is the Silent Compromise. It is silent because it is never documented. The Jira ticket will show "Feature Complete." The pull request will be approved by another developer who is also under deadline pressure. The architectural shortcut will never be reviewed by someone with the authority to reject it.

In a healthy organization, the Tech Lead intercepts this conversation. They translate the technical risk into business terms: "If we skip the circuit breaker, a payment gateway outage will cascade into thread pool exhaustion. The entire checkout service will become unresponsive. Downtime cost will exceed whatever we save by shipping early."

Without that voice, the compromise passes in silence.

4. The Case Study: Anatomy of a Production Incident

Six months later, production goes down.

Here is the code that caused it:

public class PaymentRetryService {

    private static final int MAX_RETRIES = 5;
    private final PaymentGatewayClient paymentGateway;

    public PaymentRetryService(PaymentGatewayClient paymentGateway) {
        this.paymentGateway = paymentGateway;
    }

    public PaymentResult processWithRetry(PaymentRequest request) {
        int attempt = 0;

        while (attempt < MAX_RETRIES) {
            try {
                return paymentGateway.process(request);
            } catch (PaymentGatewayException e) {
                attempt++;
                if (attempt >= MAX_RETRIES) {
                    throw new PaymentFailedException("Max retries exceeded", e);
                }
                // "Temporary" solution - TODO: implement proper backoff
                try {
                    Thread.sleep(1000);
                } catch (InterruptedException ie) {
                    Thread.currentThread().interrupt();
                    throw new PaymentFailedException("Retry interrupted", ie);
                }
            }
        }
        throw new PaymentFailedException("Unexpected retry loop exit");
    }
}

This code worked perfectly in QA. It passed the demo. Stakeholders were satisfied.

Then the payment gateway experienced a 30-second latency spike.

What happened:

Each payment request spawned a thread that blocked for up to 5 seconds (5 retries × 1 second sleep).
Incoming requests accumulated. The thread pool saturated.
New requests queued. Timeouts cascaded.
The health check endpoint became unresponsive.
The load balancer marked the instance as unhealthy.
Traffic rerouted to remaining instances, which also saturated.
Total service outage: 23 minutes.

What should have existed:

A circuit breaker (Resilience4j, Hystrix) to fail fast when the gateway is degraded.
Exponential backoff with jitter to prevent thundering herd.
Async retry with a bounded queue to avoid blocking the request thread.
Metrics and alerting on retry rates.

None of this existed because "we didn't have time."

The 5 days saved in development cost 23 minutes of downtime, three incident postmortems, and an emergency patch deployed at 2 AM.

5. The AI Factor: Generating Debt at Scale

This situation has worsened since the advent of generative AI coding assistants.

The code snippet above? A junior developer can generate it in 30 seconds with a prompt like: "Write Java code to retry a payment request up to 5 times with a 1 second delay."

The AI will produce syntactically correct, functional code. It will compile. It will pass basic tests. It will look professional.

It will also contain every anti-pattern the prompt implied.

This is not the AI's failure. It is an amplifier. It amplifies whatever engineering culture already exists.

In an organization with strong code review practices, the AI-generated code gets caught. A senior engineer asks: "Why are we blocking threads here? Let's use a proper resilience library."

In the Inverted Pyramid organization, there is no such checkpoint. The code goes from AI to IDE to pull request to production. The review is a rubber stamp. The Tech Lead who would have caught it does not exist.

Generative AI has not changed the nature of technical debt. It has changed the velocity at which we can accumulate it.

6. Verdict: Engineering Authority Is Not Optional

The industry has convinced itself that engineering leadership is overhead. That "flat organizations" and "self-organizing teams" can replace the need for technical authority. That project managers and process frameworks can substitute for engineering judgment.

This is false.

You cannot replace architectural oversight with Jira workflows. You cannot replace mentorship with Confluence documentation. You cannot replace the word "no"—spoken by someone with the technical credibility to defend it—with another sprint planning meeting.

The Inverted Pyramid produces a predictable outcome: developers who cannot grow, systems that cannot scale, and incidents that cannot be prevented.

The fix is not another process. It is not another tool. It is not another AI assistant.

The fix is restoring engineering authority to engineering decisions. Put Tech Leads back in the room. Give them the power to reject bad estimates, block dangerous shortcuts, and mentor the developers who report to them.

Or keep running sprints. And keep wondering why you never finish.

If this resonates, you are not alone. The comment section is open.

Technical Debt is Not a Metaphor. It's Why Your Migration Failed.

Jacques Montagne — Wed, 14 Jan 2026 09:30:36 +0000

I recently went through Dave Farley's guide on Managing Technical Debt. It’s a mandatory read, mostly because it treats debt strictly as a business risk, not just a developer complaint.

I have spent the last two decades fixing systems that "moved fast and broke things."
Spoiler alert: they usually stayed broken.

Here is my take on Farley’s concepts, filtered through years of battling legacy Java monoliths and migrating them to AWS.

1. The "Bit Rot" Reality Check

Farley talks about "Bit Rot"—the idea that software degrades over time. We know code doesn't physically rust.

Farley defines Bit Rot as a symptom of neglect. It happens when teams fail to refactor and "tidy up" as they go. It’s the kitchen analogy: if you cook a five-course meal but never wash a pan or wipe the counter, eventually you can’t cook anymore. You are paralyzed by the mess.

I see this constantly in Java modernization's and Cloud migrations. A team lifts-and-shifts a Java application to AWS. They don't refactor. They don't modularize. Is updating just jdk a modernization?

The result? You have a 15-year-old monolith running on expensive EC2 instances. Every time you try to patch a security vulnerability, something breaks in a completely unrelated module.

My rule: If you aren't leaving the code better than you found it, it is already rotting.

2. Configuration Debt: The New Spaghetti

This is the part of the guide that hit home the most.

In the Java world, we spent years learning how to avoid spaghetti code. But now, I see "Spaghetti Infrastructure."

Security Groups defined manually by clicking in the UI.
Lambda triggers set up in the console, undocumented.
Terraform states that are out of sync with reality.

This is Configuration Debt. It is arguably worse than code debt because it can bring down your entire environment, not just one feature.

If I catch a developer changing infrastructure settings manually in the AWS Console, we have a problem. Not because I'm a purist, but because that manual change is a ticking time bomb for the next person who runs the deployment pipeline.

3. The GenAI Trap: High-Speed Legacy

This wasn't in Farley's original text, but it belongs there now.

Tools like Copilot or ChatGPT are incredible. I use them daily. But for a disciplined team, they are power tools. For an undisciplined team, they are High-Speed Debt Generators.

I am seeing Pull Requests filled with AI-generated boilerplate that the author clearly didn't read closely.

It works? Maybe.
Is it efficient? Rarely.
Does it handle edge cases? Never.

Remember: "Bit Rot" comes from neglect. If you generate AI code without ruthlessly refactoring and testing it, you are neglecting your codebase at 10x speed. You aren't "coding faster"; you are just automating the creation of Legacy Code.

My rule for AI code: Treat it like code written by a drunk intern. Review it twice as hard.

4. Test Debt: The High-Interest Loan

"We will write tests later."

No, you won't. I have never seen a team go back and "backfill" unit tests once the feature is in production.

Test Debt is dangerous because it kills velocity. Without a reliable test suite (and I mean fast, automated tests, not manual QA), you become afraid to change the code.

When you are afraid to change the code, the Bit Rot accelerates because you stop refactoring. It is a vicious cycle.

Summary

Technical Debt is inevitable, but it must be a conscious choice (like a mortgage), not the result of incompetence (like gambling).

Refactor constantly.
Codify everything (especially infra).
Don't let AI write code you don't understand.

We are paid to solve problems, not to create new ones for the future.

The Junior Developer Role is Dead. Long Live the "Apprentice".

Jacques Montagne — Wed, 31 Dec 2025 08:12:48 +0000

The industry is panic-scrolling. "Will AI replace Junior Developers?"

That is the wrong question. The correct question is:
"Does the Junior Developer role, as defined by Agile in 2010, still make economic sense?"

The answer is No.
But the solution isn't to stop hiring. The solution is to go back to 1400 AD.

The Death of the "Ticket Mover"

For the last 15 years, we trained Juniors using the "Factory Model":

Isolate a small, non-critical task (change button color, fix a typo, write a getter).
Create a Jira Ticket.
Let the Junior struggle for 2 days.
Review the PR.

This model is dead. Why? Because an AI Agent can close that ticket in 4 seconds for $0.01.

If you are hiring Juniors to "write simple code", you are burning money. If you are a Junior hoping to build a career by "closing tickets", you are in trouble.

The "Verification Gap"

In a Senior-led "Commando Unit" (or Tiger Team), the bottleneck is no longer generating code. It is verifying that the generated code is secure, business-compliant, and fits the architecture.

Seniors are overwhelmed by verification. We need help.
We don't need "Coders". We need "Auditors".

Return of the Guild: The Apprentice Model

We need to retire the title "Junior Developer" and bring back "The Apprentice".

In the Medieval Guilds, the Apprentice did not "build their own small cathedral". They carried the Master's tools, mixed the mortar, and watched how the Master solved problems.

Here is how I integrate Apprentices into an AI-augmented workflow:

1. The Shadow, not the Silo

My Apprentices don't get their own tickets. They sit in the Mob Session with me.
They don't write code in isolation. They watch the "Prompt Engineering" in real-time. They see how I reject 5 wrong solutions from the AI before accepting the 6th.

They learn discernment, not syntax.

2. The AI Auditor

I task my Apprentices with "Hostile Verification":

"The AI wrote this migration script. I want you to spend the next 4 hours trying to break it. Find the edge case the model missed."

This turns them from "Code Writers" into "Code Critics". This is a far more valuable skill for their future.

3. The "Why" Documentation

AI generates the What (Code). The Senior knows the Why (Architecture).
The Apprentice's job is to capture the Why.

They document the decision log of the Mob Session. They map the "Mental Model" of the Senior. By explaining the Senior's decision, they internalize it.

The ROI of Apprenticeship

Critics say: "This sounds expensive. You are paying 2 people to do 1 job."

Wrong. The math is simple:

The Old Way: Junior spends 3 days on a ticket -> Senior spends 2 hours fixing the PR -> Production bug -> Rollback. Total Cost: High.
The Apprentice Way: Junior catches the AI hallucination before commit -> Senior focuses on Architecture -> Documentation is actually written. Total Cost: Low (Risk Reduction).

Summary for Engineering Leaders

Stop hiring Juniors to improve your velocity. They won't.
Hire Apprentices to improve your Safety and Longevity.

The "Code Factory" is closed. The "School of Architecture" is open.

# The New Career Path
1. Apprentice (The Verifier & Student)
2. Journeyman (The AI-Augmented Builder)
3. Master (The Architect & Guild Leader)

Stop Writing User Stories for AI. Start Writing Specs.

Jacques Montagne — Mon, 29 Dec 2025 07:41:05 +0000

The "2-Pizza Team" is dead. McKinsey just confirmed that Agentic Workflows can increase productivity by "500%".
But there is a catch.

If you feed a Senior AI Agent (Claude 4.5 Sonnet / GPT-5.2) with a standard Agile User Story, you will get garbage.

Why? Because User Stories are "Conversation Starters". They rely on human context, tribal knowledge, and the "Definition of Ready" discussed in a meeting room.
AI was not in that meeting room.

If you want the "Commando Unit" efficiency I talk about on LinkedIn, you need to switch from Story-Driven Development to Spec-Driven Development (SDD).

Here is the protocol I use to migrate Legacy Java apps to AWS Serverless without breaking production.

The Entropy of Human Language

This is a typical Jira ticket:

User Story: As a customer, I want to filter my transaction history so I can see my spending.
Acceptance Criteria: Filter by date and amount.

If you give this to a Junior Dev, they will ask questions.
If you give this to Cursor/Copilot, it will hallucinate assumptions:

"I'll use client-side filtering!" (Performance killer)
"I'll assume the date format is MM/DD/YYYY!" (Breaks in Europe)

You are not managing risk; you are amplifying it.

The Protocol: Markdown Specifications

In my workflow, the "Senior Architect" does not write production code. The Architect writes the Spec. The AI writes the implementation.

As Werner Vogels said: "The work is yours, not the tool's."

I treat English as a programming language. The Spec must be deterministic.

The Structure

I create a .specs/ folder in my repository. Each feature gets a markdown file.

# SPEC-001: Transaction History Filter (API Level)

## 1. Context
Migrating `LegacyTransactionService.java` to AWS Lambda (Node.js/TypeScript).
Target Database: DynamoDB (Single Table Design).

## 2. Interface Contract (Strict)
**Input:** `GET /transactions`
- `startDate` (ISO8601, Optional)
- `minAmount` (Integer, cents, Optional)

**Output:** JSON Array `Transaction[]`
- Max page size: 50 items.
- Pagination: LastEvaluatedKey.

## 3. Logic & Constraints (The "Meat")
1. **Validation:** If `startDate` is in the future, throw `400 Bad Request`.
2. **Query Pattern:** MUST use DynamoDB `Query` (GSI_Date), NOT `Scan`.
3. **Legacy Parity:** Must replicate the "rounding error" logic from the old COBOL core (see reference: `calc_utils.legacy.js`).

## 4. Edge Cases
- User has 0 transactions -> Return `[]` (HTTP 200), not 404.
- DynamoDB Throttling -> Implement exponential backoff (Use AWS SDK v3 standard retry).

5. The "Vibe Coding" Trap: Why Code Comprehension is King

There is a lot of buzz around "Vibe Coding"—letting the AI handle the syntax while you focus on the flow.
But as Gene Kim and Steve highlight in their work on Vibe Coding, this only works if you have extreme Code Comprehension.

AI suffers from the "Illusion of Competence". It generates code that looks correct, compiles perfectly, but contains subtle logical bugs or security holes.

In this model, you are no longer just a "Writer". You are a Code Auditor.

Vibe Coding: Rapidly iterating with AI to build the structure.
Code Comprehension: Reading every generated line to ensure it matches the Spec and doesn't introduce hidden technical debt.

You cannot "vibe" your way through a banking migration. You must comprehend the output. If you treat the AI as a "Black Box", you are not engineering—you are gambling.

The Workflow (ROI Analysis)

This looks like "Waterfall", doesn't it?
Good.
Agile was created to manage the cost of change when coding was slow.
Now, coding is instant. The cost has shifted to debugging bad requirements.

Task	Old Model (Agile + Human)	New Model (Spec-Driven + AI)
Requirements	1h (Jira/Refinement)	2h (Deep Work / Writing Spec)
Coding	8h (Dev + Tests)	5 min (AI Generation)
Auditing / Review	1h (PR Review)	2h (Deep Line-by-Line Audit)
Total	10h	~4h

Conclusion: The "Thinking" Gap

The McKinsey report scares people because it implies we need fewer developers.
It's true. We need fewer coders.
But we need more Engineers who can articulate complex system behaviors in unambiguous text and validate the result.

AI is a multiplier.
Zero times a Million is still Zero.
If your input (User Story) is fluff, your output (Code) will be technical debt.

Stop writing stories. Start writing Specs.

Follow me for more on **Legacy Modernization* and Risk Management in the cloud.*

McKinsey Just Killed Agile: Why 'Commando Units' & Spec-Driven AI Are The Future of Legacy Migration

Jacques Montagne — Fri, 26 Dec 2025 16:46:28 +0000

Listen. I’m going to be brutally honest because I’m too old to play corporate politeness games.

For the last three articles, I’ve been advocating for a controversial operational model I call "Tiger Teams" or "Commando Units".

The premise was simple: Stop the relay race. Stop treating software engineering like an assembly line where 8 people pass a ticket around for two weeks. Put 3 senior engineers in a room, give them absolute silence, and watch them migrate a monolithic payment gateway to AWS in 4 days.

My inbox was full of Project Managers telling me this is "unsustainable."

Well, last week, McKinsey & Company validated everything the "Old Foxes" have been saying for years.

Let’s break down the data, the math, and the new toolchain (Kiro) that makes this possible.

The Data: 10% vs. 700%

In the video below, Martin Harrysson drops a bomb on the industry.

Most companies are currently trying to sprinkle GenAI on top of their existing Agile processes. They keep the 10-person teams, the daily standups, and just give everyone an autocomplete tool.

The result? A pathetic 10-15% productivity gain. (According to McKinsey).

Why? Because the bottleneck isn't typing speed. It's communication overhead.

However, companies that change the Operating Model to what I call "Commando Units" (Small Pods) are seeing results that are transformational. Based on my own deployments of this model in Cloud Migrations, we are seeing a 5x to 7x efficiency jump.

The "2-Pizza Team" is Too Big

In 2026, a single Senior Architect with the right Agentic IDE has the output capacity of 5 juniors from 2020.

The New Rule: The "1-Pizza Pod"

Size: 3-4 People Max.
Composition: 1 Lead Architect, 1-2 Senior Devs, 1 QA/Data Specialist.
Methodology: Continuous Flow, not Sprints.

The Pivot: From "User Stories" to "Hard Specs"

This is where most Agile coaches will start sweating.
We have spent the last decade training developers to write fuzzy "User Stories."

"As a user, I want to upload a file..."

This is useless for an AI-driven workflow. AI models hallucinate when you give them ambiguity. They thrive when you give them constraints.

If you are modernizing a 15-year-old Java Monolith to AWS Lambda, you don't need a User Story. You need a Specification.

The Weapon of Choice: Kiro (The Spec-Driven IDE)

I have stopped using standard chat-based assistants for complex migrations. They are too "chatty" and lose context.

Recently, I switched to Kiro.dev because it enforces a Spec-Driven Workflow. It doesn't guess; it follows the "Steering" files.

Here is my exact workflow for migrating a legacy module to AWS:

Step 1: Define the "Steering" (The Rules of Engagement)

In Kiro, I don't repeat myself. I define project-wide rules in the .kiro/steering/ directory.

File: .kiro/steering/tech.md

# AWS Migration Standards
1. **Compute:** Target AWS Lambda (Java 21 SnapStart) or Fargate.
2. **Persistence:** DynamoDB (Single Table Design) preferred over RDS.
3. **Observability:** implementation must include CloudWatch Structured Logging.
4. **Validation:** Use Pydantic (if Python) or Jakarta Validation (if Java).
5. **Forbidden:** Do not use `System.out.println`.

Step 2: Write the Spec (Not the Code)

Instead of writing a prompt, I write a .md spec file. Kiro reads this and plans the implementation.

File: specs/01_order_service_migration.md

# Specification: OrderService Migration
**Goal:** Refactor `EJBOrderService.java` to `OrderLambdaHandler.java`.

## Interface Contract
- **Trigger:** SQS Event (JSON payload).
- **Output:** Write to DynamoDB table `Orders`.

## Business Rules (Strict)
- Verify `totalAmount > 0`.
- If `customerType` is "VIP", apply 5% discount (logic copied from legacy).
- Idempotency: Use `orderId` as the DynamoDB Partition Key.

## Error Handling
- If DynamoDB throws `ProvisionedThroughputExceeded`, implement exponential backoff.
- Any other error -> Send to SQS Dead Letter Queue.

Step 3: The "Legacy Factory" Execution

Once the spec is ready, I trigger Kiro's Agent.

Prompt: "Implement specs/01_order_service_migration.md following the rules in .kiro/steering/tech.md. Generate the Infrastructure-as-Code (CDK) as well."

Because Kiro understands the entire project context and strict Specs, the code comes out production-ready, typically passing 90% of unit tests on the first run.

The ROI Calculation (Show this to your Boss)

Let's talk money.

Feature	Standard Agile Team	Commando Pod + Kiro
Headcount	8 Developers + 1 SM + 1 PO	3 Senior Engineers
Meetings/Week	~12 hours/person	~2 hours/person
Workflow	"Jira Tickets & Chat"	"Spec-Driven Agents"
Velocity	Linear (1x)	Exponential (5x)
Cost	High (10 salaries)	Medium (3 high salaries)

Final Thoughts: The Silence of the Lambs

My "Grand Strategy" for 2026 is simple: Deep Work and Silence.

I have blocked my calendar from 09:00 to 11:00. No meetings. No Slack. Just me, the AWS Console, and the Kiro Agents.

The McKinsey video proves that this isn't just "introvert preference." It is the optimal economic strategy for software development.

If you are a developer: Stop coding. Start architecting.
If you are a Manager: Stop scaling up. Start scaling down.

I am Jacques Montagne. I specialize in migrating Legacy Monoliths to AWS. I am currently building the "Legacy Commando" methodology using Kiro.dev. Follow me for more field reports.

Asynchronous Warfare: How to Deliver When The Org Won't Cooperate (Part 4)

Jacques Montagne — Fri, 26 Dec 2025 11:32:46 +0000

Strategies for Mocking, Decoupling, and InnerSourcing.

The "Ferrari in Traffic" Problem

If you followed Parts 1, 2, and 3, you now have a high-performance Tiger Team.

You use Tracer Bullets to validate paths instantly.
You use CoScreen/RustDesk to mob remotely with zero latency.
You deploy in 15-minute increments.

But then, reality hits.
You need an API change from the "Core Banking Team." You open a Jira ticket.
They reply: "Added to backlog. ETA: 3 weeks."

Your velocity drops from 100mph to zero.
This is the Asynchronous Warfare phase. Your internal speed is irrelevant if your external dependencies are blocked.

You cannot "agile" your way out of a dependency on a slow team. You must Decouple.
Here are the four tactical maneuvers to survive in a hostile, slow environment.

Tactic 1: Mock First, Ask Later (Consumer-Driven Contracts)

The Trap:
You wait for the dependency to build the API so you can consume it. This is "Integration Hell" in slow motion.

The Maneuver:
Do not wait. Define the contract yourself.

Write the OpenAPI (Swagger) spec that you wish existed.
Spin up a Mock Server (using WireMock or Microcks) that returns that exact response.
Build your entire feature against the Mock. Deploy it to UAT behind a Feature Flag.

The Power Move:
When the Core Team finally wakes up, you don't ask them "Can you design an API?"
You hand them the spec and the tests: "Here is the contract we are already using. Your job is just to make the backend satisfy this test."

wiremock / wiremock

A tool for mocking HTTP services

WireMock - flexible, open source API mocking

WireMock open source is supported by WireMock Cloud. Please consider trying it out if your team needs advanced capabilities such as OpenAPI, dynamic state, data sources and more.

WireMock is the popular open source tool for API mocking, with over 6 million downloads per month and powers WireMock Cloud.

It can help you to create stable test and development environments isolate yourself from flaky 3rd parties and simulate APIs that don’t exist yet.

Started in 2011 as a Java library by Tom Akehurst, now WireMock spans across multiple programming languages and technology stacks. It can run as a library or client wrapper in many languages, or as a standalone server. There is a big community behind the project and its ecosystem.

WireMock supports several approaches for creating mock APIs - in code, via its REST API, as JSON files and…

View on GitHub

Benefit: You shift the power dynamic. You define the standard; they just implement it.

Tactic 2: The Anti-Corruption Layer (ACL)

The Trap:
The Legacy Team finally delivers the API, but it's garbage. Column names are in French mixed with Hungarian notation (int_montant_ht_VAL), and the dates are strings.
If you use their data structures directly, your clean code becomes "infected" by their technical debt.

The Maneuver:
Build a hard wall. In Domain-Driven Design (DDD), this is an Anti-Corruption Layer.

Their World: Dirty Data, XML, SOAP.
The Wall (ACL): A distinct Adapter/Mapper class.
Your World: Clean DTOs, Immutable Records, English naming.

Rule: Never let a legacy class name (e.g., T_USR_DATA_V2) leak into your domain logic. Map it at the border, even if it feels redundant.

Tactic 3: InnerSource (The "Nuclear Option")

The Trap:
The dependency team agrees the change is easy (e.g., adding one column), but they have "no resources" to do it.

The Maneuver:
Stop asking for a service. Ask for access.

"I understand you are busy. Give my team Write Access to your repository for 2 days. We will implement the change, write the tests, and you only have to do the Code Review."

Why this works:

Scenario A: They agree. You do it yourself. You are unblocked.
Scenario B (Most likely): They are terrified of letting "outsiders" touch their code. Their pride gets hurt. Result: They suddenly "find time" to do it themselves by tomorrow just to keep you out.

Either way, you win.

Tactic 4: Weaponized Economics (For The Sponsor)

The Trap:
The Infrastructure Team says: "Opening this firewall port takes 10 business days. It's the SLA."

The Maneuver:
This is where your Executive Sponsor (from Part 3) steps in.
Engineers argue about time. Managers must argue about money.

Do not say: "It's too slow."
Say: "The Cost of Delay for this feature is *€15,000 per week** in lost opportunity. If we wait 2 weeks for a firewall rule, are you signing off on a €30,000 loss?"*

Suddenly, the firewall rule gets opened in 1 hour.
Risk is the only language bureaucracy understands.

Conclusion: The Completed Guide

You cannot fix the entire organization. If you try to modernize everything at once, you will be crushed by the inertia.

Instead, build a Tiger Team:

Isolate it financially (Part 1).
Equip it with tools like mr and RustDesk (Part 2 & 3).
Defend it with mocks and ACLs (Part 4).

Stop asking for permission to be efficient.
Decouple, Mock, Deliver.

This concludes "The Legacy Survival Guide". Good luck out there.

Remote Mobbing That Doesn't Suck: The 2026 Operational Guide (Part 3)

Jacques Montagne — Wed, 24 Dec 2025 17:45:00 +0000

Low-Latency Cockpits, RustDesk, and the Git Handover Protocol.

"Okay, you convinced me."

In my previous posts, I argued that Tiger Teams (cross-functional Commando Units) are the only way to modernize Legacy Systems effectively. But there is one objection I keep getting:

"Jacques, we are 100% remote. Sitting on a Zoom call for 6 hours a day sounds like hell. How do we do this without killing each other?"

Valid point. If you try to run a Mob Session using Microsoft Teams or Zoom, you will fail. The Deep Research is clear: these tools optimize for video smoothing, creating a latency of 100-150ms.

For code, we need the "Gold Standard": <50ms.
If there is a delay between me typing and you seeing it, our brains disconnect. We stop "collaborating" and start "instructing."

To survive, you need to build a "Digital Cockpit". Here is the operational guide based on the 2025 market landscape.

1. The "Pixel Streaming" Layer (Desktop Sharing)

This is the heavy artillery. You need to see the whole context: The IDE, the Terminal, the AWS Console, and the Database Client.

Option A: The Mac-First Choice (Tuple)

If your team is 100% macOS, stop reading and buy Tuple.

The Tech: It uses a custom WebRTC engine stripped of browser bloat, defaulting to Peer-to-Peer (P2P).
💰 The Concrete Gain: 5K Resolution at 60fps. It renders text sharply enough that you forget you are streaming. It feels local.

Option B: The Multi-Window Choice (CoScreen)

If you need to debug complex distributed systems.

The Tech: It allows you to share individual windows simultaneously. I can type in your Terminal window while you type in my IDE window.
💰 The Concrete Gain: True Mobbing. It eliminates the "Driver/Navigator" locking. Everyone has a mouse. It turns a "presentation" into a "war room."

Option C: The "Sovereign" Choice (RustDesk)

For those in Banking, Defense, or heavy Linux shops. Tuple has a "Linux Gap," and TeamViewer is expensive corporate bloat.

rustdesk / rustdesk

An open-source remote desktop application designed for self-hosting, as an alternative to TeamViewer.

Caution

Misuse Disclaimer:
The developers of RustDesk do not condone or support any unethical or illegal use of this software. Misuse…

View on GitHub

The Tech: Open-source, written in Rust. Crucially, it allows Self-Hosting.
💰 The Concrete Gain: Data Sovereignty. You can deploy the Relay Server inside your own VPC. No pixels ever leave your corporate network. It is the "TeamViewer Killer" for security-conscious commandos.

2. The "State Sync" Layer (IDE Native)

Sometimes you don't need pixels. You need raw speed on a low-bandwidth connection. These tools stream the Abstract Syntax Tree (AST), not video.

The Standard: JetBrains Code With Me / VS Code Live Share

💰 The Concrete Gain: Bandwidth Efficiency. You can pair on a 4G hotspot. Plus, I can navigate to User.java to check a reference while you are writing code in UserService.java. We are unblocked.

The Disruptor: Cursor (The "Synthetic Pair")

The market has shifted in 2025. "Pairing" no longer just means two humans.

The Tech: A fork of VS Code with native LLM integration.
💰 The Concrete Gain: The AI Driver. With features like "Composer," you can prompt the AI to refactor 5 files simultaneously while the Mob reviews the diffs. The "Mob" becomes: 3 Humans + 1 AI Agent.

3. The "Hacker" Layer (Terminal Sharing)

For DevOps and Platform Engineers, the GUI is a distraction. The truth lives in the shell. Do not share your screen for this; share the session.

The Tool: Zellij (The Modern `tmux`)

If you still use tmux or screen, it's time to upgrade. Zellij is a terminal multiplexer written in Rust.

zellij-org / zellij

A terminal workspace with batteries included

Zellij

[Installation] [Screencasts & Tutorials] [Configuration] [Layouts] [FAQ]

What is this?

Zellij is a workspace aimed at developers, ops-oriented people and anyone who loves the terminal. Similar programs are sometimes called "Terminal Multiplexers".

Zellij is designed around the philosophy that one must not sacrifice simplicity for power, taking pride in its great experience out of the box as well as the advanced features it places at its users' fingertips.

Zellij is geared toward beginner and power users alike - allowing deep customizability, personal automation through layouts, true multiplayer collaboration, unique UX features such as floating and stacked panes, and a plugin system allowing one to create plugins in any language that compiles to WebAssembly.

Zellij includes a built-in web-client, making a terminal optional.

You can get started by installing Zellij and checking out the Screencasts & Tutorials.

…

View on GitHub

The Feature: zellij --session pairing.
💰 The Concrete Gain: Instant Multi-Cursor in CLI.
- You don't need to install a client.
- You SSH into the bastion, attach to the session, and fix the server together.
- It works where GUIs fear to tread.

4. The Protocol: The "Git Handover"

Tools reduce friction, but Process prevents burnout. In a remote setting, the "Alpha Geek" tends to dominate the keyboard.

The 15-Minute Timer Rule:

Set a timer.
When it rings, the Driver stops immediately.

Command:

git commit -am "wip: handoff to [Name]" && git push

Next Driver: git pull and shares screen.

💰 The Concrete Gain:

Forced Engagement: You cannot tune out (check Instagram) because you are driving in 12 minutes.
Atomic History: You generate a granular commit history. If you go down a rabbit hole, you revert 15 minutes, not 4 hours.

Appendix: The 2025 Tooling Tier List

I have analyzed the market so you don't have to. Here is what you should fight for.

Tool	Category	Rating	The Concrete Gain (ROI)	Best For
RustDesk	Screen Sharing	5/5	Total Sovereignty. Self-hostable, zero spying risk.	Banks / DevOps
Tuple	Screen Sharing	4.5/5	Input Latency. The crispest remote control (<40ms).	macOS Teams
CoScreen	Multi-Window	4.5/5	Context Mixing. I share IDE, you share Terminal.	Debugging
Zellij	Terminal	5/5	Ops Velocity. Collaborative SSH without lag.	SRE / Platform
Cursor	AI Editor	5/5	Velocity Multiplier. The AI becomes the "Driver".	Greenfield
Teams/Zoom	Corporate	1/5	Nothing. High latency, blurry text. Avoid.	Presentations

The Bottom Line:
If you are a backend team on Linux, build a RustDesk + Zellij stack.
If you are a frontend team on Mac, buy Tuple + Cursor.

Stop trying to code on Zoom.

Stop The Relay Race: A Tech Lead’s Guide to "Tiger Teams" (Part 2)

Jacques Montagne — Sun, 21 Dec 2025 16:33:29 +0000

Virtual Monorepos, Tracer Bullets, and Escaping Integration Hell.

The Paradox of Modern Tools

We have Kubernetes, CI/CD pipelines, and AI assistants. Yet, shipping a single feature across a legacy ecosystem (Java Backend + SQL DB + JS Frontend) feels like pulling teeth.

Why? Because we rely on Component Ownership (Silos), which generates Integration Hell. The cost of coordinating changes across service boundaries often exceeds the cost of the code itself.

The solution isn't a new framework—it's an organizational shift to Tiger Teams: interdisciplinary units using Mob Programming to dismantle these costs. Below is a technical field guide on implementing this approach.

Step 1: The Tooling (Virtual Monorepo)

In a legacy landscape, you rarely have a clean monorepo. You have an archipelago of repositories—some Git, some SVN, loosely coupled by APIs.
To move as a Tiger Team, you need a meta-layer of control.

Option A: The "Old Fox" Choice — myrepos (mr)

For polyglot environments (Java + JS + Python), myrepos (by Joey Hess) is the pragmatic standard. It abstracts underlying VCS differences, allowing unified control across repos.

Setup (.mrconfig):

[.]
chain = true

[backend-service-legacy]
checkout = git clone git@github.com:company/backend.git

[frontend-react]
checkout = git clone git@github.com:company/frontend.git

Instead of cd-ing into multiple directories, run:

mr update

to pull changes for all services simultaneously.

Power Move: Define custom workflows in .mrconfig to reduce friction:

git_nuke = git clean -fdx && git reset --hard HEAD

This turns mr into a force multiplier.

Option B: The Node.js Choice — meta

If your stack leans JS/TS, use meta.

mateodelnorte / meta

tool for turning many repos into a meta repo. why choose many repos or a monolithic repo, when you can have both with a meta repo?

Solo Devs Don't Survive Legacy: Why 'Commando Units' Beat 'Full Utilization' (Part 1)

Jacques Montagne — Sat, 20 Dec 2025 18:57:16 +0000

So, you’ve inherited a legacy beast. It’s written in a framework that lost support when Obama was president.

There is no documentation. The original architect retired to a farm in Provence.

And management just hired 5 new contractors and assigned each of you a separate component to modernize.

I have seen this movie before. It ends with a blown budget, a cancelled project, and you updating your CV because you spent 6 months accomplishing absolutely nothing.

Here is the brutal truth: In a high-discovery environment (undocumented legacy), solo work is simulation.

The Cognitive Load Trap

When you work alone on a legacy component, you aren't coding. You are doing reverse engineering.

You are trying to hold the entire database schema, the business logic, and the weird side-effects of a stored procedure in your RAM (working memory).

Cognitive Load Theory tells us that once your working memory overflows, your IQ drops.

You stare at the screen. You switch context. You check Slack. You rewrite the same line of code three times.

You are busy, but you aren't producing value.

Enter the "Commando" Unit (The Tiger Team)

Your colleague proposed a “Commando” approach: small teams (2–3 people), one feature at a time.

Management hates it because it looks like paying 3 people to do 1 person’s job.

Management is wrong.

Here is the physics of a Commando Unit applied to legacy:

Distributed RAM: When 3 people look at the same code (Swarming/Mobbing), you pool your working memory. One person navigates the database, one tracks the business logic, one drives the keyboard. You don’t get stuck — you bulldoze through the confusion.
Instant Code Review: In the status quo, you wait days for a review — often shallow because the reviewer doesn’t understand your component. In a Commando Unit, the review happens while you type. The error rate drops to near zero.
The Bus Factor: If you work alone and get sick, your component dies. In a Commando Unit, knowledge spreads instantly. The Bus Factor goes from 1 to 3.

The "Friday-to-Thursday" Cycle (Shape Up Style)

Your colleague suggested a specific rhythm:

Friday: Planning & research (in office). Map out the terrain.
Mon–Wed: Remote execution. Deep work. No corporate fluff meetings.
Thursday: Demo & deploy.

This isn’t “Agile” with sticky notes and empty process ceremonies.

This is Shape Up — betting on a specific scope and delivering it.

It kills the “Zombie Tickets” that sit in In Progress for weeks.

Conclusion: Don’t Be a Hero

Modernizing legacy code isn’t about how fast you type.

It’s about how fast you learn.

Solo developers learn slowly and fail quietly.

Commando Units learn fast and deliver loudly.

Stop simulating work.

Form a squad.

Kill the legacy monster together.

How to Write in Markdown but Deliver in Word. A Senior Architect's Workflow.

Jacques Montagne — Fri, 19 Dec 2025 23:38:10 +0000

The Conflict: Engineering vs. Management

There is a fundamental conflict in corporate IT:

Engineers want to write documentation like code (Markdown, in IDE, versioned in Git).
Management/Clients want "professional" documents (Word, neatly formatted, with logos).

As a Senior Architect, I refuse to spend my "Deep Work" hours fighting with Microsoft Word margins or table alignments. But I also know that sending a raw .md file to a stakeholder is unprofessional.

The solution is not to surrender to Word. The solution is to compile to Word.

The Tool: Pandoc with Reference Docs

Pandoc is a command-line tool that converts text formats. But its "killer feature" for corporate environments is the --reference-doc flag.

This feature allows you to map your plain Markdown text onto a strictly formatted corporate Word template.

The Workflow

Tutorial: Setup Your Factory

Here is how I set up a "Documentation Factory" in 5 minutes.

Step 1: Install Pandoc

macOS: brew install pandoc
Windows: choco install pandoc

Step 2: Create the "Reference Dog" (The Template)

This is the most important step. You don't create styles in Pandoc. You "steal" them from a Word doc.

Take an existing, well-formatted document from your company (one with the correct headers, fonts, and footer logo).
Delete all the content, leaving just one dummy header and one paragraph.
Save it as reference.docx.

Step 3: Write in Markdown

Open your IDE (VS Code / IntelliJ). Write your specs using standard Markdown.

# Architectural Decision Record 001

## Context
We need to migrate the Monolith to AWS.

## Decision
We will use AWS Lambda and Spring Boot SnapStart.

## Consequences
* Cost reduction by 40%
* Cold starts handled by SnapStart

Step 4: The Build Command

Run this simple command in your terminal:

pandoc input.md -o Final_Report.docx --reference-doc=reference.docx

What just happened?
Pandoc took your text from input.md and "poured" it into the styles defined in reference.docx.

Your # Header 1 became the company's official blue, size 16 font.
Your lists are perfectly indented.
The company logo is already in the header/footer.

Why This is a Career Hack

Speed: You write 3x faster in Markdown than in Word.
Version Control: You can track changes in Git. Try doing a "Code Review" on a binary .docx file—it's impossible. With this method, you review the Markdown, merge it, and generate the Word doc as a build artifact.
Professionalism: You deliver documents that look exactly like the business expects, without ever opening Office 365.

Work smart, not hard. Let the CLI handle the formatting.

AWS Q Developer Agent vs. OpenRewrite: An Architect’s Guide to Realistic Migration Strategies

Jacques Montagne — Thu, 18 Dec 2025 07:17:27 +0000

Disclaimer: This analysis is based on technical documentation, re:Invent sessions, and deep-dive comparisons of the underlying architecture. It aims to cut through the hype to find the optimal workflow for enterprise migrations.

The Promise vs. The Reality

If you attended recent AWS workshops or watched the demos at re:Invent, you likely left with the impression that AWS Q Developer Agent for Code Transformation (formerly AWS Transform) is a magic wand. You upload a Java 8 JAR, wait a few hours, and download a pristine Java 17/21 Spring Boot application.

For a "Hello World" or a standardized microservice? Yes, it works beautifully.
For a 15-year-old Enterprise Monolith with cyclic dependencies and custom SOAP wrappers? It requires a strategic approach.

As a Senior Architect, I dissected the tool to understand what is happening under the hood and how to use it effectively without getting stuck in feedback loops.

1. Under the Hood: Orchestration vs. Generation

It is crucial to understand that the Agent isn't just "Hallucinating code upgrades." The architecture typically follows a robust 80/20 split:

80% Deterministic Rules (OpenRewrite): A significant portion of the work—bumping JDK versions, modifying pom.xml, upgrading Spring Boot namespaces—is powered by engines like OpenRewrite. This is a mature, rule-based engine. It doesn't "think"; it executes precise recipes.
20% GenAI (The Resolution Layer): The LLM (Bedrock) acts as an intelligent exception handler. It steps in when the deterministic build fails, attempting to logically deduce fixes for compilation errors that static analysis cannot resolve.

The Architect's Take: You aren't just paying for AI; you are paying for a managed orchestration layer that combines static analysis with generative fallback.

2. The Feedback Loop Challenge

The main friction point in a pure-cloud approach is latency.

The Local Way (OpenRewrite CLI)

Run Recipe (mvn rewrite:run).
Instant feedback.
Fix compilation error in IDE.
Total cycle time: ~15 minutes.

The Cloud Sandbox Way

Zip code and upload to S3.
Wait for the Agent sandbox to boot.
Agent runs transformation.
Build fails -> Agent asks LLM for a fix -> Agent retries.
Total cycle time: 2 to 4+ hours.

By moving the "fix" phase entirely to the cloud, you lose the interactivity of the IDE. For complex legacy apps, this "blind debugging" can be costly.

3. The "Success Probability" Matrix

Not all apps are created equal. When planning your migration roadmap, consider this topology:

Application Type	Complexity	AWS Q Agent Success Rate
Standard Demo / Pet Clinic	Low	High (95%)
Standard Microservice	Medium	Good (75%)
Legacy Monolith	High	Moderate (45%) - Requires manual intervention
"Frankenstein" Legacy	Extreme	Low (< 15%) - Requires heavy refactoring first

Note: If your application relies on internal Nexus libraries or proprietary frameworks not visible to the public training data, the Agent will struggle to hallucinate a fix for dependencies it cannot see.

4. The Strategy: A Hybrid Migration Pattern

Instead of choosing between "Manual" and "AI-Only," I recommend a Hybrid Pipeline to satisfy both Developers (who need speed) and Security (who worry about IP):

Step 1: Local Deterministic Pass (Velocity)

Don't upload dirty code. Run OpenRewrite locally first.

Update pom.xml parents.
Apply standard recipes (e.g., javax to jakarta).
Why? It's free, instant, and catches the low-hanging fruit without the cloud latency.

Step 2: The Cloud "Closer" (Complexity)

Once the noise is cleared, upload the cleaner artifact to AWS Q Developer Agent.

Let the AI handle the obscure compilation errors and logical shifts that OpenRewrite missed.
The Agent now has a much higher chance of success because the "noise" of basic version mismatches is gone.

Step 3: AI for Assurance

Instead of asking AI to just "migrate," use tools like Q or Copilot to generate unit tests for the legacy code before you start. High test coverage is the only safety net that makes the migration verifiable.

Final Verdict

AWS Q Developer Agent is a powerful tool, but it shouldn't be treated as a "black box" solution for every scenario. By understanding its reliance on deterministic rules and combining it with local workflows, you can reduce migration time from months to weeks.

DEV Community: Jacques Montagne

AI is an Amplifier. Are You Amplifying Engineering or Dysfunction?

The "Slop" Myth vs. Economic Reality

Automating the Dysfunction

The "Cognitive Debt" Trap

The Strategy: Safe Modernization

Conclusion

The 'Sprint' Illusion: 3 Bosses, 0 Tech Leads, and the 'AI-Generated' Debt

The 'Sprint' Illusion: 3 Bosses, 0 Tech Leads, and the 'AI-Generated' Debt

1. The Diagnosis: The Inverted Pyramid

2. The Symptom: The 45-Minute Daily

3. The Mechanism of Failure: Silent Compromises

4. The Case Study: Anatomy of a Production Incident

5. The AI Factor: Generating Debt at Scale

6. Verdict: Engineering Authority Is Not Optional

Technical Debt is Not a Metaphor. It's Why Your Migration Failed.

1. The "Bit Rot" Reality Check

2. Configuration Debt: The New Spaghetti

3. The GenAI Trap: High-Speed Legacy

4. Test Debt: The High-Interest Loan

Summary

The Junior Developer Role is Dead. Long Live the "Apprentice".

The Death of the "Ticket Mover"

The "Verification Gap"

Return of the Guild: The Apprentice Model

1. The Shadow, not the Silo

2. The AI Auditor

3. The "Why" Documentation

The ROI of Apprenticeship

Summary for Engineering Leaders

Stop Writing User Stories for AI. Start Writing Specs.

The Entropy of Human Language

The Protocol: Markdown Specifications

The Structure

5. The "Vibe Coding" Trap: Why Code Comprehension is King

The Workflow (ROI Analysis)

Conclusion: The "Thinking" Gap

McKinsey Just Killed Agile: Why 'Commando Units' & Spec-Driven AI Are The Future of Legacy Migration

The Data: 10% vs. 700%

The "2-Pizza Team" is Too Big

The Pivot: From "User Stories" to "Hard Specs"

The Weapon of Choice: Kiro (The Spec-Driven IDE)

Step 1: Define the "Steering" (The Rules of Engagement)

Step 2: Write the Spec (Not the Code)

Step 3: The "Legacy Factory" Execution

The ROI Calculation (Show this to your Boss)

Final Thoughts: The Silence of the Lambs

Asynchronous Warfare: How to Deliver When The Org Won't Cooperate (Part 4)

The "Ferrari in Traffic" Problem

Tactic 1: Mock First, Ask Later (Consumer-Driven Contracts)

wiremock / wiremock

A tool for mocking HTTP services

WireMock - flexible, open source API mocking

Tactic 2: The Anti-Corruption Layer (ACL)

Tactic 3: InnerSource (The "Nuclear Option")

Tactic 4: Weaponized Economics (For The Sponsor)

Conclusion: The Completed Guide

Remote Mobbing That Doesn't Suck: The 2026 Operational Guide (Part 3)

"Okay, you convinced me."

1. The "Pixel Streaming" Layer (Desktop Sharing)

Option A: The Mac-First Choice (Tuple)

Option B: The Multi-Window Choice (CoScreen)

Option C: The "Sovereign" Choice (RustDesk)

rustdesk / rustdesk

An open-source remote desktop application designed for self-hosting, as an alternative to TeamViewer.

2. The "State Sync" Layer (IDE Native)

The Standard: JetBrains Code With Me / VS Code Live Share

The Disruptor: Cursor (The "Synthetic Pair")

3. The "Hacker" Layer (Terminal Sharing)

The Tool: Zellij (The Modern tmux)

zellij-org / zellij

A terminal workspace with batteries included

Zellij

[Installation] [Screencasts & Tutorials] [Configuration] [Layouts] [FAQ]

What is this?

4. The Protocol: The "Git Handover"

The 15-Minute Timer Rule:

Appendix: The 2025 Tooling Tier List

Stop The Relay Race: A Tech Lead’s Guide to "Tiger Teams" (Part 2)

The Paradox of Modern Tools

The Tool: Zellij (The Modern `tmux`)