Series · AI Breaks Developer Boundaries
Episode 2 · AI Breaks Developer Boundaries 2 - Open Code and Interfaces
This is the second of a three-part series on the boundaries among web, game, and embedded development, and on how AI tools are reshaping them. The first article identified the boundaries; this one asks what AI can read when it crosses them and what it cannot. Public-code ecosystems are a vastly friendlier landscape for AI. When code, change history, and usage context are closed—or survive only inside UI gestures—the observable surface becomes smaller.
This matters for more than the claim that an AI has “seen lots of code.” Development is the process in which requirements become code, configuration, assets, tests, and incident records. The public collaboration culture represented by Git and GitHub preserves those traces as source, commits, issues, pull requests, reviews, and licenses. Java itself is not synonymous with open source, but an openly developed implementation and ecosystem such as OpenJDK gains the same advantages.
There are unambiguous public examples of code-model training on public-source data. BigCode's The Stack is a 6.4 TB dataset of permissively licensed source code across 358 languages, published for GitHub-based code-model research and training. BigCode also states that StarCoder-family models were trained on GitHub data. That does not prove that every commercial model trained on every GitHub repository. Some providers, including OpenAI, disclose broad data categories rather than repository-level lists. The uncertainty about a particular proprietary model does not erase the structural advantage of public code culture for AI.
Public code still matters enormously. Code is an executable example; documentation explains names; issues retain failure conditions; pull requests and reviews record why a design changed. Together they are development knowledge infrastructure. AI works best not as isolated recall but when connected to search, repositories, tests, linters, shells, and documentation.
Public code is verifiable context before it is training material
Large language models generate code by learning patterns from large-scale text and code. The advantage of public code is not only volume: multiple implementations, failed issues, corrective diffs, tests, and documentation form a foundation for checking a generated answer. A useful answer still requires more than generation: reproduce the issue, locate the API contract, inspect dependencies, pass tests, and review license and security impact.
git status --short
rg -n "timeout|retry|ConnectionError" src test
npm test -- --runInBandThese commands do not solve a failure. They join change state, relevant code, and the current test result. When an AI can also read a README, issue history, CI output, and type definitions, it can form a narrower hypothesis than “there should probably be a function for this.” That is why a GitHub Code Quality workflow that retains evidence in a PR matters.
GitHub's Copilot code-referencing documentation explains a feature that compares proposed-code context with a public-repository index to surface references. That is provenance assistance, not disclosure of a model training corpus. The developer's role is not to paste output unquestioned; it is to verify the contract, license, and test evidence behind the change.
Public does not mean unrestricted training permission. Licenses, copyright, secrets, security vulnerabilities, and low-quality AI-generated code flowing back into repositories are real costs of a public ecosystem. An AI-friendly environment is not the same thing as data that can be used without legal or ethical review.
Code-native products are easier for an AI to observe
This is why UI-based platforms belong in the argument. AI most easily reads traces left in source repositories and tool logs. In Unity or Unreal, a person may create objects in an editor, bind Prefabs, and connect assets and events through UI. Some development context can then sit outside the code. This does not make UI inferior, nor does it mean AI can never learn editor work. It means that when a model learns from, or reads, code, documents, and diffs, information retained only as UI operations and visual judgment is more likely to be missing.
The standard in this article is therefore how much of the development process is open to people and tools. Scene data, asset references, automation APIs, build logs, and screenshot comparison can make an editor-based platform richer in AI-readable context. Conversely, if the crucial decisions live only in a closed binary, an internal-only tool, or an irreproducible sequence of clicks, the boundary is expensive for a new human developer as well as for AI.
HTML, CSS, and JavaScript illustrate the advantage. Structure, layout rules, and state transitions are textual, so much intent can be inferred before rendering a screen. Earlier code-driven UI systems such as Swing and JavaFX had the same property. But textual representation does not guarantee a beautiful or accessible result: browsers, screen sizes, keyboard navigation, and contrast still need to be run and checked.
export function SaveButton({ pending, onSave }: {
pending: boolean; onSave(): Promise<void>;
}) {
return <button disabled={pending} onClick={() => void onSave()}>
{pending ? 'Saving…' : 'Save'}
</button>;
}
It is also too quick to call editor-centric engines an AI-proof zone. The more an environment provides asset data, tool APIs, build logs, screenshot comparisons, and execution traces alongside source, the more observable the work becomes. That does not predict every platform will become code-only. It does suggest that platform competition will increasingly include a way to transfer the whole development context to AI by connecting code, declarative data, UI state, and tool calls.
AOSP and MCP represent two different kinds of openness
AOSP's architecture overview describes Android Open Source Project as publicly available, modifiable Android source and lays out framework, HAL, native-library, and kernel layers. It gives both people and AI a broad starting point for understanding OS structure, platform APIs, builds, and tests.
It is not a complete blueprint for every phone. Vendor images, SoC, graphics and radio drivers, OEM extensions, and carrier constraints vary and may not be public or portable. The VNDK overview notes that vendors may extend libraries for function or performance. A broad public base does not replace device-specific validation.
Model Context Protocol, or MCP, is a different kind of openness: an open standard for connecting an AI application to files, databases, search, and workflows. It is not a way to make a model remember everything; it gives a model explicit, inspectable paths to the required data and tools.
{
"server": "project-docs",
"capabilities": ["read_repository", "search_docs"],
"policy": "read-only"
}This is an illustrative contract, not a universal MCP configuration. MCP's essential contribution is connectivity between legacy systems and AI. When an old server's APIs, data model, operating commands, and permission boundary are exposed as tools, an AI can not only call a function but also better read what it does and in which context it is risky. MCP is not a device for covert data collection; it is a limited contract through which a provider offers function and context, lowering the discovery barrier.
Least privilege remains the central rule. A tool that reads files must not be treated like a tool that deploys. MCP's security best practices keep server selection, consent, authentication, and access control with the operator. Providers still have a clear incentive to offer MCP: the service context once supplied to people through a web screen and manual can be supplied to AI through searchable tools, schemas, and guidance, making that service selectable inside an AI workflow.
A CLI agent shows a direction, not a license
Google's Gemini CLI is an open-source terminal agent that presents file work, shell commands, web fetching, and MCP support. API plus MCP is a window through which AI can understand a legacy server's functions and context; CLI plus MCP can become the equivalent window for desktop programs, local files, and command-line environments. That is evidence that a development experience connecting models to files, commands, search, and tool calls is becoming a real product category. Gemini Managed Agents and remote MCP follow the same direction.
How to assess Microsoft's historical closedness
The author views Microsoft's historic platform strategy as having imposed a substantial interoperability cost on computing. That does not deny the productivity and tooling value created by Office and Windows. The history in which Internet Explorer and Windows-centric technologies bound web developers to one platform should not disappear either. The U.S. Department of Justice's court findings in United States v. Microsoft record Microsoft's efforts to induce ISVs to depend on Windows-specific browsing technologies and to deter reliance on APIs exposed by a competing browser.
It would be inaccurate to reduce that critique to “MSDN was private.” MSDN and today's Microsoft Learn were publicly readable, but they are naturally vendor documentation centered on Microsoft's APIs, tools, and deployment paths. That is different in character from a public knowledge infrastructure of reusable source, discussion, and change history that outsiders can independently implement and verify. Microsoft's later relationship with Linux and open source also changed materially; “Microsoft Loves Linux” appears in a 2016 Ignite session and current WSL documentation.
The AI-era test is simpler. The more that old proprietary APIs, closed formats, vendor-only tools, and license constraints dominate, the less public context is available for training, retrieval, reproduction, and independent verification. Proprietary platforms are not worthless—security, privacy, quality control, and customer-data protection require some context to stay closed. The failure is when necessary closure also removes standards, documentation, and tool contracts that would let users connect to other platforms.
“AI is definitely worse at C, C++, and C#” needs a benchmark
The hypothesis can arise from real engineering experience, but the currently public evidence does not support a categorical claim that AI writes C, C++, or C# definitively worse than Java, Node.js, JavaScript, or Python. HumanEval-X includes C++, Java, JavaScript, and Go, while MultiPL-E translates code-generation benchmarks into 18 languages. The need for such tools reflects the fact that language-level results vary by model, version, prompt, library, and task.
A stronger claim is that AI may fail more often on work such as Windows-specific C++, COM, drivers, or older C# frameworks when public examples and current test environments are scarce and vendor or version coupling is high. Turning that into a fact requires matched, task-relevant measurement.
# Keep generation, build, and tests separate for the same requirements.
for lang in python javascript java cpp csharp; do
./run-task-suite --language "$lang" --tasks ./tasks --samples 20
done| Measure | Question to ask |
|---|---|
| Build success | Does the output compile in the target toolchain? |
| Test pass rate | Does it meet the same functional contract? |
| Repair count | How many human corrections are needed? |
| Dependency error | Does it assume an obsolete package, SDK, or OS feature? |
| Security and performance | Does it pass separate memory, authority, and bottleneck checks? |
Tool connection makes automation more powerful; it does not remove approval and testing. Gemini CLI's tool documentation describes approvals and sandboxing options for file changes and shell commands.
Public code and MCP are not a bypass for permission, security, or quality. License review, secrets, data access, deployment approval, and real tests are contracts to verify before trusting AI output.
AI's apparent capacity is therefore a result of observability, not magic. The more code, documentation, examples, tests, issues, and tool APIs connect, the faster a first map of an unfamiliar field can be drawn. The last article follows that map into operating systems and physical devices.
No comments:
Post a Comment