Probably a week ago someone posted a thread with the title "Why isn't the industry freaking out about DeepSeek 4.1 Flash?"

I have been intrigued about Chinese models for a long time, but never tried anything except an early Qwen. My daily driver was Luna, with occasional elevation to Terra or Sol - all on 5.6 as I found the output of 6 jarringly incomprehensible.

I still had 95 USD on my OpenRouter account, so I thought I would give DeepSeek Flash 4.1 a try.

I think now I can understand the person who created that thread.

Here is the setup I settled on, after a lot of refactoring and calibration of the workflow:

I have a "plan" prompt which explains to the agent (Luna) that I want to have a discussion about an idea I have in mind. The agent should use the Socratic method to pull out all the necessary info from me using pointed questions. When the agent feels it has a complete picture, it should elevate to a higher level model (Sol), and ask its review. If Sol has complaints, Luna keeps asking me until the points raised by Sol are clarified. The review rounds with Sol continue until Sol says "ready to implement".

At this point Luna creates four files in a directory I specify:

1. PLAN.md: the implementation plan with all the details that came out from the design discussion 2. PHASES.md: implementation phases 3. DECISIONS.md: design decisions (this serves the same role as ADRs aka. architectural decision records) 4. DIARY.md: append-only log of what happened during implementation

Files 2-4 are written by the implementing agent. Luna only adds headers to explain the purpose of the files.

Once these files are there, I start up a new Pi session, switch to Deepseek 4.1 Flash and then point it to this plan folder.

And then it goes brrrrr... :-)

Here is what I implemented in the past week using this method:

1. A capture/analysis/decompilation pipeline for C64 demos: I ask the agent to start a selected demo through VICE, and say "on" or "off" when I want it to start/stop capture. The capture process uses VICE's builtin trace functionality: the trace log is piped into Clojure where it is saved into an optimized binary format (chunks of trace events). Once I have everything captured, I unleash my analysis pipeline which checks the write patterns of the executed code: what it wrote (VIC, SID, CIA, memory) and when (rasterline, cycle). Then it splits the execution trace into segments by type deduced from the write patterns (decruncher, loader, raster, music) and then decompiles each segment into both traditional ASM files and a s-exp based syntax which roundtrips back into the in-memory representation. Once I have the results of the analysis pipeline, I can tell the agent to analyze any demopart and it can explain how the effects are built down to the tiniest timing detail. As a first test, I asked it to create a clean-room implementation of Fairlight's legendary intro and two days later I had it, with everything in sexp assembly, including the music routine and its data. (The reason it took so long was that this was the first decomp and it provided a lot of feedback to the pipeline development.) Finally I had it write an assembler, linker and packager which creates a PRG from the assembled and linked artifact, then runs it through VICE. Done.

2. A DSP compiler which lets me compile sexp forms of a C-like DSP language into native DSP kernels running on the JVM, JS and WASM. Currently I have about 600 tests which verify that the behavior of the three targets matches that of a reference interpreter written in Clojure. I have a full numeric tower with i32, f32, f64, support for arrays and structs, typical control flow constructs, and a library of DSP building blocks like oscillators, filters, LFOs, delays and a chorus effect. By the time this is ready (end of the weekend?), I will be able to build synthesizers like Synth1, Surge XT or Vital in Clojure/Script, compile the DSP kernels in the browser, choosing between JS or WASM backends, driving the kernels via AudioWorklets and sequencing them from the host language.

There are two power tools at play here:

1. Deepseek Flash 4.1 2. Clojure and ClojureScript

Deepseek is a BEAST. It just goes on and delivers, phase after phase. What it needs: clear instructions - this is covered by the planning process quite well, but I still find it needs some steering from time to time (the right nudget of wisdom dropped into its thought stream at the right moment works wonders)

And Clojure... well. That article PG wrote about LISP (Beating the averages): what I witness now proves all of those claims.

The agent LOVES Clojure. Especially the REPL (not so much the parentheses).

Winning strategy: give it two tools: start_jvm and clojure_eval. Implement everything else it may need - tools to start up HTTP servers, compile ClojureScript, add dependencies, capture a C64 demo, run Playwright via spel, etc. - as lightweight Clojure namespaces which provide APIs to all these functionality. Let these namespaces be thin: the namespace and the functions therein shall have docstrings which tell the agent what the functions do, but the functions themselves shall be lightweight proxies to the real implementations in sub-namespaces. Then point the agent to these top-level API namespaces via your AGENTS.md. Bam, instant discoverability with minimal context usage. It will do EVERYTHING through clojure_eval and the round-trip time will be phenomenal, a perfect match to the raw speed of the agent.

...

Now all I need to figure out is what will I do when all my dreams become manifest in flesh.

DeepSeek-v4.1-Flash-1017