131–140 of 142 posts
Earlier quoted context omitted.
Why have such a rule if at any moment of time the LLM could update the readme ad hoc? Btw, your ingested readmes will affect your LLM's code generation and I made the observation that more often than not it is better to exclude the readmes from the context window.
No LLM will by default touch a README.md They will when you run /init, but after that they won't look at it unless directed to do so.
Earlier quoted context omitted.
> Regarding the memory of reasoning from LLMs, I think the issue is that even if you can solve it in the future, you already have code for which you've lost the artifacts associated with the original generation. Overall I find there's a lot of talks (especially in the mainstream media) about AI "always learning" when they don't actually learn new anything until a new model is released. But this already exists! At wor…
To make sure I understand your position: > But there are plenty of instances where I work with code that has a bus factor of 0. Do you think this is a problem? As per my other replies, if all of these instances are in completely unimportant projects, then I could see you answering "no" (but I'd be concerned if you're spending a lot of time on unimportant things). If they are important, isn't the fact that knowledge a…
Earlier quoted context omitted.
That’s not even a very large code base. My experience is definitely that anything with more than 100K-loc really makes the LLMs struggle.
there is more to it than that. it's about modularization as well. I run LLMs against a 500k LoC poker engine and they do well because the engine is modularized into many small parts with a focus on good naming schemes and DRY. If it doesn't require a lot of context for an LLM to figure out how to direct effort then the codebase size is irrelevant -- what becomes relevant in those scenarios is module size and the amou…
> The LLM codebase 'navigation' becomes near-free with good naming and structure
I have not found this to be true. They seem to break badly if you have a lot of files with similar-ish names even if they're descriptive.
The article throws out a lot of potential issues with AI generated code, but doesn't stop for a moment to consider if solutions currently exist or might exist to these problems. - Before LLMs, provided that your team did some of their due diligence, you could always expect to have some help when tackling new code-bases. Has the author never worked on legacy code before? - (oh, and it has forgotten everything about th…
> Why does it require 100% accuracy 100% of the time? I've said this before, but I'd say it again: anti-AI people, instead of AI users, are usually those who expect AI to be magical panacea. The vibe reminds me of some people who are against static typing because "it can't catch logical error anyway."
The only code you do not have to maintain is code that is fully perfect (100% accurate, 100% of the time). Bus factor zero is a problem for code that needs to be maintained. If AI is short of the 100%, then it is generating code that needs to be maintained. Ergo, a bus factor zero will be a problem for AI generated code (until such time as that code is perfect).
Earlier quoted context omitted.
As the cost of AI-generated code approaches zero (both in time and money), I see nothing wrong with letting the AI agent spin up a dev environment and take its best shot. If it can prove with rigorous testing that the new code works is at least as reliable as the old code, and is written better, then it's a win/win. If not, delete that agent and move on. On the other hand, if the agent is just as capable of fixing bu…
Will the cost of AI-generated code approach zero? I thought the hardware and electricity needed to power and train the models and infer was huge and only growing. Today the free and plus plans might be only $20/month, once moats are built I assume prices will skyrocket a order of magnitude or few higher.
Absolutely not.
In the short term it will, while OpenAI/Anthropic/Anysphere destroy software development as a career. But they're just running the Uber playbook - right now they're giving away VC money by funding the datacenters that're training and running the LLMs. As soon as they've put enough developers out of jobs and ensured there's no new pipeline of developers capable of writing code and building platforms without AI assistance, they will stop burning VC cash and start charging at rates that not only break even but also return the 100x the investors demand.
The flaw in this reasoning is AI can also help you understand code much more quickly than we could before. We are now in fractional bus factor territory.
Earlier quoted context omitted.
To make sure I understand your position: > But there are plenty of instances where I work with code that has a bus factor of 0. Do you think this is a problem? As per my other replies, if all of these instances are in completely unimportant projects, then I could see you answering "no" (but I'd be concerned if you're spending a lot of time on unimportant things). If they are important, isn't the fact that knowledge a…
I do think this is a problem. But the article goes one step further than claiming it's a problem - it claims that a bus factor of 0, and by extension, vibe coding, is "fundamentally flawed". I don't think that a bus factor of 0 is indicative of a "fundamental flaw".
1. If a process necessarily results in bus factors of zero, that process is flawed.
2. The nature of vibe coding is such that it always produces code with a bus factor of zero (i.e. this is a "fundamental" fact of vibe coding).
I definitely agree with the first point, and I think agree with the second as well (at least if "vibe coding" carries its original implication that you don't even look at/care about the code produced by the LLM).
Did you have a different interpretation? Or do you disagree with one of these points?
If you're using llms to shit out large swathes of unreviewed code you're doing it wrong and your project is indeed doomed to become unmaintainable the minute it goes down a wrong path architecturally, or you get a bug with complex causes or whatever. Where llms excel is in situations like: * I have that I want to apply to - bam, half a days work done in 2 minutes. * I want to set up test data and the bones of unit te…
I agree with your comment but I wanted to share something that gave me a good chuckle the other day. I had asked claude to write some unit tests that, after reviewing, were sound and actually uncovered a bug in the code-under-test that I had written. When I pointed this out, claude had decided that to make the unit test pass, it would not patch the bug but it would simply not exercise the failing unit test LOL! Good…