Requirements & Requirements Management Archives

Tag Archive for: Requirements & Requirements Management

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 formal requirements management best practices when repo-level planning needs governed traceability on top of it.

Why AI Coding Agents Need Durable Intent

Fission-AI maintains OpenSpec’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 makes authoritative 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.

The AI 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 for the 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, including GitHub’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 the product 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.

Our end-to-end requirements traceability practices can help you evaluate what evidence should connect. Teams can use Jama Connect for requirements 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.

If you want to see how that connection works, you can start a Jama Connect trial.

Frequently Asked Questions About OpenSpec

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.

2: Learn & Pilot AI

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:

Requirement quality reviews
Test generation
Sprint planning
Relationship discovery
Documentation
Requirements decomposition
Change impact analysis

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.

Characteristics

Spec-Driven Development
Context engineering
Product context layer
Live Traceability
Governed AI workflows
AI governance

Primary Objective: Maximize product velocity from AI coding agents.

Biggest Bottleneck: Building deterministic engineering context that AI can trust.

Read our Spec-Driven Development Playbook to learn more and walk through an example SDD workflow step by step.

5: Multidisciplinary AI-Driven Development

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 Assessment helps 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.

Get Your 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.

Explore Traceable Agile

Frequently Asked Questions

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
Preserving traceability throughout product development
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:

Established approval workflows.
Existing permission structures.
Review checkpoints.
Documentation standards.
Change management practices.

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.

Examples might include:

Systems Engineer
Functional Safety Engineer
Requirements Quality Reviewer
ISO 26262 Specialist
Cybersecurity Expert
Risk Management Reviewer

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.

Watch the Webinar On Demand

See these recommendations for AI in regulated industries in action. Watch our on-demand webinar, Best Practices for Improving Compliance and Risk Management with Model Context Protocol (MCP).

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.

Watch On Demand

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 across delivery 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 to use 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. Reducing errors 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 through spec-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 clear link 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 an analysis 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 maintain end-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.

With impact 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 a free 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.

Watch On Demand

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 use hybrid 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

A manually 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, so gaps 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 cut medical 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 and start 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 the four 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 connected requirements 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 agents verify 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 to understand 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 a Traceability 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, an arXiv 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 of governing 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 requires end-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 can govern 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 a free 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.

Requirements, code, and verification artifacts often live in different systems. Engineers switch between tools to understand requirements, implement functionality, and document traceability. By the time an audit arrives, teams may spend days or weeks proving that what they built matches what was specified.

That gap shows up often in regulated engineering environments. Security requirements span multiple teams, systems, and compliance frameworks, including ISO 26262, DO-178C, IEC 62443, and FDA design controls. The work itself is rarely contained in one place, but the evidence for it still has to hold together.

In this Features in Five demo, Katie Hucket, Product Line Manager, Advisor/AI at Jama Software, demonstrates how Jama Connect MCP™ helps close that gap by bringing governed requirements, traceability, and auditability into the engineering workflow.

Access requirements without leaving the IDE

With Jama Connect MCP, approved requirements in Jama Connect can flow directly into the IDE. Engineers can pull in the requirement, the metadata around it, and the governance state behind it. They can also see relationships to upstream system, safety, and regulatory requirements.

That context matters. It gives the engineer the information needed to implement the work without leaving the development environment, while still keeping the requirement tied to the source of truth in Jama Connect.

A secure authentication example

The demo followed a platform security team working on secure service-to-service authentication across a distributed system. That kind of implementation is common in large programs, where one requirement can touch many services and many teams.

The engineer starts by retrieving the requirement from the IDE. In this case, the requirement traces upstream to a cybersecurity control aligned with IEC 62443. That trace gives the team a direct line from implementation work back to regulatory intent.

The requirement calls for mutual TLS, but the engineering details are still incomplete. Certificate validation rules are missing. Identity extraction is not fully defined. Authorization enforcement is not spelled out. Those gaps create ambiguity, and ambiguity creates risk.

Refine the requirement through a governed process

Instead of handling the gap outside the workflow, the engineer updates the requirement directly from the IDE. The change still goes through Jama Connect governance. It is permission controlled, reviewed, version controlled, and recorded in audit logs.

That updated requirement becomes the trusted reference for the implementation effort. It also gives AI-assisted development tools better context for generating code and tests that match the approved intent.

Use approved requirements in AI-assisted development

The demo showed how governed requirements can support modern AI-assisted development without losing control of the process. Once the requirement is aligned, the engineer completes the implementation with the requirement in view.

