FredrinThe 2026 stack for a forward deployed engineer has four layers — discover, build, deploy, iterate — and three of them are genuinely well served. Discovery has matured, the build layer is crowded with good options, and deployment is close to solved for anything that is not air-gapped. The gap is the layer nobody set out to build: the work surface that tracks what all of it is doing across several clients at once.
This is a survey, so it names real tools including the ones we compete with. Fredrin claims exactly one layer, and we will mark it clearly when we get there.
What are the four layers?
| Layer | The question it answers | Maturity in 2026 |
|---|---|---|
| Discover | What does this client actually need? | Good |
| Build | How does the code get written? | Crowded, very good |
| Deploy | How does it run in their environment? | Good, unless air-gapped |
| Iterate | What happened, and what is next? | Good per client |
| Work surface | What is running across all of them right now? | The gap |
The first four are the layers every vendor sells into. The fifth is the one that only becomes visible once you are running more than two engagements, which is why it stayed unbuilt for so long.
What should you use to discover the problem?
Less tooling than you would expect, and the tooling is not the hard part.
For the customer's own environment, you mostly need read access and patience: their data warehouse, their logs, their existing integrations. The recurring surprise of the role is that the data model described in the sales cycle is not the data model that exists, and no tool discovers that for you — a query does.
Worth having:
- A notebook — Jupyter, Deepnote, or Hex — for exploring client data without committing to a shape too early.
- API exploration — Bruno, Insomnia, or Postman. Bruno's files-in-git model travels well between client environments.
- A diagram that stays current — Excalidraw or Mermaid checked into the repository. A diagram in a slide deck is dead within two weeks.
- A written decision log, started on day one. It is discovery output, not documentation overhead, and it is what stops the same question being relitigated in month three.
The mistake here is over-tooling. Discovery is constrained by access and by how many of the right questions you ask, not by software.
What are the build tools?
This is the crowded layer, and the honest summary is that several options are good and the differences are smaller than the marketing suggests.
Terminal agents — Claude Code, OpenAI's Codex CLI, Gemini CLI, and open alternatives like Aider and OpenCode. These fit FDE work well because they run wherever your terminal runs, including a jump box inside a client's network, and they leave the repository as the source of truth. If you work across client environments with varying restrictions, a terminal agent is the safest default.
AI editors — Cursor, Windsurf, Zed, and GitHub Copilot in VS Code. Strongest when you are personally in the code for long stretches, which describes a meaningful share of FDE work. Cursor in particular is very good at what it optimizes for; where it stops fitting is supervising several agents across several client repositories at once, which is a different problem and the one we compare directly in Fredrin vs Cursor.
Autonomous agents — Devin, and the newer generation of ticket-to-PR services. The bet is that you hand over a task and get back a pull request. In client work the constraint is usually not capability but permission: many clients will not grant a third-party service commit access, which decides the question before quality does. Our view on that tradeoff is in Fredrin vs Devin.
App generators — Lovable, v0, Bolt, Replit. Underrated for FDE work specifically, not for production but for throwaway artifacts: a clickable prototype that settles an argument in a requirements meeting in ten minutes. Building that by hand is a poor use of a day. Where they stop is the handoff into a real codebase, which is the honest boundary of the category and what Fredrin vs Lovable and Fredrin vs v0 discuss.
Practical advice: pick one primary and stay agent-agnostic in your workflow. The model landscape has re-ordered itself roughly annually, and any process that only works with one vendor's tool is a process you will rewrite.
How do you deploy into a client's environment?
You usually do not choose. The client has a cloud, a compliance posture, and a platform team with opinions, and your job is to fit inside them.
The realistic cases:
- They have a platform — you learn their Helm charts and their pipeline. Bring nothing.
- They have a cloud but no platform — Terraform or Pulumi, and leave behind something their team can operate without you.
- They want it fast and it is not sensitive — Vercel, Fly, Railway, Render. Excellent for the pilot that has to exist before the platform conversation can happen.
- Air-gapped — defense, some healthcare and finance. Everything changes: no external model calls, no external package registries, no telemetry. Establish this on day one, because discovering it in week six invalidates the architecture.
The durable advice for this layer is to optimize for what happens after you leave. A deployment only you can operate is a liability you handed to the client with a bow on it.
What does the iterate layer need?
Standard observability, with one FDE-specific wrinkle: you often cannot see it.
Sentry, Datadog, Grafana, OpenTelemetry — all fine, and usually the client's existing choice rather than yours. The wrinkle is that in many engagements the production telemetry lives inside the customer's boundary and you have no direct access. The workable answer is to instrument for their on-call rather than for your own curiosity, and to agree in advance how a problem reaches you. "The customer emails you a screenshot" is a real escalation path in more engagements than anyone admits, and it is worth replacing before the first incident rather than after.
What is missing?
Here is the part where we are not neutral, so treat it accordingly.
Every layer above is organized around one project at a time. The editor opens a repository. The deployment tool targets an environment. The observability dashboard shows a system. All correct, all single-subject.
Now hold five engagements at once, each with several streams of agent work in flight, and ask a question none of those tools can answer: what is running right now, and which of it needs me?
The status quo answer is a wall of terminal windows and personal memory. That works at two engagements. It degrades at four. At six it is the actual job — you stop being an engineer and become the scheduler, the message bus, and the state store for a set of very fast, very forgetful workers.
That missing layer is the work surface: the place where work is tracked as work rather than as windows. What it has to do is unglamorous:
- Give every unit of work its own branch, worktree, and agent session, so streams cannot contaminate each other.
- Show, at a glance, what is running, what is blocked on a question, and what is finished and waiting for review.
- Make review a place work sits, rather than something you remember to go looking for.
- Keep the decisions with the work, so context survives the weekend and the engagement.
This is the layer Fredrin builds, and deliberately the only one. It does not write your code — bring Claude Code, Codex, Cursor, or Copilot on the subscription you already pay for. It does not deploy anything. It does not replace your editor or your terminal. It is a desktop kanban where each ticket carries its own branch, worktree, and agent session, and its bet is that once code generation is cheap, the bottleneck is running, reviewing, and shipping what comes out.
The adjacent category worth naming honestly is the tracker. Linear is very good at coordinating what humans are doing; it has no notion of a branch that an agent is currently working in. That is not a defect, it is a different problem — the distinction is laid out in Fredrin vs Linear.
Do you need all of this?
No, and assembling the maximal stack is a way to avoid doing the work.
A defensible minimum for a working FDE in 2026:
- One terminal agent, used well.
- Git worktrees, so streams do not serialize behind one branch.
- A conventions file and a decision log in the client's repository.
- Whatever the client already uses for deployment and observability.
Add a work surface when you can feel the visibility problem — which for most people arrives somewhere between the third and fifth concurrent stream, not before. Adding it earlier is overhead in search of a problem.
What does the tooling cost?
Less than the time it saves, but the shape of the spend matters more than the total.
For a reference point, Anthropic publishes its own enterprise numbers for Claude Code: around $13 per developer per active day and $150–250 per developer per month, staying under $30 per active day for 90% of users. Other vendors are in a broadly similar range. Against a loaded engineering cost, that is not the number to optimize.
The economics that changed recently: a flat-rate coding subscription costs a fraction of metered API usage for the same volume of work, which is why bring-your-own-subscription has become the default arrangement for tools that orchestrate agents rather than resell tokens. If a tool marks up tokens, you are paying twice for the same capability — once to the model vendor and once for the wrapper. Check which arrangement you are in before you scale up usage, because the difference compounds quietly.
For client work specifically, confirm who is paying and whose account the work runs under before the first ticket. It is an awkward conversation in month one and a genuinely bad one in month four.
FAQ
What is the single most important tool for an FDE? The client's own codebase and their access to it. Everything else is downstream, and no stack compensates for insufficient access.
Terminal agent or AI editor? Terminal agent if you work across restricted client environments or supervise several streams at once; editor if you spend long stretches personally in one codebase. Many people run both, and that is a reasonable answer rather than indecision.
Is it worth learning a specific agent deeply? Learn the workflow deeply, the tool shallowly. Worktree isolation, small diffs, and written acceptance criteria transfer to whatever ships next year. Vendor-specific configuration mostly does not.
How do I handle clients who ban external AI tools? Get the boundary in writing and find out which ban it is — sending code to a third-party provider, or generated code in the product. They are different rules. Some clients permit a self-hosted or in-VPC model, which changes the answer entirely.
Do I need a work surface if I run one engagement? No. One engagement with one or two streams is well served by a terminal and git. The problem this layer solves is genuinely a multi-stream problem.
Where do I start if I am new to the role? The role breakdown for the shape of the job, the interview guide if you are still hiring in, and the parallel workflow post once you are running more than one thing at a time.
Fredrin is a desktop kanban for running many AI coding agents in parallel — every ticket gets its own branch, worktree, and agent session, on the AI subscription you already pay for. Free on macOS and Windows: fredrin.com.
