DEV Community: Ajitkumar Singh

Five ways to code with AI, five different risks

Ajitkumar Singh — Fri, 30 Oct 2026 13:00:00 +0000

"We use AI for coding" covers at least five different arrangements, and they fail in different ways. Before picking one, it helps to be precise about what a coding agent is.

A coding agent is a software system that uses a generative model to choose and sequence repository tools toward an engineering goal, while an external runtime controls what it can see, change, run and report. The model proposes. The harness supplies files, search, shell commands and patches. Policies decide whether an action is allowed. Tests and reviewers decide whether the result is acceptable.

The five modes

Mode	Unit of work	Typical authority	Main risk
Completion	the next tokens or line	a text suggestion only	a plausible local error
Chat assistant	an explanation or snippet	usually read-only	missing repository context
Interactive coding agent	a bounded repository change	files and selected commands	an incorrect multi-file change
Asynchronous coding agent	an issue, pull request or maintenance job	a disposable environment and branch	unsupervised drift
Agentic workflow	a repeatable delivery process	policy-controlled automation	a bad rule applied at scale

Not a maturity ladder

It is tempting to read the table top to bottom as a path from beginner to expert. It is not. A low-risk refactor across fifty files may suit an asynchronous agent that opens a pull request overnight. A production incident may call for an interactive agent with a senior engineer watching every step. The right mode follows from how reversible the change is, how uncertain the task is, and what a mistake would cost.

One session, several systems

Here is an interactive session from the course. A developer asks an agent to fix a duplicate payment retry. The model does not get the whole repository: the harness first gives it the project instructions and search tools. It searches for the timeout error, reads the retry policy and its integration test, and proposes a plan touching three files. Policy allows edits in the workspace and local tests, and denies network and secret access. The model patches the retry key, runs a focused test, hits a contract failure, inspects the checkout response type, revises the patch, and runs the wider payment suite. A human reviews the diff, and CI reruns every required check independently.

Count the systems in that story: a model that proposes, a harness that executes, a sandbox that limits reach, a repository that holds local truth, a CI system that produces independent evidence, and a reviewer who grants authority.

Engineering Insight

Calling all of that "the AI" hides the boundaries engineers have to design. Most incidents with coding agents happen at one of those boundaries: a permission set too wide, a test that was not run, a review that was skipped.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: What a Coding Agent Actually Is.

What multi-AZ buys, and what it doesn't

Ajitkumar Singh — Wed, 28 Oct 2026 13:00:00 +0000

"Region" and "availability zone" sound like marketing. They are really definitions of failure domains, and knowing exactly which failures each one contains is most of designing for them.

A region is a geographic area with its own control plane, such as ap-south-1 in Mumbai or eu-west-1 in Ireland. Regions are almost completely independent: separate APIs, separate service endpoints, separate failure domains, and no data moves between them unless you move it.

An availability zone is one or more data centres inside a region, with independent power, cooling and networking, linked to the other zones by low-latency connections of typically single-digit milliseconds. Zones fail independently, for physical reasons: a power event, a cooling failure, a fibre cut.

What each boundary covers

Failure	Multi-AZ survives it	Multi-region survives it
Power, cooling or fibre loss in one data centre	Yes	Yes
A rack or host failure	Yes	Yes
A regional control-plane incident	No	Yes, if the standby needs no API calls in the failed region
A bad deployment	No	No, and active-active makes it worse
An expired certificate	No	No
A corrupt schema migration	No	No: replication faithfully copies the corruption
An exhausted account quota	No	Partly, because quotas are per region

Three rows say no in both columns, and the quota row is covered only in part. A deployment pipeline crosses every zone and region without noticing them, the same certificate sits in every zone, and a corrupt migration replicates. Changes like these cause a large share of outages. Multi-AZ protects against infrastructure failure, multi-region against regional failure, and neither protects against you. A team asking for a third zone when its last four incidents were deploys is optimising the column that was already covered.

The two boundaries cost different things

