AI-Powered Code Quality in Antigravity Editor: Automated Reviews, Test Generation & CI/CD Quality Gates

Prompt Engineering: Designing for Quality from the Start

Embedding a Review Perspective into Generation Prompts

The single highest-leverage change you can make to improve code quality is building quality criteria directly into your generation prompts. This transforms the AI from a code generator into a quality-aware engineering partner.

# Quality-First Code Generation Template

Implement the following feature.

## Requirements
[Feature description]

## Quality Criteria (mandatory)
- Error handling: add appropriate try-catch around all external calls
  and never silently swallow errors
- Type safety: comply with TypeScript strict mode (no `any` types;
  use `unknown` when the type is genuinely unknown)
- Testability: isolate side effects and implement as pure functions where possible
- Performance: avoid N+1 query problems; batch database calls when processing collections
- Security: include input validation for all user-supplied data before processing

## Output Format
1. Implementation code (with inline comments explaining non-obvious decisions)
2. Anticipated edge cases and how each is handled
3. Unit test skeleton (test case names only, organized by scenario)
4. Brief explanation of any significant design decisions

Register this as a Custom Command in Antigravity—call it something like /implement-feature—so every team member generates code against the same quality bar without having to remember the template.

Iterative Quality Improvement

Rather than demanding perfection in one shot, an iterative approach produces more reliable results and is actually faster overall. The reason: asking for everything at once forces the AI to balance too many constraints simultaneously, leading to mediocre output across all dimensions.

# Step 1: Build the working baseline
Implement [feature] with a minimal working solution.
Focus on correctness first. Don't over-engineer—just make it work.

