DEV Community: Terezinha Tech Operations

The Most Important Decision You'll Make as an Engineer This Year

Pedro Arantes — Sat, 10 Jan 2026 19:41:49 +0000

The single most important decision an engineer must make today is a binary choice regarding their role in the software development lifecycle.

Option A: Continue reviewing code line-by-line as if a human wrote it. This path guarantees you become the bottleneck, stifling your team's throughput.

Option B: Evolve your review policy, relinquishing low-level implementation control to AI to unlock high-level architectural velocity.

If you choose Option A, this article is not for you. You will likely continue to drown in an ever-increasing tide of pull requests until external metrics force a change.

If you choose Option B, you are ready for a paradigm shift. However, blindly "letting AI code" without a governance system invites chaos. You need robust strategies to maintain system quality without scrutinizing every line of implementation. Here are the five strategies that make Option B a reality.

The Velocity Trap: Why Option A is Mathematically Impossible

This decision is driven by a hard mathematical reality.

An experienced engineer can meaningfully review perhaps 200 lines of complex code per hour. An AI agent can generate 200 lines of code per second.

If you choose Option A, you are pitting linear human processing speed against exponential AI generation speed. As your team adopts more AI tools, the volume of code produced will increase by orders of magnitude. If your review policy remains "human eyes on every line," your backlog will grow infinitely, and your velocity will asymptote to zero.

You cannot out-read the machine. You must out-think it.

Strategy 1: Climb the Abstraction Ladder

The first step is to redefine what you "understand" about your software.

Historically, "understanding the codebase" meant knowing how the if statements worked inside a specific function. In the age of AI, this is unsustainable. You must divide your software mental model into a hierarchy: Product > System > Modules > Functions.

The shift is simple: Stop reviewing the lowest level (functions, in this example).

If a product has a Stripe integration, you should not care if the code uses a ternary operator or an if-else block. You should care that there is a Billing System containing a Stripe Module that adheres to a specific contract.

Your job is to maintain a clear mental model of the higher levels (Product and Systems). This aligns with The Principle of Contractual Specialization. By keeping the boundaries rigid, you can let the AI handle the implementation details within those boundaries. As noted in Coding is Now a Commodity, the value has shifted from the "bricks" (functions) to the "blueprint" (system architecture).

Strategy 2: Review Instructions, Not Code

When you find a flaw in the architecture or logic, your instinct will be to fix the code. Resist it.

If the AI generates code that violates your architecture, it is a mentorship failure. Instead of rewriting the code, rewrite the instruction or the system prompt that generated it.

This transforms you from a code reviewer into an architect of agency. As discussed in From Scripter to Architect, you are no longer the author of the flow; you are the architect of the boundaries. If you fix the code manually, you teach nothing and fix only one instance. If you fix the instruction, you maintain the "employee" that will write the next 100 features.

Strategy 3: Automated Verification as the Safety Net

The fear of not reviewing low-level code is reasonable: "What if there's a bug?"

This brings us to the third strategy: Aggressive Automated Testing.

When you stop reviewing functions, you lose the ability to spot subtle logical bugs by eye. You must replace that manual vigilance with Automated Verification.

Tests are the guarantee that allows you to be "ignorant" of the details. When an engineer (or AI) needs to fix a bug in a low-level module they don't fully understand, the test suite acts as the guardrail. It ensures that fixing the Stripe integration doesn't break the User Auth flow.

This approach implements The Principle of Intrinsic Verification. You are trading the high-friction cost of manual review for the upfront cost of writing robust tests. This allows you to escape the AI Verification Trap and focus on system-level constraints rather than syntax.

Strategy 4: Enforce Schema Supremacy

You can't verify everything, but you can verify the boundaries.

Before an AI writes a single line of logic, you should strictly define the input and output schemas (Types, Interfaces, Zod schemas). This is Schema Supremacy.

If you control the shape of the data entering and leaving a module, you care much less about how the data is transformed inside. You aren't reviewing the transformation logic; you are reviewing the strictness of the contract. If the AI respects the schema, the crash radius of bad code is contained.

Strategy 5: Observability as Interest Payments

When you trade review depth for velocity, you are technically taking on a form of risk. You pay for this risk with Observability.

You shift from "Is this code clean?" to "Is the system healthy?"

Instead of agonizing over potential edge cases in code review, you ensure you have logs, metrics, and alerts that will scream if those edge cases happen in production. This aligns with Observability as Interest Payments. If you can't see it fail, you can't afford to let the AI write it without review.

Conclusion

The decision to shift from reviewer to architect is about relevance and leverage.

You can remain the gatekeeper who catches every missing semicolon, proudly "owning" every line of code while shipping one feature a month. Or you can evolve into the architect who defines the systems, authors the instructions, and enforces the verification loops—empowering an AI workforce to ship at the speed of compute.

The first path leads to traditional engineering. The second path defines the future of engineering. Make your choice.

Tutorial: How to Serve REST and MCP on the Same Server

Pedro Arantes — Mon, 29 Dec 2025 09:44:37 +0000

This example demonstrates how to create a single HTTP server that exposes both REST and MCP (Model Context Protocol) endpoints, sharing the same business logic.

Using @ttoss/http-server and @ttoss/http-server-mcp, which are built on top of Koa and the official Model Context Protocol TypeScript SDK, this example showcases how to integrate traditional REST APIs with AI-compatible MCP endpoints in a single application.

Check the source code on GitHub to adapt to your case:

Features

Shared Business Logic: A simple sum function used by both REST and MCP endpoints
REST Endpoint: POST /sum - Traditional HTTP API
MCP Endpoint: POST /mcp - AI-compatible MCP protocol
Single Server: Both endpoints run on the same server instance

Running the Example

# Clone the ttoss repository
git clone https://github.com/ttoss/ttoss.git
cd ttoss

# Install dependencies from monorepo root
pnpm install

# Navigate to this example
cd examples/http-server-mcp-calculator

# Run the example
pnpm dev

The server will start on http://localhost:3000.

Testing the Endpoints

REST Endpoint

curl -X POST http://localhost:3000/sum \
  -H "Content-Type: application/json" \
  -d '{"a": 5, "b": 3}'

Expected response:

{
  "result": 8,
  "operation": "5 + 3 = 8"
}

MCP Endpoint

The MCP endpoint follows the Model Context Protocol specification and can be called by AI assistants like Claude Desktop.

Configure in Claude Desktop's claude_desktop_config.json:

