Some months ago we published our thesis on the Forward Deployed Engineer: as AI automates more of the mechanics of software, the person who can sit with a customer, understand their business, and turn AI into real value becomes more important than ever. We still believe that. The implementation gap is real, it is where most enterprise AI projects quietly fail, and closing it is human work.
What has changed is our view of how that work should be staffed. Over many engagements we watched a pattern emerge that we want to name plainly, because naming it is the first step to fixing it. The FDE, as the industry has come to define the role, has drifted into something close to a mythical figure: one person expected to be a strong full-stack engineer, a capable ML practitioner, a data engineer, a product manager, a designer, a discovery interviewer, and a trusted business advisor, all at once. We sold that profile. We have now seen enough to say that loading all of it onto one person is not the strength it appears to be. It is a risk.
Deep in one or two fields, doing a passable imitation of the rest, with AI smoothing the surface.
The right specialists on the work, each made faster by AI inside their depth.
So we are restructuring Strongly's services into Strongly Labs: balanced, multidisciplinary teams matched to the engagement, rather than a single hybrid hero carrying every discipline at once. This piece explains why, and why we think it makes the original thesis stronger rather than weaker.
What the original argument got right
We want to keep the parts that were true, because most of them were.
Implementation is where AI value is won or lost. Enterprises do not struggle because the models are weak. They struggle because connecting AI to legacy systems, messy data, real workflows, and human stakeholders is genuinely hard, and that difficulty is rising, not falling. Human judgment about which problem to solve, which data to trust, and what "good" looks like for a specific business is not something you install. Trust, context, and the ability to operate inside an ambiguous environment remain irreplaceable.
None of that has changed. If anything, the last year has reinforced it.
It was not whether humans are central. It was how many of them, and in what shape.
Augmentation, not replacement, and why that points to a team
The original framing leaned on the idea that AI automates most coding, which frees up a single person to focus on business value. We would put it more precisely now, because the precise version changes the conclusion.
“AI augments people. It does not replace expertise.
A coding assistant makes a strong engineer faster. It does not turn that engineer into a data scientist, and it does not give them a designer's eye. AI raises the floor for a capable generalist, which is real and valuable, but it does not erase the gap between a competent generalist and a trained specialist. That gap is exactly where quality, and risk, live.
This is the heart of the matter. If AI replaced expertise, the one-person FDE would make sense, because the tooling would cover the thin spots. Because AI augments expertise rather than replacing it, the thin spots stay thin. The right response is not to ask one person to be deep in six disciplines with AI papering over the rest. It is to put the right specialists on the work and let AI make each of them faster at what they are already good at.
The lens problem
The clearest way to see why one person cannot cover every discipline is to look at how differently trained people perceive the same task. It is not only about skills on a checklist. It is about the lens through which someone sees the problem.
Consider three examples we see constantly.
An engineer running user discovery is not a designer running user discovery. A trained designer or researcher knows how to ask non-leading questions, how to separate what users say from what they do, and how to read the gap between a stated request and an underlying need. An engineer, through no fault of their own, tends to hear requirements as a spec to implement. Same interview, two very different sets of findings, and the difference compounds through everything built afterward.
A full-stack engineer assembling an ML model is not a data scientist. They can wire up a model and get an output. Knowing whether that output is trustworthy is a different discipline entirely: evaluation, bias, data leakage, drift, and the instinct for when a model is confidently wrong. In a compliance or financial setting, that instinct is the whole job.
One person playing product manager between coding sessions is not a product manager. Real prioritization, scope control, and stakeholder management are not a side activity you do in the gaps. Treated as one, they become the first thing that slips when delivery pressure rises.
When a single FDE wears all of these hats, the customer is not getting one expert in six fields. They are getting one expert in one or two fields doing a passable imitation of the rest, with AI smoothing the surface. The imitation is where rework, blind spots, and quiet failure come from.
Aligned with the customer, not the platform
There is a second reason for this change, and it is about incentives.
A platform-first FDE model has a built-in pull. When the same person who scopes the problem is also the one deploying on, and measured by adoption of, a specific platform, there is a natural gravity toward bending the solution to fit the product and the roadmap. Sometimes that alignment serves the customer. Sometimes it does not. The customer cannot easily tell the difference from the outside.
There is real value in a delivery team that pushes back on requirements. Challenging assumptions and reframing the problem is one of the most valuable things an experienced team does. The distinction we care about is the direction of that push.
It should be in service of what the customer actually needs, grounded in their problem - not in service of fitting their problem to our platform.
Strongly Labs is built around that distinction. A team assembled for the customer's problem, with the disciplines that problem requires, is aligned with the customer first. That is also why "Labs" is the right name. This is applied, multidisciplinary problem-solving oriented to outcomes, not a pool of hours that exists to drive platform consumption.
What a Strongly Labs engagement looks like
Instead of defaulting to one profile, we compose a team scoped to the work. Depending on the engagement, that team can include a data scientist, a data engineer, an AI engineer, a product manager, a designer, and a full-stack engineer, in whatever combination the problem calls for.
Data Scientist
Evaluation, bias and drift. The instinct for when a model is confidently wrong.
Data Engineer
The pipelines and the messy, real data underneath the model.
AI Engineer
Models, agents and tooling wired into systems that have to hold.
Product Manager
Prioritization, scope control and stakeholder management - not a side activity.
Designer
Discovery run through the right lens, and an interface people actually trust.
Full-stack Engineer
The production build, shipped and kept running after launch.
The people on the team still use AI heavily. Every one of them ships faster because of it. The difference is that AI accelerates specialists working inside their depth, rather than stretching one person across territory they were never trained to cover.
"Isn't a team slower and more expensive?"
This is the fair objection, and we want to answer it directly rather than dodge it.
A balanced team is not more people for the sake of it. It is the right people, brought in only when the work calls for them, and rotated out when it does not. That is a different thing from headcount. The hidden cost in the one-person model is not on the invoice. It shows up later, as rework when a generalist's ML model fails evaluation, as missed needs when discovery was run through the wrong lens, as scope drift when product management was an afterthought.
Fast to a fragile outcome is not fast. It is expensive, paid on a delay.
Right-sizing the team is how you get to a correct outcome sooner, with less risk carried into production. That is the speed that matters to a customer: speed to something that works and keeps working, not speed to a demo that frays under load.
The human element, restated
The original piece ended on the right note. AI is changing software development, and the open question is who will guide enterprises through that change so the technology delivers real value.
Our answer has matured. That guidance is not the work of a single polymath. It is a collaboration: technology and AI experts working alongside the customer's subject matter experts, each contributing the lens they were trained to bring. Success in AI delivery is, more than anything, a human collaboration activity. The most reliable way we know to make that collaboration work is to put the right humans in the room, give them AI to move faster, and align the whole team around the customer's problem.
That is what Strongly Labs is.
“Same belief in the irreplaceable human element. A better-built team to deliver it.
The right team for your problem
Strongly Labs assembles multidisciplinary teams matched to your AI engagement. If you would like to talk through what the right team looks like for your problem, let's talk.
Schedule a demo