Epic Games vibe-coded a new launcher: 7 lessons for production

What Epic actually reported

On October 14, Epic Games opened the Preview of the new launcher for Windows, macOS, and for the first time, Linux. In the official announcement, the company explicitly called it "vibe coded," but simultaneously warned that the first version still has few features. For developers of live projects and competitive gamers, Epic advises staying on the stable client for now.

Epic Games Store head Martin Käli explained it more practically to journalists: the team started from scratch on a different tech stack and used AI to write and verify new features. People defined the required behavior, managed changes, and ported functionality rather than old code. It is no longer "one prompt made the product," but a managed process with human decision-making at every important step.

What the announcement does not prove

• There is no open data on the share of AI code. The phrase "vibe coded" does not measure how many lines were generated, rewritten, or discarded.
• There is no complete benchmarking methodology. Individual startup figures are known, but not all configurations, caches, regions, and scenarios.
• Preview does not equal production maturity. Some social and account features are still missing, and Linux compatibility depends on the distribution and the game.
• Rewriting is not always beneficial. Epic had a specific pain point with the old client, a team, and resources for a parallel transition. For a small project, it is often cheaper to fix a bottleneck.

7 lessons for your own AI project

1. Start with a pain metric. Epic optimized startup, navigation, and background load. Record one metric before generating code: time to first action, number of errors, or user steps.
2. Copy behavior, not old code. Describe the scenarios that must be preserved, and rebuild the implementation only where justified.
3. Separate generation and review. Don't ask the same session to "check itself." Give a different model or a human the requirements, diff, and tests without justifying context.
4. Release a parallel Preview. The new version should have a limited audience, easy rollback, and an honest list of missing features.
5. Measure on a real scenario. Cold start, background recovery, weak network, and large datasets are different tests. One beautiful metric can easily hide a regression in another.
6. Do not give AI secrets and production access by default. Code generation does not require real tokens, payment data, or the ability to deploy changes independently.
7. A human signs off on risky changes. Accounts, payments, updates, data deletion, and security mechanisms require an explicit approval gate and a decision log.

A minimal process from prompt to release

For a small site or internal tool, this might take one day, but the order remains the same. First the criteria, then a small change, a separate review, a test, and only then publication.

Prompt for an independent production review

Copy and completeYou are an independent reviewer. Do not rewrite the code immediately. Product context: [who it is for and the main action] Change: [exactly what was added] Success criteria: [measurable condition] Must not change: [critical invariants] 1. Find discrepancies with requirements. 2. Identify risks for data, access, payments, and rollbacks. 3. Suggest minimal tests: normal, empty, error, and edge-case scenarios. 4. Separate release blockers from desired improvements. 5. For each finding, provide a specific file, function, or check. Do not assume the previous AI agent was correct. Do not use real secrets.

After the review, fix only confirmed issues. If the reviewer suggests a large refactor unrelated to the release criteria, move it to a separate task.

Checklist before publishing AI code

• There is one measurable "before" and "after" metric.
• A list of functions that the new version does not yet support is maintained.
• The diff is small enough for a human to review.
• Secrets, personal, and payment data were not passed to the model.
• Positive, negative, and edge-case scenarios have been passed.
• Speed has been verified on the target device, not just in the dev environment.
• There is a Preview, an error log, and a way to quickly revert to a stable version.
• Risky changes were approved by a responsible person.

If you need a broader team review process, continue with the guide on how to review code from AI agents. For the first project — a vibe coder's path from task to test.

One practical AI scenario per week: view the email example and subscribe with address confirmation.