# Step 2: Harden it
Review the previous implementation and improve for:
- Completeness of error handling (what happens when each external call fails?)
- Edge case coverage (empty inputs, null values, boundary conditions)
- Performance considerations (any operations that won't scale?)
Refactor the code to address any issues found.

# Step 3: Test-driven quality confirmation
Generate comprehensive tests for the hardened implementation:
- Happy paths (at least 3 distinct scenarios)
- Error paths (null, undefined, invalid types, boundary values)
- Edge cases specific to this domain
Include setup/teardown to ensure each test is independent.

This three-step pattern consistently produces higher-quality output than trying to generate perfect code in a single pass—and it gives you natural checkpoints to review and course-correct along the way.

Domain-Specific Prompt Patterns

Different types of code benefit from different quality-focused prompt variations. Here are patterns we've validated in production contexts:

For API route handlers:

Implement a [POST/GET/etc.] route handler for [endpoint].
Apply these patterns:
- Validate request body/params before any business logic runs
- Return consistent error shapes: { error: string, code: string }
- Use Result<T, E> for service layer calls
- Never expose internal error details to clients
- Log all errors with context (userId, requestId, timestamp)

For data processing functions:

Implement [function name] that processes [data type].
Requirements:
- Handle empty/null input gracefully (return empty result, not throw)
- Avoid mutation of input parameters
- Process large datasets without loading everything into memory at once
- Include progress reporting for operations exceeding 1000 items

For UI components:

Build a [component name] React component.
Quality requirements:
- No direct DOM manipulation (use React state and refs appropriately)
- Accessible: ARIA labels for interactive elements, keyboard navigation
- Handle loading, error, and empty states explicitly
- Memoize expensive computations with useMemo
- No business logic in the component (delegate to hooks or services)

Context Management: Making Quality Standards Persistent

Defining Quality Policy with AGENTS.md

Placing an AGENTS.md file at your project root is the single most impactful configuration you can make for consistent AI-generated code quality. It automatically applies your quality standards to every AI interaction in the project—no need to repeat them in every prompt.

# Project Quality Policy
 
## Coding Standards
- Language: TypeScript in strict mode (required)
- Formatter: Biome (see biome.json for configuration)
- Naming: camelCase for variables/functions, PascalCase for classes/types
- File structure: Feature-based module architecture
  (e.g., `features/payments/` contains service, hooks, components, types)
 
## Required Implementation Patterns
- Wrap errors in a Result type instead of throwing for expected failure modes
- Use Promise.allSettled for concurrent async operations where partial failure is acceptable
- Always include retry logic (max 3 attempts, exponential backoff) for external API calls
- Log structured JSON with consistent fields: { level, message, context, timestamp }
 
## Forbidden Patterns
- The `any` type anywhere (use `unknown` and narrow appropriately)
- `console.log` in production code (use the project's logger service)
- Unused imports or variables (these will fail CI)
- Commented-out code in PRs (delete it or open a ticket)
- Magic numbers (define named constants)
 
## Test Requirements
- Coverage target: 80%+ line coverage for business logic
- Test files: `{filename}.test.ts` co-located with source
- Mocking: use `vi.mock()` (Vitest); prefer fakes over mocks for complex collaborators
- Integration tests: required for database access and external API calls
- Test naming: "when [condition], it should [expected outcome]"
 
## Documentation
- All public functions and methods must have JSDoc comments
- Complex algorithms must explain the approach in a block comment before the code
- TODO comments must include a ticket reference: // TODO(PROJ-123): description

With this file in place, Antigravity automatically references these standards for all code generation, review, and refactoring tasks in the project.

Fine-Grained Rules via .antigravity/quality-rules.json

For more granular control over Antigravity's behavior, define rules in JSON format. This is especially useful for teams that want to encode quality thresholds that can be checked programmatically.

{
  "quality": {
    "review": {
      "focus_areas": [
        "security",
        "performance",
        "error_handling",
        "type_safety"
      ],
      "severity_threshold": "warning",
      "auto_fix": ["formatting", "imports", "unused_vars"],
      "always_check": ["authentication", "authorization", "input_validation"]
    },
    "generation": {
      "require_tests": true,
      "require_types": true,
      "require_error_handling": true,
      "comment_density": "moderate",
      "prefer_functional": true
    },
    "metrics": {
      "complexity_threshold": 10,
      "function_length_max": 50,
      "file_length_max": 300,
      "dependency_depth_max": 4
    },
    "team": {
      "review_required_above_complexity": 8,
      "test_required_for_public_functions": true,
      "breaking_change_requires_rfc": true
    }
  }
}

Automating AI Code Reviews

Real-Time Reviews with Inline Chat

Cmd+I (Mac) or Ctrl+I (Windows/Linux) launches Inline Chat, which is ideal for instant code review at the point of writing. The key is having a set of high-signal prompts ready rather than typing ad-hoc questions.

Here are review prompts organized by concern area:

# Security Review
Review this code from a security perspective. Check specifically for:
1. SQL injection / XSS / CSRF vulnerabilities
2. Authentication and authorization gaps
3. Sensitive data exposure (tokens, PII in logs, unencrypted storage)
4. Dependency on user-controlled input for file paths or system operations
Categorize each finding as Critical, High, Medium, or Low.

# Performance Review
Identify performance bottlenecks in this code.
Consider behavior at 100,000+ records in the database.
Flag: N+1 queries, synchronous I/O in async contexts,
missing indexes implied by the query patterns, memory leaks.

# Maintainability Review
Evaluate this code for long-term maintainability.
Check: single responsibility, coupling, cohesion, naming clarity.
Suggest specific refactors with before/after examples.

# Accessibility Review (for UI code)
Audit this component for accessibility issues.
Check: ARIA labels, keyboard navigation, focus management,
color contrast (note where it depends on CSS), screen reader behavior.

Standardizing Reviews with Custom Commands

Create a library of reusable team-wide review commands in .antigravity/commands/. These persist in source control, so the whole team benefits as you refine them over time.

# .antigravity/commands/review-security.md
 
Runs a comprehensive security review on the selected code.
 
## Checklist
- [ ] Input validation present for all user-supplied data
- [ ] SQL queries use parameterized statements (no string interpolation)
- [ ] Authentication tokens handled securely (not logged, not exposed in errors)
- [ ] Sensitive data not written to logs
- [ ] CORS policy explicitly configured for external-facing APIs
- [ ] Rate limiting applied to authentication endpoints
- [ ] Error messages don't reveal internal implementation details to clients
 
## Output Format
Group findings by severity level (Critical / High / Medium / Low).
For each finding:
- Location (file:line if available)
- Issue description
- Concrete fix recommendation with code example

# .antigravity/commands/review-performance.md
 
Analyzes the selected code for performance issues at production scale.
 
## Analysis Scope
- Database query patterns (N+1, missing indexes, large result sets)
- Memory allocation patterns (unnecessary allocations in hot paths)
- Async/concurrent execution opportunities being missed
- Caching opportunities for expensive computations
- Bundle size impact for frontend code
 
## Output Format
For each issue found:
- Severity (Blocking / Major / Minor)
- Expected impact at scale (e.g., "this N+1 query adds 100ms per 100 records")
- Recommended fix with code example

Integrating Reviews into Your Git Workflow

The most natural integration point for AI reviews is the pre-PR checklist. Create a PR template that prompts developers to run the relevant review commands:

# .github/pull_request_template.md
 
## Changes
[Description of what changed and why]
 
## AI Review Checklist
- [ ] Ran `/review-security` on security-sensitive code (auth, payments, user data)
- [ ] Ran `/review-performance` on database queries and data processing code
- [ ] All AI-flagged issues addressed or explicitly accepted with justification
- [ ] Tests generated and passing locally
 
## Testing
- [ ] Unit tests updated/added
- [ ] Integration tests updated if external services affected
- [ ] Manual testing completed for UI changes

Advanced Test Generation

Systematic Unit Test Generation

Antigravity can analyze implementation code and generate comprehensive test suites. The quality of the generated tests depends heavily on how clearly you specify your expectations.

Generate Vitest unit tests for the following function.

## Test Coverage Requirements
1. Happy paths: minimum 3 scenarios
   - Typical/representative input
   - Boundary values (min/max, empty collections, single-item collections)
   - Large data volumes (to surface performance or memory issues)
2. Error paths: exhaustive coverage
   - null input
   - undefined input
   - Wrong type (string where number expected, etc.)
   - Out-of-range values
   - External service failures (network errors, timeouts, 500s)
3. Side effects: mock all external calls with vi.mock()
   - Verify mocks called with correct arguments
   - Test both success and failure paths for each mock
4. Async behavior: test both resolve and reject paths

## Output Quality Standards
- Use describe/it blocks for logical grouping by scenario
- Name tests as: "when [condition], it should [expected outcome]"
- Use concrete expected values in assertions (not just truthy/falsy)
- Use beforeEach/afterEach to ensure test isolation
- Include a brief comment explaining any non-obvious test setup

Generated Test Example in Practice

Here's the kind of output you can expect when this prompt is applied to a payment processing function:

import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest'
import { render, screen, fireEvent, waitFor } from '@testing-library/react'
import { PaymentForm } from './PaymentForm'
import * as stripeModule from '@/lib/stripe'
import * as analyticsModule from '@/lib/analytics'
 
vi.mock('@/lib/stripe')
vi.mock('@/lib/analytics')
 
describe('PaymentForm', () => {
  beforeEach(() => {
    vi.clearAllMocks()
    // Ensure clean state for each test
    vi.spyOn(analyticsModule, 'track').mockResolvedValue(undefined)
  })
 
  describe('when rendering with a valid amount', () => {
    it('should display the formatted amount in the button', () => {
      render(<PaymentForm amount={1500} currency="JPY" />)
      expect(screen.getByRole('button', { name: /¥1,500/ })).toBeInTheDocument()
    })
 
    it('should enable the submit button', () => {
      render(<PaymentForm amount={1500} currency="JPY" />)
      expect(screen.getByRole('button', { name: /Pay/ })).not.toBeDisabled()
    })
  })
 
  describe('when amount is zero or negative', () => {
    it('should disable the submit button when amount is 0', () => {
      render(<PaymentForm amount={0} currency="JPY" />)
      expect(screen.getByRole('button', { name: /Pay/ })).toBeDisabled()
    })
 
    it('should disable the submit button when amount is negative', () => {
      render(<PaymentForm amount={-100} currency="JPY" />)
      expect(screen.getByRole('button', { name: /Pay/ })).toBeDisabled()
    })
  })
 
  describe('when payment succeeds', () => {
    it('should display a success message and track the event', async () => {
      vi.spyOn(stripeModule, 'createCharge')
        .mockResolvedValue({ id: 'ch_test_001', status: 'succeeded' })
 
      render(<PaymentForm amount={1500} currency="JPY" />)
      fireEvent.click(screen.getByRole('button', { name: /Pay/ }))
 
      await waitFor(() => {
        expect(screen.getByText(/Payment successful/)).toBeInTheDocument()
      })
 
      expect(analyticsModule.track).toHaveBeenCalledWith('payment_completed', {
        amount: 1500,
        currency: 'JPY',
        chargeId: 'ch_test_001',
      })
    })
  })
 
  describe('when payment fails', () => {
    it('should show a user-friendly error message when card is declined', async () => {
      vi.spyOn(stripeModule, 'createCharge')
        .mockRejectedValue(new Error('Your card was declined'))
 
      render(<PaymentForm amount={1500} currency="JPY" />)
      fireEvent.click(screen.getByRole('button', { name: /Pay/ }))
 
      await waitFor(() => {
        expect(screen.getByRole('alert')).toHaveTextContent(/card was declined/i)
      })
    })
 
    it('should re-enable the submit button after a failed payment', async () => {
      vi.spyOn(stripeModule, 'createCharge')
        .mockRejectedValue(new Error('Network error'))
 
      render(<PaymentForm amount={1500} currency="JPY" />)
      const button = screen.getByRole('button', { name: /Pay/ })
      fireEvent.click(button)
 
      await waitFor(() => {
        expect(button).not.toBeDisabled()
      })
    })
  })
})

This level of test quality—organized by scenario, with realistic assertions and proper isolation—is achievable consistently when you provide clear generation constraints.

CI/CD Quality Gates

GitHub Actions Integration

Here's a complete pipeline that enforces quality standards on every pull request:

# .github/workflows/ai-quality-gate.yml
name: AI Quality Gate
 
on:
  pull_request:
    types: [opened, synchronize]
  push:
    branches: [main]
 
jobs:
  quality-gate:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
      contents: read
 
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
 
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          cache: 'npm'
 
      - name: Install dependencies
        run: npm ci
 
      - name: Run Biome lint (static analysis)
        run: |
          npx biome check --reporter=json . > biome-report.json
          echo "BIOME_ERRORS=$(node -e "console.log(JSON.parse(require('fs').readFileSync('biome-report.json')).diagnostics?.length || 0)")" >> $GITHUB_ENV
 
      - name: Run tests with coverage
        run: |
          npm run test:coverage -- --reporter=json --outputFile=test-report.json
          echo "COVERAGE=$(node -e "console.log(require('./coverage/coverage-summary.json').total.lines.pct)")" >> $GITHUB_ENV
 
      - name: Enforce coverage threshold
        run: |
          if node -e "process.exit(parseFloat('${{ env.COVERAGE }}') < 80 ? 1 : 0)"; then
            echo "✅ Coverage ${{ env.COVERAGE }}% meets the 80% threshold"
          else
            echo "❌ Coverage ${{ env.COVERAGE }}% is below the 80% threshold"
            exit 1
          fi
 
      - name: Post quality summary to PR
        if: github.event_name == 'pull_request'
        uses: actions/github-script@v7
        env:
          BIOME_ERRORS: ${{ env.BIOME_ERRORS }}
          COVERAGE: ${{ env.COVERAGE }}
        with:
          script: |
            const errors = parseInt(process.env.BIOME_ERRORS || '0');
            const coverage = parseFloat(process.env.COVERAGE || '0');
            const passed = errors === 0 && coverage >= 80;
 
            await github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `## 🤖 AI Quality Gate Report
 
| Check | Result | Status |
|-------|--------|--------|
| Biome static analysis | ${errors} warnings | ${errors === 0 ? '✅' : '❌'} |
| Line coverage | ${coverage}% | ${coverage >= 80 ? '✅' : '❌'} |
| **Overall** | | ${passed ? '✅ **Passed**' : '❌ **Needs fixes**'} |
 
${errors > 0 ? `\n> ⚠️ ${errors} linting issues need to be resolved before merge.` : ''}
${coverage < 80 ? `\n> ⚠️ Test coverage is below the 80% threshold. Add tests for uncovered code.` : ''}
`
            });