Crossing a zone costs one to two milliseconds and a per-gigabyte charge on the traffic, which is small enough that spreading across zones should be the default for everything. Crossing a region costs tens to over a hundred milliseconds; Mumbai to Ireland is roughly 120 ms round trip. That is an architectural constraint rather than a line item. A synchronous cross-region call inside a request path spends more time on the wire than most services spend on their entire response, and no amount of tuning wins it back.

Common Mistake

Calling a service multi-AZ because it runs in three zones. Lose one zone and capacity drops by a third; if the other two saturate, the service failed along with the zone. Surviving the loss of a third means serving peak load on the remaining two thirds, which means running at or below 66% utilisation at peak. A zone-removal drill tells you which kind of deployment you actually have.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: Regions, Zones, and What Multi-AZ Actually Buys.

Same average, very different users

Ajitkumar Singh — Tue, 27 Oct 2026 13:00:00 +0000

Two services each handle 10,000 requests. A latency dashboard that shows the mean reports the same number for both: 153.0 ms, identical to one decimal place. They are not the same service.

	Mean	p50	p90	p99	Max	Requests over 1 s
Service A, uniformly a little slow	153.0 ms	153.0 ms	160.0 ms	161.0 ms	161.0 ms	0
Service B, fast with a 10% tail	153.0 ms	14.0 ms	17.0 ms	1,416.0 ms	1,419.0 ms	1,000

In service A, nobody waits more than 161 ms. In service B, a thousand people wait almost a second and a half.

The mean is doing exactly its job

A mean measures central tendency. It is deliberately insensitive to outliers, and in latency the outliers are the incident. Asking the mean to show a slow tail is asking it to do the one thing it was designed not to do.

Two things make it worse in practice. First, the mean has no unit of experience: no user of service B ever waited 153 ms. Their requests took about 14 ms or about 1,400 ms, and the average describes a request that never happened.

Second, the tail is not a small group of people. A p99 affects one request in a hundred, but a page or session that makes 100 requests is likely to hit it at least once: if each request independently has a 1% chance of landing in the tail, the chance is 1 ‚àí 0.99¬π‚Å∞‚Å∞, about 63%. Fan-out turns a rare request into a common experience.

What to watch instead

Percentiles per endpoint: p50 for the typical request, p99 and the maximum for the people having a bad time.
A count of requests over a threshold you care about, such as one second. It reads like the table above, and it maps directly to an objective.
Histograms, aggregated across servers. They can be merged; percentiles cannot.

Common Mistake

Averaging each server's p99 to get a fleet-wide p99. Percentiles do not combine that way: the mean of eight servers' p99 values is not the p99 of all their requests. Merge the latency histograms first, then read the percentile from the result.

The mean still has a use: it tracks total work and capacity. It just cannot tell you who is waiting.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: The Average Is the Statistic Designed Not to See This.

Read an MCP server before you trust it

Ajitkumar Singh — Sun, 25 Oct 2026 13:00:00 +0000

The quickest way to learn what an MCP server owes its users is to be one first. The reference server that the MCP maintainers publish to exercise every protocol feature is a good place to start: it is safe to run, and it shows exactly why you read a server before you trust it.

Pin the version

An MCP server's tool descriptions are instructions that a model reads. Start a server with npx some-server and no version, and every start fetches whatever was published last, so a later release can change what those instructions say without you noticing. Pin an exact version, and a change reaches you only when you choose to upgrade and read what changed.

List what it offers

The MCP Inspector, the protocol's own debugging client, has a command-line mode that connects, sends one request and prints the answer. Asked for tools/list, the reference server returns fourteen tools, each with a description, an input schema and four annotations: readOnlyHint, destructiveHint, idempotentHint and openWorldHint.

Two of them deserve a second look.

Tool	Annotation	What it actually does
`get-env`	`readOnlyHint: true`	Returns every environment variable, including the `DEMO_API_KEY` set for the test
`gzip-file-as-resource`	`openWorldHint: true`	Fetches whatever URL it is given, from the machine the server runs on

get-env really does change nothing, so its annotation is honest. Read-only describes side effects, not confidentiality. Annotations are also claims a server makes about itself, and the specification tells clients to treat them as untrusted unless the server itself is trusted.

Engineering Insight