{
  "mcpServers": {
    "calculator": {
      "url": "http://localhost:3000/mcp"
    }
  }
}

Or test with the MCP Inspector CLI:

# List available tools
npx @modelcontextprotocol/inspector --cli http://localhost:3000/mcp \
  --transport http --method tools/list

# Call the sum tool
npx @modelcontextprotocol/inspector --cli http://localhost:3000/mcp \
  --transport http --method tools/call \
  --tool-name sum --tool-arg a=5 --tool-arg b=3

Key Concepts

1. Shared Business Logic

// Single source of truth
const sum = (a: number, b: number) => a + b;

This function is reused by both REST and MCP endpoints, ensuring consistency.

2. REST Endpoint

Traditional HTTP API that directly uses the business logic:

router.post('/sum', (ctx) => {
  const { a, b } = ctx.request.body;
  const result = sum(a, b);
  ctx.body = { result, operation: `${a} + ${b} = ${result}` };
});

3. MCP Endpoint

AI-compatible endpoint that also uses the same business logic:

mcpServer.registerTool(
  'sum',
  {
    description: 'Add two numbers together',
    inputSchema: {
      a: z.number().describe('First number'),
      b: z.number().describe('Second number'),
    },
  },
  async ({ a, b }) => {
    const result = sum(a, b);
    return {
      content: [{ type: 'text', text: `${a} + ${b} = ${result}` }],
    };
  }
);

4. Single Server Instance

Both endpoints are mounted on the same Koa app:

const app = new App();
app.use(restRouter.routes()); // REST endpoints
app.use(mcpRouter.routes()); // MCP endpoints
app.listen(3000);

Benefits of This Architecture

Code Reuse: Business logic is written once, used everywhere
Consistency: Same validation and behavior across protocols
Maintainability: Changes to business logic automatically apply to all endpoints
Flexibility: Support both traditional clients (REST) and AI assistants (MCP)
Resource Efficiency: Single server process handles all traffic

Learn More

Coding is Now a Commodity

Pedro Arantes — Sat, 27 Dec 2025 13:49:00 +0000

Farming didn't disappear when tractors arrived—it evolved. Software development is undergoing the same transformation with AI. The shift is from manual coding to system architecture.

The "Commoditization" of Coding

A few years ago, "React Developer" was a sought-after title. Today, writing React, JavaScript, GraphQL, or managing basic cloud setups has become a commodity. If the "how-to-code" is now a commodity, what isn't?

The Three Phases of Development

The Low-Level Era: Early on, energy was spent on binary code and compilers. We struggled with the machine's language.

The Framework Era: Development evolved so we could see changes in real-time. We spent 100% of our time mastering specific tools like React, MongoDB, and Cloud providers.

The AI Era: You no longer need to master every syntax detail. The AI handles the "labor," freeing you to focus on the bigger picture.

The New Skill Set

If AI writes the code, your value now lies in system design—understanding how systems connect, managing global state, data consistency, and scalability. This means knowing the difference between eventual consistency and strong consistency, understanding when to use synchronous versus asynchronous patterns, not just how to write a React component.

Problem decomposition becomes critical. The ability to break complex problems into small, precise tasks that an AI can execute accurately is the new bottleneck. Following agentic development principles ensures you can direct AI effectively. Each task must be atomic, testable, and unambiguous.

You will spend more time reading code than writing it. Code review shifts from checking syntax to auditing for security flaws, performance bottlenecks, and catching AI hallucinations. Understanding what the system does becomes more valuable than knowing how to write it.

Infrastructure and observability matter more than ever. Knowing where the code runs, how it scales, and—most importantly—how to debug when it breaks separates effective developers from those still thinking in framework terms. Logs, metrics, and traces become your primary interface.

Finally, collaboration and communication with cross-functional teams ensures the system meets user needs and business goals. The ability to translate business requirements into system constraints and explain technical trade-offs to non-technical stakeholders is increasingly valuable.

The focus has shifted from the "bricks" to the "blueprint."

Why You Can't "Manage" Code You Don't Understand

Pedro Arantes — Mon, 22 Dec 2025 01:39:52 +0000

A common question in the age of AI is: "If AI writes the code, do developers just become Product Managers?"

The answer is No, and the reason lies in The Principle of Contextual Authority.

Product Managers primarily own the Problem Space (user needs, market fit, value). Engineers primarily own the Solution Space (architecture, reliability, maintainability).

If a PM doesn't understand the market, they build the wrong product. If an Engineer doesn't understand the system, they build a fragile product.

The "How" Contains the Risk

When a developer delegates to AI without maintaining ownership, they are trying to outsource the Solution Space. The story becomes: "The AI handles the 'how', I just handle the 'what'." But the "how" contains the technical risk you can't outsource.

The "how" determines if the database locks up under load.
The "how" determines if the security model is valid.
The "how" determines if the system can be extended next month.

If the engineering team delegates the "how" to AI without maintaining deep understanding, the codebase becomes a liability. Also, the team doesn't become PMs; they become custodians of technical debt they can't reason about.

The Contractor Trap

When you delegate a task to an AI because you don't understand the code (or don't want to deal with its complexity), you are acting as a Contractor. You are using the AI as a shield against complexity. The AI produces a "black box" patch that closes the immediate ticket, but you can't predict its impact on the rest of the system.

If you do this enough times, you lose your mental model of the software. You become a "Product Manager of Code"—someone who can describe what they want, but can't reliably explain why it works or when it will fail.

And unlike a real Product Manager who relies on an engineering team to ensure structural integrity, you're relying on a model that (without strong feedback loops) is optimized for plausible output, not system guarantees.

The Architect of Agency

The best strategy for scaling is not to become a manager of black boxes, but to become an Architect of Agency. You use AI to execute, but you rigorously audit the output against your mental model. You trade the low-leverage work of syntax generation for the high-leverage work of System Verification.

This requires Ownership-Preserving Delegation. Don't demand "trust me" output. Demand an audit trail: tests that pin behavior, clear invariants, notes about trade-offs, and a narrative diff you can reason about before you accept the change.

You don't lose ownership by delegating; you lose ownership by stopping to look.

From Reviewer to Architect: Escaping the AI Verification Trap

Pedro Arantes — Thu, 18 Dec 2025 18:15:29 +0000

There's a moment every engineering manager experiences after adopting AI coding tools. The initial excitement—"We're shipping features twice as fast!"—slowly curdles into a disturbing realization: "Wait, why are my senior engineers spending hours manually testing for regressions that proper automated tests could catch in seconds?"

