Tag Archive for: Requirements & Requirements Management Page 2
Tag Archive for: Requirements & Requirements Management
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.
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. Theoriginal 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 approachcan 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 coststhree to eight times more to fix at the design phase than at the requirements phase, and 29 times more at the operations phase. Earlyrequirements 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.
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) 62304requires 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) 26262expectations 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
Asystems 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 behindan 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 inspec-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 afree 30-day trial of Jama Connect.
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, atthree 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.
AI for Engineering Managers: Where It Helps and How to Start
Six months into a major program, an engineering manager discovers that three separate teams have been building against different requirement baselines. Nobody catches the misalignment until integration testing, when two subsystems fail to communicate. Rework costs the program six weeks and an entire sprint’s worth of engineering time. Better visibility could have caught the problem in week two.
This scenario plays out across automotive, aerospace, medtech, and defense programs with regularity. Artificial intelligence (AI) is starting to change the equation in regulated engineering, though vendor marketing often overstates the extent to which it helps. For engineering managers in regulated industries, the clearest use is reclaiming hours lost to aggregation, status-chasing, and manual cross-referencing, so that judgment can be applied where it matters.
This guide covers where AI fits into the manager’s workflow, where it still falls short, and how to roll it out within limits that keep risk under control.
Where AI Actually Fits for Engineering Managers
Generative AI, predictive analytics, and rule-based workflow automation each carry different implications for validation, audit trails, and safety case integrity.
Generative AI is well-suited to content and artifact generation. Traditional machine learning often fits outcome prediction on domain-specific data, which is more common in regulated engineering. Thedistinction between AI4SE and SE4AI, where AI for Systems Engineering applies AI to support systems engineering processes and Systems Engineering for AI applies systems engineering principles to develop AI-enabled systems, matters for compliance. An AI tool used to support a requirements process is subject to different governance than an AI system that is the product being engineered.
AI adoption shows up in discussions and pilots while mature rollout remains limited. In regulated industries, change is more incremental by design, and that caution reflects appropriate professional judgment.
How to Slot AI Into an Existing Engineering Workflow Without an Overhaul
Status reporting consumes time that engineers can’t bill back to the project. AI falls into four recurring workflow categories, and you do not need a full-scale overhaul to get started. The strongest place to begin is wherever time is already being lost to repetitive coordination and manual review, which tends to cluster in a few common areas.
How AI Handles Status Reports and Stand-up Summaries
Your team can use AI tools to aggregate sprint status from Jira, GitHub, and messaging platforms to produce narrative summaries. Jira with Atlassian Intelligence can generate summaries of issue content. These tools condense backlog management and sprint planning into brief review meetings. Your team can then focus on the why and the how.
Why AI Risk Alerts Depend on Documentation Quality
AI risk alerts depend on the quality of the documentation feeding them. The mismatch between AI models and real repositories comes primarily from documentation quality. In regulated environments, AI-generated risk scores must produce traceable, explainable outputs that humans can review and document for compliance. Black-box risk scoring without audit trails is generally unacceptable in medtech and other highly regulated contexts, where teams expect traceability, auditability, and documentation.
How AI Drafts Technical Documentation Under Compliance
Documentation automation is a common AI use case in the automotive industry. Common applications include user manuals, application programming interface (API) documentation, and inline comments. The Food and Drug Administration (FDA)draft guidance from January 2025 provides recommendations for AI-enabled medical devices, including lifecycle and marketing submission documentation such as performance monitoring plans across the total product life cycle.
Getting New Engineers Up to Speed With AI
If there is no documentation for a given system, engineering onboarding faces the same gap with or without AI. When good documentation exists, AI tools help new engineers surface insights faster and reduce the time spent learning team dynamics. Junior developers often see faster early utilization, while senior engineers may save more time over longer periods.
How to Improve Team Productivity Without Moving the Bottleneck
The first gains usually appear in faster coding and drafting. In complex product development, teams still need to account for what happens next, because faster output in one step does not automatically improve the whole delivery system.
Where Productivity Gains Disappear After AI
AI magnifies existing organizational strengths and weaknesses, so individual productivity boosts often get lost in downstream disorder. After AI speeds up coding, bottlenecks tend to appear in four places:
System and user acceptance testing. Gains in coding speed get absorbed by verification queues.
Performance and security testing. Load and vulnerability scans do not run faster because the code was written faster.
Monitoring, release, and deployment. Infrastructure and release pipeline capacity stay fixed regardless of coding throughput.
Security and compliance. Regulatory review cycles do not move faster because code was written faster.
Speeding up one phase without addressing downstream constraints simply relocates the bottleneck rather than removing it.
Most Developer Time Isn’t Spent Coding
Developer time also goes toward reviews, meetings, context switching and documentation. Coding assistants can improve the experience of coding work, but those other activities remain unless you target them directly. Manualtraceability work across disconnected tools absorbs hours that should go to engineering, and that cross-referencing is often where the largest recoverable time sits.
How AI Helps Engineering Managers Make Better Decisions
Engineering managers need reviewable outputs tied to specific engineering artifacts and workflow signals in three areas.
What Code Review Patterns Reveal About Team Health
Engagement with AI review tools often rises during early rollout and then settles into a lower steady state over time. Sustained adoption requires active management, not just tool deployment.
How AI Forecasts Capacity and Delivery Timelines
AI-based tools can help developers complete some complex tasks faster. Those gains tend to shrink as task complexity increases, and less experienced developers may not benefit as much as more experienced peers.
Finding Requirement Gaps Before They Cost You
Requirements gap analysis against models using Systems Modeling Language (SysML) remains a focus in model-based systems engineering practice. Theresearch targets requirements that are poorly structured, incomplete, or ambiguous, which can lead to design and verification failures if undetected. Most work remains in its early stages and does not yet address the interpretability, reproducibility, and controllability challenges that limit practical deployment.
How AI Surfaces Team Health Signals Managers Miss
AI can read patterns in everyday engineering activity that are hard to spot manually, though each signal needs careful handling.
How AI Spots Early Signals of Burnout and Overload
Communication patterns can reveal meaningful signals related to burnout and overload among engineering teams. These tools surface systemic work patterns, not individual diagnoses, and the same data that supports early intervention also raises surveillance concerns that require clear organizational policy.
How AI Informs Coaching and Growth Conversations
AI-generated insights on code review patterns, task completion rates, and skill gaps can inform 1:1 conversations with concrete data points. The coaching judgment, context, and trust-building remain the manager’s job.
Why AI Can Reduce Bias in Performance Reviews
AI can surface objective contribution data, including commit history, review participation, and cross-team collaboration, to help counterbalance recency and visibility biases in performance reviews. Depending on their design and implementation, algorithms can perpetuate or mitigate bias. Begin with human-generated content and use AI to augment reviews rather than generate them from scratch.
Where AI Still Falls Short in Engineering Management
AI adoption comes with risks that are hit harder in regulated contexts, and engineering managers need to understand the guardrails.
Where Human Judgment Still Outperforms Automation
Automation bias can increase the risk of accidents and errors when engineers stop verifying AI output. A human sign-off that rubber-stamps AI outputs does not constitute meaningful oversight. Professional liability stays with the engineer rather than the AI tool or its vendor.
Why Data Quality and Explainability Still Block AI Adoption
AI systems, particularly deep learning models, are often opaque in how they reach conclusions, and in regulated product development, that opacity creates a direct audit problem. Barriers in aerospace include a lack of curated training data, limited model transparency, and intrinsic technical limitations of generative AI models. Standards for automotive and aerospace artificial intelligence and machine learning (AI/ML) are still evolving.
Why Most Developers Don’t Trust AI Output
Developer skepticism about the accuracy of AI tools remains a problem. In regulated engineering workflows, a hallucinated standard reference or fabricated requirement that passes through AI-assisted review can spread into safety cases and regulatory submissions with consequences far more severe than in commercial software.
How to Roll Out AI in Your Engineering Team
AI rollouts in regulated teams follow a different playbook than startup experiments. Narrow pilots, early measurement, and evidence-based scaling work better.
Where Your Team Should Start With AI
Three task categories are well-suited for AI use;
Structured, repetitive, high-volume activities. Status reporting, documentation drafting, andautomated requirements quality checks are good starting points.
Data-intensive tasks with processing constraints. Requirements gap analysis across large document sets benefits from AI-assisted processing.
In regulated contexts, trust develops gradually, and teams typically need a meaningful period of observing AI working correctly before advancing to higher levels of autonomy.
How to Build Trust and Track Results
Teams often set value targets and a measurement plan early when they deploy new technology. Defining success metrics before deployment can help teams sustain projects over time, though many initiatives still fall short of expected return on investment (ROI).
How Jama Connect Supports AI for Engineering Managers
Jama Connect® is a web-based requirements management and traceability platform for complex, regulated product development. Jama ConnectAI-native platform architecture redesign gives engineering managers the structured, connected data that AI needs to operate safely in regulated workflows. It acts as the product context layer that connects requirements, risks, tests, models, code, simulations, reviews, and approvals into a single governed system of record, with Traceability Information Models (TIMs™) defining how those artifacts relate to one another. The recurring problem for many engineers is hours lost to manual cross-referencing and stale exports, which come directly from data scattered across disconnected tools. For more on how this foundation supports AI-assisted work, see our guide tospec-driven development.
Live Traceability™ connects requirements, test cases, risk items, and design elements in real time, so reviewers can work from current data rather than relying on periodic manual audits. Jama Connect Advisor™, anAI add-on for requirements, scores requirements against the International Council on Systems Engineering (INCOSE) rules and the Easy Approach to Requirements Syntax (EARS) patterns at the point of authoring. This moves quality analysis away from manual review.
Getting Started With AI for Engineering Managers
The scaling gap in engineering AI is more organizational than technical, which means the readiness work matters more than the model selection. Engineering managers get the most from AI when they treat it first as a process and documentation readiness problem and second as a tooling selection problem.
Jama Connect supports this workflow by providing AI with the structured, connected, and current data it depends on, with governance and measurement built in from day one. If your team is ready to put that foundation in place, you canstart a free 30-day trial and run your own check.
Frequently Asked Questions About AI for Engineering Managers
What is the best way for engineering managers to start using AI?
Structured, high-volume tasks with verifiable outputs are the right starting point, such as status reporting, documentation drafting, or requirements quality analysis. Safety-critical decisions should wait until your team has built confidence through lower-risk applications.
Can AI replace engineering managers?
No. The parts of the job that AI assists with, drafting, aggregation, and surfacing patterns, are a small share of what a manager does. Coaching, prioritization calls, and accountability for what ships stay with the person, and AI changes the inputs to those decisions rather than the decisions themselves.
How does AI help with engineering team productivity?
AI tools can help developers complete some complex tasks faster, though those gains often shift bottlenecks downstream into testing and compliance. The biggest opportunity sits in the non-coding work, including reviews, meetings, and documentation, that fills most of a developer’s week.
What are the risks of using AI in engineering management?
The primary risks are automation bias, data quality gaps that AI magnifies rather than fixes, and hallucinations in technical outputs that can spread into safety cases or regulatory submissions.
How do engineering managers maintain governance over AI-assisted work?
Governance depends on whether AI-assisted work is versioned, attributed, and auditable. When AI runs inside a governed system of record, every action it contributes is documented and traceable, so the artifacts hold up if they are pulled into an audit. AI used outside that environment leaves no such trail, which can create exposure when those outputs are part of a regulatory submission.
What Is the Cyber Resilience Act and How to Prepare
A vulnerability report arrives, and the question is no longer whether your team can fix it. The real question is whether you can say, within hours, which products contain the affected component and which EU markets they ship to. With components mapped to products in advance, that answer takes minutes. Without it, the day disappears into spreadsheets while a regulatory clock runs.
By September 11, 2026, manufacturers selling connected products in the European Union (EU) must report actively exploited vulnerabilities within 24 hours of discovery through theSingle Reporting Platform operated by the European Union Agency for Cybersecurity (ENISA). Most other obligations under theCyber Resilience Act (CRA) apply from December 11, 2027.
This guide covers what the regulation requires, who it applies to, the compliance timeline, and how to prepare before the first reporting deadline arrives.
What Is the Cyber Resilience Act?
The Cyber Resilience Act is a horizontal EU regulation that setscybersecurity requirements for products with digital elements placed on the EU market. A product with digital elements is any software or hardware product, including components sold separately, whose intended or foreseeable use includes adirect or indirect connection to a device or network.
The European Commission created the regulation to fill a gap. Hardware and software products were previously covered by cybersecurity requirements primarily through sectoral frameworks rather than a single horizontal framework that spans all such products. The CRA sets conditions for developing secure hardware and software, requires that users receive adequate security information, and works to make supply chains more secure so that final products and their components carry fewer weaknesses.
The regulation applies to any product placed on the EU market, regardless of where it is produced or where the company is headquartered. Products already covered by sector-specific EU legislation, including medical devices,vehicles, and aircraft, as well as maritime equipment and products used exclusively for national security or defense, fall outside its scope.
Products and Companies Covered by the Cyber Resilience Act
Connected hardware, standalone software, and manufacturer-developed remote data processing, all essential to a product’s function, fall within scope. Software offered solely as Software as a Service (SaaS) is out of scope, provided it does not qualify as a manufacturer-developed remote processing component.
The regulation assigns obligations based on theeconomic operator’s role. Manufacturers bear the primary burden for security through design, vulnerability reporting, and security updates for the expected product lifetime or for 5 years after market placement, whichever is shorter. Importers act as a verification checkpoint, confirming that manufacturers have met their obligations before products reach the EU market. Distributors carry lighter duties, mainly verifying CE marking and notifying manufacturers of discovered vulnerabilities. Any party that markets a product under its own name or makes substantial modifications becomes a deemed manufacturer and inherits full manufacturer obligations.
Free and open-source software published outside commercial activity is exempt. Once that software is integrated into a commercial product, the manufacturer of that product inherits full CRA duties for those components. The regulation also creates a legal category, theopen-source software steward, for legal persons that systematically support open-source development intended for commercial use. Stewards must document cybersecurity policies and actively report on vulnerabilities that are being exploited, though they are exempt from administrative fines.
Cyber Resilience Act Requirements
Every in-scope product must meet the Annex I security obligations, and certain important or critical products face additional or stricter requirements. Products must ship with no known exploitable vulnerabilities, secure default configurations, and controls for authentication, data protection, and minimized attack surfaces. Ongoing security updates are central to staying compliant once a product is on the market.
Vulnerability handling obligations apply throughout the product’s support period. Manufacturers must maintain a Software Bill of Materials (SBOM) in a commonly used, machine-readable format covering at least top-level dependencies. They must remediate vulnerabilities without delay, publish a Coordinated Vulnerability Disclosure (CVD) policy, conduct regular security testing, and provide free security updates for at least 5 years after market placement.
The conformity assessment pathway depends on how a product isclassified and which assessment route applies.
Default products: Self-assessment under Module A by the manufacturer, with no mandatory third-party involvement. This covers the majority of products.
Important Class I: Self-assessment is permitted only when harmonized standards are applied. Otherwise, a notified body assessment is required.
Important Class II: Notified body involvement is always mandatory, either through Module B plus C or through Module H full quality assurance.
Higher-risk products: Certain products may be subject to additional conformity assessment requirements.
In-scope products placed on the EU market must bear the Conformité Européenne (CE) marking as of December 11, 2027. The classification tier changes only the assessment pathway, not the underlying security requirements.
EU Cyber Resilience Act: What Engineering Teams Need to Do Now
Get practical ways to prepare for new requirements.
Article 14 reporting starts on September 11, 2026, which makes it the earliest binding obligation, and it applies to products already on the EU market. Two event types trigger reporting: identified vulnerabilities and severe incidents affecting product security. Both follow a three-stage cascade, with manufacturers reporting once through the Single Reporting Platform, which routes notifications to the competent Computer Security Incident Response Teams (CSIRTs) and makes them available to ENISA.
The 24-hour early warning requires minimal content. Manufacturers must confirm that an event exists, state whether a vulnerability is actively exploited, and identify which EU Member States the product is available in. The 72-hour notification adds product details, the nature of the exploit, corrective measures taken, interim measures for users, and an initial assessment of the vulnerability or incident. Organizations should also establish a consistent method for evaluating vulnerabilities, such as the Common Vulnerability Scoring System (CVSS), so severity assessments remain transparent, repeatable, and easier to defend during audits or regulatory reviews.
The final report for an actively exploited vulnerability is due within 14 days after a corrective measure becomes available. It must include the vulnerability description with severity and impact, any available information about the malicious actor, and details of the security update. The 24-hour and 72-hour deadlines run from the moment the manufacturer becomes aware, not from the completion of any investigation.
The Cyber Resilience Act Compliance Timeline
CRA obligations phase in between December 2024 and December 2027, with Article 14 reporting arriving first. The regulation entered into force on December 10, 2024. The conformity assessment body notification framework applies from June 11, 2026. Mandatory vulnerability and incident reporting under Article 14 begins September 11, 2026. Full compliance with remaining obligations, including Annex I security requirements, CE marking, and completed conformity assessments, is required by December 11, 2027.
Penalties scale with the type of failure. Non-compliance with essential cybersecurity requirements or Article 14 reporting can reach the highest tier, up to 15 million euros or 2.5 percent of total worldwide annual turnover, whichever is higher. Procedural and documentation failures, including CE marking and importer and distributor obligations, fall under a separate maximum tier. Providing false, incomplete, or misleading information to authorities can draw fines of up to 5 million euros or 1 percent of turnover. Beyond fines, market surveillance authorities can withdraw products from the EU market, prohibit availability, or order recalls.
Why Meeting the Reporting Windows Depends on Traceability
Meeting the reporting windows depends on knowing immediately which products contain an affected component and where those products are available in the EU. Filing a 24-hour early warning means answering those questions on the spot. Without a pre-existing component-to-product mapping, the search alone can consume the full window before a submission begins.
The 72-hour notification raises the bar. Teams must determine which downstream products inherit the vulnerable component, assess thescope of impact, and document corrective measures already underway. That work depends on atraceability chain linking the vulnerability identifier to the specific component version, the component version to every product release that includes it, and those releases to theshipped or deployed versions currently in scope.
Audit trails face the same time pressure. A manufacturer that assembles the early warning by hand cannot easily reconstruct the decision trail under later scrutiny. The record must capture the component inventory, the logic that classified the event as actively exploited, and the basis for severity, all of which were recorded at the time of the event.
How to Prepare for the Cyber Resilience Act
Preparing for the Cyber Resilience Act isn’t about bolting on new cybersecurity activities at the end of development. The CRA is less about adding security activities than making cybersecurity part of normal engineering. Teams are expected to identify cybersecurity risks early, derive security requirements from those risks, verify the controls they’ve implemented, and maintain evidence throughout the product lifecycle. In practice, the regulation rewards organizations that already treat cybersecurity like quality or functional safety, with requirements, testing, and traceability built into development rather than added afterward.
Teams get the most value when they treat CRA cybersecurity requirements as design inputs that trace through architecture, implementation, andverification and validation. The CRA’s Annex I requirements align with existing secure development frameworks, and theNIST Secure Software Development Framework provides a structured reference for building security into the development lifecycle. A product-level risk assessment early in development, threat modeling during architecture and design, and security testing within the development cycle all align with the regulation’s secure-by-design and vulnerability-management expectations. This helps identify cybersecurity risks early so they can be translated into security requirements and verified before release.
SBOM generation belongs in the build pipeline rather than in a separately maintained file. A manually updated SBOM drifts out of date as dependencies change. The statutory minimum covers top-level dependencies, yet capturing transitive dependencies is the only way to correlate components against Common Vulnerabilities and Exposures (CVE) databases with enough depth to support the 24-hour reporting window.
A structured intake and handling process closes the gap between awareness and submission. Documented triage and escalation workflows let a team produce a Stage 1 submission within 24 hours of first awareness, which is the kind ofsecure development practice that pays off under pressure. Coordinated vulnerability disclosure is widely considered good practice for addressing issues before public disclosure, so teams should register with the Single Reporting Platform during the testing period leading up to the September 2026 go-live and identify the CSIRT associated with their main EU establishment.
Why Requirements Traceability Matters for the Cyber Resilience Act
The Cyber Resilience Act doesn’t explicitly require organizations to purchase a requirements management platform, but it does require them to demonstrate that cybersecurity has been considered throughout the product lifecycle. That becomes much easier when engineering artifacts remain connected. End-to-end traceability can help.
Traceability enables organizations to:
Connect cybersecurity risks to security requirements.
Link requirements to verification evidence.
Identify affected product versions when vulnerabilities emerge.
Perform impact analysis faster.
Demonstrate compliance during audits.
Accelerate Article 14 reporting.
How Jama Connect Supports Cyber Resilience Act Reporting
Meeting CRA reporting windows depends on knowing which components sit in which products, what changed, and what evidence supports each decision. Jama Connect® is a cloud-based requirements management and traceability platform for complex, regulated product development, and that traceability is what turns a vulnerability report into a fast, defensible answer about affected products.
When a vulnerability surfaces,Live Traceability™ provides upstream and downstream visibility into affected products and linked components without manual review, and suspect-link notifications flag which downstream artifacts need attention when an upstream security requirement or component record changes. Baseline capture preserves the state of each release at market placement, so the record behind a vulnerability classification stays available when authorities ask.
Building Reporting Readiness Before the Deadline
The September 2026 deadline rewards teams that built cybersecurity traceability into development rather than bolting it on afterward, and the difference is invisible until the first report arrives. The companies that absorb the CRA most easily will be those that already treat each shipped release as a queryable record, because a reporting obligation is only as fast as the data beneath it.
Jama Connect supports this workflow by linking each security requirement to its component, control, test case, and evidence, so a team can trace a single CVE to every affected product release on demand. That connected record is what lets an early warning go out in hours instead of days. If you want to see how that traceability holds up under a real reporting timeline, start afree 30-day trial of Jama Connect. Or, to learn more about preparing for the Cyber Resilience Act, watch our on-demand webinar for in-depth information.
Frequently Asked Questions About the Cyber Resilience Act
When does the Cyber Resilience Act take effect?
The CRA phases in, and its first operational deadline is September 11, 2026, for Article 14 reporting. The regulationentered into force on December 10, 2024, and full compliance with CE marking and conformity assessment is required by December 11, 2027. Because reporting applies earlier to products already on the market, waiting until late 2027 leaves a gap of more than a year on the most time-sensitive obligation.
What products does the Cyber Resilience Act apply to?
It applies broadly to hardware and software products with digital elements that connect directly or indirectly to a device or network. That includes connected hardware, standalone software, and manufacturer-developed remote processing essential to a product’s function, while pure SaaS generally falls outside the scope. Products covered bysector-specific EU legislation, such as medical devices, vehicles, and aircraft, are excluded because their own frameworks already address cybersecurity.
What are the Cyber Resilience Act reporting deadlines?
The clock starts the moment a manufacturer becomes aware of a qualifying event rather than after the investigation closes. A 24-hour early warning is followed by a 72-hour notification with general information and an initial assessment, including exploit details and remediation actions. Afinal report is issued within 14 days after a corrective measure becomes available for actively exploited vulnerabilities, or within 1 month of the initial notification for severe incidents.
What are the penalties for Cyber Resilience Act noncompliance?
The steepest fines attach to failures in core security requirements and Article 14 reporting, reaching up to15 million euros or 2.5 percent of global annual turnover, whichever is higher. Other obligations carry their own maximum tiers, and providing misleading information to authorities can draw fines up to 5 million euros or 1 percent of turnover. Market surveillance authorities can also pull products from the EU market or order recalls, which often costs more than the fine itself.
Jama Connect has once again been named a Leader in G2’s Summer 2026 Grid® Report for Requirements Management Software. This recognition, based on data gathered by April 28, 2026, comes directly from the engineering teams who use Jama Connect to build complex, regulated products every day.
Below, you’ll see exactly what we earned in the report, what our customers said, and why Jama Connect continues to lead the category.
What Jama Connect Earned in the G2 Summer 2026 Report
G2 rankings reflect verified user reviews and real market performance. Jama Connect was recognized across the board:
Overall Leader in the G2 Grid® for Requirements Management
Enterprise Leader for strong performance in large organizations
Mid-Market Leader for results among mid-sized teams
Small Business Leader for small business requirements management
EMEA Leader and Europe Leader across regional grids
Momentum Leader, ranked in the top 25% of products for growth and innovation
Best Relationship for customer success and commitment
What Jama Connect Customers Say
The scores tell the story. Jama Connect earned a customer satisfaction score of 95, and the user feedback backs it up:
95% rated Jama Connect 4 or 5 stars.
86% said they would recommend us.
86% believe Jama Connect is headed in the right direction.
Recognition like this is earned through consistent performance. It signals that teams managing safety-critical requirements, regulatory compliance, and complex development cycles trust Jama Connect to deliver.
Multidisciplinary engineering teams face a constant tension: move faster without cutting corners on quality or compliance. Jama Connect is purpose-built to resolve that tension. Here’s what sets it apart.
Live Traceability™
Jama Connect maintains end-to-end traceability across the development lifecycle. Teams navigate upstream and downstream relationships with ease, manage rigorous change control, and prove compliance without the manual burden of chasing documentation across siloed tools.
AI-Driven Development
Jama Connect now powers AI-Driven Development for regulated teams through:
Jama Connect Advisor™: Natural language processing improves requirements quality by applying INCOSE rules and EARS notation, reducing the ambiguity and contradictions that drive 70%-80% of rework costs.
Jama Connect MCP™ Server: Jama Connect is the first engineering management platform to deliver an MCP Server, advancing AI-Driven Development while keeping AI outputs auditable and compliant. It improves product velocity, inference quality, and token efficiency.
Purpose-Built for Regulated, Multidisciplinary Teams
Jama Connect helps teams in medical devices, aerospace and defense, automotive, semiconductor, and more comply with industry-specific standards without slowing development. AI-generated requirements, test cases, and traceability adhere to the standards each industry demands.
The AI-Native Engineering Management Platform
This recognition reinforces our direction. Jama Connect is now an AI-native engineering management platform built to increase product velocity for regulated, multidisciplinary teams.
The premise is straightforward: siloed teams, tools, and data prevent companies from realizing the velocity gains AI promises. Jama Connect acts as the product context layer that connects them, maximizing LLM inference quality, enabling parallel engineering across disciplines, automating with CI/CD pipelines, and maintaining AI governance and standards compliance. The goal stays the same: let engineers focus on engineering, not on tooling and paperwork.
The G2 Summer 2026 results confirm what our customers already know: Jama Connect leads requirements management for teams that need clarity, traceability, and confidence across the development lifecycle.
Ready to dig deeper? Download the G2 Summer 2026 Grid® Report to see the full results, or request a personalized demo and we’ll show you how Jama Connect helps regulated, multidisciplinary teams move faster without sacrificing quality or compliance.
Imagine a state agency deploys an AI tool to help draft procurement requirements. The tool is fast, the outputs look good, and program staff start using it across multiple projects.
Six months later, the inspector general requests documentation showing how a specific contract requirement was developed, who approved it, and how it connected to the original policy directive.
No one can produce that record.
The AI tool did exactly what it was supposed to do, but the governance structure around it didn’t.
This scenario plays out in variations across state government every day. AI adoption is accelerating, but the frameworks needed to make that adoption defensible, including under legislative oversight, audit scrutiny, procurement challenges, and public records requests, haven’t kept pace.
This article outlines concrete challenges of governing AI at scale in government settings, explaining why they’re especially difficult for state agencies, and offers practical guidance on where to focus first.
The Top Challenges of Governing AI at Scale for State Agencies
1. Unclear Ownership Across Teams
When an AI tool gets deployed, multiple teams often think someone else owns it:
The business unit that requested it assumes IT manages it.
IT assumes the vendor is accountable.
The vendor assumes the agency defined the acceptable use.
This distributed confusion isn’t unique to government, but it’s more consequential there. In the private sector, a gap in AI ownership creates operational risk.
In state government, it can mean a program operates without accountable review, a use case expands beyond what was originally authorized, or no one flags that an AI output influenced a high-stakes decision without oversight.
Effective AI governance requires clearly defined ownership at every stage:
Who approved the use case
Who monitors ongoing use
Who has authority to expand or restrict it
Who is responsible if something goes wrong
Here’s what this looks like in practice. A state agency might have a program manager, an IT lead, a compliance officer, and a vendor all involved in an AI implementation.
Without explicitly assigning who owns governance decisions, each one defers to the others. The result is no one does.
2. Weak Requirements Quality Before AI Is Applied
This is one of the most underappreciated AI governance challenges, particularly in government programs: AI tools amplify ambiguous input.
When a requirement is incomplete, untestable, or vague, running it through an AI workflow produces an output that is harder to trace back to what was authorized.
The speed of AI makes this worse, because teams can move far down a development path before anyone notices the foundational requirement was flawed.
Strong governance requires that requirements meet basic quality standards before AI touches them:
Complete: They define what they need to define, without gaps
Testable: Outcomes can be verified against them
Unambiguous: There is one clear interpretation
Appropriately scoped: They specify what’s included and what isn’t
Catching quality issues at the point of authoring is far less costly than catching them during an audit, a procurement challenge, or a legislative review.
3. Limited Traceability Between Outputs and Approved Requirements
Requirements traceability is a basic accountability standard in government programs. It’s also one of the first things to break down when AI is introduced without governance structure.
AI tools produce outputs quickly. When those outputs aren’t linked to the requirements that authorized them, the agency has no reliable record of:
Where a decision came from.
What authorized it.
Whether it stayed within approved scope.
This is a governance architecture problem. Traceability needs to be built into the workflow from the beginning. It is something to be not assembled after the fact when an audit request arrives.
When traceability is part of normal work, agencies get a clear, continuous record.
They know how requirements evolved, what decisions were made, and how every deliverable connects to an approved specification.
4. Invisible Downstream Impacts When Requirements Change
Requirements change, that’s normal in any government program.
What’s not normal, but increasingly common with AI-assisted workflows, is that downstream work doesn’t automatically reflect those changes, and no one knows it.
When a requirement is updated in a well-governed system, there’s a clear signal about what work is now out of alignment.
When that structure doesn’t exist, teams continue building on a requirement that’s no longer current. They may deliver a product that doesn’t match what was authorized, without knowing it until a review surfaces the gap.
This is particularly at risk in AI workflows because outputs are produced faster and in higher volume. A single upstream requirement change can affect a large body of downstream work before anyone catches it.
Governance needs to include change visibility, a mechanism that surfaces what’s affected when a requirement changes, so program managers can make informed decisions rather than discover problems at the worst possible moment.
5. After-the-Fact Documentation
Most government programs still build compliance documentation at the end of a project cycle. This was always imperfect, but with AI-assisted work, it becomes untenable. AI tools can generate large volumes of work in a short time. Reconstructing the decision trail for all of it is time-consuming, often incomplete, and frequently inaccurate.
The solution is to shift documentation from a closing task to a byproduct of normal work. When links between requirements and outputs are created at the time work is done, and every action connected to a requirement is logged in a version-controlled record, agencies don’t face a documentation gap. They have an accurate, continuous audit trail.
6. Controls That Don’t Match the Risk Level of Each Use Case
Not every AI use case carries the same risk. An AI tool used internally to summarize meeting notes is very different from one used to help evaluate procurement bids, score program applications, or develop regulatory guidance.
One of the most common AI governance challenges is applying the same governance requirements to every use case, or applying no requirements at all. Both are failures.
When controls are too light for high-stakes uses, the agency is exposed. When controls are too heavy for low-stakes uses, teams work around them, and the governance process loses credibility.
Effective governance applies controls that match each use case’s actual risk profile, factoring in:
The stakes of the outputs (who is affected and how).
Whether AI-generated content requires human review before use.
What data the system accesses and how it’s protected.
The regulatory and oversight environment for that program area.
Matching controls to use-case risk is harder than applying a blanket policy, but it produces governance that people follow.
7. Low Visibility into How AI Is Being Used
This challenge tends to grow as AI usage expands. Tools proliferate, with some approved and others adopted informally. Without a clear view of where AI is being used, it’s nearly impossible to identify higher-risk activity. This visibility gap creates a compounding problem: the more AI is used, the harder it becomes to govern.
A practical approach is maintaining an active inventory, covering approved systems, AI features embedded in existing tools, and known informal uses. This becomes the foundation for prioritizing governance resources and identifying where controls need to be strengthened.
Why These AI Governance Challenges Are Especially Critical for State Agencies
The challenges of governing AI at scale affect all types of organizations. But state government agencies face a specific combination of pressures that makes these challenges more acute.
Non-Negotiable Accountability Standards
Legislative oversight, inspector general reviews, procurement audits, and public records requests all require a clear, traceable record of what was decided, why, and how it connected to authorized requirements.
In private organizations, gaps in that record can be managed internally. In government, they become public problems.
Explainability Isn’t Optional
When an AI-assisted decision affects a contract award, a program eligibility determination, or a regulatory outcome, agencies need to explain how that decision was made.
“The AI tool recommended it” is not an acceptable answer in any oversight context.
The governance structure needs to produce an explanation that survives scrutiny.
Requirements Documentation Carries Legal Weight
In government programs, what was authorized matters as much as what was delivered. Requirements serve the purpose of internal planning. They are also the basis for contract terms, compliance reviews, and procurement challenges.
Weak requirements quality and poor traceability open the door to operational risk and legal exposure.
Constrained Resources
State agencies can’t always match the governance infrastructure of large federal agencies or well-resourced private companies.
That makes it even more important to build governance into workflows efficiently, rather than layering on documentation requirements after the fact.
What State Agencies Need to Prioritize Before Scaling AI
The good news is that you don’t need to stop everything you’re doing. However, you do need to set the right foundation before adoption expands.
Before scaling AI use across programs, agencies need to focus on these priorities.
Establish Quality-Reviewed Requirements as the Starting Point
AI should only be applied to work that is well-defined, testable, and unambiguous. Requirements that fail basic quality checks should be resolved before AI enters the workflow.
Assign Clear Ownership for Every AI Use Case
Define who is accountable for governance decisions, who monitors ongoing use, and who has authority to approve expansions or changes. Accountability can’t be assumed; it needs to be explicit.
Build Traceability Into Workflows From the Beginning
Links between requirements and outputs should be created as work is done, not reconstructed afterward. Every deliverable should trace back to an approved specification.
Create Change Visibility Mechanisms
When requirements change, downstream impacts should be surfaced immediately. Teams shouldn’t discover misalignment at audit time.
Match Controls to Use-Case Risk
Apply more rigorous oversight, including human review, access restrictions, and documentation requirements, where the stakes are highest.
Avoid applying the same controls to everything, which produces friction without proportionate benefit.
Bottom Line: Establish Governance, Then Scale
Speed and accountability aren’t in conflict when governance is designed from the start, not bolted on later.
The agencies that will move fastest with AI are the ones that built the right structure first: clear requirements, explicit ownership, built-in traceability, and controls that match actual risk.
These are what makes AI adoption defensible when oversight comes, and in state government, oversight always comes.
Jama Connect® Can Help
If your agency is working through these challenges, Jama Connect can help you achieve governance and keep AI work defensible from the start.
Jama Connect’s AI capabilities help teams create strong, verifiable requirements with quality analysis and refinement to remove ambiguity. It catches defects at authoring to reduce manual editing cycles and later-stage costs, addressing the root cause of rework.
With immutable audit trails, integrated requirements management, and Live Traceability™ that flags downstream impacts, you’ll reduce late-stage changes and improve product quality.
To see how it fits your mission, explore Jama Connect for the public sector today.
Ready to Enable a Streamlined and Collaborative Digital Workplace
for Government and Public Service Missions? LEARN MORE
TrustRadius is an independent B2B software review platform. The award is determined entirely by verified user reviews.
There are no analyst panels or nominations, just input from the teams who use the product every day.
What the TrustRadius Top Rated Award Signals
The TrustRadius requirements management category is competitive, and earning recognition here requires consistent performance.
It’s a signal that users trust us.
For Jama Connect, that includes managing safety-critical requirements, maintaining regulatory compliance, and accelerating product development across complex, multidisciplinary engineering organizations.
“With Jama Connect, we have the confidence that we can easily show regulators the linkages between each individual item, with full traceability from top to bottom. I can easily click through the whole storyline of how requirements fit into the V-model and what actions we took.”
— Verified Customer, Director of Quality and Regulatory, Medical Device Company
What Jama Connect Is Built to Do
Multidisciplinary engineering teams face a specific challenge: move faster without cutting corners on quality or compliance. Jama Connect is purpose-built for that environment.
Key capabilities include:
AI-Driven Development: Increase velocity for regulated multidisciplinary products with Jama Connect Advisor™ and Jama Connect Model Context Protocol™ (MCP).
Live Traceability™: Maintain rigorous change management with end-to-end traceability. Navigate upstream and downstream relationships with ease across complex product requirements.
Regulatory Compliance Support: Eliminate manual compliance with AI-generated requirements and adhere to industry-specific standards for industries like medical devices, aerospace, automotive, and more.
Collaboration Tools: Keep multidisciplinary teams aligned without adding friction with features like stakeholder commenting, intuitive workflows, and export functionality.
The goal has always been simple: let engineers focus on engineering, not on chasing documentation and tooling.
How Jama Connect Powers AI-Driven Development Today
This recognition reinforces our direction.
Jama Connect recently became the first engineering management platform to deliver an MCP Server, advancing AI-Driven Development for regulated teams.
It improves product velocity, inference quality, and token efficiency while keeping AI outputs auditable and compliant.
If you are evaluating intelligent engineering management solutions or want to see what sets Jama Connect apart in requirements management, request a personalized demo.
Our team will walk you through how Jama Connect helps regulated, multidisciplinary organizations move faster without sacrificing quality or compliance.
A defense program contracts three suppliers before holding its Preliminary Design Review (PDR). Six months into development, each supplier has interpreted the system requirements differently because no authoritative baseline existed when contracts were signed. The integration milestone becomes a discovery event, revealing interface conflicts that trace back to requirements the teams never reconciled. This retroactive traceability problem can spread quickly across the supply chain when requirements are not stabilized before contracts begin.
ISO/IEC/IEEE 15288 exists to prevent these failures. The standard defines lifecycle processes that govern how systems are conceived, developed, produced, operated, and retired. When applied with discipline, it gives programs a shared process structure that spans every tier of the acquirer-supplier hierarchy. When ignored or partially applied, the consequences show up as cost growth, schedule delays, and certification gaps that compound at every stage.
This guide covers what the standard is, how its four process groups fit together, how it compares to adjacent standards, how regulated industries apply it, and the traceability structure that makes 15288 workable at scale.
What Is ISO/IEC/IEEE 15288?
ISO/IEC/IEEE 15288:2023 is the international standard for system lifecycle processes, published jointly by the International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and Institute of Electrical and Electronics Engineers (IEEE). Thecurrent edition appeared in May 2023, supersedes the 2015 version, and carries the full title “Systems and software engineering, System life cycle processes.”
It establishes a common structure of process descriptions for systems created by humans, applicable from conception through disposal. The standard defines its lifecycle processes in four groups. It does not prescribe a specific lifecycle model, development methodology, or technique. Programs can apply the processes iteratively, concurrently, and recursively to both standalone systems and systems of systems.
This lifecycle-model independence is why 15288 applies across waterfall, spiral, and agile approaches. ISO/IEC/IEEE 15288:2023 is often treated as the anchor systems engineering standard, and the International Council on Systems Engineering (INCOSE) Systems Engineering Handbook provides practitioner-level guidance on every process. That role places it at the center of the systems engineeringbody of knowledge.
The Four Process Groups in ISO/IEC/IEEE 15288
The lifecycle processes break into four groups defined in Clause 6. They coversystems engineering work across contract negotiation, development, operation, and disposal. Each group operates at a different team level, and programs tailor their application based on system complexity, mission criticality, and contractual requirements:
Agreement processes: Acquisition and supply activities that define the contractual relationship between buyer and supplier. In defense and aerospace prime/sub structures, these processes govern how requirements flow down, how acceptance criteria are established, and how deliverables are monitored across tiers.
Organizational project-enabling processes: Lifecycle model management, infrastructure, portfolio management, human resources, quality management, and knowledge management. These provide the enterprise scaffolding around individual programs, including the process assets that a program’s systems engineering plan references.
Technical management processes: Project planning, assessment and control, decision management, risk management, configuration management, information management, measurement, and quality assurance. These processes govern how development efforts are managed day-to-day.
Technical processes: The engineering processes from business or mission analysis and user needs definition through architecture, design, implementation, integration, verification, validation, operation, maintenance, and disposal. This is the engineering work itself.
Configuration management connects the other processes. When configuration management is reduced to document control, it fails to bridge disconnected tools and disciplines, and traceability gaps become structural rather than incidental.
How ISO/IEC/IEEE 15288 Compares to Adjacent Standards
ISO/IEC/IEEE 15288 has the greatest breadth but least depth of any systems engineering standard. It works as a skeleton that domain-specific standards fill with technical content. Three adjacent standards interact with it most frequently.
ISO/IEC/IEEE 12207: Software Lifecycle Processes
ISO/IEC/IEEE 12207 defines processes for the software lifecycle. A later revision aligned 12207 more closely with 15288’s process structure, and both now share the same process model, differing primarily in descriptive notes. For software-intensive systems, both standards apply simultaneously. ISO/IEC/IEEE 15288 applies at the system level, and ISO/IEC/IEEE 12207 applies at the software element level.
ISO/IEC/IEEE 29148: Requirements Engineering
ISO/IEC/IEEE 29148 expands therequirements engineering activities that 15288 names but does not detail. It covers the requirements-focused technical processes around business or mission analysis, user needs definition, and system requirements definition. ISO/IEC/IEEE 29148 defines how requirements engineering is performed within a lifecycle, but does not carry tailoring authority. Teams cannot use 29148 to modify process-level obligations established by 15288.
The INCOSE Systems Engineering Handbook
The INCOSESystems Engineering Handbook translates 15288’s normative process definitions into practitioner guidance. Each chapter follows a two-layer structure, with a normative overview consistent with 15288 followed by detailed guidance covering methods and practices. The handbook turns the standard’s tailoring provisions into step-by-step guidance that programs can apply directly to their systems engineering management plans.
ISO/IEC/IEEE 15288 Across Regulated Industries
The standard’s lifecycle process framework appears across industries where systems are complex, long-lived, and subject to regulatory oversight. In each sector, it sits alongside domain-specific safety and software standards rather than replacing them.
Aerospace and Defence
Prime contractors may flow 15288 requirements to suppliers through contract terms. Programs often pair 15288 with MIL-STD-882E for system safety, DO-178C for airborne software certification, and ARP4754A for aircraft-level development assurance.
Defense programs are a significant user community for the standard. ISO/IEC/IEEE 15288 establishes a common framework for describing the lifecycle of engineered systems, and IEEE 15288.1 establishes systems engineering requirements intended to serve as the basis for acquirer-supplier agreements for Department of Defense (DoD) programs.
Automotive
In the automotive sector, ISO/IEC/IEEE 15288 is sometimes discussed as a general systems engineering lifecycle framework for safety and development processes. ISO 26262 defines the safety activities that must occur at each lifecycle phase. ISO/IEC/IEEE 15288 provides the process rigor for how those activities are carried out, structured, and traced through requirements definition and verification. Many automotive teams pair this withAutomotive SPICE (ASPICE), which assesses the maturity of those same lifecycle processes against a defined capability scale.
Medical Devices
For medical device manufacturers building complex products or Software as a Medical Device (SaMD), 15288 can work as an internal systems engineering structure aboveIEC 62304 and ISO 13485. The FDA does not cite 15288 directly, but manufacturers building systems with embedded software, hardware-software interaction, and multi-variant product lines often adopt it.
Nuclear and Energy
The IAEA describes systems engineering as a lifecycle-wide approach for nuclear facilities and points to ISO/IEC/IEEE 15288 as a common process framework. For industrial and energy systems where operation, maintenance, and disposal span decades, 15288’s later-stage processes carry as much weight as the design-phase processes that many programs focus on.
Common Implementation Challenges With ISO/IEC/IEEE 15288
Tailoring the full process set to a specific program without breaking the standard’s intent is an early challenge for teams adopting 15288. Sound tailoring decisions are driven by lifecycle considerations, mission application, team complexity, technical complexity, risk, and technical understanding.
Programs that tailor before completing this characterization are making weakly justified adjustments. Enterprise-scale teams may document broader process coverage than smaller teams, while smaller teams may blur the line between “not applicable” and “not needed.”
Maintainingrequirements traceability across disconnected tools is the second persistent failure mode. When requirements live in one tool, architecture models in another, and verification evidence in a third, no single system can answer whether a given requirement has been verified.
Bidirectional requirements traceability is a commonly expected capability in systems engineering processes, especially in regulated or safety-critical contexts. Programs are expected to align with DoD systems engineering expectations in practice, not just in what their systems engineering management plan documents claim.
Coordinating across distributed teams and suppliers compounds both problems. A single authoritative requirements baseline that multiple teams reference through structured review workflows and Requirements Interchange Format (ReqIF)-based data exchange helps reduce this coordination challenge. Without that shared baseline, interface changes spread without visibility, and configuration management failures cascade from sub-tier suppliers upward.
Best Practices for Applying ISO/IEC/IEEE 15288
A tailored process inventory belongs in place before program execution begins. Teams can build from the full process set and document each inclusion, scaling, or exclusion decision with rationale. That inventory belongs in the systems engineering management plan, baselined in the Request for Proposal (RFP) as an attachment to the Statement of Work (SOW), not after contract award.
Technical processes work best when tied to a formally approvedrequirements baseline managed with practices aligned to ISO/IEC/IEEE 29148, including baseline approval, configuration control, and traceability. Every technical process that consumes requirements, including architecture definition, design, verification, and transition, should trace to that baseline. Verification methods such as analysis, inspection, demonstration, or testing belong with each requirement when it is entered, not after design is underway.
Verification and validation work best when treated as continuous rather than gated phases. The standard permits concurrent, iterative, and recursive application of all processes, including verification and validation. Programs that defer verification to a terminal phase lose the ability to catch requirement conflicts at the integration levels where they are cheapest to resolve.
Verification belongs throughout the integration and development process, not only at the end. Measurement processes belong in place from day one of the lifecycle. Teams should define Measures of Effectiveness during user needs definition, derive Measures of Performance during requirements definition, and establish Technical Performance Measures (TPMs) before architecture trades begin.
These indicators need continuous collection rather than milestone-driven assembly. A program that defines TPMs at PDR cannot use them as leading indicators of architectural risk.
How Jama Connect® Supports ISO/IEC/IEEE 15288
Fragmented traceability and disconnected evidence make the technical and technical management processes defined in ISO/IEC/IEEE 15288 hard to execute. Jama Connect® is a cloud-based requirements management and traceability platform for complex, regulated product development, and it addresses that problem by holding requirements definition, architecture linkage, verification and validation evidence, configuration management, and risk management in one place.
These relationships connect throughLive Traceability™, with Traceability Information Models (TIMs) enforcing expected links between artifact types, so a requirement change flags downstream test cases and risk items as suspect.
For programs operating across distributed teams and suppliers, authoring quality and data exchange become part of the same challenge. The Jama Connect Advisor™ add-on scores requirements against INCOSE rules and Easy Approach to Requirements Syntax (EARS) patterns during authoring.
The Jama Connect Interchange™ add-on supports bidirectional synchronization with tools like Jira and ReqIF-based exchange with supply chain partners, which helps maintain traceability across team boundaries without forcing every participant onto a single tool.
Making 15288 the Operating System for Engineering Work
The programs that get the most from ISO/IEC/IEEE 15288 treat it as the operating system for how engineering work gets done, so compliance becomes the byproduct of a functioning lifecycle rather than an artifact assembled before an audit.
That shift is what separates a standard that lives in a binder from one that shapes daily decisions, and it is increasingly hard to sustain ascost and schedule pressure keep climbing across major acquisition portfolios.
Jama Connect supports this workflow by keeping requirements, verification evidence, and change impact connected throughout the lifecycle, so teams can see coverage and impact without having to reconstruct them before a review. You can see how that works on your own program with afree 30-day trial of Jama Connect.
Frequently Asked Questions About ISO/IEC/IEEE 15288
Is ISO/IEC/IEEE 15288 mandatory?
At the standards level, no. Adoption alone does not make the standard mandatory, and each Program Management Office decides whether and how to apply it. It becomes contractually binding when a Program Management Office cites it in an RFP, SOW, or contract, and defense primes then flow those obligations to suppliers through subcontract terms. Check the solicitation package and subcontract language first, because that language determines whether you are managing 15288 as an internal best practice or as a contractual requirement.
What is the latest version of ISO/IEC/IEEE 15288?
The current edition is ISO/IEC/IEEE 15288:2023, published in May 2023. It supersedes the 2015 edition with improvements to selected technical processes, updates to risk management and configuration management, a new annex on model-based systems engineering, and a change in terminology from “man-made” to “systems created by humans.” Review the tailoring guidance and lifecycle terminology together rather than treating the update as a simple edition-number change.
How does ISO/IEC/IEEE 15288 relate to ISO/IEC/IEEE 12207?
The two standards are aligned so they can be used together, sharing the same overall process architecture and differing mainly in whether the activities target system-level or software-level engineering. When software is the predominant element of interest, 12207 is the standard to lead with. For software-intensive systems, both apply simultaneously, with 15288 governing system-level obligations and 12207 governing software-specific activities. A practical rule follows: use 15288 to manage system responsibilities and 12207 to manage software responsibilities within the same lifecycle structure.
Who uses ISO/IEC/IEEE 15288 in practice?
Defense and aerospace programs are the most visible adopters, often through contract flow-down to suppliers. Automotive teams apply ISO 26262 for functional safety, using 15288 more generally as a lifecycle framework, while medical device and nuclear facility programs adopt it to structure the lifecycle that domain-specific safety standards plug into. Across these settings, the common driver is the need to manage traceability, lifecycle tailoring, and cross-team coordination throughout long, complex development cycles.
Jama Software recently announced that Jama Connect® now delivers a Model Context Protocol (MCP) server. This may appear as a mere technical enhancement, but it represents something more fundamental: a shift in how engineering organizations can operationalize AI within governed, traceable environments.
Requirements and traceability management platforms have long served as repositories for structured engineering knowledge, capturing requirements, decisions, and the relationships between them. Meanwhile, AI tools have largely evolved outside these environments, often operating without access to reliable, governed context. The introduction of MCP begins to bridge this divide, connecting AI capabilities with the structured data.
By enabling AI systems to securely access and operate on structured engineering data, teams can now interact with their source of truth from within AI-enabled environments such as Claude, GitHub Copilot, or Visual Studio. This allows Large Language Models (LLMs) to generate outputs grounded in real project data, improving relevance, reducing ambiguity, and maintaining alignment with traceability and compliance expectations.
From Systems of Traceability to Systems of Insight
The introduction of MCP signals a transition from static data management to dynamic, context-driven insight.
Instead of manually extracting and interpreting information, engineers and stakeholders can query their systems in natural language and receive structured, synthesized outputs. These outputs are not generic, they are grounded in the relationships, baselines, and traceability models that define the system.
This creates a new class of workflows that are AI-assisted, context-aware, and continuously up to date.
Importantly, this is not limited to a single role or activity. The same capability can support a wide range of use cases, from requirements analysis and impact assessment to compliance reporting and design reviews.
To make this more concrete, it is useful to look at one example.
Among the many possible applications, project visibility provides a clear and familiar illustration of the value MCP can unlock.
Project managers and team leads often spend a great amount of time assembling status updates. Information is fragmented across teams, components, and tools. The process typically involves conversations, manual reviews, and iterative follow-ups, followed by the equally time-consuming task of consolidating everything into a coherent narrative, while staying up to date.
With MCP, this process can be fundamentally restructured.
By leveraging the traceability information model, activity streams and content available in their Jama Connect instance, teams can generate structured project evolution summaries on demand. These summaries provide a real-time, system-level view of what has changed, where gaps exist, and which risks or issues require attention.
Instead of chasing updates, project leaders can focus on interpreting and acting on them.
A Practical Illustration: The ThermoCare Example
To explore this pattern, we applied MCP-enabled workflows to a simulated medical device project: ThermoCare, an infrared baby thermometer.
Although simple in concept, ThermoCare reflects the realities of regulated engineering. It includes system and subsystem requirements, architectural decomposition, risk considerations, and full traceability across baselines, aligned with standards such as ISO 13485.
Within this environment, AI-generated summaries were stored directly in Jama Connect in a dedicated project management component (see image below). Both the structure and presentation were configurable, reinforcing that this is a flexible approach rather than a fixed feature.
The generated summaries included:
Executive highlights of key project developments
Milestone timelines with linked evidence
Delivery snapshots of artifacts and progress
Traceability maturity assessments with actionable insights
Recommendations for next steps and areas of focus
Example of project summary report generated via MCP
We also explored time-based queries, such as generating a “last week’s activity” summary. This surfaced the most actively updated artifacts and their contributors, providing immediate insight into project momentum and ownership.
Beyond Project Management: A Reusable Pattern
Project reporting is just one example of a broader pattern and wider range of possibility.
The same MCP-enabled approach can be applied across engineering workflows:
Requirements engineers can analyze completeness, consistency, and change impact
System architects can explore relationships and dependencies across components
Quality and compliance teams can generate audit-ready narratives and traceability evidence
Engineering leaders can gain continuous visibility into program health
In each case, the underlying principle is the same: AI operates on structured, governed context to produce meaningful, role-specific insight.
Early observations by Jama Software development teams using AI suggest meaningful efficiency gains, potentially around 30% at the stage where teams implement AI-assisted workflows, and up to 5x when organizations move toward fully agentic, spec-driven development. These figures come from Jama Software’s AI Adoption Maturity Model (AI-Assisted Software Workflow Playbook Whitepaper), which maps a four-stage progression from initial pilots through cross-disciplinary AI-driven development. However, the more important shift is qualitative.
Teams can identify traceability gaps earlier, assess readiness continuously rather than at milestones, and focus communication on what truly requires attention. Decision-making becomes more proactive, grounded in up-to-date system knowledge rather than retrospective summaries.
Who Should Pay Attention
This evolution is relevant across the engineering organization:
Systems and software engineers managing complex requirement sets
Project managers navigating milestones and delivery pressure
Quality and regulatory teams responsible for compliance and auditability
Any organization operating under structured frameworks where traceability is critical
A Direction for Engineering Workflows
AI in engineering is often discussed in terms of isolated productivity gains. MCP suggests a broader trajectory, one where AI becomes embedded within the core systems that define engineering work.
By connecting AI to structured, traceable context, organizations can move beyond experimentation toward scalable, governed adoption. The larger opportunity lies in rethinking how engineering knowledge is accessed, interpreted, and acted upon, across every role, and throughout the entire lifecycle.
Most importantly, this shift enables engineers and other stakeholders to spend more time on critical thinking, problem solving, and decision making, while leaving to AI the burden of repetitive execution and documentation tasks.
New to Systems Engineering in Medical Device & Life Sciences? Here’s What You Need to Know.
Stepping into systems engineering for the first time, transitioning into a new role, or looking to strengthen your foundation and grow with confidence? This webinar will help you build a clear understanding of what systems engineering is, what the day-to-day work looks like, and what it takes to succeed.
In this webinar,Chris Unger, INCOSE Healthcare Working Group Lead, and Vincent Balgos, Sr. Director of Solutions & Consulting at Jama Software, share practical guidance for getting started and building a strong foundation for long-term career growth in the medical device & life sciences industry. From core responsibilities and daily work to the hard and soft skills that matter most, this session will help you better understand the role and how to grow in it.
What You’ll Learn:
What systems engineers do day to day, and the core responsibilities of the role
The essential hard and soft skills that help systems engineers succeed
Practical guidance for navigating a new or evolving systems engineering role
Strategies to keep learning, growing, and building confidence in your career
Real-world insights from experienced systems engineers you can apply right away
Take the first step in your systems engineering journey and register today.
Vincent Balgos: Thank you for attending. My name is Vincent Balgos. I’m the Senior Director of Medical Device Solutions here at Jama Software. And today I’m happy to have a conversation with Chris Unger. Chris, would you like to introduce yourself?
Chris Unger: Yeah. Hi, I’m Chris Unger, the retired Chief Systems Engineer for GEA Healthcare. I spent five years in defense and then 40 years in medical device, and I’m the head of the INCOSE Healthcare Working Group.
Balgos: Great. And Chris, we just finished up with the 11th annual systems engineer, sorry, INCOSE Systems Engineering Conference. I’m curious, could you share with our audience a little bit about the history, but also what exciting events and key takeaways that you had from this year’s event?
Unger: Sure, absolutely. Thank you, Vincent. Yeah, we started 11 years ago in Chicago when AAMI created the TIR45, on how to be agile in healthcare while working with the FDA. And we had a concern that would be considered software only. We wanted to have more iterative spiral development. And it was 15 people just by invitation only, and it has grown now to the last two years of over 200 people and many, many tracks. And particularly exciting to see the evolution in topics. For example, compliance was one of our early topics, and now it’s not there. We don’t worry about compliance. What we’re interested about is customer focus, and the AI track has grown from 10 people to 50 people in the room. So very exciting evolution of topics.
Balgos: Yeah. Where do you see systems engineering growing within the MedTech area?
Unger: Yeah. Compared to 40 years ago, devices were fairly complex. CT had hardware and software, hardware chemistry and mechanics, and electronics, and some software to now, with the growth of software, it is incredibly complex. Layers, you’ve got algorithms, four levels of control theory, and so many overconstraints. So that’s where to take, for example, a thermal problem. Is that a dissipation problem in electronics? Is it a thermal cooling problem? Is it a duty cycle problem of like, “I’m spending too much time in high performance, and I should coach the customer in only using the high dissipation modes.” So those kinds of system trade-offs are becoming much more important, but that’s the baseline of the last five years. Going forward with AI, the implementation speed’s going to go way, way higher. I even saw that 10 years ago, when we had more of the beginning of the digital twin.
In the past, mechanical engineers had time to do a design, ship it out, and get it back. Now it’s like with digital twin, they do it at a design, and they get the answer back the next day. So you really did need to make sure that you understood the incremental approach to avoid rework. AI is going to take that to the next level. The ability to have AI do your circuit science for you, do your software design, the speed’s going to go up like 10X, and systems engineering has to go off and be the orchestrator, the conductor of the orchestra, make sure when everybody’s going so fast, we still stay aligned and focused on the customer.
So in those cases, being able to work with marketing, trust marketing, but also know the customer’s needs and be able to take the value to the customer, divided by being pseudo-analytical, divided by the cost to implement times the risk. Something might take a certain amount of effort and have a 10% chance of succeeding. So the effective cost of the company is 10X bigger. Being able to tie that all together and make sure everybody is focused on the most valuable work for the next week, not the next six months. The speed of those decisions is going to be huge going forward.
Balgos: Yeah. And that system thinking approach is what really brings system engineers here to help-
Unger: Sorry to interrupt. But systems thinking plus the ability to communicate it in words, taking the customer’s needs and translating that down into words that an electrical software engineer can understand. That translation, speaking both worlds together, is critical.
Balgos: So yeah, not just thinking, but then translating and helping drive these more AI-enabled teams to make quicker decisions and safer and more effective healthcare products. Great. Anything else on the AI front that excites you with MedTech coming up?
Unger: Yeah. The ability to have AI take some of the tedious work out, how to write a good requirement, A, can do that really well. It’s also really easy to learn new techniques. I was talking to the CEO of a startup about a use case, and that’s something that software people use for a while, systems people didn’t, and she didn’t understand what it was. So she was trying to get an example for a company, and she gave AI, “Give me a use case for an infusion pump in this problem.” And it gave her a 10-page report, really good quality, not AI, which doesn’t know what infusion up is. So the ability to say, “Oh, I’d like to learn this technique. Can you do this for me?” Your speed of learning will be really fast. The problem then is you’ve got to make sure that you know how to review those things.
So again, the ability to do good reviews and have good conversations with people is the skill you need now. I was talking about with a engineer, that example of the board where we didn’t use four boards to one, what’s the effect on thermal flow? What’s the effect on EMI/MC? Did you take a lot of EMC and suddenly put it into one area, so the EMC issue is bigger? That kind of skill that you should be using to converse with engineers who are brilliant in their area, but don’t understand other areas, will be much more important even when talking to the AI agents.
