The state of the art in LLM codegen prompting, especially since February (2025), seems to evolve daily. These most basic things have had lingering utility.

• Choose your weapons: mine have included Github Copilot with various models (mostly Claude 3.5+) for code. Later, Geminis 2.5 (flash + pro) for PM artifacts + code.

• Use your preferred minimum viable process style. Here for example just a Product Requirements Document (PRD) and a Software Bill of Materials (SBoM)

  –>   from an informal “napkin scribble” app description text or image, compose or generate (via PM agent role) a PRD in your preferred format e.g., markdown.

  –>   compose or generate (via PM / Security agent role) a SBoM for desired platform and stack. This example is a simple markdown file, but you might prefer a more formal format like CycloneDX or SPDX.

• Any House and Domain Lore files

• Omission reports : Simple listings of any aspects of prompt, SBoM, PRD, lore etc - that were NOT fulfilled during a generative operation. You’re very likely already using these as they can be invaluable for tuning prompts as well as refining design points. Useful in both one-shot and agentic modes.

• PRD + SBoM is the base context.

• Your preferred prompt. Could be trivial: “build the described app”, but probably it would include more detail, role info etc.

• Finally: –> prompt and a context (base context + any House & Domain Lore) -> one-shot output of shaped & targeted, generated codebase.

out of scope here: agents using up all the money.

These are documentation, coding standards, style guides, framework and/or project build guidelines and other representations of personal, customary or organizational standards.
You likely already have assembled a significant collection of these, in the form of those Cursor and GitHub Copilot instruction files, etc.

Such house lore is represented via RDF

WTF RDF ?

• The Resource Description Framework yields “data to be processed” rather than “text to be interpreted”
• These RDF files contain ontologies for a document or codebase
• Built by gen and/or hand and then run through audit iterations
• can greatly reduce ambiguity, though at a tradeoff cost of some syntax, verbosity and token usage
• Curated & maintained in a Knowledge Graph, by hand or gen

Domain / Project Lore

Source code examples, being implementations, give you a good “how”, with elaborations dependent upon documentation discipline. Additional information about the code’s structure, reasoning and rationale can greatly enhance prompt efficacy.

This can be rendered via both source code and domain knowledge summary documents, represented in RDF format to convey disambiguated specification and guidance.

• not necessarily or even usually just a single file
• all examples use RDF in turtle format. JSON-LD is another option
• whimsically, these are molds used to help cast a particular information processing shape

LLMs; consuming an Internet-full of information then guesstimating semantics. And these are often very GOOD estimates! But intent can be missed. RDF-enhanced specification & example files can improve one-shot codegen efficacy by clarifying a very particular context: YOUR house practices, YOUR domain base etc.

So, RAG?

Well, yeah. “Regular” RAG would be embedding lore into the LLM vector space, baking it in. This example process used here is more akin to a rudimentary graphRAG, with the appropriate support materials selected and presented manually into the prompt context. MCP + agent + full graph database can be used as well of course. The goal was to illustrate how structured, specific & relavant information can augment the inference efficacy from the LLMs massive but more generalized latent space.

LLM Vendors are constantly improving code generation capabilities and even in the Agent Era few-shot LLM codegen still gets a nice headline. Actual, practical uses however require us to iterate and accrete and shape codegen via validations and tests. Work is still work.
But just for amusement, how might would-be prosumers of LLM services facilitate the occurrence of nominal codegen?

First, The Very Obvious Thing: All that is not Shaped is Improvised

When running many like-prompted codegen reps you immediately find that things not locked into functional shapes via specification and other scaffolding may be subject to LLM whim. This player piano fills in estimated arrangements as the prompt is exhausted and the notation thins out, yielding an aleotoric rendition rather than pure playback. Cue confusion, angst and noise.

• Hermetic builds are not generally expected with pure LLM codegen.
• But with the latest models & services the codegen results are increasingly nominal
• …but sometimes they are not what you want
• Sometimes improvs reveal interesting things you missed
• And sometimes they are Ok, but weird
• And …sometimes they are just skibidi
  
  

In the far dim past of last Winter

Playing with repeatability experiments, building a simple version of a familiar app type (a basic web server) from specs, testing & validating. Over and over and over. Watching code variances and compliance with build guidelines. Exciting.

Spring

Our toolchest is now stuffed with elaborate Cursor rules, Github Copilot instructions, a menagerie of process roles and formalisms, deutero-prompting, delicate phrasing, extensive guard-railing, lots of w00-ware and just-tries.
Which yield frequent bouts of nominal codegen.Yay! …bouts…
How can we tighten this up?

Hot Codegen Summer

Wielding a few standard process management artifacts combined with Knowledge Graphs consisting of RDF encoded support documents (“Lore”) to be included in the prompt context.

AKA; PRDs & SBOMs and graphRAG / subgraph injection

You’re busy building a cybernetic LLM-independent PM + development methodology, like everyone else is doing.
And it’s getting quite useful. Pushing further…

Early autumn

Assembling various house and domain Lore, accreting source and docs into a private RDF-based Knowledge Graph. From there your graphRAG apparatus (a ROLE, a tool, an agent or maybe just …you) extracts needed entities and relations into tuned subgraphs, which are used as context participants.

