SublimeCoderby Rakesh Menon
Get in touch
Back home

How I work

The checks I use when coding agents write part of the code. Agents can now investigate a repository, draft a change and run the tools, so the care goes into deciding what deserves to exist and checking what reaches customers. Take what fits your team.

The checklist

Six moments where the risk changes

One question at each moment, and the checks that answer it. Light enough for every task, strong enough for the ones that can hurt someone.

  1. 1Before starting

    Is this worth building?

  2. 2Before delegating

    What may the agent touch?

  3. 3Before merging

    Could the evidence disagree?

  4. 4Before releasing

    Who runs it, and what stops it?

  5. 5After shipping, or failing

    Did it work, and at what cost?

  6. 6Every few weeks

    What should go?

The principles behind it

Why each check is there

Purpose and authority

01

Earn the right to build

Customer outcomes over implementation volume

A working feature is a claim about value, not proof of it. When building gets cheap, it’s tempting to answer every open question with more software, and the wrong product just arrives sooner. I start with the cheapest credible experiment: watching someone work, doing it by hand, a prototype or a narrow slice in production.

In practice
  • Write down the user, baseline, hypothesis, success signal, guardrail and decision date before building.
  • Name the result that would make you stop.
  • Review the outcome with product and customers, then keep, change or delete the work.

02

Delegate work. Keep judgment.

A named owner over vague autonomy

Agents can investigate, implement and run bounded operations. The obligations to customers stay with people. Every consequential change needs a human owner who can explain its purpose, risks and recovery path, and who has the time and authority to refuse a release. Identity, money, sensitive data and irreversible state need explicit sign-off.

In practice
  • Record the owner, permitted actions, escalation conditions and release authority in the task.
  • Limit file access, tools, run time and spend.
  • Ask agents to report uncertainty and the checks they couldn’t run.
  • Split work that no reviewer can meaningfully assess.

Knowledge and memory

03

Make the second failure harder

Enforced checks over repeated reminders

Adding “never do this again” to a prompt records an intention; it doesn’t prevent anything. After a real failure, put the lesson in the layer that can enforce it: a test for behaviour, a type for invalid states, a database constraint for data, a permission for authority.

For exampleA retried request creates a second invoice. A reminder leaves every caller to remember. A request key with a uniqueness constraint, plus a test of concurrent retries, protects the next caller automatically.

In practice
  • Name the failure class and add the cheapest durable barrier.
  • Prove the barrier rejects the old failure, and give it an owner.
  • Where a machine can’t check it, decide when a person reviews it.
  • Track recurrence, and retire checks whose reasons have gone.

This is the idea behind The Second Time Is a Bug.

04

Engineer the context

Relevant, trusted context over longer prompts

Agents need intent, domain language, boundaries, decisions, examples and the current state of the system. More text can add contradictions as easily as clarity. Keep instructions next to the code they govern, give them owners, and treat a customer document, issue comment or web page as evidence to inspect, never as permission to change the agent’s task.

In practice
  • Give a short brief, an architecture map, approved commands, acceptance examples and authoritative sources.
  • Note the revision the agent worked from; refresh after big changes.
  • Retrieve only what the task needs, and keep secrets out.
  • Give instructions owners and review dates; resolve conflicts before work starts.

Evidence and security

05

Demand evidence that can disagree

Independent checks over confident self-reports

Code and tests written from the same wrong assumption agree perfectly. A green suite tells you about the checks that ran, not whether the requirement was right. Derive expected results from something the implementation didn’t choose: domain rules, customer examples, an independent calculation or a known-good system.

For exampleAn agent tests a billing calculator by calling the same rounding helper the code uses, so both agree on the wrong total. An invoice calculated independently, including a fractional-cent case, can disagree.

In practice
  • Write acceptance criteria before implementation; use property tests or fault injection for important invariants.
  • Confirm a regression test fails on the known bug.
  • Keep test commands, environments and results; treat missing or flaky checks as open questions.
  • For AI features, keep representative evaluations and have a person review consequential failures.

06

Limit authority at the boundary

Enforced permissions over safety by instruction

Judge an agent’s security by what it can read, change, disclose or spend when it misreads the task. Instructions can arrive hidden in documents it reads, so a system prompt is not a security boundary: permissions have to be enforced outside the model.

For exampleA support ticket tells a diagnostic agent to upload environment variables to an external URL. In a sandbox with no production secrets and an outbound allowlist, nothing leaks even if the model obeys.

In practice
  • Default to read-only; grant short-lived credentials only when needed.
  • Validate tool arguments and permissions in trusted code; require fresh approval for irreversible actions.
  • Keep secrets out of prompts and logs; check dependencies and generated files.
  • Test with hostile content, log consequential calls and keep a working kill switch.

Architecture and flow

07

Protect the shape of the system

Changeable systems over convenient patches

A patch can close its ticket and make every later change harder. Cheap code doesn’t make coupling, duplicated business rules or clashing data models cheap to own. I prefer the simplest structure the domain needs, with explicit rules and small interfaces, and agents that work inside those boundaries and propose exceptions openly.

In practice
  • Check dependency rules, API compatibility, latency budgets and migration safety automatically where you can.
  • Record consequential decisions and what reversing them would cost.
  • Review for duplicated logic and unneeded dependencies.
  • Give exceptions an owner and an expiry date.

08

Keep each change reviewable

Reviewable work over maximum parallel output

