DEV Community: Prasad Rane

How I Use Coding Agents Without Losing My Mental Models

Prasad Rane — Tue, 22 Sep 2026 19:02:50 +0000

A junior developer recently asked me if he was falling behind because he used AI less than his peers.

I said - "Using AI for everything early in your career buys speed at the cost of mental models".

The cache bugs I wrote by hand years ago taught me why write ordering and TTL expiry interact badly. That lesson only stuck because I watched my own wrong intuition fail in production and had to trace the logs myself. A generated fix skips the failure, and the failure was the teacher.

If you accept AI fixes without understanding the underlying failure, you trade a quick fix today for a system you cannot debug when something unusual breaks.

Here is how I approach this now -

Form a hypothesis first,
use the model to find blind spots, and
ration where AI is allowed to write code.

The Hypothesis-First AI Loop The most common trap with coding agents is pasting an error log into the prompt and asking the model to fix it.

When you do that, you skip the step where you build a mental model of the system. The model returns code that compiles and passes the immediate test, but you do not learn why the failure happened or what secondary effects the change introduces.

A more reliable loop keeps the engineer responsible for the hypothesis while using the model to stress-test assumptions.

Figure 1: The four-step loop for pairing with coding agents.

The Four Steps:

Form a hypothesis: Before opening a prompt, write down what you think is failing and why. Even if your guess is wrong, stating it forces you to model the system in your head.
Ask the model for alternatives: Instead of asking for code, ask the model what other failure modes could produce the same symptom. For example: "I suspect this timeout is caused by database connection pool saturation. What other downstream bottlenecks could produce this error pattern?"
Verify against empirical evidence: Check distributed traces, server logs, and queue metrics to see which explanation fits the data.
Update your understanding: Compare the actual root cause with your original hypothesis. The gap between what you thought happened and what the telemetry showed is where your understanding improves.

2. A Common Failure Mode: Naive Retries and Pool Exhaustion

Here is an example I have seen in production code generated by AI assistants.

A service calling an external API starts seeing intermittent HTTP 504 gateway timeouts. When given the error log, the model suggests adding a retry loop with an increased timeout.

# Anti-pattern: Naive retry loop masking systemic failure
import time
import requests

def call_upstream_service(url: str, payload: dict, max_retries: int = 5):
    # Model suggested increasing timeout from 3s to 10s and retrying 5 times
    timeout = 10.0
    for attempt in range(1, max_retries + 1):
        try:
            response = requests.post(url, json=payload, timeout=timeout)
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as exc:
            if attempt == max_retries:
                raise RuntimeError(f"Service failed after {max_retries} attempts: {exc}")

            # Predictable exponential backoff without jitter
            sleep_duration = 2 ** attempt
            time.sleep(sleep_duration)

In isolated unit tests, this snippet passes. Under production load, it causes several problems:

Synchronized retry storms: Because the backoff uses fixed powers of two without jitter, hundreds of concurrent callers retry at the exact same intervals, overwhelming the upstream service as it tries to recover.
Socket and thread exhaustion: Increasing the timeout from 3 seconds to 10 seconds means threads hold outbound connections three times longer. Under steady traffic, the web server exhausts its worker pool, and incoming requests queue up until the health check fails.
Latency amplification: Instead of failing fast within 3 seconds so the caller can degrade gracefully, requests hang for up to a minute before failing anyway.

Figure 2: How an unjittered retry loop exhausts connection pools compared to a bounded circuit-breaker pattern.

The model suggested this implementation because retrying with exponential backoff is standard boilerplate in its training data. It has no visibility into your thread pool limits, traffic distribution, or upstream capacity.

3. Resilient Implementation: Bounded Retries and Circuit Breaking

When you know the failure dynamics, you do not let the model pick the strategy. You define the bounds first: maximum latency, randomized jitter, and a circuit breaker that sheds load when the downstream service is down.

Here is a Python implementation that enforces those boundaries:

import random
import time
from dataclasses import dataclass
from enum import Enum
from typing import Callable, Any

class CircuitState(Enum):
    CLOSED = "CLOSED"
    OPEN = "OPEN"
    HALF_OPEN = "HALF_OPEN"

@dataclass(frozen=True)
class ResilienceConfig:
    max_attempts: int = 3
    base_backoff_sec: float = 0.2
    max_backoff_sec: float = 2.0
    failure_threshold: int = 5
    recovery_timeout_sec: float = 15.0

class CircuitBreakerOpenException(Exception):
    """Raised when requests are shed immediately because the circuit is open."""
    pass