This is the AI Verification Trap, and there's only one way out.

The Trap

The trap isn't that AI makes you slower—it's that AI shifts the bottleneck to where your most expensive resources are doing the cheapest work.

Here's how it unfolds:

You adopt AI coding agents
Code generation accelerates 5-10x
Your review queue grows proportionally
Engineers spend their days catching type errors, formatting issues, and broken tests
High-value work (architecture, business logic, innovation) gets squeezed out
You're shipping faster, but your engineering capacity is misallocated
Competitors who automated verification are shipping faster AND building better

This trap is a direct consequence of The Principle of Verification Asymmetry: generating AI output is cheap, verifying it is expensive. When you 10x generation without automating verification, you create a misallocation crisis—expensive human attention spent on problems machines could solve.

The False Dichotomy

Most teams see only two options:

Option A: Rigorous Review

Every AI-generated PR receives full human scrutiny. Engineers catch everything—formatting issues, type errors, test failures, security vulnerabilities, AND business logic problems. Velocity improves over pre-AI baselines, but engineers are exhausted from reviewing PRs that should never have reached them. A senior engineer earning $200/hour spends 30 minutes catching a missing semicolon.

Option B: Trust the Machine

Reduce review friction. If tests pass, ship it. Velocity spikes dramatically. Six months later, the codebase is an unmaintainable disaster of subtle bugs and architectural violations that no human ever validated.

Both options waste resources. Option A wastes engineering talent on automatable work. Option B wastes future velocity on technical debt. The trap seems inescapable.

But there's a third option that most teams miss.

Option C: Stop Reviewing, Start Architecting

The insight is this: not all verification requires human judgment. Most of what engineers catch in review—formatting, types, test failures, complexity violations—can be caught by machines at near-zero cost.

The solution is to architect verification systems that filter out automatable problems before they reach human eyes.

This is the shift from "engineer as reviewer" to "engineer as architect." Instead of spending 30 minutes reviewing each PR (catching issues a linter could find), you spend 30 hours building systems that filter 1,000 PRs automatically—so human review focuses only on what humans do best: validating intent, architecture, and business logic.

The Automated Verification Pipeline

The Automated Verification Pipeline pattern provides the architectural blueprint:

┌─────────────────────────────────────────────────────────────────────┐
│                    THE VERIFICATION FUNNEL                          │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│   AI Output (100 PRs)                                               │
│        │                                                            │
│        ▼                                                            │
│   ┌─────────────┐                                                   │
│   │   Linters   │ ──► 20 PRs sent back (formatting issues)         │
│   └─────────────┘                                                   │
│        │ 80 PRs                                                     │
│        ▼                                                            │
│   ┌─────────────┐                                                   │
│   │ Type Check  │ ──► 15 PRs sent back (type errors)               │
│   └─────────────┘                                                   │
│        │ 65 PRs                                                     │
│        ▼                                                            │
│   ┌─────────────┐                                                   │
│   │ Unit Tests  │ ──► 25 PRs sent back (behavioral regression)     │
│   └─────────────┘                                                   │
│        │ 40 PRs                                                     │
│        ▼                                                            │
│   ┌─────────────┐                                                   │
│   │ Complexity  │ ──► 10 PRs sent back (exceeded thresholds)       │
│   │   Gates     │                                                   │
│   └─────────────┘                                                   │
│        │ 30 PRs                                                     │
│        ▼                                                            │
│   ┌─────────────┐                                                   │
│   │  Security   │ ──► 5 PRs sent back (vulnerability detected)     │
│   │  Scanners   │                                                   │
│   └─────────────┘                                                   │
│        │ 25 PRs                                                     │
│        ▼                                                            │
│   ┌─────────────┐                                                   │
│   │   Human     │ ──► 25 PRs reviewed (semantic validation only)   │
│   │   Review    │                                                   │
│   └─────────────┘                                                   │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘

From 100 AI-generated PRs, only 25 require human attention. And those 25 have already passed syntax, type, behavioral, complexity, and security checks. The human reviewer's job transforms from "catch all problems" to "validate intent and architecture"—the work that actually requires human judgment.

The Economics of Misallocation

The real cost isn't productivity—it's opportunity cost. Let's quantify:

Without Automated Filtering:

100 PRs × 30 min/review = 50 hours/day of review
Team capacity: 8 engineers × 8 hours = 64 hours
Review consumes 78% of team capacity
Of that review time, ~70% is spent catching issues machines could catch
35 hours/day of senior engineering talent wasted on automatable work
Remaining capacity for architecture, innovation, complex problems: 14 hours

With Automated Verification Pipeline:

100 PRs, 75 auto-filtered before human review
25 PRs × 15 min/review (pre-filtered, focused review) = 6.25 hours/day
Review consumes 10% of team capacity
0 hours wasted on automatable issues
Remaining capacity for high-value work: 57.75 hours

Both teams ship the same features. But the second team has 4x more capacity for the work that actually differentiates: architecture, innovation, complex problem-solving, and building the next generation of products.

The ROI of verification infrastructure isn't about shipping more—it's about reallocating engineering capacity from low-value review to high-value creation.

What Architects Build

The engineer-as-architect focuses on these leverage points:

1. Test Infrastructure

Not just writing tests, but building systems that make testing frictionless:

Test generators that create coverage from specifications
Mutation testing to validate test quality
Property-based testing for edge case discovery
Visual regression testing for UI components

2. Static Analysis

Configuring and extending linters to catch domain-specific issues:

Custom ESLint rules for architectural violations
Type-level constraints that prevent invalid states
Import boundary enforcement

3. Complexity Gates

Automated guardrails that prevent entropy:

Cyclomatic complexity thresholds per function
File size limits
Dependency graph analysis
Breaking change detection

4. AI-Assisted Review

Using AI to pre-review AI output:

A cheaper, faster model scans for common issues
Flags potential problems for human attention
Generates review summaries

5. Feedback Loops

Systems that learn from past failures:

Post-incident analysis feeds into new automated checks
Bug patterns become linter rules
Security vulnerabilities become scanner signatures

The Role Transformation

This shift changes what it means to be a senior engineer:

Old Role (Reviewer)	New Role (Architect)
Reviews PRs manually	Builds systems that review automatically
Catches bugs by reading code	Catches bugs by writing tests
Validates formatting	Configures linters
Checks for security issues	Deploys security scanners
Ensures consistency	Enforces consistency via automation