Pre-Commit Hooks for Local Quality Enforcement

Catching issues locally before they reach CI dramatically reduces feedback loop time:

// package.json additions
{
  "scripts": {
    "test:coverage": "vitest run --coverage",
    "test:changed": "vitest run --changed HEAD",
    "quality:check": "biome check . && npm run test:changed"
  },
  "lint-staged": {
    "*.{ts,tsx}": [
      "biome check --apply",
      "vitest related --run"
    ]
  }
}

# One-time setup
npm install --save-dev husky lint-staged
npx husky init
echo "npx lint-staged" > .husky/pre-commit
chmod +x .husky/pre-commit

With this in place, every commit automatically runs Biome on changed files and executes tests related to those files—catching issues in under 10 seconds rather than waiting for a 5-minute CI run.

Scaling Quality Across Your Team

Building a Shared Prompt Library in Version Control

Managing team prompts in the repository creates a knowledge base that improves over time and onboards new team members automatically:

project/
├── .antigravity/
│   ├── commands/
│   │   ├── review-security.md      # Security-focused review
│   │   ├── review-performance.md   # Performance analysis
│   │   ├── review-accessibility.md # Accessibility audit for UI
│   │   ├── generate-tests.md       # Test suite generation
│   │   ├── refactor-suggest.md     # Refactoring recommendations
│   │   └── explain-architecture.md # Architecture explanation for onboarding
│   ├── quality-rules.json          # Quantitative quality thresholds
│   └── templates/
│       ├── feature.md              # Feature implementation template
│       ├── bugfix.md               # Bug fix template with root cause section
│       ├── migration.md            # Database migration template
│       └── api-endpoint.md         # REST endpoint template
└── AGENTS.md                       # Project-wide AI instructions

