Agentic engineering under the hood
Everyone has an AI assistant in their editor by now. We built a way of working around it. A technical look at how agents write, test and review code at Foreside, and why the guardrails matter more than the model.
From autocomplete to agents: a different kind of tool
The first generation of AI tooling completed your sentences. Useful, but it was still typing with a turbo. The current generation works differently: an agent takes an assignment, reads the codebase itself, runs commands, writes code, executes the tests and comes back with a result. The difference is the loop. Where autocomplete makes one suggestion, an agent iterates until the tests are green or it hits something that requires a decision.
That sounds like magic, but it is mostly systems engineering. An agent is a language model in a loop with tools: reading and writing files, a terminal, a search function. The quality of the result is determined by what you feed that loop and which boundaries you set. That is exactly where our craft lives: not in the model, but in everything around it.
Context is the real engineering problem
A model knows nothing about your project until you tell it. Everything the agent needs has to pass through a limited context window: the assignment, the relevant code, the conventions, the pitfalls. Shove an entire repository in and you get an agent drowning in noise. Give it too little and you get confident code that works right past the actual problem.
So we optimise our codebases for machine readability, and that turns out to be remarkably similar to human readability. Small files with a single responsibility. Conventions described in one place, in plain language, including the why. Names that say what something does. A project memory that holds the agreements you would otherwise keep in people's heads. Every project gets such a constitution, and the agents read it on every task.
Guardrails: speed without debt
The risk of agents is not that they write bad code. The risk is that they write a lot of plausible code, faster than you can review it. Without guardrails, acceleration mostly means building technical debt faster. Our first rule: the agent proves its work. Tests first where possible, and a change is only done when the full gate is green: build, linter, test suite, and on critical paths a production smoke test.
The second rule: bounded permissions. Agents run in an environment where they cannot reach everything: no production data, no secrets, no direct deploys. Risky actions require explicit approval. And the third rule is the oldest in the trade: four eyes on every commit, at least two of them human. The agent may write, an engineer decides what lands on the main branch.
The pipeline: explore, specify, build, prove
One agent that does everything does not work well, for the same reason one person who does everything does not scale. We split work into roles. An explorer reads the codebase and reports how things actually stand, without changing anything. A specifier turns the approach into a plan with acceptance criteria. Builders execute. A verifier tests the result from the outside, the way a user or client would, and a validator reviews the work against our conventions.
Between those steps sit human decision points, exactly where a mistake is expensive: is the plan right, is the specification right, is the end result good enough. It looks like bureaucracy, but the opposite is true. Because every role has a sharp task, the steps can follow each other quickly and run in parallel. The lead time from idea to verified feature gets shorter, not longer.
Explorer
reads, changes nothing
Spec writer
plan with acceptance criteria
human decides
Builders
carry it out
Verifier
tests from the outside
Validator
checks the conventions
human decides
Measure that it works, don't feel that it settles in
The question every team must be able to answer: is this actually making us better? You do not measure that with a satisfaction poll. We look at the outcomes that matter to a client: how fast a change lands safely in production, how many incidents come out of new code, how much time goes to rework versus new work. Since we started working agentically those numbers move the right way, which is exactly why we dare to put them on our site.
Knowing where it does not work is just as important. Agents are weak on problems where the specification is the real work, in code with a lot of implicit context, and in decisions with consequences outside the codebase. Those boundaries shift every month, so we retest them every month. A way of working that leans on incantation instead of measurement is no longer engineering.
The technology is the easy part
Getting an agent running takes an afternoon. Building a way of working in which agents demonstrably deliver better software takes months of sharpening conventions, building guardrails and measuring. That is the investment we have already made for our clients. Curious what this would look like in your codebase?
Schedule a meeting