class BoundedResilientClient:
    """
    Client that limits retry duration, adds full jitter,
    and protects thread pools through circuit breaking.
    """
    def __init__(self, name: str, config: ResilienceConfig):
        self.name = name
        self.config = config
        self.state = CircuitState.CLOSED
        self.failure_count = 0
        self.last_state_change = time.monotonic()

    def _on_failure(self):
        self.failure_count += 1
        if self.failure_count >= self.config.failure_threshold:
            self.state = CircuitState.OPEN
            self.last_state_change = time.monotonic()

    def _on_success(self):
        self.failure_count = 0
        self.state = CircuitState.CLOSED

    def _compute_backoff_with_jitter(self, attempt: int) -> float:
        ceiling = min(
            self.config.max_backoff_sec,
            self.config.base_backoff_sec * (2 ** (attempt - 1))
        )
        return random.uniform(0, ceiling)

    def execute(self, action: Callable[[], Any]) -> Any:
        now = time.monotonic()

        if self.state == CircuitState.OPEN:
            if now - self.last_state_change > self.config.recovery_timeout_sec:
                self.state = CircuitState.HALF_OPEN
            else:
                # Fail immediately to protect local thread and connection pools
                raise CircuitBreakerOpenException(f"{self.name} circuit is OPEN. Request shed.")

        for attempt in range(1, self.config.max_attempts + 1):
            try:
                result = action()
                self._on_success()
                return result
            except Exception:
                if attempt == self.config.max_attempts or self.state == CircuitState.HALF_OPEN:
                    self._on_failure()
                    raise

                backoff = self._compute_backoff_with_jitter(attempt)
                time.sleep(backoff)

This pattern prevents cascading issues in three ways:

Immediate rejection: When the circuit is open, requests fail in fractions of a millisecond, leaving thread pools free for healthy routes.
De-synchronized traffic: Full jitter spreads retries evenly across time, avoiding thundering herd spikes on recovering services.
Strictly bounded wait time: Retries cap out quickly rather than holding resources for long timeouts.

4. The AI Task Rationing Matrix

To build and preserve engineering judgment, categorize engineering tasks by the risk of outsourcing understanding:

Figure 3: Framework for delegating engineering tasks to AI based on cognitive value and risk.

Category	Typical Tasks	Role for AI	Review Rule
Low Risk (High Leverage)	Syntax lookups, boilerplate, regular expressions, test setup, CLI flags	Full delegation	Verify syntax and run existing tests. Relearning these syntax details adds little value.
Medium Risk (Collaborative)	Edge cases, schema validation, test coverage gaps, local refactoring	Sounding board	Write the core logic yourself first. Ask the model what inputs or boundaries you missed.
High Risk (Critical Core)	Concurrency controls, database transactions, auth/permissions, cache invalidation	Adversarial reviewer	Design and write alone. Use the model only to generate adversarial test cases against your finished contracts.

5. Practical Guidelines for Teams

Before merging code authored or suggested by an agent, review against these checks:

[ ] Can you explain the execution path and edge cases without consulting the prompt?
[ ] Did you state a hypothesis about the bug before asking the model for a fix?
[ ] Are failure modes (timeouts, 429 rate limits, partial payloads) verified with actual test assertions rather than happy-path mocks?
[ ] Are retries, timeouts, and resource pools strictly bounded?
[ ] Does the change solve the root cause rather than increasing a buffer or timeout to mask a bottleneck?

6. Summary

Coding tools are fast, but they do not build mental models for you.

Point AI at the parts of your work where being wrong has low consequence: typing boilerplate, scaffolding tests, and looking up syntax. Keep your hands on the core logic: state management, failure modes, and system boundaries.

The Part of AI Coding Agents I Didn't Expect to Care About: Latency

Prasad Rane — Mon, 07 Sep 2026 06:19:42 +0000

I spent the last few months pretty much living in Claude Code.

It became a regular part of how I worked: give it a task, let it work through the codebase, review what it changed, and keep iterating.

Today I ran the same multi-step agentic task through Google Antigravity, and the difference surprised me.

Antigravity, running Gemini Flash 3.8, finished the task in about half the time Claude Code took with Sonnet 5.

The speed was nice, but that's not actually what stood out to me.

It was the waiting.

The hidden cost of waiting

When an AI coding agent is working through several tool calls, there are moments where you can be staring at the screen for a minute or two waiting for the next step.

At first, I didn't think much of it.

But I've noticed what I do during those waits.

I check Slack.

I look at another tab.

I start thinking about something else.

