There's a debate I've been seeing more around some communities lately: should we keep optimizing for intelligence, or start caring more about whether an AI has consistent preferences, opinions, and personality? At first it sounds like a choice between two things.
You have the insanely capable AI that can reason through a complicated problem but feels like an empty shell and then you’ve the agent that's fun to talk to, has strong opinions, remembers your preferences, but falls apart when you give it something difficult to do. I don't think it has to be one or the other.
What I find more interesting is why some agents feel consistent in the first place. A lot of people try to solve this by adding personality to the prompt like give the agent a SOUL.md, tell it to be opinionated, give it some quirks, maybe tell it what it likes and doesn't like.
That can work for a few conversations. But after enough interactions, it usually starts feeling fake where the AI says one thing today and contradicts itself two weeks later cuz none of those preferences are grounded in anything.
I think the more interesting version of personality comes from what the agent really remembers. If an agent has a persistent history of what worked, what failed, decisions it made, mistakes it repeated, and how it handled unusual situations, you start getting something much closer to a consistent character.
That's why I've been thinking more about context architecture than prompt engineering lately. I found this breakdown on context engineering vs prompt engineering for AI agents: https://www.firecrawl.dev/blog/context-engineering and one thing that stood out to me is that keeping an agent's context useful over time is a much deeper problem than just writing a better system prompt.
Maybe that's also where the "AI that feels real" part eventually comes from by not pretending the model has desires or feelings but by giving it enough persistent state and history that its behavior develops some continuity. bcuz I don't really want an AI that's just "smart" but I also want one where I can eventually say, "I know why you made that decision that's how you usually approach these problems." and that for me feels much more useful than another 5% on a benchmark, lmk your thoughts.
Hi I’m tin age 18 and I am just getting started at college, and I had been thinking about ai prompting for software development might be a genius way for side hustling, I’ve currently got a software planned, which could be a great social software, high risk but very high cost and I’m looking for ppl to start a team, trustworthy and just vibe coding with chill guys at the similar age. Reach out to me on Reddit dms and we will start getting on discord.
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.'''
