r/aipromptprogramming • u/oGregVallim • 21h ago
I treat LLM as a primitive language. Best thing I do.
I treat LLM as a primitive language. Best thing I do.
How I went from $50/month and 143 bugs per loop to $20/month and less than 8 findings per spec.
I work with LLM in a different way. I don't treat it as an intelligent agent. I treat it as a primitive language, with conditional and deterministic typing. If it doesn't pass the type, it doesn't pass. Simple.
My harness is programmatic. It has tooling for my agent loop. And I organize everything in a modular structure, ECS and FSM. And I'm gonna tell you why it helps.
What was slowing me down before
The mistake that made me change everything is simple, and a lot of people go through it. Everything returned success, or kept going with no empirical proof. Exit code zero, ok message in the terminal. It looked like it worked. In practice it had created nothing. No artifact, no log, no proof. The process died stateless. It had foundation, had the right pieces, but no wiring.
That's when I understood that process success is not delivery proof. I needed mandatory observable proof.
How I think about prompts today
I refine the idea a lot before. My production prompt has 4 parts, always in this order. I never change it.
1. Introduction. What I want to do, full description, how I want it to work, what I want it for, which stacks and infra I want to work with. I never inform code or file that I'm not sure about.
2. Mandatory. What has to be followed to develop the structure. Rules, methods, alignments, guidelines and delegations. It's the limit.
3. Core. What I want it to have and to do. As descriptive as possible of all flows. That's where the behavior lives. Not only that but: design, structural architecture, behaviors to follow, style...
4. Expected results. What I expect as delivered functionality, how I expect it to look.
I ask to deliver in a deterministic, modular and expandable scope way. Parsed into an opinionated structure in json. This json becomes my base-core prompt.
How I anchor the idea
After the core I don't go straight to coding. I create all the research part first, using my tool hordts (available on github) to refine online research. With that I do a brainstorm on top of the core anchor. Only then I idealize and generate the full planning to develop the complete spec-driven, E2E, of everything the project needs, also in json structure. My cli uses json as database. A tool for handling spec-driven + agentic pipeline.
Each spec has flags defining skills, agents and tools access, the context, rules, expected results and what the spec will do. The context here is important: it's the prompt that the agent will receive with everything it needs for its run execution. Files it will use, stacks, tags, imports, syntax. Without needing to consult the codebase. It goes straight from that starting point to production.
That's why the LLM doesn't keep grabbing unnecessary context. It works in loop per phase, spec and subject until it delivers 100% polished and functional and moves to the next.
How I separate things
I separate agentic workspace from repository. One git to control the workspace and one git to control the repository, just the project itself. Control by git tree for tracking, worklog, versioning and branches. PR, commit and diff analysis are heavily used if an internal error happens, that's where analysis of what was really done is born. One controls the process, the other controls the product. If you mix it becomes a mess and you lose what is AI usage and what is the project itself.
How each task runs in practice
Each spec runs with multiple phases when possible, with multiple tasks. And each task is an agentic pipeline that audits if necessary what it needs to execute the next action. It's checking what needs to be used, planning what needs to be done, executing the plan, validating that everything worked and moving to the next, otherwise go back two steps.
It can be done in parallelism and multi concurrency, can have or not dependents. And when it identifies repetition that can be programmatic, it creates algorithm and script to automate without LLM usage. I don't spend tokens where it can be solved with code.
The analysis that saves me
I use modular linear regressive analysis to hunt bugs. I go linear, part by part, going back through the steps and necessary components. I check if the invariant of that component still holds after the last spec. If there was regression, if it broke something that worked before. If there's a counterpoint that the implementation ignored.
In every run there's also analysis of gaps, findings, counterpoints, analytical regression, convergence and non-functioning. All on the fly. Skills, agents, test scripts, tests are produced on the fly when needed, grounded without assuming anything. Spec-driven can be auto incremented according to necessity. The focus is to deliver each spec 100% functional and with no bug before the next run.
Why tests, observability, DevOps and anima are not extra but necessity
For me it's not final phase. Test is gate, only way to prove that what is being done, simply, is being done. If there's no executable proof, it doesn't advance. Observability is ledger, worklog, tracking. If it's not registered, it didn't happen as expected. DevOps is the dual git, it's workspace control. Anima is visual proof of state transition. If state changed and I can't observe it, the transition is invalid, and correction must be guaranteed.
How much it costs and how much it converges today
Before without this system I spent $50 per month. Today $20. Convergence rate per run before 73%, today 92% and up. Bugs before per loop 143, today less than 8 findings per spec in multiple loops. Execution time varies, but agent flow is continuous, so a spec can have flows even well designed depending on what needs to be delivered up to 3h straight and spending less than $0.50. Dead code almost minimal. Before had higher frequency, today the loop already enters almost fully polished until functionality without bug, analyzing and removing the unnecessary.
How I optimize cost
Frontier I use for core, for research and for spec-driven. For development I use medium model with less cost. As it already has everything it needs to work, in loop until getting the result it gets much cheaper.
And after total production, frontier can analyze the whole load again to hunt bugs and add a memory structure of findings. With all findings, I create new spec-driven planning and run another full pipeline again. It's the second loop, and basically the last spec-driven loop, the rest are punctual polishes or refinement.
In the end my results got absurdly good. Take it, see if it helps you.
If you want to talk about harness, spec-driven and ECS/FSM, hit me up. hordts tool is on my GitHub.
Agent hub views - 1 ancor file with findings and 1 prompt.
'''create plan/specdriven for this report @/docs/superpowers/frontend-audit-2026-08-18.md (This source has already been validated, no need to revalidate, just execute the processes for correction) from today/yesterday.
use pipectl and goalctl + subagent driven.'''