The senior engineer's value is no longer in their ability to spot bugs—it's in their ability to build systems that spot bugs at scale.

Conclusion

The AI Verification Trap is real, but it's not about productivity—it's about allocation. Teams that fall into the trap aren't slower; they're misallocated. Their best engineers spend hours catching problems that machines could catch in seconds.

The transition from reviewer to architect isn't just an optimization. It's a fundamental reallocation of engineering capacity. Every hour your senior engineers spend catching type errors is an hour they don't spend designing systems, mentoring juniors, or solving the hard problems that actually require human creativity.

If your team is drowning in review queues full of formatting issues and broken tests, the answer isn't to review faster. It's to build the systems that filter out automatable problems—so human review focuses on what humans do best.

The future doesn't belong to the teams with the most patient reviewers. It belongs to the teams that freed their engineers to be architects.

From Scripter to Architect in the Age of AI

Pedro Arantes — Wed, 17 Dec 2025 14:00:36 +0000

For decades, the job of a software engineer was to write the "happy path." We spent our days scripting the exact sequence of events: fetch data, transform it, display it. We were the authors of the flow.

With the rise of Applied AI, that role is fundamentally changing. When an LLM generates the logic, we are no longer the scripters. We are the architects of the boundaries.

The Principle of Constraint-Driven Architecture

This shift is captured in The Principle of Constraint-Driven Architecture.

Because AI models are probabilistic (see The Principle of Probabilistic AI Output), they don't follow instructions with 100% reliability. They follow probability distributions. If you rely on them to "just do the right thing," you are gambling with your system's stability.

Your new job is to construct the guardrails that keep that probabilistic engine on the tracks.

The Failure Scenario: The Trusting Developer

The "Trusting Developer" writes a prompt and assumes the AI understands the intent.

// ❌ The Trusting Developer Approach
const prompt = `
    Extract the address from this email: "${emailBody}".
    Please be careful not to include the signature.
    Also, ensure the zip code is valid.
`;

const result = await llm.generate(prompt);
// Result: "123 Main St, Springfield, IL 62704\nSent from my iPhone"

The developer then spends hours tweaking the prompt to "exclude signatures," playing a game of whack-a-mole with edge cases. This is a failure of architecture, not prompting.

Corollary 1: Schema Supremacy

To succeed, you must embrace The Corollary of Schema Supremacy.

This corollary states a simple rule: If it can be code, it shouldn't be English.

Instead of asking the model to "be careful," you define a rigid schema using tools like Zod:

// ✅ The Architect Approach
import { z } from 'zod';

const AddressSchema = z.object({
  street: z.string(),
  city: z.string(),
  zipCode: z.string().regex(/^\d{5}(-\d{4})?$/), // Enforced in code, not prompt
  deliveryDate: z.date().min(new Date()), // Enforced in code, not prompt
});

// The LLM is forced to generate JSON that matches this shape
const result = await llm.generateStructured({
  schema: AddressSchema,
  prompt: `Extract the address from: "${emailBody}"`,
});

You don't ask the model to respect the rules; you build a system where breaking the rules is impossible. The model's output is treated as "untrusted user input" that must be sanitized and validated before it ever touches your business logic.

Corollary 2: The Probabilistic Funnel

Visualizing this new architecture leads us to The Corollary of The Probabilistic Funnel.

Your system design is a funnel that progressively removes randomness.

Stage 1: The Wide Mouth (Prompting)

At the top, we allow high entropy. We want the model to be creative and understand vague user intent.

// 1. User Intent (High Entropy)
const userRequest =
  'I want to book a flight to Paris next week, maybe Tuesday?';

Stage 2: The Neck (Structured Generation)

We force that vague intent into a rigid structure using schemas. This reduces entropy but doesn't eliminate it (the model could still hallucinate a date).

// 2. Structure (Medium Entropy)
const BookingSchema = z.object({
  destination: z.string(),
  date: z.string().date(), // YYYY-MM-DD
});

const structuredData = await llm.generateStructured({
  schema: BookingSchema,
  prompt: userRequest,
});
// Result: { destination: "Paris", date: "2023-12-25" }

Stage 3: The Filter (Deterministic Validation)

Finally, we apply deterministic business logic. This is the "zero entropy" zone. If the data doesn't pass, it never touches the database.

// 3. Validation (Zero Entropy)
function validateBooking(booking: z.infer<typeof BookingSchema>) {
  const date = new Date(booking.date);
  const today = new Date();

  if (date < today) {
    throw new Error('Cannot book flights in the past.');
  }
  if (date.getDay() !== 2) {
    // Tuesday check
    // Handle logic...
  }
  return true;
}

As an architect, your job is to design these filters. You decide where the creativity stops and the reliability begins. You are no longer writing the story; you are building the walls that ensure the story doesn't spill over into chaos.

How to Stop AI From Ruining Your Architecture

Pedro Arantes — Tue, 16 Dec 2025 13:18:35 +0000

We are witnessing a new phenomenon in AI-assisted teams: The Principle of Zero-Cost Erosion.
Because AI makes adding complexity (patching) nearly free, while refactoring remains expensive (requiring deep thought), teams are defaulting to infinite patching.

The Old vs. New Reality

Pre-AI: Cost(Patch) > Cost(Refactor) -> Trigger to Refactor.
Post-AI: Cost(Patch) ~ 0 -> Never Refactor.

This economic imbalance leads to "Zero-Cost Erosion," where systems degrade rapidly because "just one more if-statement" is always the path of least resistance.

The Hidden Costs

Beyond the obvious technical debt, this erosion creates two invisible taxes on your team. First, there's the Token Tax: unrefactored, verbose code consumes more tokens in the context window, making every future interaction with that file more expensive (in API costs) and less intelligent (because the context window is filled with noise). Refactoring is an investment in cheaper, smarter future agents. Second, there's the Reviewer's Asymmetry: it takes longer to review complex code than to generate it with AI. Without a brake, your senior engineers (the reviewers) become the bottleneck, drowning in "LGTM" fatigue.

The Consequences

If left unchecked, this leads to:

Hardened Technical Debt: AI cements bad patterns by mimicking them.
Operational Risk: Unrefactored code has higher entropy and failure rates.
Review Fatigue: Humans cannot effectively review the high-volume, high-complexity output.

The Solution: The Complexity Brake