And when the agent finally finishes, I have to spend a few seconds — sometimes longer — figuring out where I was in the problem.

That's a surprisingly expensive interruption.

It's not just the two minutes spent waiting. It's the context switch that happens during those two minutes.

When the feedback loop gets tight

With a faster agent, the interaction feels different.

You make a change.

The agent runs a tool.

It comes back.

You review the result and give it the next instruction.

Repeat.

When those cycles happen in seconds rather than minutes, it's much easier to stay focused on the problem.

You still have the architecture in your head. You remember why you made the previous change. You know what you want to try next.

You don't have to reconstruct the mental model every time the agent finishes a long operation.

That was the part I didn't expect to notice as much as I did.

Speed isn't just about tokens per second

When we compare coding agents, we tend to focus on things like:

Which model writes better code?
How good is the reasoning?
How well does it understand a large codebase?
How accurate are its tool calls?
How fast does it generate tokens?

Those things obviously matter.

But there's another metric that is harder to measure:

How long does it take to get back into the interaction?

A coding agent isn't operating in isolation. There's a human sitting in the loop.

If the agent takes two minutes to complete a step, the human doesn't necessarily remain in the loop for those two minutes.

That's where latency starts affecting productivity in a way that raw benchmark numbers don't really capture.

I'm not abandoning Claude Code

Claude Code is still very good, and I wouldn't make a broader conclusion from one task or one comparison.

The point isn't that one tool is universally better than another.

What surprised me was how much low latency changed the way I interacted with the agent.

After experiencing an agent that keeps the feedback loop moving quickly, long waits feel much more noticeable.

Maybe that's one of the next things we'll start paying more attention to with agentic development:

Not just how capable is the model?

But also:

How well does the system keep the developer in the loop?

Because sometimes the biggest productivity improvement isn't getting the agent to do more.

It's simply not giving the developer enough time to get distracted.

Starting Enterprise-wide Kafka Governance

Prasad Rane — Wed, 06 May 2026 17:35:52 +0000

Technical leadership isn't always about having the right title; it’s about having the right influence. When you are operating without direct authority, setting standards across autonomous teams requires a shift from "enforcing mandates" to "solving shared pain."

The Mess: Visualizing the Chaos

It began on a Tuesday in a conference room, facing a whiteboard filled with chaotic arrows representing event flows. The AWS MSK dashboard displayed a patchwork of inconsistent topic names.

loan-processing.loancreated
LoanService.Events.Created
mortgage.v2.loan.originated

These topics often performed the same functions but were impossible to correlate during system failures. Same intent. Same cluster. Completely different conventions.

When something broke, tracing ownership or flow was guesswork.

But naming inconsistencies were just the symptom.

IAM policies ranged from overly permissive to painfully restrictive
Schema evolution had no guardrails
Ownership was unclear
Every team used Kafka differently

The real issue was simple:

Everyone depended on Kafka. Nobody owned its governance.

That’s how technical debt quietly compounds; until it becomes operational risk.

The Realization: Governance is a Missing System, Not a Missing Rule

Sitting down, one thought became clear:

We’re building technical debt faster than we can document it.

Without intervention, cross-service debugging would become unsustainable within a year. But there was a constraint:

No central authority
No mandate power
Fully autonomous teams This wasn’t a tooling problem. It was a coordination problem.

Meeting Invite: Start with Pain, Not Policy

Instead of proposing a solution, I invited collaboration by framing it as a way to fix shared frustrations.

That framing mattered. No one wants another rulebook. But everyone wants their pain heard.
Five engineers showed up:
2 from platform engineering
3 from application teams

That was enough to start.

The Meeting: Shifting from Skepticism to Engagement

In the meeting, I led with pain points rather than solutions, showing real examples of redundant and confusing topics on the MSK dashboard.
Then someone said:

“We got paged last week because a producer couldn’t write to a topic. Nobody knew how to fix it.”

That changed the room. We moved from:

“Why are we here?”

“We need to fix this.”

That shift from abstract discussion to shared pain is where influence begins.

Drafting Standards: The Technical Blueprint

Over the next two weeks, I drafted the first version of a governance framework. It focused on three pillars:

1.Topic Naming Convention

Convention: {domain}.{service}.{event-type}.{version}
Example: loan.loanservice.loan-created.v1

Goal: Make the topic names - discoverable, searchable, self-descriptive, and future-proof with versioning.

2. IAM Policies (Least Privilege)

Creating mandatory least-privilege templates tied to service roles to eliminate wildcards.

Goal: Make the secure path the default path.

3. Schema Evolution (Avro + Compatibility)

