The Single-Engineer Stack Problem: Sequential, Parallel, or Orchestrated?
The boring premise
Let’s get the obvious part out of the way: at Opply, one engineer owns both ends of a feature. Backend, frontend, migration, types, tests, Storybook, the deploy. The “FE specialist” / “BE specialist” split belongs to a previous era — it made sense when shipping a serializer was half a day of typing and shipping a React form was another half-day. With AI doing the typing, holding both ends in your head is no longer the heroic move; it’s the default.
That’s not the interesting part of this post. That’s table stakes.
The interesting question — the one we actually argue about — is this:
Given that one engineer owns the whole feature, how do they actually do the work?
Before we even get to implementation
One thing worth saying up front: the story and the plan are AI-built too.
The engineer writes the ticket in an AI-assisted session. They write the plan the same way: anchored in the codebase, producing a plan stored locally. They write RFCs the same way when needed.
By the time implementation starts, there have already been multiple AI-assisted sessions producing structured artefacts.
This matters because:
- The work is already decomposed before coding starts
- The handover artefacts required for parallel work already exist
So new sessions don’t start from scratch. They start from a plan.
The four ways to do the work
There are only a few viable models:
1. One session, sequential
Do everything in a single session, step by step.
→ Simple, but context degrades and everything slows down.
2. Chunked, fresh sessions
Split the work into slices and run each in a new session.
→ Cleaner, more reliable, but still sequential.
3. Parallel sessions
Run independent slices at the same time.
→ Faster, but only if seams are clearly defined upfront.
4. Orchestrator + workers
One session plans and reviews; multiple short-lived sessions execute scoped tasks.
→ Scales best for larger work by keeping context clean and responsibilities separated.
We use all four — depending on scope.
What actually matters
The model you pick is not the interesting part.
The interesting part is what skill is being exercised when you use them.
Because once one engineer owns the full stack, and AI removes most of the implementation cost, the bottleneck shifts.
Not to coding.
To scheduling.
The real skill
The valuable skill is no longer writing code faster.
It’s structuring work so that code can be produced reliably by small, disposable execution units.
That shows up in very concrete ways:
- Task decomposition
Can you split work into genuinely independent slices? - Seam design
Can you define contracts before implementation starts? - Handover quality
Can a fresh session succeed from your plan alone? - Context management
Do you know when a session has gone stale? - Parallelism control
Can you run multiple threads without overwhelming review capacity? - Stopping discipline
Do you know when planning is “good enough”?
These are not new skills.
They are the same skills used to manage a team of humans:
- breaking down work
- defining interfaces
- coordinating parallel efforts
- reviewing outputs
The difference is the team is now a set of short-lived AI sessions, and the feedback loop is measured in minutes.
What we actually do
In practice:
- Small tasks → one clean, scoped session
- Normal features → a few parallel sessions
- Larger work → a persistent planning session coordinating execution sessions
The details vary, but the principles don’t:
Keep sessions small
Design seams early
Separate planning from execution
Treat context as a limited resource
The real shift
The shift isn’t that engineers can now do full-stack work.
The shift is that implementation is cheap, and coordination is not.
And once coordination becomes the dominant cost, the role of the engineer changes.
They become a:
- planner
- orchestrator
- dispatcher
- reviewer
That’s the part worth getting good at.
The code is just the output.
The operating model is the real artefact.