gzip-file-as-resource is not marked destructive, yet a model, or text an attacker planted somewhere the model reads, can give it any URL: a router's admin page, a service on localhost, or a cloud metadata endpoint such as 169.254.169.254. The response lands in the model's context. That is server-side request forgery, and openWorldHint: true is the only clue in the annotations.

Allow only what you decided

In Claude Code, add the server and then deny the tools you do not want a model to have, in the project's .claude/settings.local.json:

{ "permissions": { "deny": ["mcp__everything__get-env", "mcp__everything__gzip-file-as-resource"] } }

A denied MCP tool is removed from the model's context entirely, not merely refused when called. In Codex, list the only tools the server may expose with enabled_tools. Of the two, the allow list is safer when a server can grow, because a tool added in a later version stays off until you choose to enable it.

A stdio server runs as you, with your files, your network and your environment variables. Installing one is running a program, not adding a bookmark.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: Use a server before you build one.

Build the safety net before your coding agent's first edit

Ajitkumar Singh — Fri, 23 Oct 2026 13:00:00 +0000

Sooner or later a coding agent will do something you did not ask for. It will edit a file you never mentioned, run a command that changes more than it should, or make a failing test pass by weakening the test. Better instructions make that rarer. They never make it impossible.

What you can control is the damage: how much an unwanted action can touch, and how fast you can undo it. That is a setup task, not a prompting skill, and you do it once per project.

Four layers, each covering the last one's blind spot

1. Permissions decide which actions need your yes. Claude Code calls them permission modes and rules; Codex calls it the approval policy. In a codebase you do not know yet, choose a mode that asks before it edits, so you can see which files the agent reads and which commands it reaches for. The fully automatic modes are useful later, once you trust the project's setup.

2. The sandbox decides what an approved command can reach. Files outside the project and the network are the usual boundaries, and the operating system enforces them. That matters because the model can be wrong about what a command does: inside Codex's workspace-write sandbox, a write inside the project folder succeeds, while a write to your home folder and a request to the npm registry both fail.

3. Checkpoints rewind the agent's own edits. Claude Code saves one with every prompt, and /rewind restores the code, the conversation or both. It undoes a wrong direction in seconds, with one large exception below.

4. Git restores anything inside the repository, including what shell commands changed. It restores nothing outside it: not a database, not an installed package, not a message that was sent.

No layer is enough alone. Git cannot recall a published package, and permissions cannot undo an edit you approved.

Git first: one branch and a clean tree per task

Start every task from a clean working tree on its own branch. Then "what did the agent change?" always has an exact answer, and abandoning an attempt costs nothing.

git status                     # must say "nothing to commit"
git switch -c tb-101-overdue   # one branch per task
# ... the agent works ...
git diff --stat                # which files changed, and how much
git diff                       # every changed line
git stash -u                   # set an attempt aside, untracked files included

Commit whenever the tests pass, even halfway through a task. Small commits turn a bad turn into a few minutes of work instead of an afternoon, and they let you show the agent exactly which change broke something.

Common Mistake

Trusting the working tree after a rewind. Checkpoints track only the edits Claude Code makes with its file tools. A file moved with mv, deleted with rm, regenerated by a script or changed by a database migration stays changed. After any rewind, run git status and git diff to see what is really there.

The settings to leave alone

Both tools have a mode that removes every boundary at once. They exist for containers and virtual machines that are already isolated, not for your laptop. When a task needs one extra capability, such as network access to install a package, grant that one thing for that session, or run the install yourself and let the agent continue.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: Build a safety net before the first edit.

Your database reads pages, not rows

Ajitkumar Singh — Wed, 21 Oct 2026 13:00:00 +0000

You ask for one 120-byte row. The storage engine reads an 8 KiB page, because that is the smallest unit the disk and the buffer pool exchange. If your row sits alone on that page, you paid 8 KiB for 120 bytes. If the neighbours you also wanted are on it too, you paid 8 KiB for all of them.

That ratio is locality, and it is the most useful single lens for reasoning about storage performance.

How many rows share a page