Enforced Avro with BACKWARD compatibility which is integrated with schema registry and gets checked before deployment.

Goal: Prevent breaking downstream consumers silently

Automation: If It’s Not Enforced, It’s Optional

Documentation alone doesn’t scale. So we embedded the standards into tooling.

Terraform Modules: Topic provisioning templates now included regex validation for naming and pre-configured IAM defaults.
CI/CD Linters: We built a linter to flag violations in service configuration files before deployment.
Example failure: FAILED: topic name 'test_topic' does not match pattern
Example success: PASS: topic 'loan.loanservice.loan-created.v1'
Gate: Automation turned guidance into a "gate," ensuring that the right way was also the only way to deploy.
That’s when governance becomes real:

Not a suggestion. A system constraint.

The Tipping Point: Adoption Without Intervention

Three months later, something subtle happened. I was reviewing a PR from a team I’d never worked with.

Everything passed:

Naming ✔
IAM ✔
Schema ✔

No feedback needed. That’s when I knew:

The system didn’t need me anymore.

And that’s the goal of good governance.

Key Takeaway

This experience reshaped how I think about technical leadership:

Standards don’t succeed because they’re correct.
They succeed because people believe in them.

What Actually Worked

Start with pain, not policy
Involve stakeholders early
Facilitate, don’t dictate
Bake standards into tooling

Final Thought

If you're working on platform or architecture problems in a multi-team environment, remember:

You don’t need authority to create alignment.

You need:

clarity
empathy
and systems that reinforce good decisions

Standards stick when they make people’s lives better — not when they add gates.

The Feynman Algorithm: A Developer’s Guide to "Thinking Very Hard"

Prasad Rane — Mon, 27 Apr 2026 16:06:50 +0000

If you search for Richard Feynman’s methods, you’ll likely stumble upon the famous Feynman Technique, a brilliant framework for learning new concepts by explaining them to a child.

But there’s another, lesser-known Feynman method. It was jokingly coined by his colleague, physicist Murray Gell-Mann, who said that Feynman’s process for solving problems looked like this:

Write down the problem.

Think very hard.

Write down the solution.

At first glance, this sounds like a meme. "Draw the rest of the owl," right? But if we look closer at this "Feynman Algorithm," it actually perfectly outlines the lifecycle of debugging and writing software.
Let’s break down how this tongue-in-cheek algorithm can actually help you become a better developer.

Step 1: Write down the problem ✍️

Albert Einstein supposedly said, "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions."

In programming, we often skip this. We see an error log and immediately start changing variables and refreshing the browser. But "writing down the problem" forces you to define exactly what is going wrong.

Bad Problem Definition:

"The login page is broken."

Good Problem Definition:

"When a returning user tries to log in with Google OAuth, the API returns a 500 server error, but only on mobile Safari."

When you write the problem down clearly, the scope narrows. Half the time, simply defining the problem accurately reveals the solution.

Step 2: "Think very hard" 🧠

This is the punchline of the joke. To outsiders, Feynman just stared at a chalkboard and magically found the answer. But "thinking very hard" doesn't mean having a massive IQ; it means engaging in structured, focused analysis.

How do developers "think very hard"?

We Rubber Duck: We explain the code line-by-line to an inanimate object (or a patient coworker).

We Isolate: We comment out chunks of code to see if the bug still happens. We narrow down the variables.

We Step Away: Sometimes, "thinking very hard" means taking a shower or going for a walk. Your brain's "diffuse mode" keeps working on the problem in the background.

"Thinking very hard" means resisting the urge to copy-paste the first Stack Overflow answer you see without understanding why it works.

Step 3: Write down the solution 💡

You figured it out! You fixed the bug! Time to push to production and go home, right? Not quite.

In the context of coding, "writing down the solution" means three things:

Writing clean code: Making sure your solution isn't just a hacky workaround, but a readable, maintainable piece of logic.

Writing tests: Proving that your solution actually works and ensuring it won't break in the future.

Writing documentation: Leaving comments explaining why you did what you did.

Your future self (and your team) will thank you when they read a comment like:

// Using a Set here instead of an Array because checking for duplicates was causing a massive performance bottleneck.

Final Thoughts

The Feynman Algorithm might have started as a joke among Nobel Prize-winning physicists, but it’s remarkably practical for software engineers.

Next time you are stuck on a nasty bug, don't just start mashing the keyboard. Stop. Write the problem down. Take a walk to think very hard. And when you solve it, document it for the next developer.

Let me know in the comments how you practice "thinking very hard" when you are stuck on a tricky coding problem!