Software Development Workflow with LLM

Prior to 2025, I was still using "Ancient-style programming," insisting on typing out all the code manually. I don't trust LLM-generated code. I don't think it can fully understand my requirements and generate the code I actually want. But in early 2026, I tried letting AI handle a simple request for me: "change the memory space allocated after a page fault from 4KB to 2MB in the kernel." The AI handled the task I gave it very well, completing it quickly and effectively. I realized it was time to make some changes.

In the first half of 2026, I used AI to generate code for just about everything and rarely wrote anything by hand anymore, whether it was complex or simple. My approach is simple: "prompt and pray." I write a prompt (sometimes I even have the AI help write the prompt), then pray that the AI generates correct, runnable code. The AI did an excellent job, generating a lot of beautiful code. It could accomplish in a single day what would take me a month to write. But I realized I couldn't understand the AI-generated code and can't maintain it. The work I'm doing is a file system. The codebase isn't large (about thousands of lines), but it's highly complex.

After reading the paper "Sharpen the Spec, Cut the Code: A Case for Generative File System with SySSpec," I realized that writing code with AI is something that needs to be learned deliberately.

Spec before Generate. An interesting aspect of the paper is that it generates an entire file system using prompts. Most importantly, it is reproducible. This means a complete system can be fully generated from a structured prompt—once I have that prompt, it's equivalent to having the entire system. The developer's role has shifted from writing code to writing prompts, and the prompt itself has become critically important. The paper introduces a structured prompt called Spec. It is a prompt, but a structured. AI cannot generate code arbitrarily; it needs to be constrained by Spec. Of course, Spec can also be generated by AI, but unlike code, Spec is easy for humans to understand. The paper mentions two very useful methods for developing with Spec, this is: "Sharpen the Spec" and "Cut the Code."

Sharpen the Spec. A Spec needs to describe very clearly what a function or module is supposed to accomplish. It should include the function's inputs, outputs, the state of internal variables, and so on. When necessary, it can even include the specific implementation algorithm. If the system involves complex mechanisms (such as concurrency control), you may need to write a dedicated Spec for that mechanism.

Cut the Code. AI can generate massive amounts of code in a short time, yet it has a limited context window. The solution to this contradiction lies in finer-grained modularization. In the field of software engineering, modular programming is nothing new. Where AI programming modules differ from traditional ones is that they are much smaller—perhaps only around 500 lines of code. Modules should have clear dependencies between them, each accomplishing a specific function and exposing interfaces to the outside.