We need to engineer a solution that forces refactoring. This is the practical application of The Principle of Artificial Friction: when technology removes natural friction, we must engineer artificial barriers to prevent collapse.

We call this specific implementation The Complexity Brake.

How to Implement It

Quantify Complexity: Integrate a linter (like SonarQube or ESLint complexity rules) into your CI pipeline.
Set Thresholds: Define a maximum complexity score for functions (e.g., 10) and classes.
The Veto: If an AI agent submits a PR that increases the complexity of a file beyond the threshold, the PR is automatically rejected.
The Refactor Mandate: The agent receives the rejection with a specific instruction: "Complexity too high. You must refactor the existing code to reduce complexity below X before adding the new feature."

By automating the "No," we force the AI to maintain the hygiene of the codebase, ensuring that speed doesn't come at the cost of survival.

Agentic Workflow: The 3-Step Protocol

To operationalize this with agents, we use a specific workflow that prioritizes hygiene over speed.

Test-First Mandate: Before asking an agent to write any implementation code, you must first ask it (or a separate "QA Agent") to write the tests for the current code. This ensures we have a safety net for the upcoming changes.
The Artificial Friction Agent: Before the implementation begins, a specialized "Friction Agent" evaluates the target file.
- It calculates the current complexity score.
- If the threshold is reached: It halts the feature work and triggers a "Refactor Mode." It proposes a refactor to simplify the existing code without changing the tests (Green-Green Refactor).
- If the threshold is safe: It allows the process to proceed.
The Implementer Agent: Only after the Friction Agent clears the path (either by approving the current state or completing the refactor) does the "Implementer Agent" write the new feature code.

This sequence ensures that we never build new features on top of rotting foundations.

The AI Collaboration Paradox: Why Being Smart Isn't Enough Anymore

Pedro Arantes — Mon, 08 Dec 2025 13:48:21 +0000

Two engineers join your team on the same day. Both have stellar résumés. Both ace the technical interviews. Both score in the 95th percentile on algorithmic problem-solving.

Six months later, one is shipping 3x more features than the other.

The difference? It's not intelligence. It's not work ethic. It's not even technical depth.

It's something we're just beginning to measure: collaborative ability with AI.

And it's exposing an uncomfortable truth: in the age of AI agents, being smart isn't enough anymore.

The Metric That Doesn't Transfer

For decades, engineering productivity was roughly correlated with individual capability. The best problem-solvers wrote the best code. The fastest debuggers shipped the most features. Team velocity was basically the sum of individual velocities.

Then AI coding assistants arrived.

Suddenly, two engineers with identical technical skills could have wildly different productivity. Same experience. Same tools. Same codebase. One developer's output doubles. The other's barely moves.

What's happening?

Recent research on human-AI synergy reveals a paradigm-breaking insight: individual problem-solving ability and collaborative AI ability are not the same thing. They're distinct, measurable competencies. You can be exceptional at one and mediocre at the other.

This is The Principle of Collaborative Ability Distinction from our Agentic Development Principles, and it's fundamentally reshaping how we think about developer performance.

The Two Types of Intelligence

Think of a brilliant architect who works alone. They can design complex systems, optimize for scale, and solve intricate technical challenges. Give them a problem and a whiteboard, and they'll crack it.

Now put that same architect on a team.

Some brilliant solo performers are terrible collaborators. They struggle to:

Explain their reasoning to others
Incorporate feedback from teammates
Adapt their communication style to different audiences
Coordinate work across distributed contributors

This isn't stupidity—it's a different skill.

AI collaboration exposes the same dynamic. Being a great solo developer doesn't automatically make you a great AI-augmented developer. These are separate abilities:

Individual Ability	Collaborative Ability
Solve problems independently	Solve problems with AI assistance
Debug by reasoning through code	Debug by framing questions for AI
Architect systems alone	Architect systems through dialogue
Optimize algorithms manually	Optimize by iterating with AI suggestions

Research shows these abilities don't strongly correlate. Some developers with modest solo ability achieve extraordinary results with AI. Some elite solo performers can barely leverage AI at all.

Why Smart People Struggle with AI

Let's examine why high-capability developers often underperform with AI tools:

1. The Expertise Curse

Expert developers have deep mental models of how systems work. They're accustomed to deterministic reasoning:

"If I call this function with these parameters, I get this exact output"
"This code pattern always produces this behavior"
"When I see this error, it always means this problem"

AI agents are probabilistic. The same prompt can yield different responses. The same context can lead to different interpretations.

Expert developers expect precision. When they don't get it, they blame the tool: "This AI doesn't understand the problem."

They fail to recognize that working with AI requires a different framing—one based on disambiguation, iteration, and perspective-taking rather than deterministic instruction.

2. The Communication Gap

Elite developers often excel at technical execution but struggle with explanatory communication. They can build it, but explaining it to someone else (or something else) requires different skills:

Providing context: "What background does the AI need to understand this problem?"
Clarifying ambiguity: "What terms in my request could have multiple meanings?"
Structuring information: "What's the most effective order to present this information?"

These are Theory of Mind skills—the ability to infer what someone else knows and adapt your communication accordingly. Developers who excel at this (see The Principle of Theory of Mind in Human-AI Collaboration) achieve superior AI collaboration outcomes.

Developers who don't practice these skills treat AI like a better Google—and get frustrated when it doesn't read their mind.

3. The Template Fallacy

Smart developers love systems. When they discover AI, they follow a natural pattern:

Experiment with prompts
Find ones that work
Systematize them into a reusable library
Apply them mechanically

This works brilliantly for deterministic tools. It fails catastrophically for AI.

Why? Because effective AI collaboration requires dynamic adaptation (see The Principle of Dynamic Adaptation). The same prompt produces different results depending on:

The accumulated context in the conversation
The specific nuances of the current task
How the AI interpreted your previous messages

Developers who treat AI collaboration as a script to memorize plateau quickly. Those who treat it as improvisational dialogue compound their effectiveness.

What High Collaborative Ability Looks Like

Let's contrast two developers tackling the same problem: implementing a new authentication flow.

Developer A: High Solo Ability, Low Collaborative Ability

Approach:

Asks AI: "Generate an authentication flow with OAuth2"
Gets a generic implementation
Realizes it doesn't match their architecture
Asks AI: "Make this work with our user model"
Gets another generic response
Gives up, writes it themselves

Time spent: 15 minutes with AI (wasted), 3 hours solo coding

Takeaway: "AI tools aren't helpful for complex tasks"