Every team member gets these tools automatically when they clone the repository. As you discover better prompts, commit them—the whole team benefits instantly.

Hybrid Human–AI Review Workflow

The most effective quality assurance approach pairs AI and human review in a deliberate division of labor:

AI handles: syntax correctness, security pattern violations, style guide compliance, test coverage, complexity thresholds, and common bug patterns.

Humans handle: business logic correctness, architectural trade-offs, feature requirements alignment, performance implications at scale, and cross-team API compatibility.

Recommended workflow for pull requests:

1. Developer implements the feature using Antigravity, with quality prompts from the start
2. Before opening a PR: run /review-security on auth/payment code, /review-performance on data access code
3. Address all Critical and High severity findings; document accepted Medium/Low findings
4. Open PR — GitHub Actions Quality Gate runs automatically (2–5 minutes)
5. Human reviewer focuses on business logic and architecture, not mechanical issues
6. After merge: quality metrics recorded, trends visible in the weekly dashboard

This division typically reduces human review time by 40–60% while catching more mechanical issues than pure human review.

Measuring and Improving Quality Over Time

Building a Quality Metrics Dashboard

Sustained improvement requires quantitative tracking. Here's a script to collect and persist quality metrics over time:

// scripts/collect-quality-metrics.ts
import { execSync } from 'child_process'
import { existsSync, readFileSync, writeFileSync } from 'fs'
 
