DeepSeek 1017 Re-architected My App in 60 Hours

DeepSeek V4.1 Flash 1017 is the first model that made me feel like I had an engineering team. An $80 spend limit on a $10 OpenCode Go subscription feels unlimited. I gave it a real Electron app, a GPT architect, and 56 worker sessions. After 60 hours of active agent time and almost 7 billion tokens, it produced 306 commits and restructured almost the entire codebase. The broader job was estimated at 8–14 weeks for a senior engineer. Then I opened the app.

The setup: one architect, 56 workers, and me getting excited

The app is my fork of an admittedly dubious open-source game launcher. I forked it because I did not trust the maintainers, and with PHP2Shell and HTTP2Shell happening around the same time, who can blame me?

Then I started adding features. A few polishes became nice-to-haves, which became a complete redesign of every screen and UX interaction. This mania was partly excitement about the project, but mostly it was DeepSeek 1017. The infinite feeling of this model is incredible. It’s the first cheap open-source model that can just … do stuff.

Eventually, even small fixes started taking agents 2–2.5 hours. The app had grown enough that every change required understanding too much of it. So I wrote an architecture proposal: separate business logic from Electron plumbing, put network and storage behind explicit boundaries, and make features easier to change without loading the whole app into an agent’s head.

I chose GPT-6.1 Sol as the architect and gave it one very clear instruction:

You are the orchestrator / senior architect of this app, your job is to only oversee subagents, review solutions, give feedback, never write code yourself.

Then I told it to spawn as many workers as it wanted. All of them used DeepSeek V4.1 Flash at max effort. The run happened in T3 Code, with 56 worker sessions, 19,775 tool calls, and 49 messages from me.

The important number is 60.1 hours with at least one agent active, spread across six calendar days.

Icarus’s wings

This was not a shitty Twitter video game demo. The agents worked inside an existing product with local persistence, downloads, installers, controller input, two interfaces, and years of accumulated behavior.

They separated business rules from the runtime, introduced storage and network adapters, added typed contracts between processes, cleaned up shared UI dependencies, restructured the repository, and built an automated QA system for the actual Electron app. The diff touched 2,052 paths and added 111,850 lines, about 73% of them tests, fixtures, and QA tooling.

Yes, you read that right: 73% of the code produced was “tests”. Remember this; it will be funny later.

Sometimes, they were genuinely excellent.

This setup found multiple races in the old and new architecture and fixed them. They found serious security issues and patched them. Watching them work was so dopamine-inducing that my phone screen time dropped.

Later, DeepSeek took over as architect too, because on a $20 ChatGPT Plus plan, I did not get enough inference for this monumental task.

The sun

As the project neared completion, I asked whether the re-architecture was done. The architect checked its ledger and gave it four and a half out of five. The five milestones were process plumbing, storage, controller input, the big folder restructure, and packaging; only packaging got half marks.

Its summary was:

complete as a codebase and as a build; it is not complete as a running application

To this day I don’t know what it means. The code is complete but the app is not? What? The code IS the app????? Whatever, I asked for a full QA run.

The app opened to a blank window. (73% tests, btw.)

There was one missing database table and three broken resource paths.

Thousands of green checks, btw. I’m convinced LLM-written tests are just stat padding at this point.

The tests were helping the bug hide

This is my favorite failure from the whole run, because it is so easy to repeat without noticing.

The tests did not launch the real built app. Instead, they supplied __dirname, the directory the code believed it was running from. They supplied the old location. Then they calculated the expected answer using that same old location.

The production code and the tests agreed with each other perfectly. Both were wrong about the build.

A green test only proves something about the environment it ran in. If that environment is imaginary, your suite can get bigger and greener while the actual product gets more broken.

Back when GPT was the architect, there was a QA lane that actually launched the built app and took screenshots, and it quietly stopped running once DeepSeek took over. I had initially dismissed that QA lane as expensive overhead. It was the one check that would have caught the failure immediately.

The app passed QA, until I used real data

After the fixes, QA passed 10 of 15 test cases. The architect blamed the five failures on stale test instructions and declared “zero product defects”.

Then it ran the same scenarios against a copy of my real profile. All 15 passed, and it retracted the earlier diagnosis. Turns out the “missing” buttons only show up once you have sources and games, and the fresh test profile had neither.

Another useful lesson: You need to tell the agent how to verify its outputs. It can be as abstract as you want (like scoring a UI/UX design using multiple models) or as precise and deterministic as you want (like reducing the latency of X API by Y%).

So I asked the question I should have asked much earlier: “Is the app fully functional?”

No. It launches, renders, and reads real data — that’s not the same as fully functional.

Fair enough. I gave it permission to download, install, and remove games.

After a minor hiccup, a 2.43 GB download completed. Extraction worked. Installation worked. Then the game launched.

The agents had done it. They did it. They actually did it.

What it cost, and why I would do it again

An agent reviewing the run estimated 200–360 hours for a senior engineer familiar with Electron, TypeScript, and this codebase to deliver the same checkpoint. The broader architecture plus proper product acceptance was estimated at 320–560 hours, or 8–14 weeks.

Compared to that, the 60 hours of mostly autonomous agent time is stupidly fast.

And all it really cost was a $10 OpenCode Go subscription. Okay, maybe $30 if you include the GPT-6.1 Sol architect I used early on.

How to get the good part without my mistakes

DeepSeek 1017 is absurdly capable. My problems came from the system I put around it. Here is what I would change:

1. Define “done” as a user outcome. “Download, install, launch, and remove one game” is a finish line. “306 commits and all checks green” is mostly stat padding ngl.
2. You need a real end-to-end QA system. Run it after every structural change.
3. Give workers complete, small outcomes and fresh context when they finish. Let one worker own a feature through its plumbing and tests. Do not make every session inherit the entire history of the project.
4. Verify impressive summaries. Agents can fix a bug and then give you a beautifully tidy explanation. You need to build guardrails to actually verify their claims.

DeepSeek 1017 gave me the feeling of having a large engineering team for the price of a takeaway dinner.

Give it a clear outcome. Let it run.

Then open the app.