06.11.26 By Dom Profico
We redesigned the process. We redesigned the tooling. We never redesigned the organization. That’s the bottleneck now.
In the first two parts of this series, I described a new way to build software. Part 1 argued that the quality problems attributed to vibe coding aren’t new; the answer is governance infrastructure embedded in the environment, not gatekeeping access to the tools. Part 2 introduced a contribution-based development model and gave it a governing image: an armoring workshop, where every role forges, designs, or refines a real piece of the suit instead of handing off a drawing for someone else to build.
This part takes that workshop as given and asks the organizational question: if the development model changes, does the organization have to change with it?
The answer is yes, but not the way you might expect. It isn’t that every company should dissolve its teams into fluid resource pools; that’s too simple, and wrong for a lot of businesses. It’s that no matter how you structure your teams, one thing changes universally: every contributor’s relationship to the work product.
The organizing principle fits on an index card. Every contributor, whatever their role, contributes directly to the artifact that ships. Not a document about it. Not a spec of it. Not a mockup. To it.
Think about what disappears when you commit to this:
| Artifact | What Actually Changes |
|---|---|
| The PRD | PMs still do strategy and customer research. But the output is a forged prototype, not a document someone else interprets. |
| The design spec | Designers still do research and interaction design thinking. But the output is designed as part of the software artifact, not a Figma file with redlines. |
| The user story | BAs still do domain analysis and edge case identification. But the output is encoded logic in the artifact. |
| The test plan | QA still does risk analysis and quality thinking. But the output is executable test coverage against the running artifact. |
What doesn’t disappear is the thinking, the expertise, the judgment. What disappears is the translation layer between the thinking and the artifact, the intermediary documents that only existed to bridge the gap between the person who knows what to build and the person who builds it. That gap is closing.
The contribution model applies everywhere. How you structure the workshop around it depends on what your business actually does.
A SaaS company with a flagship product, or any business built on a few complex, long-lived codebases, needs a dedicated workshop. The context cost is too high for anything else. Understanding how the reporting module connects to permissions, to the data model, and to a decade of backward compatibility takes months to accumulate, and you don’t want to rotate it out. The team persists; what changes is what happens inside it.
The PM isn’t writing PRDs for engineers to interpret; they’re forging the workflow in the governed environment. The designer isn’t handing off Figma files; they’re shaping the piece the PM forged. The engineer isn’t starting from a blank file; they’re refining what already exists. Same team, same workshop, a fundamentally different relationship to the work, with each member operating in whichever mode (forge, design, or refine) their expertise demands at that moment.
The quality posture reflects the business. This is the ceremonial suit: the finish is exquisite, the craftsmanship visible, time secondary to craft. It’s the model our digital product engineering practice is built around: deep context, durable teams, production-quality work.
A large retailer, a bank, a healthcare system. These organizations build and maintain dozens or hundreds of applications. No single one is the business; the portfolio collectively enables it.
Here, fluid structures fit naturally. No individual application justifies a permanent team. The customer portal needs heavy design attention for a three-month redesign, then a year of light engineering. The compliance dashboard spikes during regulatory changes, then goes quiet. Expertise pools work because the contribution model makes them practical: when anyone can forge, design, or refine directly, continuity lives in the governed environment, not in a standing team. People flow to where the portfolio needs them.
This is arming for battle: solid, functional pieces produced at pace across many suits. Forging is efficient, design is pragmatic and refinement focuses on what matters for the fight, not ornamentation. Governance provides coherence across the portfolio the way shared standards keep every suit in one design language.
This is the most interesting case because the “product” changes constantly. You’re not maintaining a long-lived codebase; you’re delivering engagements, each with its own scope, architecture, and client context. Professional services already runs closer to a pool model: workshops assemble for an engagement, deliver, and reform for the next.
What changes is the engagement model itself. The client’s own people become contributors in the workshop, not just the ones who commissioned the suit. The client’s PM forges prototypes; the firm’s engineers refine them; the firm’s senior leads maintain the governance and integration standards.
That shifts the value proposition from “we provide capacity to translate your specs” to “we provide governed workshops and expertise at the tiers you need, so your team can forge alongside ours.” The deliverable isn’t a handoff package. It’s the working software, plus the infrastructure that keeps it healthy after the engagement ends.
If persistent teams aren’t always the answer and intermediary documents disappear, what provides continuity? How does the system remember why decisions were made?
In a human-only model, that memory lived in people’s heads: the engineer who’d been on the project for two years just knew why the data model was shaped the way it was. Fragile, but workable while the same people stayed in the room. In an AI-first model, that implicit knowledge becomes a liability. Every session starts fresh, with no memory of the last one and no awareness of the trade-offs that produced the current architecture. Left unchecked, the agent makes choices that are locally rational and globally wrong: refactoring something that was structured deliberately, or contradicting an architectural call made three months ago.
This is where documentation stops being overhead and becomes a first-class engineering artifact. It is how the governed environment remembers.
A blacksmith’s work leaves marks in the metal; an experienced smith can read a piece’s history in its grain. The documentation that emerges from forging is that grain: the architecture decision records, policy files, and context documents that capture how each piece was shaped and which trade-offs were accepted. It isn’t paperwork. It’s the memory of every decision.
What makes this different from the old documentation burden is that forging produces the documentation as a byproduct. The agent that implements a feature can generate the record explaining why; the human reviews and validates it rather than writing it from scratch. That record then feeds the next session’s context, so the next contributor’s agent picks up where this one left off. Artifact and documentation co-evolve; neither is a proxy for the other.
The governance pipeline enforces this the way it enforces test coverage: not “did you write a design doc first,” but “does the context layer reflect the decisions that actually shaped this piece.” Living documentation, continuously validated and continuously consumed.
The grain captures what happened while forging this particular suit. But some knowledge predates the first strike, and the grain can’t carry it.
| Knowledge Layer | What It Contains | Who Carries It (Old Model) |
|---|---|---|
| Craft knowledge | How to structure a component. How to handle auth securely. What patterns fail at scale. | Senior engineers, through years of practice. |
| Organizational knowledge | Architectural standards, design system, API conventions, security posture, tech choices. | Long-tenured engineers; wikis nobody reads; tribal convention. |
| Domain knowledge | Business rules, regulatory constraints, customer behavior, industry-specific logic. | BAs, PMs, domain experts. |
| Project knowledge | Decisions made on this suit. Constraints discovered during forging. Integration assumptions. | The grain structure, handled by the documentation layer. |
A senior engineer carries craft and organizational knowledge unconsciously; a BA carries domain knowledge from years in the industry. An agent has none of it unless it’s captured, maintained, and injected into the session.
That makes it the master armorer’s deepest value in this model. Their most important job isn’t forging pieces or reviewing integrations. It’s ensuring the expertise they’ve accumulated is captured, maintained, and present in every session, so each contributor’s agent can draw on knowledge they haven’t personally had time to accumulate.
This reframes the governed environment from Part 1. The scaffolding isn’t just guardrails; it’s injected knowledge. Approved libraries embody craft knowledge, architectural templates embody organizational knowledge, business-rule engines embody domain knowledge, context documents embody project knowledge. The environment doesn’t just prevent bad outcomes. It supplies good judgment.
How to capture and inject these layers is beyond this series, but the need is foundational. The grain tells the system what happened; the knowledge layers tell it what it should already know. Without both, you get software that looks right and fails under stress, because the agent had the project context but not the craft to apply it.
What did the traditional org structure actually give us? Two things: quality, through senior oversight baked into the team, and continuity, through shared memory carried by people who stayed.
The argument across this series is that both can now come from structure rather than headcount. Quality comes from the governed pipeline and the knowledge layers feeding it: the tiers from Part 1, automated scanning, architectural fitness functions, the agent-as-first-reviewer. Continuity comes from the grain: the ADRs, policy files, and context documents that feed each session and persist no matter who is present month to month.
Once that’s clear, team topology becomes a business decision, not a structural necessity. Deep products keep dedicated workshops; portfolios use pools; services firms assemble per engagement. In every case the quality comes from the pipeline, the continuity from the grain, and the expertise from the knowledge layers. Not from the org chart.
This is the question that makes people uncomfortable, so let’s take it directly.
Sprint planning, velocity tracking, and capacity management were built for the persistent squad. Where workshops persist, some of these rituals survive but evolve; in a pool model, they lose their object entirely. You can’t measure the velocity of a pool contributing to twelve products at once.
What replaces them is a different set of signals.
Artifact health. How many products are in progress, what’s their governance posture, where does each piece sit in the forge-design-refine progression, and where are quality signals degrading or bottlenecks forming?
Contribution throughput. Not story points, but how quickly contributions integrate, pass governance, and land. It measures the health of the workshop, not the output of any individual.
Expertise development. This is where the role genuinely changes. The manager’s main job becomes growing craft: are designers shaping production-quality components? Are BAs encoding business logic well? Are engineers working in the right mode?
None of this means managers become unnecessary; it means the job changes. The coordination overhead, sprint planning, ticket grooming, status reporting and handoff management gets absorbed by the governance infrastructure and the contribution model. What’s left is harder and more valuable: developing people, maintaining standards, and judging where expertise is most needed. If you’re working out how agentic tools fit your engineering practice, our generative AI solutions practice does exactly this with enterprises.
If PMs can forge software and designers can shape code, does everyone collapse into a generic “product engineer”? No, and that would be a failure mode, not a goal.
Specialization is what makes the workshop work. The PM’s value isn’t that they can forge a prototype; it’s the product judgment to know which prototype to forge. The tool is the hammer. The expertise is the arm that swings it.
What changes is how that expertise is expressed. A PM who validates hypotheses through working software beats one who validates through documents, but they’re still a PM, deepening in product strategy, customer insight, and market judgment. The ability to forge is a capability, not an identity.
The new dimension is contribution range: how many pieces someone can work across. A designer who can forge a layout and shape its interaction logic is more versatile; an engineer who understands product context makes better calls when refining. It’s the T-shaped model reframed: the vertical bar, deep expertise, gets deeper as the tool absorbs mechanical work, and the horizontal bar, what you can contribute to, gets wider, without diluting what you know.
For teams spread across time zones, the model changes the onshore/offshore calculus. Today the onshore team defines work, the offshore team picks up tasks, and handoffs happen at the edges of timezone overlap, the relay race at organizational scale.
In the contribution model, each geography advances the actual work during its day. The US team forges and designs; the India team picks up the pieces, reads the grain that captured the day’s decisions, and keeps going. The pipeline integrates continuously. The overlap window, roughly four hours between US East and India, becomes the highest-value coordination time, not for standups, but for senior review: assessing what the prior geography produced, resolving tensions, and setting priorities for the next cycle.
That reframes offshore teams from execution capacity to contribution partners. Someone forging in India with full context from the grain is doing the same work, in the same mode, as someone in the US; the pipeline doesn’t care about geography. The cadence becomes follow-the-sun: the work advances, governed and documented, around the clock. Instead of handing off a task list at end of day, you hand off the living artifact and the grain that tells the next contributor where each piece stands.
Three parts. One argument.
The through-line is the artifact. Every contributor shapes the real thing; no intermediary documents, no translation layers. Governance ensures quality, the grain ensures continuity, and the knowledge layers keep the craft present in every session, so the next contributor and the next agent can pick up where the last left off.
We redesigned the process decades ago when we moved from waterfall to agile. We redesigned the tooling in the last two years as agentic coding tools matured. The organization is next.
The companies that figure this out won’t just ship faster. They’ll build fundamentally better products, because the people with the deepest domain expertise will be forging, designing, and refining the product directly rather than writing documents about it.
The constraint that shaped our organizations, that only engineers can produce software, is the same one that shaped our SDLC. Both are dissolving. The organizations that redesign for that reality will gain a structural advantage that better process and better tools alone can never match.
This is Part 3 of a three-part series.
Part 1: Vibe Coding Doesn’t Have a Quality Problem. You Do. explored why vibe coding’s quality concerns aren’t new.
Part 2: The SDLC is a Relay Race. Software Should be Forged proposed a development model where every role forges, designs, and refines the running software directly.
If these ideas resonate and you want to talk about how they apply to your organization, whether you’re a product company, a portfolio enterprise, or a services firm navigating this shift, Bridgenext helps enterprises design and implement governed agentic development models. We’d welcome the conversation.
Dominick is CTO and Head of Engineering & Technology at Bridgenext, where he leads the AI, Data, and Digital Engineering practices. He spends most of his time thinking about how enterprises can adopt agentic development without sacrificing the governance that production systems demand.