Developer B: Moderate Solo Ability, High Collaborative Ability

Approach:

Asks AI: "What are the key decisions I need to make when implementing OAuth2?"
Reviews the list, identifies gaps in AI's assumptions
Asks: "Our app uses stateless JWT tokens and separates auth from user management. How would you structure the flow given these constraints?"
Examines the response, spots a misunderstanding
Clarifies: "When I said 'stateless,' I mean we don't store session data. Does that change your approach?"
Iterates until the AI understands the architecture
Asks for implementation broken into small, testable steps

Time spent: 30 minutes with AI (productive dialogue), 1 hour implementing and adapting

Takeaway: "AI tools help me explore solutions faster and catch edge cases I'd miss"

Developer B isn't smarter. They're better at collaboration.

The Skills That Matter Now

If collaborative ability is distinct from individual ability, what specific skills should developers cultivate?

1. Perspective-Taking (Theory of Mind)

Practice:

Before prompting, ask: "What does the AI need to know to help me?"
After responses, ask: "What did the AI misunderstand about my request?"
Regularly ask: "What assumptions is the AI making that I haven't validated?"

Why it matters: Developers who actively model the AI's "mental state" frame better prompts and catch misalignments faster.

2. Iterative Refinement

Practice:

Never accept the first AI response as final
Treat each interaction as a feedback loop: "What got better? What's still wrong?"
Develop a habit of three-turn minimum: explore → narrow → refine

Why it matters: AI collaboration is dialogue, not dictation. Compound understanding through iteration.

3. Context Calibration

Practice:

Track what you've already discussed in the conversation
Notice when the AI seems to "forget" earlier context (context window overflow)
Learn when to provide more context vs. when to reset and start fresh

Why it matters: Context is your scarcest resource in AI interactions. Manage it intentionally.

4. Adaptive Communication

Practice:

Vary your communication style based on the task (exploratory vs. prescriptive)
Adjust prompts based on response quality (too generic → add constraints; off-topic → clarify)
Recognize when templates help vs. when they hinder

Why it matters: Static approaches fail in dynamic environments. Flexibility compounds effectiveness.

The Organizational Implications

This paradigm shift has profound implications for how we build engineering teams:

Hiring: Look Beyond Algorithmic Prowess

Traditional technical interviews measure individual problem-solving. That's necessary but insufficient.

New assessment vectors:

Pair programming with AI: How does the candidate leverage AI tools during a coding challenge?
Prompt refinement exercise: Give a candidate a mediocre AI output and ask them to improve it iteratively
Context management: Present a complex problem and observe how they decompose it for AI assistance

Onboarding: Teach Collaboration Explicitly

Don't assume developers will "figure out" AI tools. Collaborative ability is a skill that must be taught.

Onboarding components:

AI collaboration workshop: Teach perspective-taking, iterative refinement, context management
Shadowing exercises: New hires observe senior engineers' AI workflows
Low-stakes practice: Assign small tasks specifically for AI collaboration skill-building

Performance Reviews: Measure Collaboration Competency

If productivity increasingly depends on collaborative ability, we must measure and reward it.

New metrics:

AI leverage ratio: How much more productive is the developer with AI vs. without?
Collaboration quality: Do they iterate effectively or give up after one failed prompt?
Knowledge transfer: Do they document their AI workflows to help others?

The Uncomfortable Truth

Here's what the data tells us: in head-to-head comparisons, developers with high collaborative ability outperform developers with high solo ability when both have access to AI.

Let that sink in.

A moderately skilled developer who excels at AI collaboration can outship a brilliant engineer who doesn't.

This doesn't mean individual ability is obsolete—it means it's no longer sufficient.

The future belongs to developers who cultivate both:

Deep technical expertise (individual ability)
Adaptive collaboration skills (collaborative ability)

The developers who recognize this shift and invest deliberately in collaborative ability will have an outsized advantage.

The developers who dismiss AI as "just a tool" without examining their collaboration approach will find themselves outpaced by peers with half their experience but double their collaborative effectiveness.

Conclusion: The New Intelligence

For decades, we've optimized for hiring "the smartest engineers." We've celebrated solo genius. We've rewarded individual contribution.

AI agents are rewriting those rules.

Intelligence still matters. But collaborative intelligence matters more.

The smartest developer in the room isn't the one who can solve the hardest algorithm. It's the one who can orchestrate the most effective human-AI partnership.

This is the paradigm shift: from individual capability to collaborative capability as the primary driver of productivity.

The question isn't whether you're smart enough to compete in the AI era.

The question is: are you collaborative enough?

Learn more about developing collaborative AI skills in our Agentic Development Principles.

Mastering Prompts Through Inversion: The Anti-Prompt Guide

Pedro Arantes — Sun, 07 Dec 2025 13:56:31 +0000

Want to instantly level up your prompting skills? Stop trying to write "good" prompts. Instead, learn how to write the worst possible prompts—and then do the exact opposite.

The mental model of Inversion is a powerful tool in engineering and problem-solving. As the mathematician Carl Jacobi said, "Invert, always invert." When applied to AI prompting, this means identifying the specific patterns that guarantee failure (hallucinations, vague answers, off-topic ramblings) and ruthlessly eliminating them.

The "Anti-Prompt" Philosophy

We've compiled a comprehensive guide based on this philosophy. It identifies the common "Anti-Patterns" that degrade model performance. Here is a breakdown of why they fail:

1. The Lazy Delegator (Vagueness)

The Mistake: Using broad verbs and ambiguous words like "cool", "better", or "nice".
Why it fails: The model has infinite degrees of freedom and will regress to the mean, giving you the most statistically likely (mediocre) answer.

Anti-Prompt: "Write something about marketing."
Fix: Be specific. "Write a LinkedIn post about B2B marketing trends in 2025."

2. The Kitchen Sink (Overloading)

The Mistake: Asking for everything at once—mixing explanation, coding, and creative writing in one block.
Why it fails: It confuses the model's attention mechanism. Instructions buried in the middle often get ignored ("Lost in the Middle" phenomenon).

Anti-Prompt: "Explain quantum physics, write a poem about cats, and give me 10 business ideas."
Fix: Chain your prompts. Break the task into distinct steps.

3. The Mind Reader (Missing Context)

The Mistake: Assuming the AI knows who you are, who the audience is, and what the goal is.
Why it fails: Without a persona, the model defaults to a generic, bland "helpful assistant". Without an audience, it guesses (often wrongly).

