We need some way to make AI-driven coding strive for parsimony.
We need some way to make AI-driven coding strive for parsimony.
1998 - Huge business, re-writing some vital piece of the platform in the middle of Y2K. Contract coders are expensive but also the only available people to throw at this.
The architect had mapped out the entire system down to class/method level. They'd produced a huge list of classes and methods that needed to be built. So the company hired a bunch of contract coders to build said classes and methods, including your humble protagonist. We were each given a list of methods to write up - parameters, operation, expected output. We wrote them up, and ticked them off the list. We were not briefed on how they interacted. There were no tests that we could run. There was apparently no-one checking that what we wrote in the method actually matched the spec. This was before git, so version control was extremely rough, and also before JIRA (iirc the list was an Access database).
We all realised very quickly, like the first week, that this entire project was doomed. But we were getting paid a lot of money to do this, so we just did it. It got really boring really quickly. Every day we wrote a bunch of methods, and next day got a list of the next set of methods to write. The lists just kept coming, with no idea how long the master list was, or how the classes interacted with each other, or how the system actually worked, or anything.
I left after a month. The money was good, but the boredom was driving me insane.
I learned later from friends who stayed that the whole project was canned a couple of months later when it became obvious that this was a complete waste of money and would never work.
Whenever I see a project manager staring at JIRA instead of talking to their people or looking at the codebase, I'm reminded of this project. And your comment reminded me of that ;)
A meaningful risk of course is that the tools available to the model (ripgrep + fancier semantic approaches) allow it to do a good job of reasoning over things much larger than its context window, and so it doesn't pay the penalty sufficiently to fix it.
Look at all the libraries full of books we've built. It's useful for more than mere training sets.
The limit here I think the ancestor comments are getting at is cognitive load, which is real and measured. We only have so much memory to devote to a "stack" when executing, and it's usually quite constrained.
Hence my library mention. Humans have been doing this for millennia: orienting ourselves within a library (the physical kind, full of books) and calling upon its information resources as needed to accomplish tasks (research). Ultimately, it's all just one big cache hierarchy. Your short term memory, your long term memory, the book in your hands, the desk at the library, the nearby shelves, the card catalogue, the stacks, the inter-library loan system.
To manage it all, we humans have developed our abilities for abstraction. When we build clean, tight abstractions we reduce our cognitive load. Perhaps the best abstraction we've built so far is the TCP/IP and web stack. We don't need to care at all about the hardware details of a server in order to talk to it. It's such a powerful and airtight abstraction that we take it for granted.
I'd like to hear from more people who have spent a lot of time building with LLMs, because so far what people are saying is that these models do not have the ability to reason about and build the kind of marvellous abstractions us humans have built.
I've built a lot with LLM's, my experience sort of but not really tracks that. I've had to course correct a few bad abstractions but the larger the code base becomes the better it seems to be at reusing things. Maybe this is because of types, or spec-first development (with OpenAPI), or black box integration testing - but also maybe not. But generally I have to think about the abstractions and let the LLM fill in the details with rare exception.
That said, reality at scale always come with details that will break the model, and the main roads when it happens are to ignore/reject any change proposal in the model, go in the mystic quest to reach a model that will fit it all including these new cases with an elegant simple solution, or accommodate special cases on the side until it grows too big or just percolate too fast in the main part to let it be sustainable.
Basically we've taken the "mystic quest" route, but we now have a pretty damn good data model
What's more profitable, optimizing for inference time or optimizing to increase inference time by increasing token count?
I cannot remember who it was but there was an author who was traveling with their dog. They noticed that their dog would always pee on various tree to mark them as their territory. On their travels they ended up need some giant Red wood trees and figured, "I want to give my dog the ultimate claim of territory."
So he took his dog up to the Red wood tree and it did nothing, instead the dog wandered over to a smaller sapling and peed on that instead. The problem was the Red wood was so big and alien to the dog, it didn't recognize it as a tree.
I do wonder how many things are like that in our universe, that even if we could see them, we just wouldn't be able to understand it because it just goes beyond what we are capable of understanding. We think we have a grasp of the universe and use models to codify it but that is no guarantee that we can truly 'get it'.
Could higher level AI code be like that, would we know when we see it?
It doesn't look like we are that bright, at least collectively. And if they are individual which are really above everyone else on that matter and the rest, like maybe you but definitely not me, then their individual power seems to be unable to move us all away from our collective ill habits.
Maybe for simple one-person projects. We've long since developed methods and models to allow us to make things bigger than ourselves. Linux, SAP, etc. These software projects are not held in the mind of a single developer. But we use structure, rules, and other tools so that the pieces still fit together.
I do worry what that will mean for projects such as Linux though. Not that I think it will die or anything, but rather that it will become so fragmented that forward movement ceases.
This is the single reason why my experience with agentic development honestly kind of sucks, and wastes so much of my time.
The simplest prompt can result in the most verbose garbage ever produced, and scope-creep nobody's every seen before.
AI has a huge cognitive load problem right now. It's no wonder why so many devs say they're completely exhausted after a few hours, and not in ways they were before they picked up agentic dev.
It's the infinite AI monkeys at a computer keyboard phenomenon.
Or the car on the highway that bumps left and right on the guardrails until, eventually, it arrives at its destination and nearly everybody is amazed at that great success.
The AI kool-aid drinkers are going to answer: "but that's how human code too".
And I'm really not sure about that.
That isn't to say software is perfectly built, but it's usually pragmatically built to balance costs of development and correctness - well chosen abstractions let us push up both qualities at once.
So: better modularity.
https://blog.metaobject.com/2019/02/why-architecture-oriente...
What happens if we take the most abstract libraries in any given field - and:
1. Bound to the llm to only use those as building blocks. Does it affect his reasoning ? Will it think more abstractly ?
2. Train the llm on those, so maybe it will get a feel for abstraction ?