With nothing else taking space, an 8 KiB page would hold 68 rows of 120 bytes. A PostgreSQL heap page also spends 24 bytes on its page header and, for every row, 4 bytes on a line pointer and 24 on a tuple header (23 bytes, padded), so it holds 55.

page_bytes, row_bytes = 8 * 1024, 120
ideal = page_bytes // row_bytes                       # 68 rows
postgres = (page_bytes - 24) // (4 + 24 + row_bytes)  # 55 rows

Same index, fifty times apart

Two tables hold the same customer's 200 orders, and the same index finds them in both. In the first, the orders were inserted over three years, so they are scattered across about 200 pages written at different times. The second was bulk-loaded in customer order last night, so the 200 rows sit side by side.

How the rows are stored	Page reads for 200 rows
Scattered	200
Clustered, 68 rows a page	3
Clustered, PostgreSQL's 55 rows a page	4

The index tells the engine where to look. It does not reduce the number of pages the engine must fetch; locality does. That is how "the query returns 200 rows and takes 400 ms" happens with a perfectly good index.

Most pages never touch the disk

Pages are usually served from the buffer pool, the memory the engine keeps for hot pages, where a hit costs a memory access instead of an I/O. A hit ratio above 99% is normal on a well-sized database, which makes the ratio a poor alarm: a table scan that evicts the working set can keep it high while ruining every other query's locality. What matters is not how often you hit, but what was evicted to make room.

Think Like an Engineer

A database with 64 GiB of RAM and a 60 GiB working set can be an order of magnitude faster than the same database with a 70 GiB working set. With uniform access there is no gradual decline, because the set either fits or it does not. Skewed access softens the cliff: the hot part of a 70 GiB set may still fit.

When a query is slow despite a good index, count pages, not rows.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: The Database Does Not Read Rows.

Why Kafka is a log, not a queue

Ajitkumar Singh — Tue, 20 Oct 2026 13:00:00 +0000

A traditional message queue deletes a message once it has been delivered and acknowledged. It sounds like tidy housekeeping. In practice it causes three problems you have probably met.

You cannot add a second independent reader. Marketing wants every order event too, but the fulfilment workers already share each message between them. A second view needs a fan-out topology, publishing twice, or another copy of the data somewhere.

You cannot replay. A bug in the fulfilment consumer mishandled nine hours of orders. The messages are gone, so the fix is a one-off backfill script against the database, rebuilding events that used to exist.

The broker tracks every message's fate: delivered, acknowledged, redelivered, dead-lettered. That bookkeeping is a large part of what makes queues hard to scale.

What a log changes

A Kafka topic is an append-only log kept according to a retention policy, not consumed away. Reading does not delete. A consumer group records only how far it has read in each partition, its offset. Adding a reader means adding a group with its own offsets. Replaying nine hours means moving a group's offsets back nine hours.

The price of storing one number

Within a traditional consumer group, a partition's progress is a single integer. That is what makes fan-out and replay cheap, and it is also why the group cannot say "this one record failed, deliver just that one again" while moving past it. One stuck record blocks its partition, which is why Kafka designs end up with a dead-letter topic.

	Queue	Kafka consumer group	Kafka share group
Second independent reader	needs fan-out or double publishing	yes, a new group	yes
Replay nine hours	no, the messages are gone	yes, reset the offsets	yes, from the retained log
Acknowledge one record	yes	no, progress is one number per partition	yes
Ordering	lost with competing consumers	per partition	weakened
Parallelism ceiling	number of consumers	number of partitions	beyond the partition count

Share groups, available from Kafka 4.2, bring back per-record acknowledgement, and with it per-record bookkeeping and weaker ordering. They are a different trade, not a newer version of the same thing.

Think Like an Engineer

A team wants both fan-out and per-record acknowledgement on one topic. They can have it with two groups of different kinds on the same log: a consumer group for the reader that needs per-key order and replay, and a share group for the worker that needs to skip failures. What no single group can offer is both, because skipping a record and keeping that key's order are the same decision seen from two sides.

The useful question about a topic is which of those columns its readers need. A topic carrying changes to an order's state needs per-partition ordering. A topic of independent work items may not.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: Why a Log, and Not a Queue.

Your context window is a budget

