The builder’s advantage
The FDEs are coming. Sam Sweilem on agentic engineering, private AI, and the cost of waiting for consensus.
Sam Sweilem, CEO of LockedIn Labs · VIBECIO editorial imageVIBECIO Editorial Desk ·
“The FDEs are coming.” Sam Sweilem likes the provocation. But his case for forward-deployed engineers starts with an experience familiar to anyone who has built software inside a large company: you can see what needs to change, understand how to change it, and still spend months waiting to find out whether the organization understood your idea.
Sweilem, a former CIO and the CEO of LockedIn Labs, now spends long nights building with agents, sometimes across five or six builds and multiple sessions. He can inspect an idea while he is still thinking it through. If the first version is wrong, he changes it. “I’m locked in” became a running joke in the lab. He likes being able to follow an idea while he is in that flow, without waiting months for another attempt.
He calls that the builder’s advantage. Thirty years of experience becomes more useful when the person who understands the problem can also build something to test against it. His bet is that this will change what enterprises expect from their engineers—and who gets to influence the decisions.
The idea used to come back months later
“I've always been a builder.” Sweilem started roughly thirty years ago running cables in data centers and building servers. He moved toward leadership because he wanted a say in the decisions. Being responsible for one task in a project plan was frustrating when he believed the project itself was heading in the wrong direction.
He pursued PMI certification, worked through business analysis, project management, and program management, and kept being pulled back into architecture. Healthcare eventually brought those experiences together. He describes healthcare applications using NVIDIA and Google technologies, alongside implementations in financial services.
The familiar frustration was waiting months for an idea to return in a form altered by successive interpretations. A correction meant another cycle. Working directly with agents lets him inspect the first version while he can still explain why he wanted it. Sometimes the implementation is wrong. Sometimes building it exposes a flaw in the original idea.
His objection to the old process is specific. Requirements documents and roadmaps helped allocate expensive, limited development capacity. Faster implementation changes that calculation. A useful delivery review should distinguish time spent building, time waiting for a decision, and time repairing a misunderstood requirement. A queue protecting scarce developer capacity deserves a different conversation from a review protecting patient information.
Claude 4.6 changed his own assessment of what a team could attempt. The July 2025 Project NANDA report provides earlier context: its January–June research emphasized weak integration and limited learning inside workflows, rather than model quality, as the main explanation for the divide it observed. Sweilem’s view goes further. He believes both the technology and the enterprise were underprepared then. After sustained building, he now considers AI ready for serious enterprise work, even where the organization remains unprepared to use it. AI isn’t waiting for consensus.
For long-running work, the test is whether an agent can resume after an interruption, identify unfinished work, recover from a failed tool call, and preserve the decisions already made. Anthropic’s engineering account of long-running agents describes incremental work, durable progress records, and end-to-end testing across sessions. A longer context window alone does not supply that operating discipline.
For Sweilem, these are recognizable systems problems. “It’s just a lot of systems connected to each other,” he says. The work still involves understanding dependencies, securing access, keeping services stable, and knowing what will happen under load.
Choose the model after you define the decision
Sweilem’s approach uses different tools for different jobs, including privately hosted models for work involving sensitive information. That opens a more useful architectural question than which frontier model currently leads a benchmark: how much reasoning does this particular step require, and how will the application know whether the result is usable?
TypeSafe founder Diogo Almeida pushes that question further. In his prelaunch talk on what follows RLHF, uploaded in July, he argues that pleasing a person in a conversation and making dependable decisions inside software are different objectives. Jev’s September launch gives that argument a concrete interface. TypeSafe calls its training approach reinforcement learning for calibrated decisions, or RLCD, and describes parallel output sampling in place of autoregressive text generation. That is a different training objective and output architecture, not evidence that every AI task should move to the same design.
The useful separation is between bounded judgments repeated inside a workflow and work that requires exploration, planning, or substantial code changes. TypeSafe calls its proposition System One. A fast decision component can help route a request; a more capable reasoning model can investigate an unfamiliar exception. Ordinary code should enforce exact rules. These roles can coexist in the same application, and a difficult case may justify the more expensive route.
The economics merit attention. On September 20, TypeSafe’s model reference lists jev-1.13.0 at $0.042 per million input tokens, with output free; its launch report reports 70–500 ms latency under its evaluation conditions. Retrieval, retries, evaluation, and human intervention still determine what a completed workflow costs.
Consider a hypothetical healthcare scheduling service, rather than a reported client deployment. A patient sends a request to change an appointment. A model identifies the request type and missing information. The application checks the patient context and the current appointment record. An old message about a cancelled visit should not move a different appointment simply because the output conforms to the expected schema. Messages involving possible clinical urgency stay outside the administrative automation path.
That design needs an explicit decision about which cases can proceed. Choose a threshold on representative labeled cases, then test it on held-out cases. Report the fraction handled automatically and the error rate within that fraction. An apparently excellent error rate achieved by deferring almost everything buys little automation. TypeSafe’s confidence documentation distinguishes its derived confidence statistic from the returned distribution; its own Jev limitations document incorrect answers and sensitivity to distracting or adversarial context. A valid type makes the answer easier to consume. It does not make the decision correct.
The measure to carry into an executive review is human minutes per correctly completed case, alongside completion coverage, error costs, and end-to-end latency. Increasing model spend can be the economical choice if it removes enough investigation or rework. Reducing inference cost can be a poor trade if the saved tokens return as an employee’s queue.
Sweilem’s use of private models makes another boundary consequential: which information may reach which service? Set permitted destinations from the data’s classification and purpose, then inspect the complete outbound request, including retrieved context and tool results. Google’s Sensitive Data Protection documentation describes detection as imperfect. Finding no sensitive entity does not authorize sending restricted data elsewhere. Uncertain classification stays restricted until resolved.
NVIDIA’s enterprise AI factory architecture treats infrastructure, software, and deployment as one connected design. For the private platform Sweilem describes, that means operating a service other teams can depend on: known model versions, controlled access, retained evaluation evidence, and a recovery path.
When an agent can spend your money
Agentic commerce brings these choices into a transaction. In the public notes for Nate B. Jones’s conversation with Stripe’s Emily Glassberg Sands, agents become customers that discover and buy services. For those workflows, a checkout screen may give way to a programmatic exchange. The business still has to decide which commitments it will accept from software acting on someone’s behalf.
The Model Context Protocol (MCP) connects the agent to tools; the Machine Payments Protocol (MPP), introduced by Stripe and Tempo, coordinates machine payments. Neither defines the buyer’s complete purchasing policy. An engineer has to connect identity, approved purpose, permitted suppliers, spending authority, and the information allowed to leave with the request.
Here is a concrete design requirement: the agent may request a purchase, but its runtime credentials must not be able to raise the budget, edit the supplier policy, or bypass the service authorizing the transaction. Keep policy administration separate from execution. A signed credential establishes claims about the caller; application controls still have to decide whether this purchase is allowed.
A spending cap also has to survive concurrency. In an illustrative case, two agents each see $1,000 available and each request a $700 purchase. Both requests pass a naive balance check. The action service needs to check and reserve the maximum authorized amount for that purchase atomically against shared authoritative state before contacting the payment provider. Database transactions and locking can support that local reservation; they do not make a remote payment part of the same atomic transaction. If the final amount exceeds the reservation, the service requires new authorization.
Now suppose the payment request times out. The money may already have moved. Retain the operation identity, reconcile with the provider, and avoid freeing the reservation simply because no response arrived. Stripe’s idempotency mechanism supports replaying a request under documented conditions. It does not make an entire business workflow happen exactly once. A stop control should block new commitments while reconciliation continues for work already in flight.
This is also where cheap inference can produce an expensive system. A useful completion record connects the authorized request to the purchase, the delivered service, and acceptance of the result. Cap cumulative spending and tool attempts as well as each individual transaction. A hundred individually permitted tool calls can still be a failed assignment. The budget owner needs to see the cost of accepted work, including recovery when the agent gets stuck.
The FDEs are coming. The client has to own the result.
These are the responsibilities behind Sweilem’s version of the FDE: discover what the business needs, build with the people doing the work, understand what the system may change, and stay through release. Good engineering teams will recognize the job. His bet is that agents let a much smaller group carry more of it without handing the problem through a succession of specialists.
A team can return from a conversation with users, revise an implementation, and test the revision while those users still remember the problem. To make that useful, it needs access to the right people and authority to resolve ordinary design decisions. Calling it a pod changes little if every adjustment still waits in the same queues.
Acceptance needs a separate owner. The same agent can misunderstand a requirement, implement the misunderstanding, and generate a test that confirms it. Give the builder the task contract and useful examples. Protect the authoritative evaluator from modification by the builder’s runtime identity, and keep a separately controlled set of held-out cases. Changes to the contract require explicit review. Hiding the requirements would make the work harder; preventing the implementation from rewriting its own acceptance criteria makes the evidence more useful.
That separation must survive release. The model producing a patch should not acquire production access merely because it reports passing tests. An independent owner decides what the evidence establishes and what remains untested. A model change, a retrieval change, and a permission change can each alter behavior without a large code diff. Include them in the release record and the recovery plan.
JPMorganChase’s Innovation Week account puts AI across the product lifecycle and connects it to the operating model. Sweilem’s proposal would need to be judged across that lifecycle: elapsed time from an agreed problem to an accepted release, then the interventions and corrections required after launch. More generated code does not establish that the organization has become better at delivering.
LockedIn Labs connects practitioner development with delivery through its FDE Academy and its work alongside client teams. The ambition is to leave the client able to change the system: code, evaluations, operating knowledge, and an AI software development lifecycle its own people can use. A client that needs the supplier to explain every failure has inherited a dependency, however quickly the first version arrived.
Sweilem wants experienced operators working alongside new graduates. Shopify engineering leader Farhan Thawar’s case for hiring interns in the AI era offers a relevant comparison: agent-assisted work paired with human ownership and review. Someone who knows why a batch job runs at a particular hour has knowledge a new builder needs. Someone fluent in the new tools may find a faster way to test whether that constraint still applies.
For comparable work, the second deployment should need less help from the FDE than the first. That is a more demanding promise than a fast initial release. Can the client diagnose a failure, change a business rule, or evaluate the next model without calling the original builder back? If so, each engagement leaves the enterprise with more people who can build—and fewer ideas waiting for someone else to interpret them.
Sweilem keeps coming back to the knowledge accumulated before these tools existed. “What’s not infinite is that knowledge of what to build.” That is why he wants experienced people back at the keyboard—and new builders beside them.
About this interview
Edited from written responses supplied by Sam Sweilem, who commissioned this cover profile. Career and implementation experience are self-reported. Direct quotations preserve his supplied wording. Technical designs and economic arguments are editorial analysis developed from the conversation and linked sources; hypothetical scenarios illustrate design choices, not customer deployments or measured LockedIn Labs results. Readiness judgments are Sweilem’s perspective. Company references do not imply endorsement. Readers can write to VIBECIO.
Sources