The code reflects the updated requirement. A reference to the requirement is embedded in the implementation, and a formal trace relationship is created.

That pattern scales well beyond a single service. In a large program, the same approach can apply across hundreds of services and thousands of requirements, with consistent traceability across the system.

RELATED: AI-Assisted Software Workflow Playbook

Establish traceability during development

Traceability has often been treated as a cleanup task. Teams finish the work, then go back and recreate links after the fact. That usually means extra manual effort, and it often leaves gaps.

Jama Connect MCP changes that rhythm. Traceability is created while the work is happening. Requirements, code, and verification artifacts stay connected as the implementation moves forward.

Jama Connect’s Traceability Information Model gives teams a way to work with more than direct links. They can follow structured relationships across upstream regulatory and system requirements, downstream software components, and verification evidence. If a requirement changes, the impact can be traced through the chain of related work.

Understand the impact of change

The demo also showed how this model helps during change analysis. If a new certificate standard is introduced, teams can identify the requirements, code, and validation work that may be affected.

That is the kind of analysis required by standards like ISO 26262 and FDA design controls. It also gives engineering and compliance teams a clearer view of what needs to be updated, reviewed, and revalidated.

Maintain audit readiness across the lifecycle

When traceability is captured as part of the workflow, teams can check coverage across the code base, confirm alignment between requirements and tests, and review how verification evidence maps back to the original requirement.

That makes audit preparation more straightforward. Teams are not rebuilding the story later. The story is already in the system, tied to the work itself.

Closing the loop

Jama Connect MCP connects governed requirements directly into AI-assisted development workflows. It helps teams use approved requirements in the IDE, create traceability as work happens, and keep requirements, code, and verification aligned throughout the product lifecycle.

For large engineering organizations, that means fewer audit findings, faster change impact analysis, and fewer defects caused by requirement gaps. It also gives teams a way to scale secure, compliant product development without losing control of the process.

An avionics team three months into a DO-178C (Software Considerations in Airborne Systems and Equipment Certification) effort discovers that many of their high-level requirements have no linked test cases. They had been running test cycles for weeks against requirements that were never fully verified or traced. The rework pushes certification timelines back and adds weeks of schedule pressure that nobody budgeted for.

Now add artificial intelligence (AI)-generated code that nobody reviewed, no documented requirements behind it, and no traceability chain for an auditor to follow. The cost multiplier worsens at every downstream stage.

AI coding tools have produced two distinct engineering workflows. In vibe coding, natural language prompts replace formal specifications. In spec-driven development, documented requirements govern every downstream decision. For teams building products that must pass audits, certification reviews, and safety checks, differences among these requirements affect cost, rework, and delivery risk.

This article defines both approaches, compares how they behave across an engineering program, and shows when each one fits.

What Is Vibe Coding?

Vibe coding is a workflow in which a developer prompts an AI model in natural language, accepts the generated output with minimal review, and iterates on errors rather than designing around them. The original description of vibe coding, coined by Andrej Karpathy, characterized it as giving in to the vibes and forgetting that the code even exists, including accepting AI output without reading diffs and pasting error messages back into the model with no comment until a bug goes away. Code outgrows the developer’s comprehension, the AI’s context window sees only fragments of the system at any moment, and the intent behind each design choice disappears once the prompt is gone.

The approach can speed up software creation while skipping core engineering practices. Code review is limited, tests are sparse, and teams trust AI output without enough checking. That distinguishes it from the broader category of AI-assisted engineering, where generated code still passes through review, testing, and traceability.

What Is Spec-Driven Development?

Spec-driven development establishes a formal, documented specification of what to build and how to build it before design or implementation begins, and every downstream activity traces back to that specification. Standards bodies and systems engineering guidance codify this discipline. In regulated industries, requirements communicate what systems engineers expect, define project success criteria, and support regulatory conformity. A specification document is a technical artifact, a compliance instrument, and an audit trail all in one.

How Vibe Coding and Spec-Driven Development Differ

The two approaches diverge across four dimensions that matter to any engineering program. They handle requirements differently, behave differently as a system grows, generate defects at different points, and serve different kinds of teams. Looking at them side by side shows where the methods overlap and where they pull in opposite directions.

How Each Approach Handles Requirements

In vibe coding, requirements are implicit and emergent. The prompt becomes obsolete the moment code is produced, so the code itself turns into the only record of what the software does. Code is a poor medium for capturing why a decision was made.

In spec-driven development, the specification is the source of truth. It establishes what constitutes correctness before any implementation decisions are made. Detailed requirements covering usability, security, performance, and edge cases are written before development begins.