Ajitkumar Singh — Sun, 18 Oct 2026 13:00:00 +0000

Every token you put in front of a model is paid for three times: in money, in latency, and in the model's attention. A bigger context window raises the ceiling. It does not change the job, which on every turn is to send the smallest set of tokens that lets the model answer correctly.

Five lines in the budget

Budget line	Grows with	Lever
System prompt	Policy and operating instructions	Keep it precise, versioned, and stable where caching applies
Tool schemas	The capabilities exposed in this state	Expose tools per task, or let the agent discover them progressively
Conversation state	Raw turns, summaries, persisted facts	Compact it, and retrieve what this decision needs
Retrieved context	Number of chunks × chunk size	Rerank so the count stays small and precise
Long-term memory	How much is pulled in per turn	Retrieve the few relevant memories, not the whole profile

Two of these lines are easy to underestimate. In runtimes that send every registered tool on every turn, irrelevant schemas use up input tokens and can make choosing the right tool harder. And replaying every raw turn of a conversation grows without limit unless the application compacts it, summarizes it, or retrieves only the state the current decision needs.

Do the arithmetic before choosing context

Take a hypothetical 8,192-token window. Reserve 1,024 tokens for the answer and 512 for message framing and estimation error, which leaves an input allowance of 6,656. Instructions take 700, tool schemas 1,000, the current task 200 and typed state 500: 2,400 spent before any evidence, and 4,256 left for evidence and history.

8,192 - 1,024 answer - 512 framing      = 6,656 input allowance
6,656 - (700 + 1,000 + 200 + 500)       = 4,256 for evidence and history

6 chunks x 800 = 4,800   over by 544
5 chunks x 800 = 4,000   fits, with 256 to spare

Use your provider's exact token accounting, including any reasoning or output limits. A rough counter is only an estimate, and the budget is only as good as its numbers.

Common Mistake

Taking the top five chunks because five fit. The sixth may be the exception to a rule stated in the first five, and a prompt that holds the rule without its exception produces a confident, wrong answer. Rank whole evidence bundles, a rule together with its exceptions, and include each bundle completely or not at all. If the bundle the question needs does not fit, report insufficient context rather than answering from part of it.

The principle that makes retrieval work, a handful of highly relevant chunks beating a large dump, applies to the whole session. Every line of the budget competes for the same window.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: The Context Window Budget.

Pick the place before you pick the model

Ajitkumar Singh — Fri, 16 Oct 2026 13:00:00 +0000

Three decisions sit in front of every request you make to ChatGPT or Claude: where you ask, which model answers, and how much reasoning you ask it to spend. Developers argue about the second and ignore the first. Yet most disappointing answers come from asking in the wrong place, and most wasted money comes from the other two choices.

Six jobs, six places

The job	Where it belongs	Why there
A question, an explanation or a one-off piece of code	A chat	You check the answer by reading it, so a conversation is enough.
Recurring work with the same files and rules	A project or a skill	The context is set up once instead of pasted in every week.
A question that needs many sources	A research mode	It gathers and cites sources, and you check the sources.
A multi-step task with files, a browser or a schedule	Claude's task hand-off or ChatGPT's Work mode	Built for a finished deliverable rather than a back-and-forth.
Changes across a repository that must be run and tested	A coding agent such as Claude Code or Codex	It can run the tests that prove the change works.
A task inside your own program, run many times with checked output	An API	Your code controls the input, the output format and the checks.

The boundaries are soft. A chat can write a whole module, and a coding agent can answer a question. The question that decides it is where the job is cheapest to check. A refactor that touches nine files is cheap to check where the tests can run, and expensive to check by eye in a chat window.

Then change one thing at a time

Once the place is right, start from the mid-tier model at its default effort, and change something only for a reason you can name:

The answer missed something you supplied, such as a constraint buried in a long file or two facts that interact. Raise the effort, or move up a tier.
The answer is wrong because it lacked information, such as the file where the bug lives. No model fixes that. Supply the information.
The task is routine: renaming, reformatting, summarizing. Drop the effort or the tier. You wait less and use less of your allowance.

A stronger model guesses more fluently

