Skip to main content

4 posts tagged with "agentic-engineering"

View all tags

The ADR Your Agent Never Read

· 10 min read
Tian Pan
Software Engineer

Your team rejected the microservices split in 2024. There was a two-hour meeting, a heated Slack thread, and a spreadsheet comparing operational costs. The conclusion was firm: the monolith stays until the platform team ships multi-region deploys. Everyone who was in the room still remembers.

Your coding agent was not in the room. Last Tuesday it proposed the split again — confidently, with a clean migration plan and a well-argued design doc. The Tuesday before that, a different agent session proposed extracting the billing service. Next week, a third one will suggest replacing your bespoke job queue with the message broker you evaluated and rejected twice. None of them are wrong on the merits as they can see them. They just can't see the merits, because the reasoning that settled these questions lives in a Slack thread that expired, a meeting that wasn't recorded, and the heads of two engineers, one of whom left.

This is the quiet failure mode of agent-assisted engineering: settled questions get re-litigated at machine speed. And the fix is a practice most teams filed under bureaucratic nice-to-haves a decade ago — the architecture decision record.

Two Writers, One Working Tree: Concurrency Control for Human-Agent Co-Editing

· 10 min read
Tian Pan
Software Engineer

You are halfway through renaming a function when the file reloads under your cursor. The diff you were staging no longer matches the working tree. Your dev server hot-reloads twice for no reason you can see, and a test that passed ten minutes ago now fails in a file you never opened. Nothing crashed. Nothing warned you. You and your coding agent have just been editing the same working tree at the same time, and you found out the way most teams find out: through mystery diffs.

Databases solved this problem fifty years ago and gave it a name — concurrency control. Two writers touching shared mutable state need either a lock, an isolation boundary, or a merge protocol, and the choice among those is a design decision with known trade-offs. Yet most engineering teams adopting coding agents never make that decision explicitly. They drop a second writer into a single working tree, keep the habits of a single-writer world, and then file the resulting weirdness under "AI being flaky." It is not flakiness. It is a race condition, and you are one of the racers.

The AI Standup Where Yesterday's Status Is a Lie

· 9 min read
Tian Pan
Software Engineer

The team meets at 10am. The first engineer reports what their agents finished overnight. Except the eval suite that kicked off at 7am hasn't returned, the PR the agent opened at 3am is waiting on a review from another agent whose queue depth is unknown, and the long-running refactor agent is on hour eleven of an estimated four-hour run with no signal that it's stuck and no signal that it's healthy. Yesterday's status is not "done" and not "in progress." Yesterday's status is unknowable from inside the room.

The standup was a synchronous ritual built for synchronous human work. Each person did a thing, finished it, slept on it, and reported it the next morning. The unit of work was a workday. The unit of reporting was a person. The cadence matched the substrate. None of that holds anymore. The unit of work is now an agent run that started before you went to bed and may finish during the meeting or three hours after. The unit of reporting is a fleet, not a person. And the cadence — a 9- to 15-minute round-robin at 10am sharp — is a frequency the substrate doesn't produce events on.

The PR-Bot That Never Sleeps: When Your Reviewers Become the Rate Limiter

· 11 min read
Tian Pan
Software Engineer

For two decades the bottleneck in software engineering was writing code. We optimized IDEs, autocompletion, refactoring tools, and frameworks to make typing cheaper. We won. Now the bottleneck moved one step downstream: writing is cheap, and reading is expensive. The PR-bot can spin up ten implementation attempts in parallel and open ten pull requests against your repo before you finish your morning coffee. Your reviewers cannot.

The rate limiter for AI-assisted software delivery is no longer the model's tokens per second. It is the number of human eyes you can put on a diff per day. And when those eyes get overwhelmed, you do not get a graceful degradation — you get rubber stamps. Code merges with LGTM 🚀 on top of code that nobody actually read. A senior engineer approves an AI-written patch that another AI tool already reviewed, and three weeks later a data-inconsistency bug eats forty hours of someone's life. Surface correctness is not systemic correctness, and a green pipeline is not understanding.