How Loft Supports Product-Shaped Engineering
AI lets engineers work across more of the product lifecycle. Loft supports that broader ownership with a ratified product contract, explicit authority, and evidence for human acceptance.
Imagine an engineer asking an agent to let customers revise a delivery address after payment authorization but before fulfillment begins. By the end of the session, the agent has updated the interface and service, written tests, and prepared a deployment plan.
The change is ready to review, but the product decision is still unsettled. Which behavior was ratified? Which address fields may change? What happens if tax or payment data must be recalculated? Do the tests demonstrate the intended outcome, or do they repeat the implementation? Who has authority to accept the result?
AI is helping engineers work across more of the product lifecycle. That broader reach can support a product-shaped role: a deep technical professional who understands the problem, shapes the solution, follows it into production, and learns from the outcome.
Loft is built for the organizational problem that follows. When engineers and agents can produce more of the product, they need a shared contract for what the product is meant to do, who can decide, and what evidence is required before the result is accepted.
AI is widening the engineering role
The conventional engineering role often began after a requirement arrived and ended when code was complete. AI makes both boundaries easier to cross.
Engineers can move left into problem framing, specification, design, and prototyping. They can move right into testing, release, operations, and feedback. A survey of more than 1,000 engineers building with AI (www.amplifypartners.com) found that 44% believed roles in the product organization were blurring significantly, while another 37% said they were blurring somewhat. This is self-reported evidence from an AI-oriented sample, but it reflects a visible change in activity.
Company reports show the same direction. In OpenAI's account of an agent-first engineering experiment (openai.com), the team's work shifted from writing code toward specifying intent, designing the environment, and building feedback loops for agents. Anthropic's internal study (www.anthropic.com) found engineers and researchers crossing stack boundaries, with security staff analyzing unfamiliar code and safety teams building front-end visualizations.
A Microsoft Research mixed-methods study (arxiv.org) found that AI-assisted development still depends on problem formulation, choosing inputs, evaluating suggestions, and deciding what to implement. More experienced developers evaluated generated code more effectively.
The stronger role remains grounded in specialization. A product-shaped engineer can own a bounded outcome and perform more adjacent work while recognizing where product, domain, security, reliability, or other specialist authority is required.
The related article When Every Role Gets Faster, Why Doesn't Software Delivery? examines what happens at the organizational level when local work accelerates. Here, the focus is the engineer's broader delivery loop and the authority boundaries around it.
Broader execution needs a common product boundary
An agent can generate a candidate implementation. It cannot infer which of several plausible product meanings the organization has ratified.
For the delivery-address change, the product brief may promise a convenient customer experience. An architecture note may impose an order-state transition that the brief never mentions. The payment integration may restrict which fields can change after authorization. The test suite may encode today's implementation rather than the intended behavior. Each source contains useful information, but none is automatically the governing truth.
A product-shaped engineer can discover and compare those sources. The engineer still needs an answer to three organizational questions:
- What is the ratified product intent for this scope?
- Who has authority to ratify a proposed change and accept the result?
- What evidence should support the acceptance decision?
Without shared answers, broader execution creates more versions of the product. The engineer becomes the person who reconstructs intent from documents, code, tickets, conversations, and agent output. Review becomes an exercise in resolving meaning instead of judging the result.
Loft gives expanded roles a ratified product contract
A product contract is a human-ratified, structured account of the intended product outcome for a defined scope. In Loft's model, it can connect product behavior, vocabulary, requirements, constraints, architecture, acceptance criteria, provenance, and decision authority.
The participants need more than a long document. A product rule should retain its identity when an engineer, agent, architect, or assurance specialist refers to it. A proposal should remain distinct from the ratified state. Constraints and acceptance criteria should stay connected to the behavior they govern.
Human ratification gives the contract authority. Agents can draft requirements, identify contradictions, propose designs, or prepare acceptance scenarios. Their output remains a proposal until people designated by the organization ratify it.
That distinction lets the engineer work more broadly without silently inheriting every decision right. The product contract supplies the ratified boundary. The engineer and agents can act within it. Specialists can contribute constraints and independent checks. Authorized people decide whether the contract should change and whether to accept the implemented result.
Loft depends on human judgment to establish product truth. For new software, a team can develop the contract alongside the product. For an existing system, the team may first recover evidence from code, tests, tickets, documents, production behavior, and experienced people. Recovery describes what the available sources indicate. Ratification gives a proposed description authority for the stated scope.
How a product-shaped engineer works with Loft
Return to the delivery-address change. It crosses product policy, payment behavior, order state, security, customer communication, implementation, and testing. AI can help one engineer work across much of that surface. Loft supplies a governed path through it.
1. Author
The engineer, product owner, domain specialists, and their agents develop a proposal for the new behavior.
They define the permitted order states, the time window, what happens when payment or tax information must change, which address fields are restricted, what the customer sees, and which failure cases matter. Agents can inspect the current implementation and documentation, draft scenarios, and surface conflicting assumptions.
What they write is still a proposal. Finding a behavior in code does not prove that the organization intends to preserve it.
2. Ratify
People with relevant authority review the proposal. The product owner and designated engineering, security, payment, or operations specialists contribute decisions and constraints within their areas of responsibility. The organization resolves disagreements through its own decision rights.
An authorized publication turns the agreed proposal into the next immutable Authored State: the ratified product contract for that scope. The contract records the governing intent and its provenance. Unresolved questions remain visible instead of being smuggled into implementation choices.
3. Implement
The engineer and coding agent work against that ratified version and scope.
The contract states the obligations the implementation must address while leaving implementation choices to engineers within their authority. The engineer reviews the candidate implementation and escalates decisions that exceed the ratified boundary.
4. Reconcile
The team maps the implementation and its evidence back to the product contract.
Tests may support some acceptance conditions and fail others. A requirement may have no evidence yet. An operational constraint may remain indeterminate until the change runs in an appropriate environment. Reconciliation makes those relationships visible and leaves professional review and final acceptance to people.
Passing tests can still check the wrong rule, share the implementation's mistaken assumption, or omit an important condition. The evidence has to be judged against the ratified contract.
5. Decide
Authorized people inspect the result and the evidence. They accept the result, reject it, or request another iteration.
The engineer owns the bounded delivery loop. Product and domain authorities retain control of meaning. Specialists retain the decisions assigned to them. The final acceptance decision remains with authorized people.
The complete workflow is Author → Ratify → Implement → Reconcile → Decide. It creates a structure for engineering ownership to expand without turning technical capability into undeclared authority.
See the five stages applied to a worked change, including two implementation candidates, their evidence, and the final human decision.
Specialists can shape the work earlier
Product-shaped engineering still depends on deep specialists. Security, reliability, privacy, data, infrastructure, and domain expertise remain necessary where failure is difficult to detect, costly, or hard to reverse.
Loft gives that expertise more than one route into the work. Specialists can contribute requirements, constraints, vocabulary, acceptance conditions, and review decisions to the shared contract. Their knowledge can guide engineers and agents earlier instead of appearing only after implementation reaches a specialist review queue.
Independent assurance separates production from acceptance. For higher-risk work, the organization can assign authorship, ratification, review, and acceptance to different people according to the decisions each role is authorized to make.
This is the practical boundary around product-shaped engineering: broader local ownership, supported by reusable specialist knowledge and explicit escalation.
The same model applies to new and existing software
A new product can establish vocabulary, intended behavior, constraints, and acceptance conditions before much code exists. The contract develops with the implementation.
An existing system starts with evidence scattered across code, tests, documents, runtime behavior, and human memory. The first task may be to recover a bounded description, identify contradictions, and ask authorized people which behavior should govern the next change.
The starting points differ, but the controlled loop is the same. Teams author a proposal, ratify the contract, implement against that version, reconcile evidence, and decide whether to accept the result.
Loft keeps product meaning, authority, implementation, and evidence connected as software is created and changed.
Evaluate Loft on one bounded outcome
Evaluate the role shift through complete delivery outcomes, not generated output alone.
Choose one reversible product change that crosses product, engineering, and assurance. Name the people who can ratify the intended behavior and accept the result. Record the current sources of product intent, the repeated clarification work, and the effort spent reconstructing context during review.
Then run the change with one ratified Loft product contract and the complete workflow. Measure elapsed time to acceptance, clarification and review effort, material rework, defects, specialist interventions, and whether the responsible engineer can explain the evidence and trade-offs behind the result.
A useful result would show that broader ownership shortens the complete delivery loop without moving hidden work or risk into review. If the contract is incomplete, the evidence is weak, or specialist rescue work grows, the pilot should expose that too.
AI gives engineers more reach. Loft gives the organization a ratified contract, visible authority, and an evidence trail for deciding whether to accept the result.