I've been noodling on how to make agentic coding less about dry prompting and constant manual guidance, and more like an actual system that can operate on its own.

A lot of people are already doing some of this. In some repos. With some agents. Sometimes.

That's not really the problem anymore.

The question is how we get everyone doing these things everywhere, all the time, automatically, without every developer having to invent their own workflow, train every agent from scratch, and remember twelve bits of ritual before starting a task.

The agent itself is only part of the system. The repo, documentation, tests, tooling, review process, task queue, and handoff state all matter just as much. Probably more.

The goal isn't a better prompt. It's an environment where the agent has enough structure to do good work without being babysat.

Self-healing docs for every system

Agents should own keeping system documentation current.

Point them at the docs you know matter, or let them discover the right ones through AGENTS.md. Every system doc should start with a detailed, greppable summary. Every system doc should also be indexed from AGENTS.md so agents have one reliable place to begin.

The hard part isn't writing docs. The hard part is keeping them attached to reality.

That means documentation changes happen alongside code changes, not six months later during a cleanup sprint nobody wants to do. Reviewer personas can help here too. If a security reviewer owns the authentication docs, part of its review is checking whether those docs still describe the system that now exists.

Documentation becomes maintained state, not reference material we vaguely hope is still true.

Agents run the app

When there's an app, the agent runs it. No exceptions.

It shouldn't stop at editing files and watching unit tests turn green. It should start the real application, exercise the changed behavior, observe what breaks, and fix problems while the implementation context is still fresh.

This matters even more during autonomous or async work. Nobody is sitting there to notice that the build technically passed while the actual screen is blank, the API contract drifted, or the happy path now requires clicking a button twice.

If an agent can't run the system it's changing, that's an infrastructure problem we should fix. Not an acceptable limitation of the workflow.

End-to-end and Pact tests that stay current

Tests need their own maintained documentation.

Document how to write them, what to avoid, and what every existing test actually covers. General rules belong in agent-rules. Service-specific conventions belong in repo-rules. Keep a running inventory in markdown so an agent can answer a basic question before changing anything: what behavior is already protected, and where are the gaps?

Agents should write and run targeted tests during implementation. If they improve an existing test while they're there, that improvement gets committed with the work. No separate test cleanup backlog where good intentions go to die.

Contract tests matter here too. Pact or an equivalent gives agents a concrete boundary between services instead of asking them to infer one from code, stale docs, and optimism.

Custom pre-commit linters

Anything we can enforce mechanically should be enforced mechanically.

Catch problems at pre-commit while the context is still loaded. Use --fix wherever possible. If a problem can't be fixed deterministically, shell out to a cheaper model like Composer or Sonnet and have it fix the code.

A linter that only tells the agent it did something wrong is useful. A linter that repairs the problem is a system.

This is also where coding conventions should end up whenever possible. Humans and agents shouldn't have to remember rules a machine can enforce.

Cross-agent and adversarial review

Research, planning, implementation, and wrap-up should each get reviewed.

Mix models across the process so Claude, Cursor, Codex, or whatever else we're using isn't grading its own homework. Different models notice different failure modes. That's useful. Treat it as a feature instead of trying to force one model to be researcher, implementer, critic, security reviewer, and final authority.

Reviews need explicit instructions. Document what a good review looks like and give reviewers specific personas:

  • Maintainability
  • Code quality
  • Security
  • Performance
  • AI smells
  • Domain-specific concerns, such as financial services

Each persona should own relevant system docs and verify them during review. We can standardize the mechanics through agent-rules and Unblocked so teams aren't rebuilding the same review choreography in every repo.

The point isn't more ceremony. It's to make skepticism automatic.

Agent traces and worksheets

Every agent session should leave a worksheet behind.

What did it investigate? What decisions did it make? What changed? What remains uncertain? What failed? What should happen next?

If an agent dies halfway through, another agent should be able to pick up that worksheet and continue without reconstructing the session from git history and vibes.

Commit worksheets with the work. Tag commits with matching worksheet names so the full trail is easy to recover later. Those traces become useful context for future changes, reviews, audits, and debugging.

This isn't about recording every token. It's about preserving enough state for continuity.

Automatic feedback at session end

At the end of every session, the agent should record what worked, what didn't, and where the workflow got in its way.

Commit that feedback with the work. Then periodically review it and improve the system.

Otherwise we've built a diary nobody reads.

The interesting part is aggregation. One agent struggling with a setup step might be noise. Twenty agents struggling with the same setup step means the workflow is broken. We should be able to discover that without waiting for a developer to get annoyed enough to file a ticket.

A shared tools/bin folder

Give agents a place to build small Python or Bash tools that make future work easier.