And then you upload them to the Great Service Provider in the Sky. Your privacy & confidentiality are protected by majestic TOS wordwalls, reputation and vibes. This somehow does not fill you with joy sparks.
How about local? Local would be better… Much model & hardware research follows.

So…maybe just go retail with big flavors of Qwen, Mistral or DeepSeek on a top-maxxed 512GB Mac Studio?
All local, sandboxed & safe for source code and other confidential/private material. Also fences in agentic extravagance.
Pretty cool…but unfortunately too costly* for personal use.
What is indeed a minimum viable personal local codegen LLM setup?
To be Continued…

* A price which if we were looking back for silly historical concordances of the contemporary local LLM scene would be oddly similar to that of the flagship 512K Mac of late 1984 (about $10K, inflation corrected).
Bleeding edge cuts.

The original post from 2020 is HERE

As an experiment in concise function naming, consider using the classic Lisp (x->y) ‘coercion/conversion’ syntax as much as possible in your Clojure code. What are some consequences of programming in this manner?

First note that a slightly gratuitous semantic cast of the ‘coercion/conversion’ endpoints is probably required. By referring to these endpoints as ‘entities’ you accrue a bunch of functions where entity->entity and program logic is then dominated by entity transformations.

Entity oriented Naming.
 

motivation:

In statically typed languages such as OCaml/Haskell/Rust/etc you have both a function name and a function signature.

We need the function names because some things are different from other things, and because type signatures describe ingress and egress things but not necessarily what happens inside the function.

For example the function:
bank-balance
might have a type signature of:
  id->double

but then so might a much nicer function:
bottomless-bank-balance
  id->double

More seriously, it would be nice to have concise function names that are both structurally and semantically descriptive.
 

so then, Entities:

• as Clojure is dynamically typed these are treated as type-like rather than actual types (although some entities are actually types, e.g., String) and any associated discipline is handled manually

• the names of functions consist of only one or two entity clauses, representing input and output

• parameters may not be apparent from the name, but you can easily read the endpoints. Actual function parameters are only an IDE convenience feature away

• function names may resemble function signatures but the name clauses do not necessarily represent function parameters, and entity-endpoint name clauses do not imply currying

• entities are value-like but not necessarily pure or referentially transparent

• they blend well with pre/post block asserts

• they encourage names like location-value over something like get-location-value

• and entities & functions mostly sort into the expected lisp-ish categories:

  • nouns: x
  • verbs: x->y
  • predicates: x?
  • state-mutation ops: x!
  • verb-likes/actions: basically everything else (as usual it’s probably best to keep the “everything else” category to a minimum)

 
Some examples from an application written in this manner

• nouns:
  packed-codon
  upacked-codons (list)
  image-file
  MResult
  string
  out

• verbs:
  text-file->image-file
  image-file->string
  packed-message-string->MResult

• state mutator / destructive:
  draw-image-pixel!

• predicates:
  supported-image-file?
  fasta-file?

• verb-likes/actions
  cli-decode cli-encode

 
and some example code

(defn otp-image-file->string 
  "Given OTP-encoded image file + appropriate key files,
   return plaintext.

   note: By app convention, filenames are used as 
         file references."

  [fname, key-files]
    (packed-codon-string->string 
      (apply str 
         (map codon->packed-codon
              (string->unpacked-codons 
                (packed-codon-string->string 
                  (image-file->codon-string-themed fname)) 
                string->otp-numcodes   
                key-files )) ))   )



(defn image-file->string 
  "Extract the base-encoded text from an AGCTAG-style image"

  [fname]
    (->> fname
         image-file->codon-string-themed
         packed-codon-string->string ) )

results:

pros:

• reduction of write-time cognitive load, e.g., time spent conjuring the ‘right’ function name
• enhancement of glance-time efficiency, e.g., time not spent wondering what a function does
• a reductive stylistic pressure towards smaller, specific transformation functions
• a kind of inherent facilition of concern separation
• entities are type-like, and sometimes even actual types

cons:

• can be wordy. Care must be taken to keep individual entity names “appropriately small”
• reductive sure, but ‘type-like’ is not the same as ‘type’
• maybe not generally efficient

mehs:

• if you try to structurally force everything into a bunch of entity transformations, you’ll sink into a bikeshed-y morass
• quit saying ‘reductive’; anyway this is just stale, are you unaware of all Lisp Traditions?

conclusions:

Ok sure, yet another facile remix of some Lisp-isms. But consider:

These conventions emphasize the ‘verb’ aspect of functions. Construction tends to proceed verb-first, then with the identification of noun-like abstractions.

In practice, cases where entities do not arity-map to function parameters are not really as confusing as might be initially assumed and can help reveal overly complex function signatures. And if there is an implicit pressure towards reducing the number of function parameters, this is probably not a bad thing.

The data transformation style of programming emphasized by this naming scheme seems to fit well with Clojure, and the type-like names do seem to facilitate function reuse.

Using this structural pattern you quickly accrue a lexicon of the entities. This can be a nice addition to your documentation, even if you use a doc generator.

And finally, it’s not unusual for vaguely-named or “processor/handler” functions to tend toward bloat accretion. An entity->entity naming style can help keep such naughtiness in check.  

epilogue:

I have found that this fairly simple style of nomenclature can both improve program readability and facilitate logic organization. Perhaps you will find it helpful as well.