The trouble comes when you now want that system to do something unique for your business, and those ripple effects through the entire system you didn’t design become very painful.
Which is not bad
I don’t bother with the agentic stuff anymore than I would run a calculator on auto - what is the actual point if you think of what that really means
That being said, I am still guiding it on a regular basis and only recently let it run open ended trying fixing small to medium size bugs. The next stage will be try let it run in a loop trying to fix the 100 issues it has identified as well as getting most of the bash test suite to pass.
Yet I see comments and articles like above every week, where someone says "Yeah, I just left my agent run for a few nights, and then it made this awesome tool."
There is a huge gap here, but I can't pinpoint it yet. Either I (and everyone I talk to) is Doing It Wrong, or your code is actually flawed at its core and bugs will take exponentially longer to fix and never converge, or... I just need to let my agent run for 3 months??
[0]: https://medium.com/@vishvananda/i-spent-2-billion-tokens-wri...
1. You have very good tests. The agent can write them, but you have to prompt it to do that, and some human input may be needed here.
2. You have a good, modular architecture. Again, this is something that needs to be prompted and/or developed up front. Agent work can scale if you divide and conquer, so that any given task has a well-defined scope, limiting the amount of context needed to handle it well. If you let an agent just build a big pile of code, you’ll have issues.
Once you have the above, you’re more likely to be able to just let the agent run.
This is why you hear about things like SQLite being ported to Rust (by multiple groups!) It has a comprehensive unit test suite and a good existing architecture. Such porting projects are benefitting from already having done the upfront work that I mentioned, plus they have the original source code as a reference implementation.
Because of that, most of what I do involves a lot of interaction with the agent. That’s because I’m typically working on complex existing systems, that don’t necessarily have the above properties, and agents aren’t at the point where they can handle that autonomously.
You really need to add yourself as a human in loop to be in the middle of design choices. That is, ask the model for a plan, what the trade offs are, should parts of the code be refactored before the next feature, etc.
Also, there’s an element of reading the code and ordering refactors. I’ve noticed that for embedded code codex loves to to do everything in a main.c and too many compiler defines. Asking it to propose a refactoring into modules helps a lot.
It’s just like writing real code, if you don’t do design up front and don’t aggressively refactor as the requirements change, it becomes a mess.
I've noticed this pattern as well when people decide to vibe code a large project.
They usually get their MVP quickly, but as soon as they want a new feature or to fix a bug, the LLM takes the shortest possible route to a solution. The problem is that after about a dozen rounds of "the honest fix" and "load-bearing code" (insert your favorite claudeism) it's a tangled mess of enterprise-grade spaghetti.
I think it's because the people full-on vibe coding just don't have the experience or time to design large scale systems and anticipate what might cause problems if they want to change something later.
IMO coding agents can be useful, but the only safe place is the manageable changes you would design up and hand off to a junior anyway (but can't because your company decided to outsource years ago).
Doesn't that happen to a human engineering team if you don't course correct it many times a month (which in code output is similar to an LLM in a day)?
The future is duplication. Code is no longer meant to be read by humans but by machines.
you ever worked with human engineers before? :D
- Project portfolio management software. Good results so far. This is unguided experimentation: Fable researches feature ideas and plans them, then Opus 5 implements them, without me in the loop. The features include things such as an auth server, full-text search, audit logging, resource leveling, HA/DR, IaC, and more.
- FHIR & SNOMED medical software experimentation in demo-only environments. This has mixed results so far. This is guided experimentation: the FHIR specifications and SNOMED specifications are thorough and I'm in the loop. Fable plans OK, but Opus 5 is thrashing a lot, going down many rabbit holes.
It includes a custom WAL, structure aware semantic chunking, ingestion and indexing pipelines, hybrid (rrf), text and vector retrieval, ACL aware filtering at query level, query classifier, citation tracking, and a CrateDB backend that performs fused retrieval over a single table. total LOC: 180 K. Status: evaluation by State agencies for investigative search on legacy documents. tool used - Codex, Luna, and earlier codex 5.3, and gpt 4 mini.
This solution should look for more problems.
I also built a caching proxy server for apt packages, that's a bigger project, and that is 30.5K lines of golang, which doesn't seem bad compared to apt-cacher-ng which is 19.3K of C++ (my project does significantly more).
- my coworkers
our c code probably looks at us and says: how, how can you let these agents roam free.
llms are not code and are incompetent and inefficient relative to code, but on the other hand you cannot roam without a little echo echo echo in your blood.
We wasted every second dime On diets, lawyers, shrinks, and apps, and flags And plastic surgery
- So long & thanks for all the fish, a perfect circle
The interesting question in my view is what is the largest system an AI can maintain over a long time horizon -- while keeping a coherent architecture that adapts and responds well to change. All the while remaining performant, scalable, and understandable to humans. I am unaware of what is the currently longest-lived vibe coded project but it cannot be more than a few years old.
So to my mind, we don't have very much real data yet.
In a benchmark, there are usually clear tests and a correct reference. In actual product development, requirements are often unclear, and we do not always know what the correct result is.
Passing tests is also not enough to confirm security, maintainability, or operability. I would like to see a benchmark where an AI continues changing the same product for several months. It would be interesting to see whether the architecture remains understandable and safe after many changes.
Product org problems also is very context-dependent. Product orgs can work significantly different, in some orgs humans desire to be deep in the details, in other orgs the product folks are happy to let engineering drive the boat beyond a certain level of complexity. So one size harness can't necessarily fit all.
People who try to get AI to do a lot of un-manned work seem to have a bit of a bias toward viewing LLM work as "good" or "good enough" in a way that they wouldn't have accepted in the pre-AI era.
I don't think i wrote more than 10 lines of code in the largest project i'm working on. Lines of code: Java: 900_635, typescript: 725_418, C++: 180_445, Dart: 96_181.
It's been obvious from the start that no model, as good as it is, can do large(-ish) amounts of work by its own without supervision, control, criticism, etc ... If left unsupervised, models usually do half the work, leaving stubs and todos everywhere.
Quality comes from applying software engineering principles as much as possible, just like you would do with teams of junior devs: planning sessions and implementation sessions with adversarial critiques, specifying as much as possible upfront, planning unit/smoke/integration tests, etc ...
Many systems rely on swarm of agents to build software but i've found it very difficult to get good results without lots of overhead/token waste because of inter agent communications mostly.
So instead i built what is mostly a workflow engine to structure / organize processes into workflows with different agents assigned different roles. I've setup a basic landing page here https://kodfactory.com if anyone wants to follow along.
The space is too big and the code too extensive for a 1M context window and the capabilities of the current SOTA models.
All models in the leaderboard probably have had access to the original source code in their training data.
- They build a browser engine from scratch that implements every whatwg spec for the last 15 yrs, fixes every bug chromium has and runs 10x faster than chromium
- they build a super highly optimized version of windows that runs much much faster than windows 11
80 years, yet we still can't mark up hypertext without copying and then modifications to the source.
All software has problems. Most engineers spend their careers fixing issues caused by previous engineers. This was the case before LLMs, and it will continue to be the case for the foreseeable future.
It’s an interesting eval but this is a distinct limitation — most applications that consumers use directly are not purely text-based.
I decided to try Codex+gpt-5.6-sol-xhigh, and it's really good. It reminds me a lot of Fable 5, but it also is a LOT harder to use all your tokens with. Plus they give you a free reset a week right now. I'd even go so far as to say I think it's better than Fable 5. With an asterisk...
That asterisk: For anything very big, I'm having it do review loops using Claude Code + Opus 5.
For example, I gave it a few paragraphs describing a bi-directional rsync without the Unison database. It worked solo for 4-5 hours and in my testing it works great. I gave it a few small feedbacks (give me progress in human units not bytes, there's a bug syncing a specific file rather than directory, etc).
It's impressive AI can put together it's own version, but I can't help but feel it's probably just relying on existing excel clones as it's a well trodden space.
Novel applications are what impress me. Not a clone.
It is important not to wait for today's AI tech to get to AGI. It is better to exploit the useful things it can do today while waiting for it to get better tomorrow.
Cloning existing software might be useful today. It allows the model to
1) learn from its mistakes
2) mix known solutions (embed product A inside product B)
3) mine value (turn product A into a set of reusable libraries)
etc.
I'm building a language with AI, and when I leave the AI running on its own, it keeps generating code in strange directions. I wonder what kind of structure AI-only code would have.
The ingestion side includes durable asynchronous processing, recovery and replay, idempotency, strict ordering, structure aware segmentation, parent child relationships, and batched local embedding. The retrieval side includes hybrid (rrf), text and vector search, document versioning, collection and category scoping, document level ACL enforcement, parent expansion, provenance, and citation tracking.
Your estimate is fair. But, reliable WAL and retrieval layer are each substantial projects. We did not build the underlying database query engine from scratch, but the correctness work around ingestion, recovery, hierarchy, security, ranking, and provenance was still significant.
The project now has more than 3,000 automated tests, including coverage for recovery, concurrency, ordering, ACLs, versioning, and retrieval behaviour. Tests are not proof of correctness, but incremental implementation, explicit invariants, failure testing, and continuous human review are how we built confidence in it. We also had script to automate live endpoint tests with real data samples, this help largely to mitigate issues after a refactoring or enhancement. total production code is 80k LOC and rest is test coverages. One thing to say after seeing the results are, many of the RAG framework does it wrong. We got exceptional results and we also have agentic retrieval for answering complex queries. We designed it in our own way because government systems cannot afford false results, especially when the product is intended for crime investigation or compliance management in banks.
Edit: I forgot to mention that we also support PostgreSQL.
After building this system, we concluded that vector dimensionality is only a small part of retrieval accuracy. We use 384 dim embeddings and still achieve excellent results.
Great, but since no human has looked at them, how do you know that they are relevant and actually test undesired behavior?
Also, would you be able to point at which tests should be added in the future?
We also use a headless API with a fully decoupled frontend, and the frontend is written entirely by developers. This helps catch additional issues during integration because every endpoint is exercised and validated through the actual userfacing workflows.
I may not be able to convince developers about the process we follow, but we got it working, and tested for concurrency, load and fanout behaviour. This is our primary requirement, as this is targeted towards large scale government customers. Regarding future tests, they will be added for new features, reported bugs, newly discovered failure modes, and regressions. This level of test coverage also helps us use AI without allowing significant drift in the codebase.
In the linked paper the researchers state "AI solutions must match the original program’s output exactly on end-to-end tests, including held-out tests. " And a bit further on "The AI agent is given execute-only access to the original program and a set of visible test cases, but does not have access to the original source code. "
At a guess, their agents are not going off into the weeds (like mine do occasionally) is because they have both access to a reference runtime implementation to use as a definitive end to end test to guide development. And also a relatively large token budget to run enough characterisation tests to allow them to home in on solutions.
It's decent at design and implementation, but strangely terrible at language consistency - and expectedly architecture.
Steering it on language consistency is easy. Steering it on architecture has required me to learn a lot more about compilers than I wanted to do for this project (since that's a lot more than I wanted to take on for something that was supposed to be a "fun" "side" project).
I'm not sure about architecture. When I first implemented the slot system in my language, I designed it around that implementation, and in the end, the architecture suffered. There were quite a few cases where consistency was simply unavoidable.
It's not easy to create a completely new architecture with something that doesn't exist in existing languages. Consistency doesn't come together as easily as you'd think.
In that sense, I really admire the people who first introduced something new.
When I started implementing it, I focused on one killer feature and just went for it—with the feeling that if this succeeds, my language will succeed. But once I started building around it, it turned out to be very different from other compiler architectures.
With CRUD or other well-established domains, it's easier to maintain consistency. But achieving internal consistency in a program seems to be a different kind of challenge.
But then it always comes down to having some human who is accountable for verifying the behavior. I think ultimately we just need a better set of languages and frameworks to minimally encode the types of applications we want to build today, so that human comprehension and verification of the source code becomes easier.
There are also small teams of experts who need little to no supervision, and will NOT devolve without constant correction. They will do things like look for an existing function before writing a new one, or use good judgement when trying to find a library, rather than reinventing the wheel.
No need for multiple programming languages anymore. But again, doubt that happens.
That isn't true. Everyone knows it and you know it. So why would you make a statement like this? Does it make you feel like a "thought leader"? This isn't X or LinkedIn. Bulshitting here just makes you look like a fool.
Cuz what if a human has to intervene as the LLM can’t get it right?
Assuming a human then has till be able to comprehend it?
Step 2: Dehumanize them constantly