Live data from Hacker News

The Tower Keeps Rising

lucumr.pocoo.org

141–150 of 280 posts

Re: The Tower Keeps Rising

#141

Earlier quoted context omitted.

While I don't disagree, memory certainly was more of a restrictions on us humans than it is on llms. Therefore, the answer may not be as obvious as it seems. We build abstractions to reduce (memory) footprint of features, right?

Humans built codebases many millions of lines long, well before LLMs existed. Human memory has not been a restriction on us in a long time. Look at all the libraries full of books we've built. It's useful for more than mere training sets.

I think the trick here is plural; I guarantee no single human knows all 1 million lines. Note this is different than knowing how to orient yourself in a million line codebase quickly.

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.

Re: The Tower Keeps Rising

#145
Is communication at risk? Perhaps more demanding of one's attention, more insistent in its attempt at inclusion and contribution?

Large Language Models are the most powerful communication tools to have ever existed - probably behind the written and spoken word and marginally behind the internet, maybe more important than phones and texting.

With understanding now on tap in this new form of infrastructure, the tower (codebase) and our coordination within it are both very customizable - up, down, sideways - per the will of the team and maintainers.

The sample size of your architectural taste, intuition, or expertise at abstraction may never be large enough for a LLM to match it. But if you want it to, it too can keep getting better and closer at this as it seeks alignment with your acceptance.

Once your tower is built, what's next?

Re: The Tower Keeps Rising

#146
post #141

Earlier quoted context omitted.

Humans built codebases many millions of lines long, well before LLMs existed. Human memory has not been a restriction on us in a long time. Look at all the libraries full of books we've built. It's useful for more than mere training sets.

I think the trick here is plural; I guarantee no single human knows all 1 million lines. Note this is different than knowing how to orient yourself in a million line codebase quickly. 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.

Note this is different than knowing how to orient yourself in a million line codebase quickly.

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.

Re: The Tower Keeps Rising

#147
post #37
post #6

I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear. I feel like that gives an even more literal tower-rising metaphor, and that's what it feels like people using agents naively (and software engineers of lower skill or earlier-career), end up violating. Agents are getting better at folding things into themselves, especially if you direct them to... but unfor…

Do you believe "micro services" can make a comeback? local daemons with an exposed API, each daemon vibe coded?

Not microservices, but something more akin to FaaS into a mesh, with a backing domain logic library.

Re: The Tower Keeps Rising

#148
I increasingly feel that the reason vibe coding specifically prohibits reading the generated code is that it's impossible to forget the horror that lurks in these python files.

The code will do what you asked for in a broad sense but wherever choices arise on how to accomplish the goal it'll have made those choices incoherently.

There'll be strange validations applied inconsistently to some user inputs but not others. Data will be repeatedly sorted or converted to lower case for no reason at 3 stages. The column labels are all hard coded strings even though they are the first row of the input CSV. It'll create global functions taking data classes half the time and classes the other half.

If you look, and if you think you might one day need to update and maintain the code manually, then it's very hard to resist fixing this sort of thing, but fixing this sort of thing cancels a lot of the time saving out.

Re: The Tower Keeps Rising

#149

Earlier quoted context omitted.

Do you have specifics? It would be interesting to see what kind of improvements are possible.

I just see in my usage that I can release tens of features a day, whereas I'd be able to release one or two a day usually. I don't know if it's 100x, but it's definitely more than 10x. I've written up my process here: https://www.stavros.io/posts/how-i-write-software-with-llms/ The biggest thing to get right is to let the LLMs do what they're great at (code implementation from very detailed specs, and code review), a…

Thanks for the detailed explanation of your process, I think I'll try it out.

Re: The Tower Keeps Rising

#150
post #69
post #27

The core thesis of this essay is reminiscent of the Lisp Curse [1] / Bipolar Lisp Programmer [2]. It's been a few years since I read these, but if I recall the argument there, it was that Lisp makes it so easy to build stuff and scratch exactly your own itch, that there's no real strong push for lisp programmers to come together and collaborate to build non-trivial and general purpose artifacts. And that is why the l…

> compared to languages which demand much more effort to get anything substantial done. It is not clear at all to me that other languages "demand much more effort" for the same end result. It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting ps…

> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp

For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp

If you then optimize for employability, which I assume most developers do (not all, but a large percentage), you might end up with not that many people practicing lisp regularly

Post reply on HN