Here is the trap the second rule protects you from. An assistant gives a wrong answer about how a search feature builds its query. The instinct is to switch to the biggest model. But if nobody attached the file that builds the query, the assistant was guessing, and a stronger model guesses more convincingly, not more correctly. Supply the evidence, ask again, and only then reach for more reasoning.

Common Mistake

Assuming a ChatGPT or Claude subscription pays for API calls from your own program. The apps are covered by the subscription; the APIs are billed separately, by the token, through an API account. Both carry the same brand name, which is why teams mix them up.

What changes for a team

Before a team debates which model is better, it is worth asking where its AI work happens. Recurring prompts pasted into fresh chats every Monday, repository changes copied out of a chat window and never run, a script calling a chat product instead of an API: each is a placement problem that no model upgrade will solve. Fix the place, then tune the model, then tune the effort, in that order.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: Choose the product, the model and the effort.

A container is a process, not a small VM

Ajitkumar Singh — Wed, 14 Oct 2026 13:00:00 +0000

There is no guest kernel inside a container, and nothing is virtualised. A container is an ordinary Linux process on the host; run ps on the host and you will see it. What makes it a container is two kernel features wrapped around that process:

Namespaces restrict what it can see: its own process tree, network stack, mounts and hostname.
cgroups restrict what it can use: CPU, memory and IO.

Picturing it as a small virtual machine is where most container surprises come from. Three of them turn up in support queues again and again.

The kernel is shared

Every container on a node runs on the host's kernel. A kernel vulnerability is therefore a host vulnerability, and a container escape is a real category of incident rather than a theoretical one. Containers are a convenient isolation boundary, but not one strong enough for running untrusted code from strangers. That needs a VM, Firecracker or gVisor.

Your process is PID 1

Inside its PID namespace your application is process 1, and PID 1 plays by different rules: it gets no default signal handlers, and it must reap its zombie children. Whether a deploy shuts your service down cleanly depends on which process ends up in that slot.

Container command	PID 1 is	On SIGTERM
`CMD ["java","-jar","app.jar"]`	The JVM	The shutdown handler runs
`CMD ./start.sh`	The shell	Many shells don't forward it, so SIGKILL arrives after the grace period
Run with tini or `--init`	An init process	Forwarded, and zombie children are reaped

This is the mechanism behind a very common bug. The grace period is set correctly, the application implements shutdown correctly, and pods are still killed hard on every deploy, because a shell sits between the signal and the code.

Think Like an Engineer

The exec form CMD ["./start.sh"] removes the wrapping shell, but the script still runs under its own interpreter, and that interpreter becomes PID 1. If the script ends with exec java -jar app.jar, the JVM replaces it and receives the signal. Without that one exec, nothing has changed.

Memory limits are visible only if you look

Older runtimes report the host's memory through the usual interfaces. A JVM or Node process then sizes its heap for a 64 GB machine while it lives in a 512 MB container, and the kernel's OOM killer ends it with a SIGKILL that no shutdown code can catch. Modern JVMs are container-aware by default. A lot of tuning advice, and a lot of running code, is not: anything that sizes a pool or a cache from "available system memory" will size it for the node.

The tell is a container that dies at a limit far below what its configuration implies.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: A Container Is a Process With a Restricted View.

Why a retry charges the customer twice

Ajitkumar Singh — Tue, 13 Oct 2026 13:00:00 +0000

Order 88213 needs one payment of ₹4,998. The client calls the payment service with a 2,000 ms timeout and retries once on timeout, a policy many of us have written, and one that SDKs, service meshes and some HTTP clients apply without being asked.

Five ordinary steps

The client sends the charge.
The payment service commits charge ch_0001, then replies. That order is correct: replying before committing would confirm charges that never happened.
The reply is lost on the way back.
The client waits 2,000 ms and times out.
The client retries, and the service, seeing what looks like a new instruction, commits ch_0002.

The customer has paid ₹9,996 for a ₹4,998 order. Nothing exotic happened: no corrupted packet, no clock skew, no misbehaving node. A correct service, a correct client, a default retry policy and one lost response.

The client cannot fix this