interface QualitySnapshot {
  timestamp: string
  git: {
    sha: string
    branch: string
    author: string
  }
  coverage: {
    lines: number
    branches: number
    functions: number
    statements: number
  }
  lint: {
    errors: number
    warnings: number
    autoFixable: number
  }
  tests: {
    total: number
    passing: number
    failing: number
    skipped: number
    duration: number
  }
}
 
function collectMetrics(): QualitySnapshot {
  // Run tests with coverage
  const testOutput = execSync(
    'npx vitest run --coverage --reporter=json',
    { stdio: 'pipe', encoding: 'utf8' }
  )
  const testReport = JSON.parse(testOutput)
  const coverage = JSON.parse(
    readFileSync('./coverage/coverage-summary.json', 'utf8')
  )
 
  // Run Biome analysis
  const biomeOutput = execSync(
    'npx biome check --reporter=json .',
    { stdio: 'pipe', encoding: 'utf8' }
  )
  const biomeReport = JSON.parse(biomeOutput)
 
  // Get git context
  const sha = execSync('git rev-parse HEAD', { encoding: 'utf8' }).trim()
  const branch = execSync('git branch --show-current', { encoding: 'utf8' }).trim()
  const author = execSync('git log -1 --format=%ae', { encoding: 'utf8' }).trim()
 
  const snapshot: QualitySnapshot = {
    timestamp: new Date().toISOString(),
    git: { sha, branch, author },
    coverage: {
      lines: coverage.total.lines.pct,
      branches: coverage.total.branches.pct,
      functions: coverage.total.functions.pct,
      statements: coverage.total.statements.pct,
    },
    lint: {
      errors: biomeReport.diagnostics?.filter((d: any) => d.severity === 'error').length || 0,
      warnings: biomeReport.diagnostics?.filter((d: any) => d.severity === 'warning').length || 0,
      autoFixable: biomeReport.diagnostics?.filter((d: any) => d.tags?.includes('FIXABLE')).length || 0,
    },
    tests: {
      total: testReport.numTotalTests || 0,
      passing: testReport.numPassedTests || 0,
      failing: testReport.numFailedTests || 0,
      skipped: testReport.numSkippedTests || 0,
      duration: testReport.testResults?.reduce((sum: number, r: any) => sum + r.perfStats.runtime, 0) || 0,
    }
  }
 
  // Append to history
  const historyPath = './quality-history.json'
  const history: QualitySnapshot[] = existsSync(historyPath)
    ? JSON.parse(readFileSync(historyPath, 'utf8'))
    : []
 
  history.push(snapshot)
 
  // Keep last 90 days of snapshots
  const cutoff = Date.now() - 90 * 24 * 60 * 60 * 1000
  const pruned = history.filter(s => new Date(s.timestamp).getTime() > cutoff)
 
  writeFileSync(historyPath, JSON.stringify(pruned, null, 2))
  return snapshot
}
 
