A dispute involving an unfinished game-development milestone has become a sharp illustration of the practical and legal hazards surrounding generative AI in professional production. Haley MacLean, an intellectual-property lawyer and head of video game practice at Voyer Law, described an anonymized case in which a programming contractor submitted work that was broken, filled with issues, and ultimately unusable.
The immediate problem was not simply that AI had been involved. In MacLean's account, the contractor was unable to explain or repair what had been delivered after the client asked for revisions prior to accepting the milestone. The contractor then sought full payment despite being unable to make the requested fixes. The result, MacLean said, was that the work would not be paid for and the client had lost time.
More seriously, MacLean said the contractor had entered confidential game information into an AI tool in order to produce the milestone. That allegedly created a separate confidentiality breach on top of the quality and contract dispute. The incident is a reminder that generative AI questions in games are not limited to public debates about art, writing, or whether a finished title carries an AI disclosure. They can also affect ordinary production relationships, ownership, security, delivery standards, and the ability to maintain a project over time.
A milestone that could not be maintained
Game development is built around deliverables. A contractor might be hired to produce a system, integrate a feature, build tools, fix a set of bugs, or complete another defined piece of a project. A milestone is generally not valuable merely because files have been handed over. The work needs to meet agreed requirements, function in the target project, and be capable of review and revision.
For useful background on this topic, read Fangtopia-launches-with-cozy-hex-tile-kingdom-building-on-pc-ps5-and-switch-2/">Fangtopia Launches With Cozy Hex-Tile Kingdom Building on PC, PS5 and Switch 2.
That last point sits at the center of MacLean's example. If software arrives with errors, a client normally has reason to request changes before accepting it. A contractor who understands the code should be able to identify how it works, diagnose failures, and make revisions. When the person responsible cannot do that, the client is left with a potentially fragile system that may be harder for the internal team or a replacement contractor to salvage.
MacLean's comparison was deliberately simple: being able to order food does not make someone a chef. Applied to game code, the point is that receiving output from an AI system is not the same as possessing the technical knowledge required to design, validate, debug, and support that output. Prompting may produce material quickly, but production work still has to survive implementation, testing, integration, maintenance, and the scrutiny of the people paying for it.
That distinction matters especially in games, where a seemingly isolated component can interact with performance targets, platform requirements, networking, accessibility, game balance, save data, security, and countless other systems. Code that appears plausible at a glance may still be unsuitable for a real project. If it cannot be understood by its author, the risks grow when the game changes direction or a bug appears late in development.
Confidentiality is a separate concern
The account also points to a problem that can be more urgent than the quality of the delivered code: what happens to private project material when it is supplied to an external AI service. Game projects regularly involve confidential information long before a public announcement. That can include internal design documents, proprietary tools, unreleased characters, story details, technical architecture, business plans, licensed material, platform discussions, and information covered by non-disclosure agreements.
MacLean said the confidential game information was placed into the AI tool to generate the milestone. The precise terms of the relevant contract and the particular AI service were not disclosed, so the full legal context is not public. Still, the basic concern is clear. Contractors often have obligations governing how client material may be used, stored, shared, or disclosed. Feeding that information into a third-party system may conflict with those obligations depending on the agreement and the service's terms.
For developers and publishers, the issue is not answered merely by asking whether AI output looks useful. Teams also need to know what data an employee or contractor has submitted, whether the service retains or processes that data, who can access it, and whether the use fits the project's confidentiality and security commitments. A tool can be technically capable while still being contractually inappropriate for a particular assignment.
That concern extends beyond programming. Marketing plans, quality-assurance material, localization documents, porting work, and internal production notes can all contain sensitive information. In a business built on surprise announcements and intellectual property, a casual upload of private material can have consequences long before a finished game reaches players.
Why anti-AI language is becoming standard contract material
MacLean has said she is seeing generative-AI provisions become increasingly common in game contracts. In her view, they are now routine enough that the absence of such language may stand out, particularly where a publisher is also responsible for creating assets or handling other parts of development and release.
These clauses can serve several purposes. They may prohibit certain generative AI uses outright, require approval before such tools are used, limit which systems can be used, or establish disclosure obligations. They can also address ownership, indemnity, data handling, warranties, and responsibility for correcting defective work. The exact language will vary by deal, role, jurisdiction, and project, but the objective is often the same: establish clear rules before a dispute arises.
For a contractor, explicit terms can also remove ambiguity. If AI assistance is permitted under defined conditions, the contractor knows what documentation, review, or security practices are expected. If it is not permitted, there is less room to argue after the fact that an output-generation tool was simply another part of the workflow. Transparency is likely to be more important than ever when work is being delivered by distributed teams using fast-changing tools.
MacLean has previously framed generative AI as a potential copyright, reputation, and rights-ownership issue for game development. The dispute she described adds a more immediate operational lesson. Regardless of a team's broader ethical or creative position on AI, a client still needs a deliverable that works, can be maintained, and was created without mishandling protected information.
Debate over AI and "vibe coding" continues
The situation arrives during a broader argument over AI-assisted development, often captured by the increasingly common phrase "vibe coding." The term has been used to describe work created primarily through AI prompts by people who may not understand the underlying programming language or systems. Its meaning remains loose, and AI tools can be used in many different ways by experienced developers. But the criticism in this case is aimed at uncritical reliance: producing code without being able to assess or repair it.
That tension has been visible across games and adjacent technical communities. The people behind the PlayStation 3 emulator RPCS3 have publicly pushed back against AI-reliant coding practices, urging users to learn debugging and programming rather than leave behind unusable material. Concerns about low-quality AI content have also become frequent in discussions around PC storefronts and open-source projects, including ports and recompositions.
Not every prominent industry figure sees the technology the same way. Epic Games chief executive Tim Sweeney has remained a strong proponent of AI. Epic briefly made generative AI a requirement for a new Unreal Engine game jam, and the company also said it had used "vibe coding" for the new Epic Games Store launcher. Those examples show why the conversation cannot be reduced to a simple division between adoption and rejection: companies are experimenting with AI in different areas, with different levels of human oversight.
Valve co-founder Gabe Newell offered another perspective in 2025, suggesting AI could create a curious scenario in which less experienced programmers who are especially capable with AI tooling may become more effective in terms of value creation. That prediction recognizes the possibility that new interfaces can change who can produce useful software. It does not erase the demands of a commercial game contract, however. Value creation in a client relationship includes accountability for the work, not only the ability to generate a first draft.
Human responsibility remains the deliverable
The most important takeaway from MacLean's account is not that every use of AI necessarily leads to failed software. It is that a professional cannot hand off responsibility to a tool. A development partner is hired for judgment as well as output: the ability to understand requirements, protect confidential materials, verify quality, communicate limitations, and fix problems when they appear.
As AI systems become more integrated into game-development workflows, teams may need policies that are more specific than a broad yes-or-no stance. They may need to define approved tools, establish whether confidential data may ever be entered into them, require review of AI-assisted code, document how generated material was used, and ensure that someone on the project can maintain every shipped system.
For studios, publishers, and contractors alike, the lesson is straightforward. Fast output is not the same thing as completed work. If a milestone cannot be debugged, revised, or safely traced back to an accountable developer, it may create more cost than it saves. In the case described by MacLean, that cost was measured in a rejected payment request, a failed delivery, and time the client could not get back.
Community
Discussion
Start the conversation.
No comments have been posted yet.