Initial Output Speed vs Speed at Scale

Vibe coding shortens the path from idea to working prototype. The problems surface as a project grows. The codebase exceeds anyone’s ability to hold in memory. The AI’s context window sees only fragments of the system, and no architectural map exists to support recovery when the build becomes unstable.

Spec-driven development starts more slowly because writing and reviewing specifications takes time. The specification then provides a stable reference that lets multiple contributors work from shared ground truth without renegotiating intent at every step. That stability compounds as team size and system complexity increase.

Where Do Defects and Rework Originate?

On large aerospace and spacecraft programs, a requirements error costs three to eight times more to fix at the design phase than at the requirements phase, and 29 times more at the operations phase. Early requirements review can remove issues before the first test case runs. Vibe coding bypasses that review stage, so ambiguities and omissions travel downstream until verification or an audit exposes them. Spec-driven development puts more effort up front and catches those problems at the lowest-cost point in the lifecycle.

Who Does Each Workflow Serve Best?

Vibe coding fits solo developers, early-stage founders, and teams building disposable prototypes where the code will not face an audit, ongoing maintenance, or multi-team coordination. Spec-driven development is well-suited to multi-team programs, regulated product development, and projects that require audit evidence or long-term maintainability.

See how engineering leaders are using spec-driven development to remove bottlenecks and increase product velocity.
Download the Spec-Driven Development Playbook →

When to Use Vibe Coding

Vibe coding fits specific, bounded contexts. Its limits become clearer as scope and team size increase.

Why Prototyping Is the Strongest Use Case

AI-assisted generation shortens iteration cycles when code is not intended for production. Its purpose in this context is to quickly validate a concept, not to serve as a maintained system, so the absence of formal specifications carries little long-term cost.

Where Do Solo Projects and Disposable Code Fit?

A solo founder validating a business idea can reach working software faster than their own skills alone would permit. Hackathon builds and one-off automation scripts fit here as well. The productivity gains apply directly, and maintainability risks matter less because the work was never meant to be maintained.

What Limits Surface as Teams Grow?

Teams run into production issues with AI-generated code, including performance problems, security gaps, and maintainability issues. Without deliberate design patterns or modular architecture, applications built through vibe coding struggle as user demand or feature scope grows. Inconsistent prompting styles among engineers can also lead to duplicate work and incompatible patterns within the same codebase.

Why Spec-Driven Development Holds Up as Programs Grow

Shared specifications reduce coordination failures that arise as programs become more complex.

How Shared Specifications Reduce Ambiguity

Large engineering programs face a coordination failure that grows nonlinearly with team size. When two engineers read the same requirement differently, divergent implementations follow. Bidirectional traceability back to top-level product requirements, with managed changes to established baselines across the full lifecycle, is the standard approach on large programs. A shared specification gives teams, suppliers, and reviewers one authoritative reference.

How Verification Maps Back to Defined Intent

Program requirements in regulated environments must map back to higher-level requirements and forward into verification activities. Defining verification requirements early helps control overall program cost on major defense and aerospace programs, where late discovery of a verification gap can ripple through thousands of artifacts.

Why Onboarding and Handoffs Stay Predictable

On programs that span years or decades, original engineers routinely rotate off. Training new team members in established requirements management procedures is a core activity on long-running programs. New contributors read the specifications to understand what the program is supposed to do and why.

Where Vibe Coding Creates the Most Risk in Regulated Systems

In regulated environments, the absence of formal specifications creates compliance gaps that surface during audits, certification reviews, and post-market investigations. The cost of finding those gaps late compounds across requirements, design, verification, and submission artifacts.

How Untraceable Decisions Create Audit Gaps

Every major safety standard governing software in MedTech, aerospace, and automotive depends on bidirectional requirements traceability. DO-178C requires traceability between requirements, source code, and test cases, with low-level requirements traced to source code and verification performed through requirements-based testing. International Electrotechnical Commission (IEC) 62304 requires traceability from user needs and risk analysis through requirements, code, and tests. AI’s probabilistic nature and limited transparency create tension with the International Organization for Standardization (ISO) 26262 expectations for bidirectional traceability and safety assurance throughout the development chain. Under IEC 62304, AI-generated code without formal specifications meets the functional definition of Software of Unknown Provenance (SOUP).

AI-Generated Code Without Specs Expands the Defect Surface

AI-generated code can introduce exploitable bugs and higher-risk architectural or privilege-related issues even when surface-level syntax errors decline. Without formal specifications and the verification and traceability activities that DO-178C and IEC 62304 expect, those architectural defects may never surface before release.