const snapshot = collectMetrics()
console.log(`📊 Quality Metrics (${snapshot.timestamp})`)
console.log(`  Coverage: ${snapshot.coverage.lines}% lines / ${snapshot.coverage.branches}% branches`)
console.log(`  Tests: ${snapshot.tests.passing}/${snapshot.tests.total} passing (${snapshot.tests.duration}ms)`)
console.log(`  Lint: ${snapshot.lint.errors} errors, ${snapshot.lint.warnings} warnings`)

Run this script in your CI pipeline on the main branch to build a longitudinal quality record.

Common Failure Patterns and How to Avoid Them

Trusting AI output without domain validation. AI can be confidently wrong about domain-specific requirements. After generating any business-critical code, always follow up: "What happens to this code when [specific edge case in your domain] occurs?" The AI often catches its own blind spots when prompted this way.

Quality context living only in the conversation. When you start a new session or reinitialize context, quality standards stored only in the conversation disappear. The fix: persist everything in AGENTS.md and .antigravity/quality-rules.json. These files are loaded automatically every session.

Writing tests after the fact. Retrofitting tests onto finished code is harder than it sounds—the code often wasn't designed for testability. Instead, ask Antigravity to define test cases before implementation: "Before we write the code, what test cases should we write for this feature?" This also doubles as a requirements validation step.

Treating quality tooling as a solo initiative. Optimizing your personal workflow in isolation won't move the team needle. Commit .antigravity/ to your repository, document the AI quality workflow in your onboarding docs, and demo it to your team. The network effects of a shared quality culture compound quickly.

Ignoring the quality metrics trend. Collecting metrics without reviewing them is pointless. Set a weekly 15-minute team ritual to review the quality dashboard, celebrate improvements, and pick one thing to fix next week.

Summary

The real power of Antigravity Editor isn't raw code generation speed—it's the ability to elevate code quality assurance at every stage of your development workflow, from the first keystroke to the production deployment.

The framework we've covered in this guide:

• Quality-first prompt design: build correctness, security, and maintainability criteria into every generation request
• Persistent context: lock your standards into AGENTS.md and configuration files so they apply to every session
• AI review automation: standardize review patterns as Custom Commands your entire team can invoke consistently
• Test generation: generate tests in parallel with implementation, not as an afterthought
• CI/CD quality gates: enforce standards objectively on every PR with automated checks
• Continuous improvement: track quantitative metrics over time to spot regressions and celebrate progress

Together, these layers create a system where high-quality code isn't the exception—it's the baseline expectation that the tooling actively enforces.

Shift your relationship with Antigravity from "write faster" to "maintain quality at speed." That's the foundation of a durable engineering competitive advantage.