Maybe it's an agent_review command that launches the right reviewer through a consistent interface without every agent remembering model-specific CLI syntax. Maybe it's a script that starts all local dependencies, captures screenshots, compares benchmarks, or validates docs.

Document how to write useful scripts. Keep expanding the toolkit when repeated work appears.

This is one of the compounding parts of the system. The agent shouldn't just complete today's task. It should leave the environment slightly better equipped for tomorrow's task.

Periodic sweeps across recent commits

Individual commits can all look reasonable while the system slowly drifts into something cursed.

Run periodic reviews across batches of recent changes. Look for duplicated patterns, inconsistent abstractions, performance creep, documentation drift, test gaps, and architectural decisions that only become visible when viewed together.

Pull requests are good at answering “is this change acceptable?” They're less good at answering “what direction have the last thirty acceptable changes taken us?”

We need both views.

Project-specific coding conventions

Every repo needs one clear source of truth for conventions that can't be enforced automatically.

Review agents should use it. Implementing agents should update it when a real convention emerges. Anything that can move into a formatter, linter, type system, or test should move there instead.

The doc is for judgment calls. The tooling is for rules.

Mixing those together creates a long style guide everyone ignores and a review process full of comments that should have been compiler errors.

The agent loop, or “night shift”

Autonomous work needs a defined orchestration loop.

How is work selected? What context gets loaded? When does research stop and planning begin? Which checkpoints require adversarial review? How is progress recorded? What validation must pass? What state has to exist for another agent to continue safely?

Package that into a skill instead of relying on a heroic prompt.

A night shift agent should be boring. It picks up known work, follows a predictable loop, records its state, validates the result, and leaves the branch clean. Boring is good. Boring means we can trust it while we're asleep.

An accessible task queue

Agents need a reliable place to find work and update its state.

That could be TODOS.md. It could be Linear or Jira with a usable CLI and API. The specific tool matters less than the interface.

An agent should be able to discover available tasks, understand priority and dependencies, claim work, post progress, and leave enough context for whoever comes next.

If the task queue only works through a web UI and tribal knowledge, it isn't accessible to the system we're trying to build.

False-confidence test audits

A passing test suite can still be lying.

We need a periodic audit skill that looks for tests that don't prove what we think they prove. Tests with meaningless assertions. Mocks that bypass the behavior under test. Snapshots nobody reads. Browser tests that pass because they never reached the right page. Contract tests pinned to the wrong thing.

Find them and fix them.

Green is only useful when it's attached to reality.

Visual regression tests

For UI work, capture screenshots and compare them with tooling and agent visual review.

Commit the artifacts with the work using Git LFS, or attach them to the pull request. Give reviewers the before and after state instead of asking them to infer visual behavior from JSX and CSS.

“The DOM looks right” is not the same as “the UI looks right.”

Agents are increasingly capable of evaluating images. We should use that capability as part of normal validation, not as a special demo.

Automatic performance benchmarks

Run repeatable benchmarks and flag meaningful regressions automatically.

Performance shouldn't depend on somebody noticing that the app feels slower three releases later. Define the critical paths, measure them consistently, store baselines, and make regressions visible during the work that caused them.

Not every change needs a full laboratory. It does need enough measurement to catch obvious damage.

Profiling tools agents can actually use

Give agents tools for targeted benchmarking, comparing implementations, and reading profiles.

If performance is part of the decision, the agent should measure it instead of guessing. That means making profilers scriptable, documenting common workflows, and producing outputs an agent can inspect and compare.

“Seems faster” is not data. It's barely a sentence.

End-of-shift full validation

Before autonomous work wraps up, run the whole validation loop:

  • Full test suite
  • Contract and end-to-end tests
  • Visual regression checks
  • Performance benchmarks
  • Cross-agent reviews
  • Recent-change sweeps
  • Documentation checks
  • Worksheet and feedback completion

The goal is simple. When a developer comes back, the branch should be clean, understandable, and ready to continue. No archaeological dig required.

This is an environment problem

I think we spend too much time trying to make agents better through prompting alone.

Prompts matter. Models matter. But the bigger opportunity is building an environment that makes the right behavior automatic.

Good agents need the same things good engineers need: current documentation, executable systems, useful tests, clear conventions, good tools, skeptical reviewers, visible work, and a reliable way to hand off state.

The difference is that agents can follow these systems with relentless consistency once we standardize them.

That's the part I'm interested in. Not whether one person can get a great result from one agent with one carefully constructed prompt. We already know that's possible.

The real question is whether we can make that quality repeatable across teams, repos, models, and sessions without requiring everyone to become an agent whisperer first.

That's when agentic coding stops being a clever interface and starts becoming infrastructure.