What Late-Stage Requirement Discovery Costs

Without a specification, defects of omission such as missing safety behaviors, unhandled edge cases, and absent error handling are harder to detect because no document exists to measure the code against. In regulated industries, a defect found during Food and Drug Administration (FDA) premarket review or a DO-178C certification audit requires more than a code fix. It requires updated requirements, updated design documentation, updated test cases, independent re-review, and re-submission.

How to Choose the Right Approach for Your Team

The right approach depends on regulatory constraints, team size, and what happens to the code after it is written.

How to Match Method to Project Complexity

Regulatory constraints, multi-team interfaces, and the need to trace AI-generated artifacts can each force a formal specification phase. Exploratory work has to formalize into traceable specifications at a defined transition point, and a requirements management system becomes necessary at that stage.

How to Blend Exploration With Specification Discipline

A systems engineering approach applies formal discipline to speed alignment during requirements analysis while working alongside formal requirements development. Artifacts from exploratory work undergo a deliberate transition that includes requirements decomposition, traceability, and security review before reaching production. The same discipline applies when AI sits within the toolchain itself, which is the rationale behind an AI-native requirements platform that keeps generated artifacts traceable, rather than treating AI as a bolt-on.

How Jama Connect Supports Spec-Driven Development

Jama Connect® provides the Product Context Layer for engineering organizations, a governed system of record that connects requirements, risks, tests, SysML models, code repositories, simulations, defects, reviews, approvals, verification evidence, and change history. At the center sits the Traceability Information Model™, which defines how requirements, models, code, tests, simulations, and verification results relate to one another.

That foundation gives teams the structure to move exploratory work into production without losing the traceability links auditors expect. Jama Connect is web-based, supports on-premises deployment, and serves complex, regulated product development. Live Traceability™ maintains real-time upstream and downstream visibility across development artifacts, closing AI-related audit gaps that arise when AI-generated code lacks documented requirements. This product context is what lets anything performed with AI stay versioned and documented as AI-generated, the discipline detailed in spec-driven development for AI-powered engineering.

Jama Connect Advisor™ scores requirements against International Council on Systems Engineering (INCOSE) rules and Easy Approach to Requirements Syntax (EARS) patterns at the point of authoring, catching ambiguity before it reaches downstream work. Global healthcare leader Grifols cut its review cycles from 90 days to fewer than 30 days after bringing Jama Connect Review Center into the workflow. This demonstrates how much faster specification discipline can run when the right tooling supports it.

Choosing Between Vibe Coding and Spec-Driven Development for Your Program

The line between vibe coding and spec-driven development appears the moment informal exploration has to become documented, traceable, and verifiable. For teams building products that will face auditors, certification authorities, or safety investigations, the specification is the compliance evidence, the onboarding document, the change-control anchor, and the institutional memory that outlasts personnel turnover. AI-assisted prototyping shortens the early stages of product development, and the engineering discipline that follows determines whether those prototypes become certified products or result in expensive rework.

Jama Connect supports this workflow by holding the specification as the source of truth and keeping every requirement, design artifact, and test linked as the work moves from exploration into production. Start a free 30-day trial of Jama Connect.

Start Your Free Trial

Frequently Asked Questions About Vibe Coding vs Spec-Driven Development

Is vibe coding the same as rapid prototyping?

Rapid prototyping is an established engineering practice with a defined purpose, producing an exploratory artifact to validate requirements before committing to production design. Vibe coding can be applied to prototypes, but it can also produce production code with no inherent boundary separating the two. Rapid prototyping has a recognized role in standards-compliant development, while vibe coding has no recognized regulatory analog yet.

Can spec-driven development work with AI coding tools?

Yes, at three levels of rigor. Spec-first means the specification is written before AI-assisted coding begins. Spec-anchored means the specification is retained as an ongoing reference throughout. Spec-as-source means the specification is the only human-edited artifact and the code is fully generated from it.

Does spec-driven development slow teams down?

It adds upfront overhead, and it prevents requirements drift and downstream rework that cost far more to fix later. For teams in regulated environments, IEC 62304 and DO-178C already require structured design documentation and requirements-to-implementation traceability, so the overhead is not optional.

Which approach is better for regulated industries?

Spec-driven development aligns structurally with regulated industry requirements. DO-178C, IEC 62304, and ISO 26262 all require formally documented requirements, bidirectional traceability, and documented evidence of verification. A vibe-coded prototype can feed a regulated process, but the formal specification, traceability, and verification work must still run in full before a product can be certified.