Anti-Prompt: "Explain how a car engine works."
Fix: Assign a role. "Act as a senior mechanical engineer explaining to a 5-year-old."

4. The Negative Bias (Negative Constraints)

The Mistake: Relying only on negative constraints ("Don't do X", "Don't be Y").
Why it fails: Models are often bad at negatives and may focus on the very thing you told them to avoid.

Anti-Prompt: "Don't be boring. Don't use long sentences."
Fix: State what you DO want. "Write in a witty, conversational tone with short sentences."

5. The Chaos Agent (Structure & Format)

The Mistake: Letting the model choose the format or giving contradictory instructions.
Why it fails: You get whatever format is statistically most common (usually paragraphs).

Anti-Prompt: "Write a story but make it detailed. Put it in a table if you want."
Fix: Force the format. "Output the result as a JSON object."

6. The Chatty Cathy (Fluff)

The Mistake: Treating the AI like a human colleague with small talk.
Why it fails: It wastes tokens, dilutes the signal, and signals low commitment.

Anti-Prompt: "Hi there! I was wondering if you could maybe help me..."
Fix: Be direct. "You are an expert Python developer. Write a script to..."

Why It Works

Understanding these failure modes gives you a checklist for success. Instead of guessing what might work, you can systematically verify that your prompt doesn't contain the elements that make it fail.

For example, instead of asking "How do I make this better?", you realize that "better" is a vague anti-pattern. You invert it to: "Optimize this text for a 5th-grade reading level."

Read the Full Guide

Ready to master the art of the Anti-Prompt? Check out our detailed documentation:

👉 How to Prompt: The Anti-Prompt Guide

It includes a full breakdown of the 6 major anti-patterns, examples of failure, and the specific corrections you need to apply.

Mastering the Context Window: Why Your AI Agent Forgets (and How to Fix It)

Pedro Arantes — Sat, 06 Dec 2025 17:52:25 +0000

AI agents are transforming how we write code, but they are not magic. They operate within a strict constraint that many developers overlook until it bites them: the context window.

If you treat an AI session like an infinite conversation, you will eventually hit a wall where the model starts "forgetting" your initial instructions, hallucinating APIs, or reverting to bad patterns. This isn't a bug; it's a fundamental limitation of the technology. Success in agentic development requires treating context as a scarce, economic resource.

The Hard Limit of Memory

Every Large Language Model (LLM) has a fixed context window—a maximum limit on the amount of text (tokens) it can process at once. This includes your system prompt, the current conversation history, the files you've attached, and the model's own response.

When you exceed this limit, the model doesn't warn you; it simply truncates the input. Usually, the oldest parts of the conversation—often your critical architectural guidelines or the initial problem statement—are silently discarded.

This reality is codified in The Principle of Finite Context Window:

AI models have a fixed context window... Teams must manage context as a scarce resource, prioritizing relevant information and resetting sessions when necessary.

If you are not aware of this limit, you might find yourself in a situation where an agent that was brilliant five minutes ago suddenly starts generating code that violates the very rules you gave it at the start of the session.

The Downward Spiral of "Just One More Fix"

When an agent produces buggy code, the natural human instinct is to correct it immediately within the same chat. "No, that's wrong, try again." "You missed this edge case." "Fix the import."

However, every interaction consumes tokens. As you pile on error messages, stack traces, and correction prompts, you are filling the context window with "garbage" data. This leads to The Principle of Compounding Contextual Error:

If an AI interaction does not resolve the problem quickly, the likelihood of successful resolution drops with each additional interaction... Fast, decisive resolution is critical.

A long, winding debugging session is often counterproductive. The model is "reading" a history full of its own mistakes, which biases it toward repeating them. Instead of fixing the bug, you are often better off resetting the context and starting fresh with a refined prompt.

Strategies for the Finite Window

So, how do you work with a massive codebase when your "smart" assistant has a limited memory? You cannot simply dump a 100GB repository into a 200k token window. You need a strategy.

Here are the three main architectures for handling codebases larger than the context window:

1. The "Agentic" Approach (Best for Development)

This is the approach used by advanced coding tools like Aider, Cursor, or custom agent scripts. Instead of dumping the entire codebase into the prompt, you give the agent a "map" of the file structure (which consumes very few tokens).

How it works:
The agent looks at the map and decides which specific files it needs to read to solve the task. It then loads only those files into its context.

Why it works:
This mimics how a human developer works. You don't hold the entire codebase in your head; you look up the specific files relevant to the bug you are fixing. It keeps the context clean and focused on the immediate problem.

2. RAG (Retrieval-Augmented Generation)

This is the standard enterprise solution for querying large knowledge bases.

How it works:
You break your code into small chunks, turn them into mathematical vectors (embeddings), and store them in a database. When you ask a question, the system searches for the most relevant chunks and sends only those to the model.

Why it works:
It scales infinitely. You could have a 100GB codebase, and the model only sees the 10KB relevant to your question. However, it can sometimes miss broader architectural context if the relevant chunks aren't retrieved correctly.

3. Vertical Model Scaling

Sometimes, the best solution is brute force. If you have a complex problem that requires understanding the entire system at once, you can switch to a model with a massive context window.

How it works:
This allows you to paste an entire repository directly into the prompt without complex retrieval architectures.

Why it works:
It simplifies the workflow. You don't need to worry about which files to include; you just include everything. This is powerful for large-scale refactoring or understanding deep dependencies, though it comes with higher latency and cost.

Conclusion

Context is currency. Every token you feed an agent has a cost—not just in money, but in the model's attention span and reliability.

By understanding The Principle of Finite Context Window and avoiding The Principle of Compounding Contextual Error, you can stop fighting against the tool and start using it effectively. Whether you choose an agentic approach, RAG, or a massive context model, the key is intention: know what is in your context, and ensure it's only what matters.

The 80% Rule: Why Your AI Agents Should Only Speak When Confident

Pedro Arantes — Fri, 05 Dec 2025 14:03:35 +0000

We've all been there: You ask your AI coding assistant for a solution to a tricky bug. It responds instantly, with absolute certainty, providing a code snippet that looks perfect. You copy it, run it, and... nothing. Or worse, a new error.

The AI wasn't lying to you. It was hallucinating. It was "confidently wrong."

In our Agentic Development Principles, we call this The Principle of Confidence-Qualified AI Output. But in practice, we just call it The 80% Rule.

The "Yes Man" Problem