After a timeout, the client does not know whether the first charge committed. It cannot find out by waiting longer or reasoning harder, because the information it needs never arrived. Removing the retry does not help either: then a request that really was lost leaves an order unpaid.

So the repair has to happen at the other end. The service must be able to recognize the second request as a repeat of the first.

What an idempotency key changes

The client creates one key for the payment, before the first attempt, and sends the same key with every retry. The service stores the key together with the charge it created, in the same transaction, with a uniqueness constraint on the key. When a request arrives with a key it has seen, the service returns the stored charge instead of creating a new one.

charge(request):
  if a charge exists for request.idempotencyKey:
    return that charge          # a repeat: charge nothing
  in one transaction:
    create the charge
    record idempotencyKey -> charge
  return the charge

The uniqueness constraint matters when two copies of the same request arrive at once: only one of them can commit.

Run the same five steps again and only step 5 differs: the service replays ch_0001, and the customer pays ₹4,998.

Engineering Insight

The key identifies the payment, not the HTTP request. A client that generates a fresh key for each attempt has added a header and fixed nothing, because every retry looks new.

Where else this shows up

Any operation with an effect outside the request is exposed to the same lost reply: sending an email, reserving stock, starting a job, calling another company's API. Before shipping a retry policy, it is worth asking of every endpoint it covers what happens when the work succeeds and only the answer disappears.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: Why a Retry Charges the Customer Twice.

What an AI agent actually is

Ajitkumar Singh — Sun, 11 Oct 2026 13:00:00 +0000

"Agent" gets used for everything from a single function-calling request to a research bot that runs for days. Underneath, the idea is narrow. An agent is a language model placed inside a loop: it can take an action, see what happened, and decide what to do next, until it proposes an answer or the runtime stops it at a turn, time, cost or policy limit.

Same model, different harness

A plain model call is one round trip. You send a prompt, the model writes text from what it already knows plus whatever you pasted in, and the interaction is over. It cannot look anything up, check its own answer, or try again unless you send another request.

Nothing about the model changes when it becomes an agent. What changes is the code around it. Instead of stopping after one response, the harness feeds the model's tool requests, and their results, back to it turn after turn.

Take a hotel guest who writes "My AC isn't working." A plain call replies with sympathy and promises to contact maintenance; no ticket exists and nobody has been told. An agent identifies the guest and the room, checks the maintenance policy, creates a repair ticket, assigns available staff, starts the SLA clock and lets the guest know.

The loop: think, act, observe

An HR assistant has exactly one tool, search_hr_docs(query). Someone asks whether fathers can carry forward unused parental leave.

Think. The answer needs the parental leave policy, so search for it.
Act. Call search_hr_docs("parental leave").
Observe. "Fathers receive 30 days of parental leave." That answers how much, not whether it carries forward.
Act again. Call search_hr_docs("carry forward policy").
Observe. "Unused parental leave may carry forward up to 10 days into the next year."
Stop. Both facts are in hand, so the model writes the answer.

If you have written retry logic, the shape is familiar, with one difference: the model proposes the next operation. The runtime still enforces a maximum number of turns, per-call deadlines, cancellation and a total cost allowance, however keen the model is to continue.

Engineering Insight

The model never touches a database, an API or a file. It emits a structured tool request, and your orchestrator validates it, runs it and returns the result. The model reaches the outside world only through the capabilities your application chooses to expose.

Five parts, and where autonomy stops

Part	What it does
Model	Decides the next step from everything observed so far
Tools	The only way to read or change anything outside the model's own text
Memory and context	The current situation: this conversation and the tool results so far
Policies and guardrails	What the agent may and may not do, such as needing approval above a refund limit
Loop	Runs think, act, observe, and checks whether to stop

The usual mistake is treating "agent" as all or nothing. In the hotel example the model is good at recognizing that "my AC is making a weird noise" is a maintenance request and picking the right workflow. The ticket lifecycle, the SLA calculation, permissions, approvals and audit events should stay deterministic code. Let the model decide which action fits; let your workflow engine decide how it runs.

Originally published at engineertoai.com. The full lesson is free, with no sign-up: What Is an AI Agent?.