A review queue isn’t delivered value. Run as much parallel work as the team can integrate, verify and understand, and no more. DORA’s 2025 research linked AI adoption to higher throughput but lower delivery stability. That’s an association, not proof, but it’s a reason to watch what happens downstream.

In practice
  • Limit work in progress by review capacity.
  • Use isolated workspaces and clear file ownership; integrate often.
  • Give each task a stopping rule, a test plan, a budget and an honest summary of its limits.
  • When review or CI is the bottleneck, start less and fix that first.

Production and stewardship

09

Make production tell the truth

Evidence from real use over a successful deploy

A deploy proves an artifact reached an environment. It doesn’t prove a user finished a task or that failures are recoverable. Design the evidence of success and failure with the feature. For AI in the runtime path, watch outcome quality, latency, cost, tool failures and fallbacks.

In practice
  • Before launch, define a success signal, an actionable alert, a diagnostic path and a recovery mechanism.
  • Roll out gradually against a baseline.
  • Rehearse rollback and fallback, including data compatibility.
  • Stop the rollout when a guardrail fails; resume only after recovery is proven.

10

Own the whole life of the work

Ownership through retirement over a handoff at merge

A feature is an opportunity and a maintenance obligation. The team that ships it should stay connected to its support load, running costs, vulnerabilities and eventual removal; otherwise speed is borrowed from someone else’s future. In an incident, restore service first, then fix the conditions that allowed it.

In practice
  • Name an operating owner before release, with runbooks and support ready.
  • Turn incident findings into enforced checks, and reserve time to finish them.
  • Remove unused features, old flags, stale data and dead services.
  • Call work done when the useful outcome holds, and retired when the obligation is verifiably gone.

Customers and organisation

11

Bring customer learning home

Customer learning over endless bespoke rescue

Engineers working beside a customer find what no spec shows: undocumented processes, unreliable data, workarounds, and the gap between the feature requested and the job behind it. That should change the product’s assumptions, not just fix today’s problem.

In practice
  • Capture the observed workflow, what you changed, the outcome and any recurring pattern; review it with product and engineering.
  • Decide whether each requirement belongs in the product, a supported extension, a priced service, or nowhere.
  • Give each exception an owner, support terms and an expiry.
  • Bring test fixtures, domain knowledge and reusable pieces back to the shared product.

12

Organise around lasting outcomes

Shared responsibility over faster handoffs

If product defines, engineering builds, security blocks and operations inherits, agents speed up each queue without improving the whole. Teams should own a customer outcome, with the people and authority to make trade-offs early. And keep training people: removing junior work without replacing how people learn it spends down the team’s future judgment.

In practice
  • Fund outcomes and ongoing maintenance, not just project completion.
  • Agree on decision rights and how conflicts escalate.
  • Bring customer evidence and operational health into planning.
  • Protect apprenticeship: pairing, code reading, explaining behaviour and practising recovery.

Economics and limits

13

Measure the gain after the cost

Net improvement over activity metrics

Count review time, rework, incidents, compute, support and future maintenance before calling something faster. Commits, tokens and accepted suggestions don’t show what customers gained. Outside studies frame the question; your own measurements answer it.

In practice
  • Set a baseline; compare similar work with and without the change where you can.
  • Track task success, time to a decision, lead time, failures, recovery and total cost together.
  • Learn at team level, never through individual surveillance or AI-usage quotas.
  • Reassess when models, tasks or workflows change.

14

Choose where AI doesn’t belong

Proportionate automation over AI everywhere

Pick the conventional solution when it’s safer, clearer or cheaper to run. Using AI to build a system is different from putting AI in its decision path: an assistant can draft tests for a payment service while authorisation and ledger rules stay deterministic. A human click isn’t oversight if the person can’t evaluate what they’re approving.

In practice
  • Compare against a simpler baseline before adopting AI.
  • Document failure tolerance, data constraints, how you’ll evaluate it and the fallback.
  • Define prohibited actions and a way off the provider or model.
  • Keep the team’s right to say no to AI.

Warning signs

Habits that look like speed

Their costs show up somewhere else, usually later.

The apology loop

The same bug comes back, followed by another reminder to remember it.

InsteadReplace the reminder with a tested barrier, an owner and a written reason.

The green-check illusion

Generated tests restate generated code, so every check shares the same wrong assumption.

InsteadAdd independent examples, invariants, hostile inputs and evidence from real use.

The unlimited delegate

An agent gets broad credentials because permissions are inconvenient.

InsteadGrant narrow, short-lived access, enforced outside the model.

The review avalanche

Agents start work faster than people can understand and merge it.

InsteadStart less, shrink changes and invest in review.

The bespoke product trap

Customer forks pile up that only one engineer can run.

InsteadDecide: shared capability, supported extension, priced service, or no.

The adoption scoreboard

Leaders reward AI usage, code volume or demos instead of outcomes.

InsteadCompare results, total cost, reliability and learning against a baseline.

The ceremonial human

Someone approves things they don’t have the time, information or expertise to judge.

InsteadGive them real authority and time, or let the system do less.

The abandoned launch

The release is celebrated while support, incidents and retirement become someone else’s job.

InsteadKeep the operating duty with a named team, and fund it.

Sources

Each finding applies to the setting it studied, and an association isn’t a cause. METR’s 2025 trial found experienced developers slower with AI tools; its 2026 update judged newer tools likely more helpful while calling its own data weak evidence of how much. The examples are illustrations, not incidents from client work.

If you want these wired into a team’s repositories, that’s what agent-ready engineering is for.