Kimi K3 Handles a Full-Stack WeChat Mini Program, Breaks Production, and Fixes Itself
Hello everyone, I'm Meng Jian.
Kimi K3 has been officially released. Now that the results are out, I can finally say this publicly: before the release, I had already handed over the entire real-world project of the ShipSolo WeChat Mini Program to it. It went through the full process from requirement sorting to deployment verification and ultimately delivered a complete product.
The experience of delivery has already touched the level of GPT-5.5 and Claude Opus 4.8. After running through this, my most direct feeling is: domestic models have truly reached this tier.
The process wasn't entirely smooth: it caused a production-affecting error during the Windows local packaging phase. Fortunately, it tested itself, rolled back, and found another way to fix it without waiting for me to rescue it. I will write about this section openly, without letting it overshadow the results.
Beyond the experience, Moonshot AI has also officially released a K3 Coding benchmark. All models in the chart are set to max or xhigh thinking effort.
On DeepSWE, K3 scored 67.5, slightly higher than GPT-5.5's 67.0, significantly higher than Opus 4.8's 59.0, and a notch below Fable 5's 70.0 and GPT-5.6 Sol's 73.0. On Terminal Bench 2.1, K3 scored 88.3, only 0.5 points lower than GPT-5.6 Sol's 88.8, and higher than Opus 4.8, Fable 5's 84.6, and GPT-5.5's 83.4.
On Program Bench, K3 scored 77.8, ranking first among the models listed in the chart. GPT-5.6 Sol scored 77.6, and Fable 5 scored 76.8. On FrontierSWE, K3 scored 81.2, second only to Fable 5's 86.6, and higher than GPT-5.6 Sol's 71.3, Opus 4.8's 66.7, and GPT-5.5's 64.9.
This chart is worth pausing over. In the past, when looking at domestic models, I would first ask if they were good enough. This time, I started asking which projects could be handed over to them first.
Looking solely at Coding, K3 has stably entered the first tier. The benchmark provides the position, and the ShipSolo real-world test answers whether this capability can land in a real project.
This article lays out the entire process openly: what judgments it made correctly, where it went wrong, and how I used it.
01 This project is much more complex than it looks
ShipSolo is a product I operate. The official website already has 24 free articles, a member handbook, and a complete set of site-building Skills. Adding a WeChat Mini Program to it this time sounds simple, but what it actually took over was an entire system already in operation.
The existing system includes backend data based on D1, a Google OAuth account system, a Mini Program repo that was only half-written with leftover historical issues, and a deployment chain involving Nginx + SSL servers and Cloudflare Worker + OpenNext. There are two domain names: shipsolo.io for overseas users, and shipsolo.cn which has already completed ICP filing. The legal domain for WeChat Mini Program requests must use the filed domain; the .io path is a dead end, so it had to rely on .cn.
My first round of requirements for K3 had five points: the Mini Program should reuse existing data from shipsolo.io as much as possible; Google login users need to be linked with WeChat identities; articles should be easy to forward and read in WeChat groups and Moments; the Mini Program is positioned for customer acquisition and traffic引流; when encountering unclear areas or insufficient information, proactively ask me instead of guessing blindly.
Generating a static site from a blank page is something current models can basically handle. Taking over a system with historical baggage, where data and accounts are running online, tests a completely different capability: whether it can first understand the structure before taking action.
02 It didn't rush to write code; it first figured out the problems
After receiving the requirements, K3 didn't start working immediately.
It first read through the README, NEXT_STEPS, miniapp directory, backend code, and D1 schema thoroughly. It also crawled the online pages of shipsolo.io, cloned the website source code using the local GitHub CLI, and got a clear picture of the existing API structure, authentication methods, and content organization.
The output of this round of research was very specific, directly identifying 4 launch blockers: missing tabBar icons causing compilation failure, empty content for the copy WeChat ID function, a bug in the search interface route, and share buttons that didn't respond when clicked. These problems were all hidden in the existing repo and were uncovered in one round of research. If these four problems weren't solved, the Mini Program wouldn't even qualify for submission for review.
It also identified the hard constraint that the Mini Program's legal domain must be ICP-filed, proposing to use api.shipsolo.cn as a bridge layer. For the backend data solution, it offered three options: reverse proxy with a single D1 database, MySQL bidirectional synchronization, and direct Cloudflare connection. It listed the maintenance costs and data consistency risks for each, ultimately recommending the single-database reverse proxy, citing the ability to avoid dual writes and data drift.
The account linking solution was also designed bidirectionally: Google users scan a QR code to bind their account to a WeChat openid; conversely, a placeholder account is first created on the Mini Program side using the openid, and when the user later logs in with Google, it automatically merges into the email account without losing historical data.
After presenting the plans, it stopped and waited for my decision, not making the choice for me. I chose reverse proxy + single D1 database, QR code binding, and a pure引流 version as V1.
After reviewing this round of research, my internal judgment was very direct: first understand the system, then lay out the options clearly, and finally wait for my decision—it didn't get this order wrong. It has the patience to understand the system.
03 Two coder agents worked in parallel, pushing forward across the stack
After the decisions were made, K3 launched two coder agents: one responsible for the Mini Program interfaces on the io Worker side, and the other specifically handling the Mini Program's blocking issues and data source integration.
This split was made along dependency boundaries: the Worker interfaces didn't depend on the Mini Program side code, so both sides could truly work simultaneously, not just claiming parallelism while actually waiting for each other.
The scope of advancement covered the Worker's schema and interfaces, sharing functionality, login flow, live streaming page, Nginx/SSL configuration, Cloudflare deployment, and that set of account merging logic. Midway, it wanted to read a sync script but found the file didn't exist at all. After confirming the situation clearly, it switched paths and continued pushing forward, not getting stuck spinning its wheels on a single error.
The four layers—Worker, D1, Mini Program, and Nginx—moved forward simultaneously. Individual file or tool failures didn't cause it to stall; but whenever it hit a node requiring product decisions and production authorization, it would proactively stop and ask me.
04 It broke production, then rescued itself
The incident happened like this: K3 built the OpenNext Worker locally on Windows and deployed it directly. After deployment, it proactively ran a round of smoke testing and found that all dynamic routes across the site were returning 500 errors.
It immediately executed a rollback. After confirming that the online service was restored, it then went to investigate the root cause.
The problem occurred during the build phase: file paths generated on Windows systems contain backslashes, while the build plugin filtered paths using forward slashes. The two sides didn't match, ultimately generating an empty route lookup logic, and all dynamic route handlers were lost. A public GitHub issue can be found online, documenting exactly this same type of OpenNext path problem in Windows environments, with matching symptoms and root cause. This shows that the attribution wasn't something it fabricated out of thin air, but it also can't be said that it was the first to discover this problem, nor can it be confirmed whether the issue has been officially fixed.
After figuring it out, it explained the cause and proposed switching to triggering Linux CI builds and deployments via push main. Moreover, before actually executing the push, it first came to me for approval.
After approval, Linux CI completed the build and deployment. It then ran another round of interface regression testing, and the ShipSolo Mini Program in the WeChat Developer Tools ran normally. At this point, the entire delivery was truly complete.
Let me be clear upfront: making a mistake is making a mistake; this is a real demerit. The compatibility issue between Windows and OpenNext isn't unknown. It failed to identify this pitfall before deployment. The reason this didn't cause lasting impact was the smoke test gate. No matter how well the subsequent handling was done, the earlier mistake isn't canceled out by it.
But the other side must also be said: discovering the problem, stopping the loss in time, rolling back, identifying the root cause, and trying a different path to redo—this entire set is itself engineering capability. It didn't stubbornly push forward with the 500 errors, didn't pretend nothing was wrong and continue, and didn't decide on its own to press push main. The window of time where production was running sick was kept very short by it. The length of this window directly determines the cost of a mistake.
What this incident truly changed was my way of trusting it: one success showed me it had capability; making a mistake and then being able to self-test, roll back, find the cause, and re-request authorization is what gave me the confidence to let it continue touching real projects.
The Agent in demos can succeed in one go often because the chosen path inherently has few surprises. Real projects face unfamiliar environment combinations and a pile of historical baggage. Whether it can discover and contain errors on its own when they occur is closer to the real problem faced in actual delivery than a single successful generation.
05 Why I say the experience reached GPT-5.5 and Opus 4.8
Let me clarify first: this is based on my real experience with this one project; I didn't run independent benchmarks. The basis is broken down into four points.
Understanding existing systems. Two repos with history, a mixed authentication system, and domain constraints brought by ICP filing—after reading through them, the architectural judgments it gave were solid, and it didn't recklessly alter already-running logic. This type of project tests whether it can accurately establish context, and it did.
Long-task continuity. From requirement sorting all the way to deployment verification, the task spanned at least four technical layers. There was no disconnection in the middle requiring me to repeatedly re-explain the background; the direction never went off track.
Tool and Agent collaboration. Using GitHub CLI to pull code, launching parallel coder agents, modifying Nginx configurations, running Cloudflare deployments—it strung together cross-tool operations to complete the task. When encountering a file that couldn't be read, it confirmed the real state clearly and switched paths, never getting stuck and dying.
Error correction and sense of permission. It broke production, tested itself, rolled back itself, identified the cause itself, and proactively came to ask for instructions before the next high-risk action. The entire process from discovering the problem to restoring normalcy—it completed it without waiting for my reminder, then handed the final choice back to me. Having these capabilities combined isn't common among the models I've used.
This experience was very close to Opus 4.8. It can fully handle projects of medium complexity.
06 You can hand it over, but guardrails must be installed first
This experience simultaneously proved two things: K3 can handle projects of medium complexity; when Agents go into production, key nodes must still be supervised by a human.
My own approach can be directly copied.
Before starting work, have it read through the entire project—documents, schema, existing logic, all of it. Writing without reading will likely lead to stumbling in unexpected places. The reason its architectural judgments were reliable this time was precisely because the research was done before writing code.
Split tasks along dependency boundaries: interfaces are interfaces, pages are pages, deployment is deployment. Each segment must have clear acceptance criteria. Once dependency relationships are clarified, parallelism is safe; otherwise, it's just a performance of parallelism.
Smoke testing must be built into the deployment process, not remembered only after something goes wrong. After each deployment, run a round of core route verification and confirm normalcy before proceeding. What rescued production from the 500 errors this time was precisely this step.
Production changes must have a rollback path, and it must be prepared before deployment, not figured out on the spot after an incident. The reason it could roll back immediately this time was that a stable version existed to switch back to.
Operations like push main, changing DNS, or modifying credentials must all require manual authorization. It can prepare the plan and wait for my confirmation, but cannot press the execute button itself. This time, it proactively came to ask for instructions, showing this awareness exists, but the boundary still needs to be written into the process. Relying on process is more reliable than relying on model consciousness.
K3 has entered my daily toolbox. With model capability at this level and engineering support keeping pace, the delivery speed for this type of project has genuinely increased.
Domestic models have reached this point and deserve a serious look—in the first tier, there is finally one more domestic option that can be directly put to use.
For the next medium-complexity project, I will still throw it to K3 first to try.
👋 I'm Meng Jian, former Tencent T11 / former ByteDance Tech Leader, now doing AI programming full-time.
🔥 More AI programming in practice:
- GitHub: @mengjian-github
- Column: AI Programming in Practice
Found it useful? Like + Save is the greatest support 🙏