Tag Archive for: Requirements & Requirements Management
Tag Archive for: Requirements & Requirements Management
State Medicaid agencies have spent the past decade modernizing technology. Their next challenge will be governing an ecosystem that never stops changing.
Federal mandates continue to evolve. Modular architectures mean every policy change can affect multiple vendors, systems, integrations, and testing efforts simultaneously. At the same time, CMS continues shifting toward outcomes-based certification that emphasizes measurable evidence over documentation.
While modernization for agency leaders was once measured by system replacement, it is now measured by the ability to continuously adapt while maintaining compliance, accountability, and confidence across an increasingly complex ecosystem.
Looking ahead, the next phase of Medicaid modernization will be defined by governing continuous change.
Modernization Has Changed the Nature of Risk
Technology risk has largely been replaced by governance risk. Today’s Medicaid enterprise environment consists of:
Multiple implementation partners
Modular procurements
Cloud services
AI-enabled capabilities
Interoperability initiatives
Continuously evolving CMS guidance
None of these are inherently problematic. However, the challenge is coordinating them while maintaining a defensible record of every policy decision, requirement, approval, implementation, validation, and outcome.
Today, modernization is less about replacing systems and more about managing change across a living ecosystem.
Continuous Policy Change Is the New Normal
Federal and state Medicaid programs have always evolved. What’s different today is the pace of change:
Community engagement initiatives
Work requirements
Interoperability mandates
FHIR implementation
Eligibility policy updates
Outcomes-Based Certification
Each initiative introduces new requirements that ripple across multiple systems, implementation partners, testing teams, and stakeholders.
How do agencies respond to continual federal policy changes without disrupting delivery? How can they coordinate dozens of vendors while maintaining accountability? How do they demonstrate compliance continuously instead of preparing for certification events?
Technology like Modern Medicaid Enterprise Systems can support evolving changes to policy without disrupting delivery. They were designed to accommodate change. But can organizations implement those changes safely while maintaining confidence in every decision, requirement, approval, and outcome?
How can they coordinate dozens of vendors while maintaining accountability? How do they demonstrate compliance continuously instead of preparing for certification events?
For agency leadership, continuous change is becoming the operating model rather than the exception.
Modular Delivery Requires State-Owned Governance
Modular delivery has become the foundation of Medicaid modernization. States gain flexibility by independently procuring and replacing capabilities over time rather than relying on one monolithic platform.
But modularity also changes accountability. System integrators change and contracts end. Technology evolves, but the state’s business requirements do not. That means agencies cannot outsource ownership of their requirements. State agencies remain accountable for the policies they implement, the outcomes they deliver, and the evidence required to demonstrate compliance.
Organizations that are well prepared for continuous modernization maintain ownership of:
Modernization succeeds when the state remains the steward of its own program, regardless of who builds individual modules.
Evidence Is Becoming More Valuable Than Documentation
Another distinction becoming increasingly visible is how CMS evaluates modernization.
Streamlined Modular Certification and the continued evolution toward Outcomes-Based Certification emphasize measurable outcomes supported by evidence rather than large collections of documentation. Required certification artifacts have been reduced, placing greater emphasis on demonstrating that requirements were implemented, verified, and validated.
This represents an important change in mindset. Preparing documentation before certification events is no longer enough. Leadership teams need confidence that evidence already exists, including every:
Policy decision.
Requirement.
Implementation.
Approval.
Test.
Outcome.
Certification becomes less about producing documents and more about demonstrating a continuously maintained chain of accountability.
Governing Continuous Change
Governance is an operational capability.
As federal policy continues to evolve, agencies need confidence that they can understand the downstream impact of every change, coordinate work across multiple vendors, and demonstrate progress without assembling evidence by hand.
Governance creates that confidence. It gives leadership visibility across implementation while preserving accountability across the entire Medicaid Enterprise System.
How Jama Connect® Supports the Next Phase of Medicaid Modernization
Jama Connect was built for organizations developing complex, highly regulated systems where change is constant and evidence matters.
For state Medicaid agencies, Jama Connect serves as the governance layer that connects policy decisions, business requirements, implementation activities, testing, approvals, and certification evidence across agencies, system integrators, and module vendors. It complements existing development toolchains rather than replacing Medicaid applications.
Jama Connect helps agencies:
Maintain a state-owned source of truth for business and regulatory requirements.
Connect requirements to implementation, testing, approvals, and CMS outcomes through Live Traceability™.
Understand the downstream impact of policy and requirement changes before they create implementation gaps.
Give program leadership and IV&V independent visibility into progress across vendors rather than relying solely on status reporting.
Build a defensible record that supports certification readiness, audit activities, and ongoing modernization.
Jama Connect gives agencies the governance layer that sits above a complex ecosystem of vendors, integrators, and delivery teams. Rather than replacing development tools, Jama Connect establishes a state-owned system of record that connects policy decisions, business requirements, implementation activities, testing, approvals, and certification evidence into a continuously maintained chain of accountability.
The Future of Medicaid Modernization
The next decade of Medicaid modernization will be defined by how well agencies govern continuous change. The agencies that succeed will maintain ownership of their requirements, coordinate increasingly complex delivery ecosystems, and build evidence as they work instead of reconstructing it later.
This remains clear: Technology enables modernization, but governance makes it sustainable.
Modernize Faster. Govern Better.
Learn how Jama Connect helps state Medicaid agencies maintain state-owned requirements, coordinate multi-vendor delivery, and build the evidence needed to support continuous modernization and CMS certification readiness.
Request a personalized demo and see how Jama Connect helps agencies govern continuous change.
IBM Rational DOORS was built in 1991 when it became clear that document-based tools such as Microsoft Office did not offer the capabilities able to manage and analyze requirements traceability. And while it was revolutionary at the time, not much has changed about the product in over 30 years.
Many teams are looking to switch away from Rational DOORS because of IT mandates, poor usability due to an antiquated user interface, lack of collaborative features, and a host of other reasons.
However, thinking that migrating to DOORS Next Generation is the easiest, most logical next step is a mistake. In this post, we’ll discuss why many migration efforts from IBM Rational DOORS to DOORS Next are failing, and provide a simpler, more modern alternative.
Considering a switch? If you want to move away from IBM Rational DOORS, you are not constrained by a specific path of migration.
Leaders might already understand the need to switch from Rational DOORS, but they aren’t sure of the next best step. Some lean toward switching to IBM DOORS Next with the assumption that it will be easier to learn and deploy than starting from scratch with a new solution.
However, the only thing that DOORS Next shares with the original DOORS is the name; otherwise, it’s a completely different platform that takes the same level of migration effort that any migration away from DOORS legacy would take. Any expensive DXL customizations — which can sometimes add up to more than a million lines of code — cannot be migrated to DOORS Next.
As you make your decision on whether to migrate away from DOORS or not, consider the risks associated with DOORS and the benefits of choosing a different option.
Risks may include:
Loss of control and employee frustration. Employees frustrated with DOORS work outside of DOORS, most often in Microsoft Word or Excel, which means that requirements are no longer maintained in a central system and a rigorous process is not followed. This leads to an inability for management to monitor key metrics for the end-to-end process to identify process risk patterns.
Increased operational costs. Continuing the existing path of using DOORS increases an organization’s risk and expense complying with ever demanding IT security regulations.
Disruption in business. New users are reluctant to pick up the antiquated user interface of DOORS, expecting software to be as intuitive as applications in their social environment. Not having the ability to move fast and scale business to meet innovative market demands will cost your business time and resources.
Missed market opportunities. Errors, defects, and omissions not found until the end of the process cause costly delays and overruns. A company’s long-term success can be hindered by delayed launches and missed market opportunities.
Increased exposure to risk in regulated markets. A requirements management tool helps you stay compliant and increase visibility in regulated markets. Limited customer and cross-functional involvement in the review and approval of requirements and a lack of stakeholder alignment create unnecessary risks. And, the absence of process exception tracking, which determines if requirements have been omitted or modified, creates additional exposure. With more stakeholders refusing to use DOORS, compliance is checked after the fact with the arduous task of tool admins importing data and then running trace analysis. Extended stakeholders who are using DOORS are only able to see any errors long after they have been introduced and eventually imported.
Distraction from the core business. An ineffective requirements management tool encourages organizations to create customizations rather than simply configuring a tool to meet process needs. Developing and maintaining ad-hoc customizations forces an organization to focus on how to create requirements management functions rather than focus on core business. A modern requirements management solution enables teams to work faster and more efficiently, leading to faster time to market.
Need more proof? Here’s what IBM says about migrating from IBM Rational DOORS to DOORS Next
Looking at Rational DOORS and DOORS Next Side-by-Side
It may sound like migrating from Rational DOORS and DOORS Next is just a click of a button, the two systems have completely different infrastructure, processes, and structure. It’s a very complex and manual process. In fact, migrating to DOORS NG will cause major architectural shifts that will impact performance and require extensive employee training.
There are a number of data types, including historical data, that can’t be migrated at all. But don’t take it from us; IBM says it themselves.
Additionally, there is no upgrade path from Rational DOORS to DOORS Next
5 Common Migration Myths Debunked
Transitioning to a new solution doesn’t have to be challenging; however, there are some assumptions that mislead us into thinking that difficulty is inevitable. Consider the following myths:
MYTH 1: Migrating away from IBM solutions will be more expensive. The amount of work that goes into upgrading to DOORS Next or transitioning to a new RM solution is the same, differentiated only by the quality of the tool and services available to help with migration. An option other than the DOORS family is most often a better fit for your organization.
MYTH 2: Customization will carry over to DOORS Next. You spent a lot of time customizing IBM DOORS and may believe those customizations will transition seamlessly to DOORS Next. However, this isn’t the case and is the reason selecting a different solution doesn’t involve more work.
MYTH 3: DOORS is already deployed and cheap to maintain. Continuing the current path with IBM DOORS is an expensive option in the long term, and often requires dedicated personnel. Switching to an alternative RM solution can improve efficiency while saving money.
MYTH 4: Business disruption is too difficult. The right RM tool will empower teams to effectively hit deadlines, collaborate, and improve business outcomes
MYTH 5: The user experience will suffer., Many people refuse to use DOORS due to a challenging user experience. DOORS Next is a completely new tool with a new user experience. Adopting a user-friendly solution allows teams to collaborate far more effectively as team members can accelerate concepts, designs, and validations for faster times to market.
Migration Away from IBM Rational DOORS is Inevitable – Here’s An Alternate, Easier Path
The fact is, IBM DOORS is extremely outdated, and at some point, updates and support will inevitably end.
If you’re currently using DOORS, you likely know that moving to a different solution is necessary, and you might be considering DOORS Next. However, fast-shifting market dynamics require a new approach to accelerate innovation. As a modern alternative to traditional legacy platforms, Jama Connect® enables digital transformation with a more efficient and user-friendly approach to managing risk and compliance.
Jama Connect is a proven IBM DOORS alternative with flexible and reliable solutions, including:
Operation in an IBM DOORS supply chain. Innovative companies leverage Jama Connect to get up and running fast with a modern requirements management process that tightly aligns with industry standards and practices that support regulatory compliance. Organizations can connect to customers and suppliers that use IBM DOORS through Data Exchange for Jama Connect.
Integration services. Jama Connect provides integration with key product development lifecycle tools.
Coexists with IBM DOORS. IBM DOORS is embedded in many organizations and may take some time to migrate completely. Progressive teams and divisions can get started on Jama Connect quickly while the larger organization works toward replacing existing programs over time. This approach is supported through a mix of integration, migration, and exchange services.
Jama Software®‘s Live Traceability™ allows engineering teams to quickly and easily access the latest and most complete information for any requirement, no matter the stage of development or tools used. This real-time capability boosts productivity by ensuring teams work with the latest data and reduces risks like delays and defects by finding issues early. Research shows that issues found late can be much more expensive to fix, which is why Live Traceability is so important. Jama Connect® helps overcome the limitations of older tools, leading to better results in many industries such as automotive, medical devices, aerospace & defense, and more. To learn more, visit Buyer’s Guide: Selecting a Requirements Management and Traceability Solution
To learn more about the three flexible approaches to support companies moving away from IBM DOORS and how our migration team can help, download our datasheet.
Teams running Claude or a similar assistant across dozens of sessions hit a familiar wall. The artificial intelligence (AI) forgets decisions made two prompts earlier and reintroduces bugs it already fixed, and the reasoning behind an architecture choice disappears with it.
OpenSpec keeps agents aligned by storing that intent in version-controlled proposals, delta specs, designs, and tasks instead of transient chat history. Some teams reach for a workaround first, a handwritten PROJECT_STATE.md in the repo that survives between conversations, which points to the same underlying gap. When requirements live only in chat history, earlier decisions vanish the moment the context window fills. A lightweight spec framework like OpenSpec can sit alongside formalrequirements management best practices when repo-level planning needs governed traceability on top of it.
Why AI Coding Agents Need Durable Intent
Fission-AI maintainsOpenSpec’s public GitHub repository and distributes it as a Node Package Manager (npm) package for AI coding assistants. It’s an open-source, lightweight framework built around a structured specification workflow. Agents read proposal.md, delta specs, design.md, tasks.md, and archived change folders before they touch a line of code.
The project describes its own approach as fluid and brownfield-friendly, scaling from personal projects to larger engineering programs. For software teams running AI agents, those planning files stay available for later review long after the chat session that produced them ends.
How Does Spec-Driven Development Preserve AI Context?
Spec-driven development (SDD) inverts a long-standing relationship. SDD makesauthoritative specifications that guide code and treats code as derivative. As AI coding tools become common in professional software development, specification discipline becomes the control surface for implementation decisions.
Once agents write a meaningful portion of the code, specifications give large language models the behavioral contract they need to generate reliably. Chat state disappears once the session ends, but a written spec doesn’t.
Why Vibe Coding Breaks Down on Complex Projects
In vibe coding, a developer prompts iteratively without structured documentation.Andrej Karpathy popularized the term and, a year on, said the approach was best suited to throwaway weekend projects rather than production systems.
TheAI coding failure modes show up fast at scale. In production-style vibe-coded applications, teams can find missing Cross-Site Request Forgery (CSRF) protections, weak security headers, exposed secrets, and other critical security issues. Regenerating code without a versioned specification record adds technical debt on top of those security gaps.
Why Middle-of-Session Details Get Lost
Multi-day AI coding work depends on decisions scattered across dozens of prompts, and as context windows fill, models tend to favor tokens at the start and end while the middle gets dropped. OpenSpec’s change artifacts sit next to the code in version-controlled files instead, so the record doesn’t depend on what the model remembers. For regulated product teams, those files create a clearer upstream signal forthe traceability record auditors expect.
How Does the OpenSpec Workflow Work?
OpenSpec organizes everything under an openspec/ root with two directories that carry the entire model. Planning artifacts stay co-located with code, and reviews use normal git workflows, so teams never have to reconstruct decisions from chat logs.
What Goes Inside a Change Folder?
The specs/ folder holds current source-of-truth specifications organized by domain. The changes/ folder holds proposed modifications, each in its own named subfolder, following a fixed artifact sequence.
proposal.md: Captures the change intent and scope.
delta specs: Describe the requirements and scenarios that define what is changing, with scenarios attached to each requirement.
design.md: Documents the technical approach, or how the change gets built.
tasks.md: Lists the implementation steps.
Delta specs use small diffs with explicit markers such as ADDED, MODIFIED, REMOVED, and RENAMED. The diff itself carries the change, which keeps the workflow practical for brownfield systems where a team can specify a change before documenting the whole application.
How Do Teams Propose, Apply, and Archive Changes?
OpenSpec’s core profile uses slash commands to keep planning, implementation, and archival steps distinct. A typical flow moves through explore, propose, apply, sync, and archive, giving the AI agent explicit steps instead of a loose chat transcript.
Command
Purpose
/opsx:explore
Think through ideas before committing (optional)
/opsx:propose
Create the change folder and generate all planning artifacts
/opsx:apply
Implement the tasks from the change
/opsx:sync
Merge delta specs into main specs (optional)
/opsx:archive
Archive the completed change
/opsx:propose generates every artifact in one step. /opsx:apply works through the task list, checks items off, and prompts the user to pick a change when several are active.
Archiving folds the work back into truth. It checks artifact and task completion, offers to sync delta specs if that hasn’t happened, and moves the change folder into a dated archive path. Teams needing tighter control can add commands like /opsx:new, /opsx:continue, /opsx:verify, and /opsx:bulk-archive from the expanded profile.
Which AI Assistants Work With OpenSpec?
OpenSpec works with many AI assistants through slash commands, including Claude Code, Cursor, GitHub Copilot, Codex, Windsurf, Amazon Q Developer, Gemini, and JetBrains Junie. Integration runs through tool-specific slash commands and config file placement. Claude Code uses commands like /openspec:proposal, GitHub Copilot reads from .github/prompts/, and Amazon Q uses an @openspec-proposal syntax. The framework needs a current Node.js runtime and no Model Context Protocol (MCP) dependency to run.
When Should We Use OpenSpec?
Use OpenSpec when AI coding work needs repo-level planning artifacts and a full requirements platform that belongs outside the code repository. Its lightweight footprint and delta-based model fit iterative work on existing systems well. Teams still need to decide where the official requirements record lives.
Brownfield Work Comes Before Greenfield Builds
OpenSpec is built around brownfield adoption, for codebases that already exist and need current-behavior discovery before any planning artifact gets written. For those projects, the recommended pattern runs /opsx:explore first, reviews that output, then uses /opsx:continue to step through proposal, spec, design, and tasks one artifact at a time. Greenfield work is supported too, since the default /opsx:propose command generates the full artifact set in one step, though OpenSpec doesn’t define a greenfield-specific workflow of its own.
Does OpenSpec Fit Solo Work and Cross-Team Programs?
For a solo developer, the workflow stays inside a single repo. OpenSpec’s default step generates four core planning artifacts per change, a smaller starting set than more heavily templated alternatives, which fits its lighter, delta-based approach.
Cross-team work changes the problem. A feature can span the application programming interface (API) server and the web app, with changes in a shared library. In that case, OpenSpec uses Stores, a planning repo of its own that carries the same specs-and-changes shape as git push. Before standardizing on it, review current repository activity, issue responsiveness, and pull request (PR) backlog.
How Does OpenSpec Compare to Spec Kit and BMAD-METHOD?
OpenSpec sits in a crowded field of dedicated SDD tooling, includingGitHub’s Spec Kit toolkit and the community-built BMAD-METHOD framework. OpenSpec asks for less ceremony, focuses on brownfield work, and stays compatible with whatever AI tool a team already uses.
The three tools differ most in model, workflow, fit, and runtime:
Dimension
OpenSpec
Spec Kit
BMAD-METHOD
Developer
Fission-AI
GitHub
bmad-code-org (community)
Spec model
Delta specs (diffs)
Full Markdown artifacts
Story files
Workflow
Change-centric, fluid
Linear phased workflow with gates
Agile-style cycle
Best fit
Brownfield, lightweight
Structure and traceability
Full software development lifecycle, greenfield
Runtime
Node.js
Python
Tool-agnostic
OpenSpec vs. Spec Kit
Spec Kit uses a linear phased process, Spec to Plan to Tasks to Implement, with explicit gates between phases. It produces full Markdown artifacts at each stage with rich templates and quality checklists, and it creates a git branch automatically. OpenSpec leaves branch creation to the team.
OpenSpec writes delta specs that show only what’s changed, with markers such as ADDED, MODIFIED, and REMOVED, and then merges the completed changes into a source-of-truth document at archive time. Spec Kit provides teams with more explicit structure for spec quality, plan quality, and verification discipline; OpenSpec keeps the workflow lighter.
Spec Kit fits better when a repo-level workflow needs stronger gates. OpenSpec fits better when the goal is a minimal but persistent structure. Readers evaluating this workflow should decide whether the repo-level spec layer also needs to connect to a governed requirements record.
OpenSpec vs. BMAD-METHOD
BMAD-METHOD takes a different shape. It simulates a full agile team through named AI personas, including Analyst, Product Manager (PM), Architect, User Experience (UX) Designer, Scrum Master, Dev, and BMad Master as the orchestrator. The Scrum Master agent creates detailed story files carrying architectural context, implementation guidelines, embedded reasoning, and testing criteria for the Dev agent.
BMAD covers the full software development lifecycle (SDLC) and extends into game development and creative work through expansion packs. That coverage comes with a heavier tradeoff. Its extensive per-persona context drives up token consumption per request compared with a lighter, delta-based workflow, and file-based context passing can interrupt handoffs.
BMAD fits greenfield projects that want a simulated agile team and detailed planning. OpenSpec fits brownfield codebases and solo developers that need lightweight alignment around versioned specs.
Getting OpenSpec Into an Existing Repo
The Massachusetts Institute of Technology (MIT) License lets teams inspect OpenSpec’s open-source workflow before adopting it. Installation needs a current Node.js runtime and a few minutes in the terminal. Run npm, then openspec init in the project, and it drops into whatever AI coding assistant the team already runs.
If the codebase is mature and the agent keeps losing the thread mid-session, the brownfield-first, delta-based model is a low-friction starting point. For systems engineers and Quality & Regulatory Affairs groups, OpenSpec only earns its place if its output connects to the traceability record auditors expect.
How Jama Connect Can Connect OpenSpec Outputs to Governed Traceability
OpenSpec’s proposals and delta specs aren’t a governed requirements record on their own. Jama Connect® adds theproduct context layer by mapping AI-generated planning artifacts to approved requirements, verification evidence, and version-controlled baselines. Its Traceability Information Model (TIM) defines the specification framework a change should satisfy before it counts as done, and its Model Context Protocol (MCP) Server can expose that governed context to the tools agents already use.
Connecting an OpenSpec change folder to that framework closes a specific gap:
Specification framework: The TIM defines the relationships a change should touch, so a proposal or delta spec can be checked against the governed record.
AI-generated artifact auditability: Suspect flagging surfaces when an AI-assisted change affects a downstream requirement, test case, or risk item that hasn’t been reviewed.
Versioned governance: Any change a requirement undergoes through the MCP Server is written to that requirement’s version history, the same field-level record of who changed what, when, and why that governs every other edit in Jama Connect. Baselines and electronic signatures then give the change folder’s history a formal, auditable counterpart outside the repo.
Ourend-to-end requirements traceability practices can help you evaluate what evidence should connect. Teams can use Jama Connect forrequirements baselining across governed changes, electronic signatures, audit trails, test management, risk management, and industry frameworks aligned to standards such as International Organization for Standardization (ISO) 26262. Those capabilities help Quality & Regulatory Affairs teams demonstrate which approved requirement an AI-assisted change came from, what verification covers it, and what changed since the last baseline.
Building OpenSpec Into a Governed Traceability Workflow
OpenSpec’s repo artifacts capture what an AI agent was asked to build and why. On their own, they can’t confirm that work traces back to an approved requirement or a tested outcome, which is the gap that trips up teams shipping AI-generated code in regulated environments. Connecting those artifacts to a governed traceability record, whether that lives in Jama Connect or another platform, is what closes it.
What is the difference between OpenSpec and traditional requirements documents?
OpenSpec produces lightweight, version-controlled delta specs that describe only what a change affects, stored alongside code for AI agents to read. A formal requirements management platform like Jama Connect captures the complete requirements set with baselines, traceability, and audit history. OpenSpec works as a planning layer; requirements management remains the system of record.
Does OpenSpec replace a requirements management platform?
No. OpenSpec authors specifications and plans AI coding work, while a requirements management platform handles baselining, electronic signatures, and multi-level traceability for regulated programs. OpenSpec isn’t positioned as a replacement for dedicated application lifecycle management (ALM) or requirements management (RM) tooling.
Can OpenSpec work with regulated or compliance-heavy projects?
Yes, as an upstream specification layer. Every change ties back to a versioned spec, and folders are archived with date stamps for an audit trail. Regulated industries still need downstream traceability and inspection-ready evidence, which teams typically get by pairing OpenSpec with a platform such as Jama Connect.
Is OpenSpec open-source?
Yes, under the MIT License, so teams can inspect the repo-level workflow before adopting it. It requires a current Node.js runtime and installs via npm, pnpm, yarn, or bun, making it easy to test within an existing repo before expanding to team use.
AI coding assistants are now ubiquitous across software engineering teams, yet relatively few organizations have transformed how engineering itself operates. Teams write code faster while continuing to struggle with bottlenecks in requirements, specifications, testing, verification, compliance, and engineering governance.
That’s because becoming an AI-native engineering organization requires changes across the entire engineering lifecycle.
This article introduces the AI adoption maturity model, a practical framework for understanding the AI maturity levels for engineering teams and the capabilities organizations develop as they progress from manual engineering to multidisciplinary AI-driven development.
Keep reading to learn more about each level and see how you can scale your team responsibly.
A More Accurate Assessment of AI Maturity
Most organizations today measure AI adoption by tooling usage. They assess how many team members use GitHub Copilot, Claude Code, or Cursor, but while these are useful indicators, they don’t tell the whole story.
Using an AI coding assistant doesn’t necessarily mean an organization is building products faster, reducing risk, or improving engineering quality. Those outcomes depend on more than code generation.
Coding May Be Faster, But Product Delivery Isn’t
More software teams are embracing AI. In fact, 84% of surveyed software engineers reported using AI agents in their work, according to the 2025 Stack Overflow Developer Survey.
While they dramatically increase programming speed, eliminating what was long recognized as the bottleneck in complex systems development, many engineering organizations haven’t seen the same improvement in overall product velocity.
This is because writing code is only one activity in the entire engineering lifecycle. When one bottleneck was alleviated, more were discovered. Before code can be generated, requirements must be defined, reviewed, and translated into clear specifications. After code is written, it still needs to be tested, integrated, verified, and, in many industries, demonstrated to meet regulatory or customer requirements. As coding becomes easier, those activities become new constraints.
The Bottleneck Has Shifted
AI coding assistants exposed new engineering bottlenecks, shifting constraints upstream to requirements, specifications, and context engineering, and downstream to testing, integration, verification, and compliance.
AI can only build from the context it receives. If requirements are incomplete, specifications are ambiguous, or engineering knowledge is fragmented, AI simply produces mistakes faster.
Many organizations have already experienced this firsthand. AI coding agents can move quickly in the wrong direction by misinterpreting requirements, ignoring guidelines, or introducing defects.
The organizations seeing the greatest gains are creating better specifications, stronger governance, richer product context, and end-to-end traceability for the engineering systems surrounding AI.
That’s why measuring AI maturity by developer tooling alone no longer tells the whole story. A more useful measurement is how AI participates across the engineering lifecycle.
The AI Adoption Maturity Model provides a framework for understanding that progression.
AI Maturity Levels for Engineering Teams at a Glance
Organizations typically progress through five stages as AI becomes more deeply embedded. Each stage addresses a different bottleneck while preparing teams for the next level of maturity. While every organization’s journey looks different, we’ve consistently observed these five patterns as engineering teams scale AI.
AI Maturity Levels for Engineering Teams: AI Adoption Maturity Model
AI Maturity Level
Primary Focus
AI’s Role
Biggest Bottleneck
Hallmarks of Success
Typical Organization
Next Step
Manual Engineering
Establish engineering discipline
Little or no AI adoption
Documentation, manual effort, limited visibility
Requirements managed in Word, Excel, and static documents. Manual reviews and traceability. Engineering knowledge lives in people’s heads.
Organizations relying on document-based requirements and manual engineering processes.
Begin experimenting with AI in low-risk engineering activities.
Learn & Pilot
Understand AI capabilities
Individual experimentation
Developer time to experiment
Small AI pilots, coding assistant evaluations, prompt experimentation, initial governance discussions.
Teams exploring GitHub Copilot, Cursor, Claude Code, or similar tools on individual projects.
Expand AI into existing engineering workflows.
AI-Assisted Current Workflows
Improve developer productivity
AI supports existing engineering workflows
Human review, existing processes, fragmented workflows
AI assists with coding, requirements, testing, documentation, and engineering reviews while existing processes remain largely unchanged.
Organizations using AI coding assistants and introducing AI-assisted engineering workflows without changing development processes.
Reconfigure engineering around governed specifications and product context.
Spec-Driven Development
Maximize product velocity
AI agents build from governed specifications and product context
Building deterministic engineering context, governance, and traceability
Spec-Driven Development, context engineering, governed specifications, Live Traceability™, AI governance, AI-assisted verification.
Organizations redesigning software development around AI agents and structured product context.
Extend AI beyond software into multidisciplinary engineering.
Multidisciplinary AI-Driven Development
Scale AI across engineering disciplines
AI participates throughout the engineering lifecycle
Organizational transformation and cross-disciplinary coordination
Shared product context across software, systems, hardware, quality, verification, and compliance. Continuous engineering intelligence. Parallel AI-driven development.
Engineering organizations operating with AI across multidisciplinary product development.
Continuously optimize AI performance, governance, and engineering outcomes.
Breaking Down the 5 AI Maturity Levels for Engineering Teams
1: Manual Engineering
Every AI journey starts here. At this point, engineering knowledge primarily exists in documents, spreadsheets, email, and individual expertise. Requirements are managed in Word or Excel, and traceability is maintained manually. Reviews happen through documents and email. AI plays little or no role because very little structured engineering knowledge exists for it to use.
Characteristics
Static documentation
Manual reviews
Manual traceability
Limited engineering visibility
Knowledge locked in individual teams
Primary Objective: Create consistent engineering processes before introducing AI.
Biggest Bottleneck: Documentation and manual coordination.
At this stage, organizations begin experimenting with AI. Developers test AI coding assistants, prompt engineering techniques, and early AI workflows to understand where productivity gains exist. The goal here is learning rather than large-scale transformation. Teams can identify promising use cases while building internal confidence and governance around AI adoption.
Characteristics
AI coding assistant pilots
Small-scale experimentation
Team education
Initial AI governance discussions
Primary Objective: Gain enough knowledge to confidently move to broader AI adoption.
Biggest Bottleneck: Developer time available for experimentation.
3: AI-Assisted Current Workflows
This is where most engineering organizations operate today. It’s also where organizations mistakenly believe they’ve become AI-native. At this stage, they have AI-assisted developers, not AI-assisted engineering.
Developers use GitHub Copilot, Cursor, Claude Code, Windsurf, and similar tools to accelerate coding while maintaining existing engineering processes. AI improves productivity without requiring significant organizational change. Potential time-to-market gains reach up to 30% at this stage.
This is where organizations also begin extending AI beyond coding into engineering workflows. Examples include:
Current engineering processes remain largely unchanged. AI assists the workflow rather than redefining it. Refer to our AI-Assisted Software Workflow Playbook to see practical examples of these workflows in greater detail.
Primary Objective: Increase developer productivity while maintaining existing governance.
Biggest Bottleneck: Existing engineering processes, fragmented workflows, and human review.
4: Agentic Spec-Driven Development
This stage represents the biggest shift in modern AI software engineering. In Spec-Driven Development, AI agents work from governed engineering specifications and trusted product context rather than source code alone.
At this point, organizations stop treating AI as a coding assistant and begin treating it as an engineering participant. Product velocity gains have the potential to reach 5X at this phase of AI maturity.
This requires a significant reconfiguration of the software development process. Specifications become the primary source of engineering intent. Engineering knowledge moves from people’s heads into structured, deterministic artifacts. Product context becomes explicit rather than implied.
AI agents assist across:
Requirements decomposition
Specification authoring
Context engineering
Code generation
Test generation
Verification
Documentation
This is the foundation of Spec-Driven Development, where engineering teams maximize time-to-market by removing the upstream and downstream bottlenecks surrounding AI coding agents.
At the highest level of maturity, AI extends beyond software engineering across the entire engineering organization. Software, systems engineering, hardware, quality, verification, validation, and compliance teams all operate from the same governed product context.
AI helps coordinate work across engineering disciplines while maintaining governance, traceability, and engineering intent.
Organizations establish:
Shared product context
Parallel AI-driven development
Cross-disciplinary traceability
Continuous engineering intelligence
AI governance
Enterprise-scale engineering knowledge
Rather than accelerating individual engineering functions, organizations accelerate product development itself. This is where organizations can achieve true potential, reaching up to 10X in potential product velocity gain.
Primary Objective: Maximize product velocity across engineering disciplines.
Biggest Bottleneck: Organizational change and cross-disciplinary alignment.
How to Assess Your AI Maturity Level
Most organizations progress through these levels one stage at a time, while others may choose to jump straight to Spec-Driven Development after learning and piloting AI. Both approaches are feasible, but the choice depends on the organization’s level of urgency and capacity for change.
Ask yourself:
Does AI have access to governed product context?
Where does AI retrieve engineering context?
Are specifications structured for AI consumption?
Can another engineer reproduce an AI-generated decision?
Can AI-generated artifacts be traced back to approved engineering intent?
Is AI use governed and auditable?
Can auditors understand how AI contributed?
Can you trace generated code back to approved requirements?
Can multiple AI agents safely collaborate on the same product?
Can engineering teams confidently scale AI across multiple workflows?
These answers reveal much more about your AI maturity level than the coding tools installed inside your IDE.
Looking Ahead to AI Engineering
AI coding assistants have already altered software development as we know it. Looking ahead, the next competitive advantage will come from enabling AI across requirements, specifications, testing, verification, and governance. The key here will be using trusted product context.
As organizations progress from AI-assisted coding toward Spec-Driven Development, they discover that the limiting factor is now engineering context. AI agents need governed requirements, verified specifications, traceability, and engineering intent to make reliable decisions. That’s why organizations moving into Levels 4 and 5 increasingly invest in systems that manage product knowledge.
Jama Connect® was built for this exact challenge. It serves as the governed system of record that AI agents rely on for trusted engineering context. Its MCP server allows coding agents to retrieve approved requirements, specifications, traceability, and product knowledge while respecting existing permissions, workflows, and compliance controls.
Find Your AI Maturity Level
Every engineering organization is somewhere on this maturity curve. Understanding the AI maturity levels for engineering teams can help you identify which capability will unlock the next stage and what changes are needed to advance responsibly.
Our AI Maturity Assessmenthelps you identify where your organization sits today, what constraints are holding you back, and the next steps for advancing responsibly.
Our free AI Maturity Assessment helps engineering leaders:
Establish an AI maturity baseline.
Identify workflow gaps and hidden risks.
Strengthen governance and traceability.
Learn what to fix first and how to scale safely across workflows in our free AI Maturity Assessment.
Your team has been running Agile for years. Stories are planned in Jira, sprints run on two-week cycles, and the sprint board tells you exactly where everything stands. Releases ship on time, retrospectives close out action items, and the Definition of Done is defined and followed.
Then comes the requirement: Automotive SPICE® (ASPICE) compliance.
When your team maps Agile practices to what the ASPICE standard requires, the gaps become visible. Your Jira backlog manages work effectively, but the standard also expects a current product specification that reflects requirements at a given point in time. Your sprint board tracks delivery flow, and the standard expects the full chain of requirements to be traceable from stakeholder need to implementation. Your Definition of Done sets quality criteria.
In addition, the standard expects independent quality assurance records. Your retrospectives capture learning, but the standard asks a different question: Was the agreed process followed, and is there evidence to prove it? None of these are failures. They reflect how Agile methods are designed to work. ASPICE requires something more.
Agile SPICE is the recognized path to bridging that gap. It gives teams and assessors a shared framework for demonstrating ASPICE compliance in an Agile development context.
What Agile SPICE Actually Is
Agile SPICE is a Process Reference Model (PRM) and Process Assessment Model (PAM) published by intacs, the global body governing Automotive SPICE assessor training, examination, and certification. First released in 2022 and now at version 1.4.1 (released in July 2025 and fully aligned with ASPICE 4.0), it is designed to work alongside ASPICE, not replace it.
Agile SPICE supports the evaluation of ASPICE principles in Agile projects and the application of Agile methods in consistency with ASPICE. It introduces three dedicated Agile processes and interpretation notes for the ASPICE engineering and selected supporting processes.
The 3 Agile SPICE Processes and What They Cover
Three processes provide Agile-specific base practices for the areas of work management, partner collaboration, and quality assurance.
1: AGL.1: Agile Work Management
AGL.1 is the Agile equivalent of MAN.3 Project Management in ASPICE. It covers how an Agile team organizes and executes its work across the full management scope, including:
Jointly defining the product vision.
Assembling the right team with the right competencies.
Evaluating feasibility.
Managing stakeholder dependencies.
Estimating and prioritizing the backlog.
Planning iterations.
Tracking progress transparently.
Resolving impediments.
The work approach, including Definition of Ready and Definition of Done (DoR/DoD), must be defined, documented, and kept current.
2. AGL.2: Partner Collaboration Management
AGL.2 is the Agile equivalent of ACQ.4 Supplier Monitoring in ASPICE. It requires partners to establish a documented collaboration model covering:
Joint Agile events.
Joint artifacts.
Roles.
Information to be exchanged.
Partners share Definitions of Ready and Done, maintain aligned backlogs, and inspect progress continuously. Risks and impediments are managed collaboratively throughout development.
3. AGL.3: Agile Quality Assurance
AGL.3 is the Agile equivalent of SUP.1 Quality Assurance (QA) in ASPICE. In Agile, the self-organizing team structure makes independence harder to establish and demonstrate. ASPICE requires QA to be performed independently and objectively, without conflicts of interest, evaluated based on organizational and financial assignment.
Quality objectives are collaboratively identified and agreed upon, in line with the team’s work approach, governance criteria, and external customer requirements. Impediments affecting quality are tracked in the backlog, escalation paths are defined, and both are known to every team member and accessible to anyone in the organization.
What Agile SPICE Expects as Evidence
Agile SPICE provides interpretation and mapping of Agile work products to what ASPICE process indicators look for as evidence. These are the major gaps most Agile projects face.
The Product Specification and the Backlog Are Not the Same Artifact
Agile SPICE is explicit on this: the requirements valid at a given point in time must be fully derived from the product specification and cannot be represented solely by the historical progression of the product backlog.
The difference matters. A well-managed backlog records what the team planned and completed. The product specification records what the product must do and why, differentiated from the backlog’s historical record of work completed. The requirements valid at a given point in time must be derivable from the product specification, not reconstructed from the historical progression of the product backlog.
Without a product specification that exists independently of the product backlog, teams cannot demonstrate that all requirements have been identified, are current, and have been implemented completely, all of which an assessor will look for.
Traceability Across the Full Development Chain
ASPICE requires bidirectional traceability across the full development chain. Agile SPICE clarifies how that chain maps to the work products Agile teams produce: stakeholder requirement, system requirement, backlog item, architectural element, test case, and test result. This chain applies to changes too. When a requirement changes, the impact must trace through all affected work products: the backlog item, the architecture, tests, and downstream requirements connected to it.
Independent QA Records and Configuration Baselines
Agile SPICE separates two responsibilities: the team is jointly responsible for the quality of their processes and work products, while quality assurance is independently responsible for ensuring conformance to agreed quality objectives is achieved and maintained.
The standard allows QA to draw on iteration reviews, retrospectives, and DoR/DoD criteria as inputs. Agile SPICE requires independently produced evidence artifacts, including review evidence and quality conformance evidence, that demonstrate conformance was checked without conflict of interest. Sprint review minutes and DoD checklists can inform those artifacts, but cannot substitute for them.
Configuration management also applies to Agile artifacts. Backlog items, iteration backlogs, and iteration review information should be considered as configuration items and version controlled accordingly.
The configuration management approach must be updated each iteration, and baselines must be performed according to the Agile work approach, for example at the end of each major iteration or release. DoD criteria can contribute to baseline completeness checks, but baseline audits and baseline reproduction checks must still be planned and implemented.
Both are evidence gaps that Agile teams consistently discover late, often during assessment preparation rather than during development.
How Jama Connect Supports Agile SPICE Compliance
Most teams worry that achieving Agile SPICE compliance means disrupting the development workflows that already work. It doesn’t. Jama Connect® manages the STATE of your development effort while your team continues managing FLOW in whichever work management tool they already use, such as Jira or Azure DevOps.
Jama Connect can be integrated with these tools so work items synchronize automatically and developers continue working in their existing tools.
Product Specification and Traceability
The product specification is maintained in Jama Connect as a managed, current set of requirements, separately from the product backlog. Jama Connect keeps bidirectional traceability between stakeholder requirements, system requirements, backlog items, architectural elements, test cases, and test results live throughout development. When requirements change, downstream items are flagged through Jama Connect’s Suspect Links mechanism. Teams get immediate visibility of impact without waiting for a manual review cycle.
Requirements Exchange Across Partner Boundaries
Partners can exchange requirements at defined sync points, or share a common Jama Connect instance so every party sees the same current requirements, changes, and review status in real time.
Independent QA and Baselining
In Jama Connect, work products go through formal reviews that produce the review evidence Agile SPICE requires. The independent QA function uses these records, alongside other inputs, to produce quality conformance evidence. Customers and partners can be invited into Jama Connect reviews.
The resulting evidence record spans organizational boundaries rather than staying within a single team. Teams can implement a defined baselining approach in Jama Connect, with baselines created according to agreed events and procedures.
To learn how Jama Connect supports Agile SPICE compliance in practice, explore our Traceable Agile™ solution.
Can Agile SPICE Be Applied to Programs That Mix Agile and Waterfall Phases?
Yes. Many automotive programs run system-level and hardware engineering activities under a more traditional waterfall-aligned model while software development teams work in Agile iterations. The three AGL processes and the Part 2 interpretation notes apply to the Agile portions of a program without requiring the full program to change its delivery model.
Can We Apply Agile SPICE Without Changing the Agile Framework We Already Use?
Yes. Agile SPICE is framework agnostic. Whether a team is using Scrum, Kanban, SAFe (Scaled Agile Framework), or a hybrid approach, the existing work approach is the starting point. Agile SPICE provides interpretation notes that show how evidence from any of these frameworks maps to ASPICE base practice indicators.
Do the AGL Processes Appear in the ASPICE Assessment Report?
Yes, but as substitutes, not additions. The sponsor and assessor agree upfront which processes are assessed using Agile SPICE. The assessment still produces ASPICE capability level ratings on the same scale, so the report an OEM receives looks the same.
Artificial intelligence is transforming how engineering teams develop products, analyze requirements, and identify risks. But for organizations developing safety-critical or highly regulated products, the conversation is about doing so responsibly.
Many engineering leaders face the same challenge: How can we introduce AI into engineering workflows while maintaining control over the development process?
The answer isn’t simply choosing the right AI model. Successful AI adoption in regulated industries depends on governed workflows, human oversight, auditability, and traceability.
In this article, we’ll explore best practices that can help engineering organizations confidently scale AI while maintaining the compliance and quality their industries demand.
What Makes AI Adoption Different in Regulated Industries
Engineering teams in regulated industries face unique challenges when adopting AI. While AI offers tremendous opportunities to accelerate requirements reviews, improve risk analysis, and automate repetitive tasks, many organizations hesitate to introduce AI into engineering workflows because of legitimate concerns, including:
Maintaining compliance with industry regulations and standards
Ensuring engineers retain control over technical decisions
Providing auditors with clear evidence of how decisions were made
Preventing AI from becoming an ungoverned black box
These concerns are well founded. If AI operates outside established engineering processes, it can create uncertainty around approvals, documentation, and accountability.
The goal is to implement AI in a way that strengthens existing governance rather than bypassing it.
7 Best Practices for Successfully Using AI in Regulated Industries
1: Keep Humans at the Center of Every AI Workflow
One of the most effective ways to improve AI in regulated industries is by ensuring every AI-generated recommendation remains subject to human review and approval.
For example, AI can review draft requirements, identify ambiguities, suggest improvements, or flag potential risks. Engineers then evaluate those recommendations before deciding whether to accept, modify, or reject them.
This human-in-the-loop approach preserves engineering judgment while significantly reducing time spent on repetitive review activities. Instead of replacing subject matter experts, AI allows them to focus on higher-value engineering decisions where their expertise has the greatest impact.
2: Build AI into Existing Governance Processes
Rather than creating disconnected AI tools that operate outside established workflows, organizations can integrate AI directly into governed engineering environments.
When AI works within existing requirements management and review processes, teams can maintain:
This allows organizations to improve efficiency without sacrificing process integrity.
3: Maintain Complete Traceability
To maintain traceability, every recommendation, edit, or generated artifact should remain visible and attributable throughout the engineering lifecycle.
Strong AI compliance means teams can answer questions such as:
What changes were recommended?
Who approved them?
When were they implemented?
What information influenced the recommendation?
What version of the requirement was updated?
Maintaining a complete audit trail gives engineering teams confidence while providing auditors with the transparency they expect.
4: Standardize AI Through Reusable Personas
One of the more innovative approaches to AI governance is creating reusable AI personas. Instead of relying on generic prompts, engineering organizations can develop standardized personas that represent specific engineering disciplines or areas of expertise.
Each persona contains defined knowledge, responsibilities, and review criteria that can be reused across projects. This creates more consistent AI outputs while reducing the variability that often comes from ad hoc prompting. As AI adoption grows, reusable personas help organizations scale expertise without sacrificing consistency.
5: Automate Repetitive Tasks, Not the Critical Thinking
Requirements reviews and risk identification often involve highly repetitive work. Engineers spend valuable time reviewing requirement wording, checking standards, searching documentation, and identifying potential issues before technical discussions can even begin.
AI excels at these repetitive, rules-based activities. For example, AI can:
Review requirements against predefined quality criteria.
Scan engineering standards.
Generate traceable requirements.
Identify potential risks.
Produce structured recommendations.
Highlight missing information.
By automating these mechanical tasks, engineering teams gain more time to focus on innovation, architecture, design tradeoffs, and technical problem solving.
6: Ensure AI Respects Existing Permissions and Security Controls
Successful use of AI in regulated industries also depends on maintaining organizational security. Engineering teams need confidence that AI only accesses information users are already authorized to view.
Rather than introducing new security models, AI should inherit existing permissions and authentication policies. When AI operates using the same access controls as engineering users, organizations maintain consistent governance while reducing security concerns.
7: Make AI Recommendations Auditable
One of the biggest concerns surrounding generative AI is the perception that it’s a black box. The best way to address this concern is through transparency.
Rather than allowing AI to silently change engineering artifacts, organizations should ensure recommendations are visible, reviewable, and fully documented before implementation.
When every recommendation includes clear context, attribution, and version history, AI becomes easier to trust and audit.
This level of transparency is essential for organizations operating in highly regulated environments.
Putting AI Into Practice
Modern engineering platforms are making these best practices practical by integrating AI directly into governed development workflows.
Jama Connect® provides the contextual model layer that AI needs to understand product requirements, relationships, reviews, and traceability, giving AI the engineering context that standalone AI tools lack.
Using technologies like the Model Context Protocol (MCP), organizations can connect AI to requirements management while maintaining permission controls, preserving traceability, and keeping engineers firmly in control of every decision.
Instead of replacing engineering processes, AI becomes another governed participant within them, accelerating reviews, improving risk identification, and helping teams produce higher-quality requirements without compromising compliance.
It’s About Governance, Not Just Technology
The future of AI in product development won’t be defined by which model organizations choose. It will be defined by how effectively they govern AI throughout the engineering lifecycle.
Organizations that establish repeatable, transparent, and auditable AI workflows will be better positioned to improve productivity while maintaining the compliance, traceability, and quality their industries demand.
By keeping humans in control, preserving auditability, standardizing AI behavior, and embedding AI within existing engineering processes, organizations can confidently scale AI without sacrificing trust.
We demonstrate how governed AI workflows, reusable AI personas, and Model Context Protocol streamline requirements reviews, improve risk management, and help engineering teams maintain compliance while accelerating product development.
Artificial intelligence (AI) coding assistants can make individual coding tasks appear faster, while organizational delivery metrics lag. The speed may show up in commits and pull requests (PRs), while customer-visible delivery stays flat. Those gains get absorbed somewhere between the individual keyboard and the production release, lost to downstream bottlenecks.
Vice Presidents (VPs) and Directors of Engineering often see individual activity rise while release performance stays flat. We can make individuals faster, but making the whole system faster without compromising quality is harder, especially as teams scale across software, systems, hardware, quality, and verification.
This blog covers the metrics, requirement practices, and traceability habits that help teams improve developer velocity without trading away quality.
What Is Developer Velocity?
Engineering teams improve developer velocity by delivering valuable software to customers faster and more efficiently. The emphasis sits on outcomes, which means shipping features that solve real problems and create measurable business impact.
We need to separate three terms that get used interchangeably. Velocity describes how much work a team can reliably complete in a sprint, which makes it a planning and predictability signal. Productivity looks at how efficiently value is created per unit of effort. Throughput captures the total productive capacity moving through the system over a period. Developer experience covers the conditions that produce output more than output itself, and sustainable velocity depends on those conditions holding over time.
Enterprise velocity benchmarks are most useful when they combine technology, working practices, and organizational support with team-level output. The clearest signal comes from treating velocity as a property of the delivery system.
Why Developer Velocity Stalls as Engineering Teams Scale
Scaling slowdowns usually emerge from the system around the team. Each contributing factor is reasonable on its own, and together they compound into delivery drag:
Coordination overhead grows quickly: As teams grow, dependencies, handoffs, review queues, and release coordination consume capacity before added headcount improves delivery.
Unclear or shifting requirements force rework: Late changes ripple through design and verification plans and are far harder to absorb once development is already underway.
Late-stage defects multiply the cost of every miss: A missed requirement is easy to clarify while the system is still being defined, but expensive to fix once teams are integrating, testing, or certifying the finished product.
Context-switching and fragmented tooling drain capacity invisibly: When a developer waits too long for tests to run, the problem goes cold, they move to another task, and they later pay to rebuild the context they’d already paid for once.
Frequent interruptions, parallel project assignments, and fragmented tools force developers to spend mental energy rebuilding context that could otherwise be devoted to solving the problem at hand. These constraints are easier to reduce when leaders measure flow instead of individual activity.
How to Measure Developer Velocity the Right Way
Measurement can turn good intentions into bad incentives when we choose the wrong signals. Wrong metrics can steer us toward worse outcomes.
Story Points and Lines of Code Mislead in Predictable Ways
Story points support team planning better than individual measurement, and using them for performance evaluation destroys their value as planning tools. Story points completed are often less useful productivity signals than cycle time and lead time. Lines of code miss a different problem. Different languages and styles can express similar functionality in very different line counts, and the metric may reward verbose code and gaming behavior. Activity-based metrics like these provide a weak view of software quality or team effectiveness.
Delivery Flow Metrics Tell a Truer Story
Change lead time and deployment frequency help describe throughput, while failed deployment recovery time and change failure rate help describe stability acrossdelivery and stability metrics. Flow-oriented metrics add flow efficiency, the percentage of time spent on active work versus waiting, which exposes the queues and handoffs that pure speed metrics miss. Cycle time carries one caveat worth respecting. When leaders fixate on delivery speed alone, teams can cut quality and accumulate technical debt.
Outcome-Based Signals Beat Output Vanity Metrics
A useful measurement program uses several dimensions. Trying touse a single metric to define productivity creates blind spots. We need to look at multiple dimensions together, so leaders can see tension between speed, collaboration, satisfaction, quality, and flow. Balanced measurement frameworks do this by weighing throughput against developer experience, which produces more useful conversations and reduces fear-driven single-number pressure.
Proven Ways to Improve Developer Velocity
Sustainable velocity improves when teams reduce wasted work before it reaches downstream recovery:
Stabilize requirements early to cut rework at the source: Rework can absorb significant software effort, and poor communication around requirements is a common cause. Reducingerrors in your requirements may be the single most effective action developers can take to improve project outcomes. Catching ambiguity before it spreads is the most useful early intervention available, because the cost multiplier on a late-caught defect dwarfs the cost of getting the requirement right the first time. Teams using AI coding agents are formalizing this discipline throughspec-driven development for AI agents, where a structured spec defines what should exist before an agent generates any code.
Establish clear traceability from requirement to test: A clearlink from requirement to test ties a requirement back to its sources and forward to design artifacts, code, and test cases. That bidirectional chain supports impact analysis and gives teams evidence for regression testing and compliance. Traceability scores had a statistically significant relationship with cycle time and quality in ananalysis of over 40,000 projects, and top-quartile performers outperformed bottom-quartile counterparts by a factor of 2.5 in test case execution and defect detection.
Shorten feedback loops with continuous integration: Improving continuous integration maturity makes integration and regression feedback part of the development workflow, so teams can discover integration errors sooner and reduce check-in overhead. Fast, automated feedback lets us catch integration and regression problems while the work is still fresh, before a developer has to reconstruct the context from memory.
Cut handoff friction between disciplines: Delivery friction comes from the effort required to keep context aligned across boundaries when teams rely on manual coordination. Cross-discipline misalignment can compound quickly. Interface, systems, operations, and software decisions can create constraints for one another without early coordination. Practices that help include embedding architects inside development teams and setting clear expectations for PR reviews. Value stream mapping can also reveal where handoffs create delay.
Those practices work best when teams also avoid measurement habits that reward the wrong behavior.
Common Mistakes That Quietly Slow Engineering Teams Down
Some velocity killers hide within reasonable-sounding management decisions, especially when teams tune dashboards rather than the delivery flow. Chasing a single speed metric and treating velocity as an individual measure creates related failure modes. Once a measure becomes the target, people tune the measure instead of the outcome. Code coverage targets can produce meaningless tests, and deploy-frequency targets can encourage empty deployments.
The Satisfaction and well-being, Performance, Activity, Communication and collaboration, and Efficiency and flow (SPACE) principle measures across several dimensions in tension, so no single number can be gamed in isolation. When teams are pressured to increase velocity, they may inflate story point estimates and cut corners on quality.
Velocity works best as an observation about a team’s capacity. Cross-team velocity comparisons are misleading because each team calibrates story points within its own context. Stronger engineering measurement programs focus on system-level outcomes and team-level conditions, and they avoid individual output metrics entirely.
Unmanaged requirement churn creates a different blind spot. It helps to distinguish refactoring, which can be healthy, from rework, in which recently shipped code must be rewritten because the original work missed the mark. A rising rework pattern is a signal worth investigating. Delivery dashboards can hide rework, so teams relying solely on deployment metrics can have a blind spot exactly where requirements-related waste lives.
Building Developer Velocity Into Your Engineering Operations
To make velocity easier to manage repeatably, connect delivery metrics to the specification and verification records already used during development. We may see early signals from focused improvements, especially when existing bottlenecks are obvious, but the trends that matter take longer to prove out. Delivery and experience metrics need enough time to show whether changes are producing sustainable improvement or a short-lived spike.
Repeatable velocity management combines quantitative delivery metrics with qualitative experience signals. Teams should start with controllable input metrics they can actually influence and limit the set to avoid overload. As specifications and verification carry more delivery pressure, getting requirements clarity right becomes the best place to focus.
Regulated teams that already maintainend-to-end traceability across the lifecycle have a structural advantage here. They built the specification infrastructure everyone else is now being told to adopt.
How Jama Connect Supports Developer Velocity
Complex, regulated product development slows when teams manage requirements and traceability across disconnected documents and spreadsheets. Jama Connect® is web-based requirements management and traceability software that keeps those records connected.
In manual workflows, a mid-program requirement change forces someone to walk every downstream link by hand to find affected test cases and design elements. Live Traceability™ addresses this failure mode by maintaining real-time upstream and downstream visibility and eliminating the need for periodic manual reconstruction.
Withimpact analysis on every change, teams can review affected work before a change ships, and compliance documentation is built as a byproduct of development. For a Systems Engineer, that means less manual traceability work across documents and spreadsheets.
For a Test Engineer or Verification and Validation (V&V) Engineer, it means linked test cases can show which requirements are covered and which tests need review when something changes upstream. For Quality and Regulatory Affairs, it means audit-ready documentation is built from the same requirements and verification evidence the engineering team uses every day.
Improve Developer Velocity Without Losing Control
Developer velocity improves when teams manage the whole delivery system, individual coding speed alone is not enough. Clear requirements, traceable verification, and balanced metrics give leaders a way to move faster without hiding quality risk. To see how Jama Connect can help connect requirements, traceability, verification, and impact analysis in one workflow, start afree 30-day trial of Jama Connect.
Frequently Asked Questions About Developer Velocity
How is developer velocity different from productivity?
Velocity measures how much work a team can reliably complete per sprint, which makes it a planning and predictability signal. Productivity measures how efficiently value is created per unit of effort. A team can have high velocity while producing low-value output, which is why the two should never be treated as the same thing. Use velocity for team planning instead of performance scoring. Productivity conversations should include customer value, quality, and delivery flow so teams do not chase completed work that does not matter.
What metrics best track developer velocity?
Cycle time and lead time give a stronger view of delivery performance than story points and lines of code. The stronger approach measures across several dimensions in tension, which makes gaming harder. Start with cycle time, lead time, change failure rate, and recovery time, then compare those signals with requirement stability and test coverage. Teams working in regulated environments should also connect delivery metrics to requirements traceability so speed gains do not hide verification gaps. In Jama Connect, that link between requirements, tests, and delivery records is maintained as work changes.
Can improving velocity hurt software quality?
Improving velocity can hurt quality when teams focus only on speed, but balanced delivery and stability metrics keep that tradeoff visible. Speed and stability can move together when teams improve the system around delivery, along with individual coding activity. The risk rises when teams adopt speed-focused tooling without process discipline, because individual activity can increase while delivery stability suffers. Fundamentals like small batch sizes and thorough testing still matter.
How long does it take to improve developer velocity?
Teams may see early improvement from focused effort when bottlenecks are clear. Deeper trends in delivery and experience metrics take longer to become meaningful, so treat velocity as continuous improvement rather than a one-time fix.
One of the challenges I often hear from our automotive customers is that a large portion of time disappears into tasks that are both very manual as well as very tedious.
An example of one of these tasks is scanning standards or regulatory documents, finding consistencies both between the standards and their internal requirements, then tracing them down to relevant system requirements or generating newly needed requirements from them.
There is much that can be gained by bringing AI agent toolkits into the equation, while keeping key judgement points in human hands.
Two technologies come together to optimize this workflow:
Independently built agent toolkits that are specifically for automotive engineering workflows.
Model Context Protocol (MCP) built specifically to give governed access to requirements and traceability within Jama Connect®.
Putting these together gives teams the capability of taking AI generated content from standards all the way to auditable and traceable artifacts, without the need of a manual data entry gap or consistency check in between.
Dedicated AI Agents Know the Standards
The automotive safety and security domain is very well suited to AI assistance and augmentation as so many of the workflows are very structured and driven by standards and regulation. Take standards like ISO 26262, ISO 21434, ASPICE, ISO 21448 (SOTIF) and you have a strong definition of specific work products with defined content requirements.
A Hazard Analysis and Risk Assessment (HARA) or Threat Analysis and Risk Assessment (TARA) has defined structures. Safety goals are asked to have specific attributes. Functional Safety Requirements (FSRs) derive from safety goals in predictable ways.
AI agent toolkits are being developed to take that structured knowledge and turn it into specialized agents who can do the analysis work for you.
Instead of spending time scouring the standards to build the needed requirements for a function, create a safety engineer agent for ISO 26262, a cybersecurity analysis agent who understands ISO 21434, an agent who understands the autonomous safety standards, and have them work together to build the necessary requirements and traceability for that function.
The AI takes care of the mechanical heavy lifting of standard analysis, formatting compliance, and first-draft generation. The SME engineer then applies contextual judgment, domain expertise, and accountability that no AI system can replace, particularly in a safety-critical domain where the engineer’s professional and legal responsibility is necessary.
The toolkit acts essentially like a knowledgeable engineering colleague who never forgets the standards but leaves the final verdict to the SMEs who are responsible.
This content could be created and then manually copied over into Jama Connect or fed through the API, but these introduce unnecessary bottlenecks when the process could be streamlined directly through an MCP.
Jama Connect Via MCP
Model Context Protocol (MCP) is a standardized interface that allows AI systems to interact directly with external tools and platforms. An MCP server for Jama Connect exposes the platform’s capabilities, such as creating items, updating attributes, establishing trace links, and querying project structure as operations that an AI agent can invoke directly during a workflow.
This adds context. Instead of analyzing a function in the abstract, the AI has direct access to the project’s actual requirements structure, existing items, coverage relationships, review statuses, and gaps in the current traceability graph, which changes the quality of the analysis.
Use Case: Hazard Analysis
An AI suggesting candidate hazards for a function is more useful when it can see which system-level requirements already exist in the project, which hazards have already been identified, and where coverage links are currently missing. The suggestions are grounded in the project’s living state rather than a generic interpretation of the standard.
The toolkit can now generate the content and trace it automatically in the predefined structure within Jama Connect, and then it’s up to the engineer to review the content and give approval throughout the process.
Here is what this might look like for a HARA workflow:
The engineer invokes the safety agent with a description of the function under analysis. For example: an automated emergency braking system operating in urban environments at low speeds.
The agent applies ISO 26262 Part 3 methodology to produce a structured hazard identification, severity/exposure/controllability ratings, ASIL determinations, and candidate safety goals.
Via the Jama Connect MCP, the agent creates the HARA items directly in the live Jama Connect project, populated with the generated content, and associated with the appropriate upstream items.
Safety goals are then created as downstream items, with coverage relationships to the HARA hazards already established.
Any items created through this assisted workflow are labeled as AI-assisted drafts in Jama Connect so that the engineer can quickly filter and review them.
The engineer reviews the generated content in Jama Connect, modifies what needs modification, and formally sends the items for approval, triggering the review workflow that the project’s functional safety process requires.
What AI should not be doing in a regulated safety context is determining final ASIL classifications, asserting compliance completeness, or producing artifacts that are treated as authoritative without explicit engineer review and approval. The professional and legal accountability for safety analysis outputs sits with the engineer, and the tooling should make that accountability concrete rather than diffuse it.
The source and history of every item visible and auditable, a requirement for any safety process that may face external assessment. An item created through AI-assisted analysis is not inherently less valid than one created entirely manually, but it must be traceable as such, and it must carry evidence of an engineering review before it can be treated as authoritative.
Move Faster With AI Agent Toolkits and Jama Connect MCP
What once took hours or even days can now be compressed into minutes, with effort focused on reviewing and refining results rather than manually creating them from scratch.
Engineering time is concentrated where it delivers the most value: applying expertise, judgment, and accountability instead of performing repetitive administrative tasks.
That speed comes with a clear accountability structure. AI agent toolkits do the analytical heavy lifting but every item that enters the authoritative record does so because an engineer reviewed and approved it. Items created via MCP are labeled as AI-assisted drafts in Jama Connect and cannot be treated as authoritative until a formal review is completed. That boundary is what makes this approach defensible in regulated environments and auditable.
For teams already using Jama Connect, the MCP approach is also complementary to the AI capabilities being built directly into the platform through Jama Connect Advisor™. Advisor supports in-application AI assistance such as analyzing requirement quality against INCOSE and EARS standards, generating test cases from requirements, as well as surfacing missing traceability links through relationship discovery. The MCP extends that reach further, allowing externally configured agents to operate across broader project context and bring standards-specific domain knowledge into the same governed workflow. The two layers work on the same system of record, so the governance model stays consistent regardless of where the AI assistance originates.
As AI agent toolkits become more capable and MCP adoption grows across the engineering toolchain, the scope of what can be analyzed, suggested, and routed for human review will expand significantly. Teams that establish the governance model now will be better positioned to absorb this capability without compromising the process integrity that safety-critical development demands. The goal is not to automate engineering judgment out of the loop. It is to give engineers more leverage over the parts of their work that genuinely require it.
Learn More About AI in Automotive Engineering
As AI becomes more capable, automotive organizations face a broader challenge: how to adopt AI at scale while maintaining governance, traceability, functional safety, and cybersecurity compliance.
To explore how leading automotive teams are navigating these challenges today, watch our on-demand webinar, How AI-Driven Engineering is Transforming Automotive Development, where I discuss practical strategies for balancing AI-driven innovation with the rigor required for safety-critical development.
A two-person team ships a working product in three weeks. Eighteen months later, that same team has fifteen engineers, four enterprise prospects in the pipeline, and nobody who can answer a basic question about which features trace back to a committed requirement. The product that moved fast now moves slowly, and every change introduces another round of uncertainty over who made the decision. The speed that won the early market has quietly become a tax on every release.
This pattern recurs across software startups. The informal coordination that worked in the founding group breaks down as the team grows, and the cost shows up as rework when lost knowledge stalls enterprise deals. A startup that builds traceability into its workflow early keeps the speed that won its first market while gaining the audit evidence enterprise customers demand.
This guide covers why startup development breaks at the scaling point, what changes when the first regulated or enterprise customer arrives, and how to build a repeatable requirements process before growth turns every release into a reconstruction exercise.
What Is Startup Product Development?
A startup often begins with a minimum viable product (MVP) and then has to turn that early product into a scalable, repeatable offering for a growing, increasingly demanding customer base. At this stage, the company is still proving the product can deliver real customer value. The MVP helps the team learn quickly with limited effort, with each build, release, and measurement cycle informing what comes next.
Startups often struggle during that transition because the operating model changes faster than the team’s habits. Early-stage work prioritizes time to market, quick iterations, and full-stack generalists, while growth-stage work shifts toward feature release velocity, specialized engineers, formal sprint processes, and tech debt management. Scaling means building repeatable systems that hold up as the team grows, so a decision made once isn’t relitigated every time a new engineer joins.
Why Startup Product Development Efforts Break at the Scaling Point
Team size often triggers the failure point earlier than founders may expect. In small teams, direct conversation can carry most product decisions. As the company grows,informal communication across teams becomes harder to sustain, and coordination work begins to crowd out the engineering work the team was hired to do.
Shared context breaks is usually the first thing to break as a team grows. Small teams get an enormous amount done informally because everyone understands what kind of decision is being made. That understanding fades as the team grows, and a new hire can’t absorb it on day one, so every new engineer slows the team down before they speed it up.
Misalignment between what was built and what was specified often surfaces at the worst possible moment. Once requirements and design move downstream, a defect can force changes across design, code, test, and customer expectations at once. Catching confusion while the requirement is still being shaped is far easier than discovering it during integration, a failed test, or a customer complaint. When product managers and engineers drift apart, teams pursue features that are hard to build while engineering decisions drift from user needs, and the gap stays invisible until a missed deadline or a failed customer demo surfaces it.
A few recognizable moments signal that informal coordination has stopped scaling:
Headcount crosses the context threshold: A new engineer can no longer absorb how the product fits together from hallway conversations alone, so onboarding slows the whole team.
The first enterprise deal arrives: A security questionnaire asks for evidence that lives only in people’s heads or scattered spreadsheets.
Change becomes expensive: A single requirement change forces manual hunting through design, code, and test to find everything it touches.
When two or three show up at once, a lightweight process pays for itself.
How Lean Speed Turns Into Hidden Technical and Process Debt
Lean startup work often relies on quick solutions deliberately, which is fine until those shortcuts accumulate invisibly. The useful distinction is between debt the team consciously accepts and records, and debt that accumulates through undocumented shortcuts, rushed decisions, and assumptions no one revisits. The second kind builds silently until it creates a crisis. When developers are aware of technical debt, they can plan around it, but hidden debt tends to surface unexpectedly and is harder to mitigate.
Undocumented decisions are among the costliest forms. When developers leave a startup, they take critical project context with them because small teams rely on tacit knowledge rather than durable records. Design rationales, hidden assumptions, and the reasoning behind a tradeoff disappear when no one writes them down. New bugs take longer to fix because nobody knows the original intent, and small changes become risky because no one is certain about dependencies.
This debt often appears in bug-fix queues and onboarding, while requirements rework compounds both problems:
Developer time lost: Developers spend capacity on maintenance and debt cleanup that could otherwise go toward new product work, and early technical shortcuts can slow feature delivery.
Avoidable rework: Development effort can be diverted into correcting work that traces back to misunderstood, incomplete, or poorly documented requirements.
Hiring more engineers doesn’t solve this if poor documentation is the actual problem. Every new developer added to an undocumented system needs the same hand-holding as the previous one, which worsens the bottleneck.
What Changes When a Startup Adds Its First Regulated or Enterprise Customer?
The first large enterprise deal brings a new kind of scrutiny. Enterprise procurement teams can include finance, legal, compliance, engineering, systems, quality, regulatory, and test leaders, and they won’t sign contracts with vendors that present a risk to their data. Sales closes the deal; the customer sends a security questionnaire that asks whether you have a System and Organization Controls 2 (SOC 2) report, and a negative answer can stall or kill the deal.
SOC 2 discussions quickly become evidence discussions because buyers want to see security controls and, for mature reviews, proof that those controls have operated over time. For European enterprise sales, additional security and privacy expectations may come up before contract review begins. For teams building medical software, design-control expectations can put documented change procedures and audit trails into the development conversation earlier than a startup might expect.
At that stage, spreadsheets and chat threads stop working as a system of record. Auditors and enterprise buyers expect evidence, history, and decision records to be connected and retrievable. Spreadsheets make it hard to track changes or user actions, version control collapses into competing copies of the same file, and evidence ends up scattered across inboxes and shared drives rather than tied to the record it supports. Spreadsheet-based compliance forces teams to explain how their process works rather than demonstrate control through the system itself, inviting deeper audit scrutiny.
How to Build a Repeatable Product Development Process Without Killing Velocity
A small team can sustain lightweight practices that ride along with the work it already does. Regulated development leaves room for how teams meet rigorous objectives, and safety-critical teams can usehybrid regulated development approaches that combine plan-driven controls with iterative development.
Start With Requirements a Small Team Can Sustain
Requirements are the place to start. Easy Approach to Requirements Syntax (EARS) constrains textual requirements with a small set of keywords and a structure that separates preconditions, triggers, and system responses. A requirement is traceable when it is uniquely and persistently identified with a tag. For example, after defining the personal identification number (PIN), “Prompt_PIN: The software shall prompt the user for the PIN” gives the requirement a stable identifier the same wording without the tag lacks.Adopting the EARS notation can reduce vagueness, complexity, omission, and untestability.
Connect Requirements to Design, Code, and Test
From there, connect each requirement to the design, code, and test phases so that coverage gaps surface early. Teams can define verification expectations and establish traceability to test cases at the initial definition. In agile teams, traceability checklists fold into existing sprint ceremonies without a separate documentation burden. Teams using behavior-driven development make traceability easier still, since executable specifications already connect user stories to test execution.
Choose Tooling That Surfaces Gaps Automatically
The contrast in scaling between ad hoc tooling and a connected requirements workflow shows up in coverage visibility, audit readiness, and rework risk.
Dimension
Ad Hoc Tooling (Spreadsheets, Chat)
Connected Requirements Workflow
Coverage Visibility
Manual spot checks, gaps found late
Unlinked requirement or test surfaces as a gap immediately
Audit Readiness
Weeks of war-room assembly before each audit
Evidence current and retrievable on demand
Rework Risk
High, with misalignment discovered at integration
Lower, with change impact visible before code is written
Amanually maintained traceability matrix deserves caution before committing to it. Curating links by hand across analysis models, design, source code, and test cases creates exactly the overhead that kills velocity.
Keep Requirements Clear as Coding Agents Take Over More Work
As coding agents enter the picture, clear requirements carry more of the validation burden.Vibe coding without specifications increases the risk of hallucinated calls, inconsistent outputs, and changes that weaken validation to resolve errors. The constraint is shifting away from typing code and toward writing clear, complete requirements a human or autonomous agent can act on. A specification on its own is still flat text, though. Without a system that records how each requirement connects to design, test, and the reason it exists, an agent has no reliable context to reason against, and a year from now, no one can explain why a piece of logic is there.
How Jama Connect® Supports Startup Product Development
When a startup hits the wall where informal coordination stops working, and the first enterprise customer starts asking for audit evidence, a single source of truth connects requirements to design, code, and test. Jama Connect is a web-based requirements management and traceability platform built for complex, regulated product development, and it gives a growing team a connected workflow while letting engineers keep their existing tools.
A coding agent or a chatbot can draft a requirement or generate code, but it works from flat text with no durable picture of how that requirement connects to a design element, a test case, or a regulatory obligation. Traceability Information Models (TIMs) in Jama Connect supply that picture.
A TIM defines the expected relationships across the workflow and flags missing downstream items, so a system requirement with no linked test case surfaces as a coverage gap on its own. That structured product context is what gives Artificial Intelligence (AI) output something reliable to reason against. Live Traceability™ then ties each high-level requirement to whichever tests and design artifacts satisfy it, sogaps surface as they form instead of at the next audit, and bidirectional Jira integration lets software teams keep working in Jira.
Build Your Startup Product Development Process Before Scaling Slows You Down
The scaling wall is predictable, which means it can be prevented. A connected record answers the questions auditors, enterprise buyers, and your own engineers keep asking, and the payoff compounds as the team grows. Grifols cutmedical device development time by 80 hours per project after moving its requirements off disconnected tools.
If your team is building toward that first audit or enterprise deal, you don’t have to wait for a missed deadline to find the gaps. You can run your own check andstart a free 30-day trial.
Frequently Asked Questions About Startup Product Development
When should a startup formalize its product development process?
Common inflection points include growing from a single founding team into multiple collaborating teams and closing the first enterprise deal that triggers a security questionnaire. Once coordination becomes the bottleneck, that’s the signal to adopt a lightweight process for selecting requirements management tools you can iterate on rather than a heavyweight system you’ll resent.
What is the difference between an MVP workflow and a scalable product development process?
An MVP workflow is built for validated learning with the least effort, so generalists ship quick iterations and discard whatever doesn’t land. A scalable process is built for repeatable delivery, so specialized engineers work in formal sprints against traceable requirements with defined verification. It also defines who owns requirement decisions, how changes get approved, and where release evidence lives, which is where thefour fundamentals of requirements management come in.
How do startups prepare for their first compliance audit?
A first-time audit usually starts with a gap analysis comparing your existing controls against the target framework, since preparation often reveals gaps that were invisible during normal execution. Teams then assign owners for each control domain, centralize evidence, and start with the minimum practical scope. Pulling that evidence is far faster when requirements, tests, and changes already live in a connectedrequirements traceability matrix for audits, rather than scattered spreadsheets.
Do early-stage teams need requirements traceability?
For teams building regulated or enterprise software, yes. The traceability matrix engineering uses to surface coverage gaps is structurally the same artifact auditors ask for, so building it once in Jama Connect serves both purposes. Teams shipping purely consumer software with no audit exposure can defer it, but most startups underestimate how soon that first enterprise questionnaire arrives.
Agent-first software workflows can begin with an empty git repository and a team of coding agents. By shipment, application logic, tests, continuous integration (CI) configuration, documentation, and internal tooling may all come from agents. The shift moves engineering work to a different layer. The job now is to design the specs, constraints, tools, and feedback loops that agents use to produce reliable work.
This guide covers what harness engineering is, how spec-driven development and the Model Context Protocol fit in, why agents need a product context layer, and how to build agent workflows that hold up under audit.
What Is Harness Engineering?
Harness engineering follows a single principle. Humans provide instructions, while agents execute them. Our job shifts from writing code to designing environments, specifying intent, and building feedback loops that let coding agents perform reliable work. We prioritize work, translate user feedback into acceptance criteria, and validate outcomes. When an agent struggles, that signal identifies missing documentation or guardrails, and we feed it back into the repository.
In coding-agent systems, “harness” refers to the core agent loop and execution logic underlying the agent experience. The same idea can be framed more broadly as the collection of specifications, quality checks, and workflow guidance that govern the loops an agent runs. In shorthand, the agent is the model plus its execution loop. The model writes code. The execution logic checks whether that code is correct and aligned with intent. Building and maintaining that execution layer means working on the loop itself, rather than generating code prompt by prompt.
Why the Engineer’s Job Changes When Agents Write the Code
Progress slows when the environment is underspecified, even when the agent can generate code. The agent lacks the tools, abstractions, and internal structure to make progress toward high-level goals. The missing work is scaffolding, the tools and structure that help agents do useful work.
Engineers build the structure that agents read. We also build feedback loops as infrastructure, with tools that let agentsverify their work in context after producing a first answer. In one common agent-loop pattern, an engineer writes docstrings and assertions, the agent generates the implementation, and failed assertions produce tracebacks that the environment can feed back into another attempt.
Agent legibility shapes day-to-day results. Agents can only use information available in their active context while running. Details stored in Google Docs, chat threads, or individual memory do not guide the system unless they are surfaced to it. Versioned materials such as code, markdown, schemas, and executable plans are what the agent can work from.
Context layers are organized so that an agent can reason about the business domain directly from the layer. In the same way we improve code navigability for new engineering hires, the goal is to enable an agent tounderstand boundaries and intended behavior directly from durable project artifacts. Agents are most effective in environments with strict boundaries and predictable structure.
How Spec-Driven Development and MCP Set the Stage for Harness Engineering
Agents build more reliably against durable specs. Spec-driven development (SDD)puts the specification at the center of the workflow. Engineers describe what to build, refine it through structured phases, and let the agent implement it. The reframe matters because development moves from code as the source of truth to intent as the source of truth.
The Model Context Protocol (MCP) connects large language model (LLM) applications to external data sources and tools through a client-host-server architecture. Servers expose three primitives. Resources are data sources like file contents or database records, tools are executable functions an agent can call, and prompts are reusable interaction templates. MCP closes a practical gap in agent work, because engineering work rarely stops at editing files. It also involves checking tickets, querying production data, testing in a browser, and writing changelog entries. Much of that work happens outside the repo. MCP is one way that external context reaches the agent.
Together, SDD and MCP give agents stable inputs to read against, whether that context arrives as a spec file or through a structured server.
Why Agents Need a Product Context Layer
When knowledge remains in chat threads, scattered docs, and people’s heads, agent work exposes the gaps. Common context failure modes include context poisoning, where incorrect information compounds. Context distraction has the agent repeat past behavior instead of reasoning afresh. Context confusion lets irrelevant tools cause wrong choices. Context clash leaves the agent stuck on contradictory information.
Repository knowledge alone does not close this gap because a codebase does not contain specific categories of context. Without semantic context, agents can generate code that violates architectural principles. Without historical context, they can reintroduce previously resolved problems. The repo holds code history but not the business authorization context, the human approval chain, or the task-level justification behind a decision.
The examples are the kind every engineering team recognizes, like a field named calc_temp_v2 that two engineers know is a deprecated staging column, or a metric redefined mid-year. None of that survives cleanly in the repository, and agents cannot reliably recover it after the fact.
For regulated, multi-team products, the gap turns into an exposure. Regulated environments need decision provenance, and partial answers and limited traceability make it harder to show how an answer was produced. Those links become part of compliance evidence.
How the Traceability Information Model Gives Agents Structure and Context
Artifact types, relationship types, and enforcement rules can be defined before requirements work begins through aTraceability Information Model for requirements (TIM). It specifies which traces are required (a system requirement must link to at least one test case), which are optional, and which are prohibited. A spreadsheet-based matrix records links at a single point in time and diverges the moment anything changes, whereas a TIM is a governing schema that the tooling enforces. Missing downstream items get flagged automatically rather than surfacing at a milestone review after orphan requirements have already accumulated silently.
That model gives the spec an enforced relationship layer. SDD writes a structured, behavior-oriented artifact that expresses functionality and guides coding agents. A TIM defines the relationships that those artifacts must hold to each other. For spec-driven systems, that means making specs machine-readable, enforcing spec checks in CI, and constraining agents to files linked to specific spec IDs. A TIM provides the enforced relationship layer underneath that practice, which is why regulated domains that mandate requirements-to-implementation traceability can treat it as part of the workflow.
Free-form documentation drifts, and nobody notices until it matters. By making intent explicit, specifications reduce the ambiguity that pushes artificial intelligence (AI) systems to infer missing requirements, anarXiv analysis of SDD notes, and regulated domains often mandate traceability that SDD provides naturally. For companies mapping European Union (EU) AI Act traceability obligations into engineering workflows,bidirectional traceability across artifacts can help connect requirements, design, code, and tests. The structure the agent must respect is the structure the auditor can later read.
Governance and Auditability in Harness Engineering
High agent throughput raises governance stakes. When agents contribute changes at tremendous speed, questions about code quality, maintainability, and accountability scale with the volume of changes. When we bring agents into regulated product development, the discipline ofgoverning AI within systems engineering is still taking shape across the software development lifecycle.
Audit trails need more than commit history. In regulated software companies, audit evidence often requiresend-to-end traceability for audits that link each deployed change to its initial request, the code’s authorship, review and approval by the appropriate people and the test and build artifacts. AI-generated test cases still need to be version-controlled and traceable. Changes still require formal change control, and audit logs must capture when AI was used and by whom. Missing that infrastructure carries a direct cost because the events have to be reconstructed after the fact. Inside Jama Connect, any work performed with AI is versioned and documented as AI-generated, creating audit evidence that external AI tools cannot replicate. Teams running AI outside a governed system of record carry compliance risk when those artifacts are later required for audit.
When humans did not write the code, auditors and engineering leaders need decision lineage that survives beyond any single commit or memory. Every line of code should trace back to a justified requirement, and every requirement should trace forward through design and into verified test cases. Logged action records should show which agent identity performed the action, which resource was changed, the time of the action, the justification, and the outcome. Change control over AI artifacts should document the circumstances of AI use in compliance records so accountability endures beyond the people involved.
When we adopt agent-driven development, we should build governance documentation, agent inventories, and audit log infrastructure early. Agent governance and audit evidence should use the same records.
How Jama Connect Supports Harness Engineering
Jama Connect® is the Product Context Layer for engineering organizations. It connects requirements, risks, tests, SysML models, code repositories, simulations, defects, reviews, approvals, verification evidence and a requirements management and traceability platform, including TIMs that enforce a product context model for harness engineering. A TIM defines which artifact relationships must exist, and Live Traceability™ flags every downstream artifact for reassessment when an upstream requirement changes, so gaps surface during development rather than at a milestone review.
That same structure feeds directly into the AI layer. Jama Connect Advisor™ scores requirements against International Council on Systems Engineering (INCOSE) and Easy Approach to Requirements Syntax (EARS) standards at the point of authoring. It catches ambiguity before a coding agent inherits it. Requirements records cangovern agents and satisfy an audit when they are derived from live data rather than assembled after the fact.
Build an Agent Workflow You Can Audit
Agent-driven development exposes the next bottleneck as usage scales, governance. If your team is scaling AI agent usage faster than your governance structures can keep up, the same governed structure can carry both agent work and audit evidence. Start afree 30-day trial of Jama Connect.
Frequently Asked Questions About Harness Engineering
What is the difference between harness engineering and spec-driven development?
Spec-driven development defines what an agent should build by making the specification the source of truth. Harness engineering defines how the agent’s environment is structured to execute reliably against that spec, including guides, feedback sensors, scaffolding, and constraints. SDD can be treated as a specialized discipline within agent workflow design.
Does harness engineering mean engineers stop writing code?
Engineers still write code. In agent-first projects, humans may contribute less application code directly while writing docstrings, assertions, custom linters, structural tests, and rules files that constrain the agents. The work shifts toward engineering the conditions for correctness.
How does a TIM help AI coding agents?
A TIM defines the artifact types and relationships that must exist before requirements are written, giving agents a structured, enforced model of intent to build against. When an upstream item changes, downstream artifacts are automatically flagged, keeping generated output coherent and surfacing coverage gaps during development rather than at an audit.
Why does agent-driven development need an audit trail?
When agents write code at high volume, no human can explain every change from memory, and regulated standards still require traceability from request to approval to verified test. An audit trail captures which agent did what, under what justification, and against which requirement. Without it, incident response and compliance reviews become longer and harder to reconstruct.