Large Language Models (LLMs) are designed to predict the next most likely token. They are eager to please. If you ask a question, their training compels them to provide an answer—any answer—rather than silence.

This makes them excellent creative partners but dangerous engineering consultants. When an engineer is unsure, they say, "I need to check the docs." When an LLM is unsure, it often invents a plausible-sounding API method that doesn't exist.

This creates noise. Every time you have to verify a low-quality suggestion, you pay a cognitive tax—a direct violation of the Principle of Cognitive Bandwidth Conservation. You stop trusting the tool.

The Solution: Force Self-Reflection

The good news is that while LLMs are probabilistic engines, they are also capable of evaluating their own probability distributions. You can ask an LLM to "grade" its own answer before showing it to you.

We implemented a simple instruction across our agentic workflows:

"Only provide a solution if your confidence is HIGH (>80%). If you are unsure, state 'I don't know' or ask for more context."

How to Implement The 80% Rule

You don't need complex code to use this. It starts with your system prompts or custom instructions.

1. The System Prompt

Add this to your custom instructions in VS Code (Copilot), ChatGPT, or Claude:

CRITICAL INSTRUCTION:
You are an expert engineering consultant.
- Before answering, assess your confidence level (0-100%) based on your training data and the provided context.
- If Confidence < 80%: Do NOT guess. State clearly: "I am not confident in this answer because [reason]." Ask clarifying questions or suggest where I should look.
- If Confidence >= 80%: Provide the solution directly.

2. The "Vibe Check"

If you are already deep in a conversation and suspect the AI is drifting, use a "Vibe Check" prompt:

"On a scale of 0-100%, how confident are you that this specific import path exists in the current version of the library?"

You will be surprised how often the model replies: "Actually, upon reflection, I am only 40% confident. That import might have changed in v5."

Why This Matters: Signal vs. Noise

Implementing the 80% Rule changes the dynamic of your development workflow.

Reduced Cognitive Load: When the AI speaks, you know it's worth listening to. You don't have to fact-check every single line.
Faster Failure: Instead of debugging a hallucinated solution for 20 minutes, you get an immediate "I don't know," prompting you to check the official documentation yourself.
Better Trust: An agent that admits ignorance is an agent you can trust.

Conclusion

AI agents are powerful, but they lack the human instinct for self-preservation that keeps us from making wild guesses in production. By enforcing The Principle of Confidence-Qualified AI Output, we impose that discipline artificially.

Make your agents earn the right to interrupt you. If they aren't 80% sure, they should stay 100% silent.

Agentic Development Principles - Part 1

Pedro Arantes — Fri, 05 Dec 2025 01:03:49 +0000

I am documenting the Agentic Development Principles that currently guide my team and me. This post is Part 1, focusing on maximizing effective human-AI collaboration when using LLMs as development assistants, ensuring we build products efficiently and safely.

Agentic Development refers to the practice of using AI agents as collaborative partners in the development process. This approach requires the intentional design of specialized workflows, clear feedback loops, and well-defined decision boundaries.

Principles

The Principle of Immediate AI Feedback Loop

Integrate AI tools directly into the coding environment to deliver instant suggestions and error checking, minimizing context switching and delays. This maximizes value-added time and aligns with B3: The Batch Size Feedback Principle.

Failure Scenario: A team uses an AI code completion tool with a 5-second delay. Developers either wait (breaking flow) or ignore the tool, resulting in inconsistent adoption and wasted potential.

The Principle of Human-in-the-Loop Veto

Every AI-generated output must pass final review by a domain expert who retains full accountability. AI accelerates delivery but introduces risk; human oversight ensures quality and prevents costly errors, supporting E1: The Principle of Quantified Overall Economics.

Failure Scenario: An AI-generated database query is deployed without review, causing performance issues and technical debt.

The Principle of Small-Experiment Automation

Use AI agents to break down large tasks into small, verifiable experiments (e.g., auto-generated unit tests, code variations), reducing risk and enabling fast feedback. This applies V7: The Principle of Small Experiments.

Failure Scenario: An AI generates a massive, brittle test suite. Maintenance overhead grows, slowing development and negating the benefits of automation.

The Principle of Contextual Input Quality

Developers must provide high-quality context and select the agent/model with the best cost-benefit profile for each task. Effective prompt engineering and tool selection minimize waste and the Cost of Delay, echoing E16: The Principle of Marginal Economics.

Failure Scenario: Using a slow, expensive model for a trivial task with a vague prompt leads to wasted time and resources.

The Principle of Continuous Agent Proficiency

Teams must practice frequent, low-stakes interactions with AI tools to build expertise in prompt engineering and tool selection. Skill development reduces long-term rework and accelerates learning, following FF11: The Batch Size Principle of Feedback.

Failure Scenario: Developers receive initial training but lack time for practice, resulting in slow learning and inefficient workflows.

The Principle of Delegated Agency Scaling

Scale AI agent autonomy by task complexity: fully delegate repetitive, low-risk tasks; use AI as a consultant for complex or high-risk decisions. This balances velocity and risk, applying B4: The Batch Size Risk Principle.

Failure Scenario: Delegating complex build optimization to AI leads to short-term gains but introduces critical errors, increasing rework and risk.

The Principle of Automated Guardrail Prerequisite

Before granting full autonomy to AI agents, ensure robust automated safety nets (e.g., CI/CD, test suites) are in place to continuously validate outputs. Automation must be checked by automation to prevent catastrophic failures, supporting B4: The Batch Size Risk Principle.

Failure Scenario: An AI refactors components with inadequate automated tests, introducing subtle bugs that escape detection until production.

The Principle of Layered Autonomy

Establish tiered governance: Company sets strategic safety and cost policies, Team defines tactical goals and quality metrics, Developer retains autonomy over tool selection and workflows. This decentralizes optimization while maintaining compliance and security.

Failure Scenario: Mandating a single AI tool for all teams blocks specialized workflows, increasing risk and cycle time for critical tasks.

The Principle of Compounding Contextual Error

If an AI interaction does not resolve the problem quickly, the likelihood of successful resolution drops with each additional interaction, as accumulated context and unresolved errors compound. Fast, decisive resolution is critical to prevent error propagation and cognitive overload, aligning with B3: The Batch Size Feedback Principle.

Failure Scenario: A developer repeatedly prompts an AI agent to fix a bug, but each iteration introduces new minor errors and increases context complexity. After several cycles, the original issue is buried under layers of confusion, making resolution harder and increasing rework.