Inference Driven
Source of Truth: docs/ARCHITECTURE.md
Status: Canonical repo cleanup aligned to the current VS MCP Bridge and BlogAI narrative as of 2026-05-16. Bracket-style tokens are intentional BlogEngine/GwnWikiExtension tokens.
Inference-Driven Software Design With Copilot: Pros and Cons
Using AI Assistance Without Turning Development Into A Black Box
Copilot is a useful development assistant. It can complete patterns, suggest code, write tests, and keep a developer moving through mechanical work. The risk is not that Copilot is useless. The risk is treating inference as if it were architecture, verification, and judgment all at once.
That distinction is the heart of the BlogAI story. AI-assisted software design works best when generated code is surrounded by source-of-truth documents, observable workflows, approval boundaries, logs, diagrams, and durable evidence. Without those things, a team can move faster while understanding less.
VS MCP Bridge has become a practical case study for that lesson.
What Inference Means In Practice
In software development, inference means the model is producing likely code, explanations, or next steps from the context it can see. That can be powerful, but it is not the same as owning the system model.
The model may know common patterns. It may mirror nearby code. It may produce a convincing implementation. But it does not automatically know which boundaries are non-negotiable, which logs are required for future triage, which security claims would overstate the current system, or which documentation is the source of truth.
That is why inference-driven development needs a workflow around it.
Where Copilot Helps
Copilot works well when the local task is clear and the surrounding code already teaches the pattern.
- It can accelerate repetitive edits, tests, and small refactors.
- It can suggest idiomatic code when the project conventions are visible.
- It can help explore unfamiliar APIs or fill in routine structure.
- It can reduce friction when the developer already knows what should happen.
In that role, Copilot behaves like a fast assistant. It is especially useful when the developer can review the output against a clear contract.
Where Inference Becomes Risky
The same strengths become risky when the task is architectural, security-sensitive, or poorly bounded.
- A generated change may look correct while bypassing the real execution boundary.
- A suggested log line may leak data or pollute MCP stdout.
- A local refactor may erase a correlation id that future troubleshooting depends on.
- A plausible explanation may imply authentication, sandboxing, or secret storage that does not exist.
- A quick fix may solve the symptom while leaving no evidence for the next session.
These are not reasons to avoid AI tools. They are reasons to stop treating prompt-to-code as the whole workflow.
Prompt-To-Code Is Not Enough
The early mistake in many AI-assisted workflows is assuming that the prompt ends when code appears. In practice, the better workflow is prompt-to-evidence.
A useful AI-generated change should be answerable:
- What boundary did it touch?
- Which source-of-truth document says this behavior is correct?
- Which tests or validation steps prove it?
- Which logs or artifacts would explain it later?
- Which Mermaid diagram reflects the observed flow?
- What should a future AI session read before extending it?
That is the difference between code generation and engineering discipline.
How VS MCP Bridge Changed The Workflow
The VS MCP Bridge cleanup made this concrete. The project did not become clearer just because an AI generated code. It became clearer because logs, diagrams, handoffs, and architecture documents exposed where the system was vague.
Sequence diagrams helped reveal transport boundaries. Trace logs made request and operation correlation visible. Durable artifacts showed whether execution really flowed through the expected catalog and executor path. Approval and security traces forced a clearer distinction between current plumbing and future hardening.
That evidence led to better architecture:
- the MCP stdio boundary stayed clean
- the VSIX stayed isolated behind the named-pipe boundary
- compiled tools gained descriptors, requests, results, catalogs, and executor-owned logging
- MEF became a discovery seam instead of an execution shortcut
- approval-aware execution became part of the tool boundary
- security seams stayed explicit without claiming production authentication or sandboxing
- audit and redaction became part of reconstructable tool execution
In other words, the AI assistance was useful because the project kept forcing it back through observable architecture.
Human Review Still Owns The Design
Copilot can propose. Codex can implement. ChatGPT can explain tradeoffs. None of those tools should silently own the design.
Human review still decides whether a change matches the architecture, whether the risk is acceptable, whether the evidence is enough, and whether the documentation tells the truth. The stronger the tool, the more important that review becomes.
This is especially true for security and approval workflows. A model can generate a policy class or approval hook, but the project still needs to say what is intentionally deferred: OAuth, user identity, real secret storage, sandboxing, signed plugin manifests, tamper-evident audit stores, and SIEM export are not complete just because a seam exists.
Source Of Truth Beats Chat Memory
One of the strongest lessons from this project is that durable source files beat chat memory.
The current workflow asks future sessions to start from files such as:
Those files make the system teachable. They also reduce the chance that an AI session resumes from an outdated mental model.
Where BlogAI Fits
BlogAI can help turn this architecture work into learning material, but only if the blog stays aligned with the code.
That is why the current blog cleanup starts from preserved database exports, canonical repo sources, manifest metadata, and explicit token/link rules. Blog posts should not drift away from the system they are explaining. They should point readers back to the current architecture, trace workflows, Mermaid sources, and handoffs that support the claims.
Done well, BlogAI becomes more than a publishing surface. It becomes a way to keep project knowledge synchronized with code, validation artifacts, and operational lessons.
Related Mermaid Trace Sources
The following diagram sources directly support the story:
Those .mmd files remain the diagram source of truth. The post references them directly instead of embedding generated images.
Practical Pros And Cons
| Practice |
Strength |
Risk |
| Copilot as coding assistant |
Fast local implementation help |
Can produce plausible but wrong code if review is weak |
| Codex-style implementation sessions |
Can inspect, edit, validate, and commit cohesive slices |
Needs repository source-of-truth and validation constraints to stay grounded |
| Architecture chat and review |
Good for explaining tradeoffs and surfacing assumptions |
Can become speculative if not tied back to code and artifacts |
| Durable traces and handoffs |
Make AI-assisted work reconstructable |
Require discipline to keep current |
Takeaway
Inference-driven development is useful when it is not treated as autonomous development.
The stronger pattern is human-directed, evidence-backed AI assistance: use Copilot for local acceleration, use Codex or chat tools for broader implementation and reasoning, require source-of-truth documentation, preserve trace evidence, and keep approvals, logs, and boundaries visible.
That is what VS MCP Bridge is trying to teach. The goal is not just prompt-to-code. The goal is prompt-to-evidence, with code as one result of a workflow that remains understandable after the session ends.
See Chat Sessions Models And Agents for related background on chat sessions, models, and agents.