Five ways to write code: how to choose the right workflow

In the last year, our approach to building with agents has evolved a lot. We now know there’s no one best way to build a feature or fix a bug with coding agents, and choosing the right workflow depends on the task at hand.

In a previous post on the EM role, I described how our engineering team is changing as it integrates AI into the workflow. Instead of assigning four engineers to a task, one or two engineers working with an agent and a PM can oversee a project end-to-end.

With total ownership over their work, engineers can choose the right workflow for themselves and their projects, whether that’s working locally with Claude Code, Codex or Cursor, delegating to Seapoint Coding Agents (SCA)*, or applying a combined approach.

*SCA is our hosted coding and review platform. It runs on a desktop in our office, and engineers can assign work to hosted agents from their local development environment or via Linear.

Choosing the right workflow

Complexity increases from left to right. Ambiguity increases from bottom to top. The examples suggest a starting point for choosing a workflow.

To decide which workflow is best for the task at hand, we first need to look at how complex the work is and how much uncertainty exists.

Engineers can take one of the following paths:

• Fully delegate to SCA
• Plan locally and delegate to SCA
• Plan locally, build locally
• Prototype first
• Take control of SCA work

If a simple, well-defined change is needed, we can easily offload to SCA. If the implementation is straightforward but there’s ambiguity – for example, reproducing a customer-facing bug – we can plan locally, go back and forth until the ambiguity is resolved before handing over to an agent. When both the problem and the approach are unclear, a prototype helps us work out what to build.

1. Fully delegate to Seapoint Coding Agents

Fully delegating to a Seapoint Coding Agent works well when we can describe the current behaviour, the desired behaviour and how we’ll check the change.

Here’s how it works:

• Delegate a ticket to SCA in Linear.
• The agent proposes a plan and waits for approval.
• Once approved, the agent builds the change, runs the verification steps and opens a draft pull request with a live preview.

A small validation change or a clearly reproduced bug fits this approach well. You can run the agents in the background and return to review the code and try the result before shipping.

2. Plan locally, build on SCA

Sometimes, we need to work through a problem before we can delegate it to SCA. In these cases, we start by planning locally.

To start, an engineer works with a local coding agent to examine production evidence, look at designs and settle the scope. When there’s enough context and a well-defined execution and test plan, SCA takes over.

This approach can be useful, for example, when the cause of a bug is unclear, as the investigation needs an engineer’s judgement. When we know what’s wrong and what the fix is, we can then hand over to an agent.

3. Plan locally, build locally

Sometimes, an engineer needs to stay involved throughout the build. In these cases, we use a local workflow that runs from planning through to pull request, using Claude Code or Codex.

Planning locally and building locally is best used when the work involves a lot of different decisions, local tools or credentials, or if something is being investigated at the implementation stage. With an external API integration, for example, each stage can reveal something about the provider that changes the next step. Sometimes, engineers just want a fast feedback loop to iterate on changes.

4. Prototype first

Some tasks don’t fit into a Linear ticket and aren’t suited to a well-defined plan at the start. Engineers could be exploring new ideas, investigating a bug, integrating with an alternate SaaS provider or API, and so on.

Our prototype workflow gives us a running version of the app, deployed in a container, at a shareable URL that works across our internal VPN. Product and design can try it while the engineer makes changes, giving us something concrete to discuss before we commit to an approach.

The prototype helps us decide what to keep, change or discard. From there, we can plan and build locally or delegate the work that is clear.

5. Take control of SCA work

Even if an agent has already started working, an engineer can always take over.

We often find that an agent gets most of a change right, with a few details left to address in review. An engineer can connect to the agent’s development environment, inspect the running app and edit the existing work.

Sometimes the changes needed are too small to justify switching branches locally. In these cases, engineers can connect to the agent’s environment and make those edits without disrupting their current local work.

Since this path can apply to any SCA workflow, it doesn’t need its own matrix quadrant. You can delegate a task, try the preview and take over when judgement is needed.

Shared expectations, different ways of working

All five paths draw on shared engineering guidance, agent skills, verification workflows and pull request review. Even if a build has been delegated to SCA, engineers still own the projects and need to check the change does what’s intended.

We’re still learning which paths work best for different tasks, and adoption across the team is uneven. For us, the useful lesson is to give engineers options, share what works, and let them change their approach as they learn.