Mishuk Adhikari
Lead Engineer at xCloud, 9+ years in software, now building AI agents
mishuk.ad.bd@gmail.com +880 1768 629894
I build agents that diagnose and fix production issues. None of them can merge code or send a customer message without a human. I wrote a rule into my diagnosis agent: never trust exit_code = 0. A task status is a claim, and the output is evidence about the work. Before an agent gets a new model, I run a golden set of requests through its real decision path, more than once. One run can be noise. I built Next Term, an open-source Mac terminal where one agent can run the others. Its file-writing and commit tools wait for approval.
My agents read production through a layer I built: token-scoped, read-only and audited. Merge authority is enforced by the repository’s own rules, so it does not depend on what an agent was told.
Agents are the newest layer of my work. Under them is backend and platform engineering, mostly in PHP and Laravel, with some Python. The role-by-role history is in the CV.
The interesting problem with AI in engineering is not the model, it is bounded, auditable access.
One agent diagnoses. A second reproduces the failure, fixes it and deploys to staging. A human merges. Anything an agent writes for a customer is saved as a draft, and a person decides whether it is sent.
Agents in a chain, with a human on the merge.
The first agent takes a production issue and investigates it end to end. It reads sanitized database views, recent production errors and server logs, and hands the engineer four things: what it checked, the likely cause, the next action, and one caveat where the evidence is thin. The second turns that diagnosis into one traceable pull request. It reproduces the failure before it writes any code, makes the smallest complete fix, tests the real path, opens the pull request with reviewers requested, and deploys it to staging. Neither of them can merge.
When an answer depends on arithmetic, the model does none of it: a script computes the amounts and the answer shows them as a table. Before replying, the agent writing that answer re-queries fresh data and sum-checks its own totals.
I build the diagnosis agent’s context by hand from the codebase, the docs, production errors and the logs, partly with automation, and keep it current myself. It does not learn on its own from corrections, because fully automatic learning produced garbage.
Running the implementation agent safely costs capacity more than cleverness. New work waits at an admission gate when memory is short. Restarts happen at the next idle window, never mid-task. Each run works in its own worktree, so a bad run damages one worktree. I set the worker limits from measured load.
What they may read, and what they may not.
My diagnosis agent reads production through an access layer I built. Every endpoint is read-only, each kind of read needs its own token ability, and every call is written to an audit log. Access can be switched off for anyone who opts out. Data comes through a select-only database role over sanitized views that mask personal details and strip secrets.
The refusals are the more interesting half. No generic file reads outside the log roots, no arbitrary queries, no credential decryption.
The same shape is in Next Term, which anyone with a Mac can install. Its tools that write a file, stage, commit or rearrange the screen wait for an Approve on the Mac, and a decline or no answer changes nothing. Files outside the open projects, secrets files and git hooks are refused.
How I change the model behind an agent.
Before a model change, I run a golden set of requests through the same decision path the agent uses and record the action it picks. One set of everyday requests has a recorded baseline that any drift is checked against. A harder set, written to be ambiguous or to contain decoys, is there to tell models apart. No model grades the answers.
I run a comparison several times before I trust it, because one run can favour a model by chance. And I score behaviour. When the right move is to ask the user a structured question, an answer in fluent prose is a failure, however well it reads.
I instrumented the agent’s execution paths for tracing with prompt and completion text stripped by default, so a trace records the steps and the tool calls without the conversation.
How I check the work, and what I got wrong.
The debugging rule I wrote into my diagnosis agent is never trust
exit_code = 0. A command can print a fatal error and still exit 0, so the
agent reads the start and the end of the output and scans it for error signals
whatever the status says. A task status is a claim about a task. The output is
evidence about the work. Where the two disagree, the output wins.
I have shipped that failure myself. The egg club ledger below trusted a 200 from a read that had quietly stopped at a thousand rows.
A subagent’s summary is not accepted as proof either. The parent re-checks the files, the deployment and the repository state itself. Verification runs at each boundary of a task, from reproducing the premise to holding the reply until the evidence it cites exists, and a human’s QA sign-off outranks the agent’s own claim that its work passed QA.
Three things I got wrong in my own agents: a quarter of an instruction file never reached the model, a rescue guarantee shipped inert, and a browser check was passing on a failed login, so it reported a pass on a page it had never seen.
How I work on a change.
I measure before I claim. When a change of mine was expected to cut database queries, I measured it, found no saving at the scale I could test, and shipped it without a number.
I review by running code as well as reading it. On one migration, two throwaway tests showed that its rollback was not the reverse of the change.
One flow I designed creates nothing until the user commits. The analysis runs first, with no side effects, so an abandoned attempt leaves no half-made records behind.
Five products I built on my own time.
I built these outside work in 2026 and engineered them the way I work in production. The constraints come first, the architecture decisions are made and written down, coding agents work inside that process as tools, I review every change, and nothing ships that I have not run on a real device.
Next Term, a terminal for running coding agents
Run several coding agents in a plain terminal and you get identical tabs and no idea which one is waiting on you. Next Term is a native macOS terminal and editor, free and open source under MIT, where every tab shows whether its agent is working, done or waiting, and an agent’s proposed edit opens as a side-by-side diff to accept or reject. It is also a local MCP server, so one agent can open projects, start others in new tabs, hand them tasks and read what they did. The server listens on a local socket with no network port, brings no model of its own and needs no account.
I shipped a privacy bug in it. Before version 0.11.2, an agent listing the tabs could
see a dev server’s login token, such as the one in a Jupyter ?token=
address. The source
is public, and so is the
release note
for the fix.
গ্রন্থাগার, a community library on Android
Madan Mohan Library in Belkuchi, Sirajganj, was founded in 1948. Its members needed the catalogue, the events programme, the blood-donor register and the points ledger on low-end phones, over a network that comes and goes. The app is Kotlin and Jetpack Compose, Android 7 and up, Bengali only, with the font shipped inside the APK because many of those phones have none. Everything a member sees is cached. Everything a member does with no signal is queued and replayed later, and conflicts are settled per record type, because a points-ledger entry and a catalogue edit do not want the same behaviour. The migration that introduced the queue has a device test, because that kind of change has to be proven on a real phone.
কোষাগার, the same library’s cash book
The treasury app, installed by about five people, the treasurer and the admins. It is a separate app on purpose, and the decision is written down: reading the library’s money is a member’s right inside the app they already have, and writing it is a treasurer’s job that deserves its own tool. Collection happens standing up in a room with no signal, so every write that moves money queues locally and reconciles later. The one exception is the opening balance, which is online-only, because a figure copied off a paper register should fail in front of the person copying it, not silently afterwards. Charts are drawn on a Compose canvas, with no charting library, to stay inside a 4.6 MB app budget.
The backend and the two web apps
Both apps talk to a Laravel backend I built for the library. It serves six hostnames from one codebase, among them the API, an APK download host and two installable web apps whose service workers are written without a PWA toolchain: a network-first app shell, an offline fallback and cache versioning on redeploy. One domain glossary is binding on the backend, the web apps and both Android apps, so the bare word balance does not appear in the code, because it means two different things depending on who is carrying cash. I wrote it up in Building a library system for phones that lack a Bengali font.
The office egg club
The one I vibe-coded, as a fun project when AI coding tools launched. The office egg club needed a ledger: who ate, who paid, and who is sponsored. I rebuilt it from a PHP app as React on Vercel with serverless functions over Supabase Postgres, installable on a phone. The balance is computed from the ledger on every request rather than stored, so a bug cannot leave a stale number behind. It still went wrong once. PostgREST caps every read at a thousand rows and still returns 200, so when the ledger outgrew the cap, the balance engine read a truncated history and billed sponsored members for eggs that were free. The fix was a paged read helper and a test that fails on any unbounded query.
Things you can open.
The agents’ code is private. These you can open right now.
- Next Term. A free, open-source macOS terminal and editor for running coding agents side by side, and a local MCP server one agent can use to run the others. Source on GitHub.
- MCP server. A read-only Model Context Protocol server that answers questions about me. Spec-compliant, with no model in the loop: every answer is a hand-written constant or a post I published, so it cannot invent a detail about me.
- Madan Mohan Library. The library’s public site. The member app and the treasury guide are in Bengali, the guide mostly screenshots.
- Building a library system for phones that lack a Bengali font. How the backend, the web apps and the two Android apps fit together, on Writing.
-
Laravel Telescope, slow-query filter.
Merged November 2021. Ten lines that added an
isSlowQuery()entry method, so filtering slow queries is one readable call instead of a check on the entry’s type and content. I documented it in the Laravel docs. - WordPress.org profile. Two plugins in the official directory, 2017 and 2018, in my first year of professional engineering.
- CV. As a PDF, and as markdown at /cv.md.
- GitHub
Working with me.
I work asynchronously by default, from Dhaka on UTC+6, and have done it for real: 18 months fully remote for a US employer about 11 time zones away. I write decisions down as decision records, so the reasoning does not depend on who was in the room.
The roles that fit are senior or lead on the individual-contributor track: agent and platform engineering at a product company running real infrastructure. Not engineering management.