The AI-Native Gap
In engineering conversations, teams frequently conflate 'using AI to write code' with 'shipping AI-powered software.' This confusion leads organizations to apply lightweight developer productivity policies to critical customer-facing AI safety risks, or conversely, burden deterministic coding tasks with heavy AI compliance frameworks. This topic establishes a clean two-way taxonomy: 'Building WITH AI' governs how engineers use coding assistants, while 'Building FOR AI' governs the validation, monitoring, and compliance of non-deterministic product features.
Architectural Orientation: Conflating Tooling with Product Safety
When organizations begin their AI transition, confusion often arises around what requires new quality governance. An engineer using Claude Code to refactor an SQL query is performing an activity fundamentally different from an AI agent generating clinical trial summaries for doctors.
Conflating these two dimensions leads to two critical operational pitfalls:
Pitfall 1: Under-Governing Products
Applying a generic "Copilot Policy" to a customer-facing chatbot, ignoring hallucination budgets, citation grounding, and post-market drift monitoring.
Pitfall 2: Over-Burdening Developers
Forcing statistical eval harnesses and EU AI Act technical dossiers onto engineers writing deterministic CRUD endpoints simply because they used an AI IDE.
“If you're asking whether your team can use Tool X, that's Building WITH AI.
If you're asking whether your users can trust Feature Y, that's Building FOR AI.”
Use this rule in sprint planning to immediately route feature requirements to developer tooling guidelines or probabilistic product governance.
Dimension 1: Building WITH AI (Developer Workflow)
Building WITH AI encompasses copilots, coding assistants (e.g., Claude Code, Cursor, aider, GitHub Copilot), and spec-driven agent workflows. Here, AI acts as an accelerator for the software engineer.
While the method of code creation changes, the resulting artifact may be completely deterministic. A microservice written by an AI coding assistant that executes SQL queries still requires standard unit tests, linting, and CI/CD pipelines. The primary governance concerns are developer productivity, peer code review rigor, secret leakage prevention, and open-source license provenance (ISO 27001 A.8.25).
Dimension 2: Building FOR AI (Product Capabilities)
Building FOR AI refers to shipping software where artificial intelligence is part of the runtime execution path for end users—such as Retrieval-Augmented Generation (RAG) search, autonomous workflow agents, generative summarization, or recommendation engines.
Because these capabilities produce non-deterministic outputs sampled from probability distributions, they introduce unique engineering demands that do not exist in traditional software:
- Knowledge Transformation: Converting raw enterprise documents into structured Markdown/HTML trust layers with cryptographic chunk provenance.
- Context Engineering: Managing prompt token budgets, hybrid retrieval indexing, and dynamic context injection middleware.
- Statistical Evaluation: Measuring hallucination rates, citation grounding, and toxicity across test populations rather than single binary asserts.
- Continuous Post-Market Monitoring: Tracking production drift, user feedback, and semantic shifts over time as mandated by EU AI Act Article 61 and ISO 42001 Clause 9.1.
Worked Practice Scenarios
Billing API Refactor
A developer uses Claude Code to modernize an existing PostgreSQL billing service into TypeScript.
Governance: Code review, SAST, license check. Standard unit tests apply.
Clinical Trial RAG Chatbot
A product team builds a customer-facing assistant that matches oncology patients to medical trial protocols.
Governance: Hallucination budgets, citation grounding, continuous drift telemetry.
Autonomous Claims Agent
Engineers use AI IDEs to construct an autonomous insurance agent loop with step budgets and human escalation gates.
Governance: Code provenance for synthesis + 6-stage lifecycle for agent execution.
Where to Go Next: Downstream Topics Routing
| Topic in Core Concepts | Applies to Building WITH AI? | Applies to Building FOR AI? | Primary Takeaway |
|---|---|---|---|
| Topic 4: The Probabilistic Lifecycle | Optional context | Mandatory (All 6 Stages) | Phase gates from problem framing to post-market monitoring. |
| Topic 5: Evidence Requirements | Not applicable | Mandatory | Telemetry streams, distribution curves, and error classifications. |
| Topic 6: Regulation Mapping | License checks only | Mandatory | EU AI Act Annex IV, NIST AI RMF, and ISO 42001 alignment. |
| Topic 7: Artifact Generation | Prompt templates | Mandatory | Data sheets, prompt manifests, and golden evaluation suites. |
| Topic 8: QMS Integration | Standard SOP update | Mandatory | Integrating probabilistic evidence into ISO 13485 / 9001 QMS. |
Use this prompt in your AI assistant during product discovery to categorize workstreams and assign appropriate governance controls.
Topic 4: The NUP Lifecycle for Probabilistic Software
Community Discussion & Feedback
Attributed peer feedback and official Netspective architecture notes.