From Jeff Atwood's latest, thoughtful blog posts (on the flipside from dhh) > But what happens to the commons when everyone is privately whispering to LLMs? > Where exactly will the LLMs get their next set of training data from, if we don't build for and protect the commons together? How will we continue to share knowledge – and love – with each other? https://blog.codinghorror.com/you-cant-vibe-code-love/ > (remark: on getting help while studying alone/isolated) You know who did help me? Random strangers on Stack Overflow. People who had nothing to gain from helping me other than just trying to help someone in need. > An LLM would have done exactly what I wanted back then. But would it have given me what I needed? > > At the time, I needed to know somebody cared enough to help me. https://blog.codinghorror.com/if-we-do-not-stop-to-help-each-other-what-do-we-become/
https://www.youtube.com/watch?v=k2qls2LiBRc The Paradox of Why AI Code Is Failing Us - 3 Pillars An interesting watch.
Yeah, the context window is a problem. To narrow to Clojure - at the 10 minute mark, they talk about context windows. LLMs can't determine return types, hidden cross-links etc... Two thoughts: • Clojure doesn't have static typing (not without spec or, partially, the new :keys!). Is it naturally worse than, say, Haskell? • As they mention - RAG partially fixes this. Do harnesses like claude code intuit return values and parameters for Clojure?
A live REPL the bot can talk to gives a more immediate and "real" intuition of whether something will work than reading a namespace. Claude does hit the REPL if it is told about it. (Or, it can run tests and make sure something "works").
The problem is the growth. Humans cannot grow a codebase at such insane rates. LLMs give you insane unbounded growth, they add, they don't remove.
> they add, they don't remove. Can you elaborate? Feels like you mean something other than just what the words mean.
context window is a problemIt was a problem before LLMs too. Nobody can keep codebases for entire systems in their heads. That's why it's important to design things right - modular components with encapsulated implementation and strict boundaries (shit that Polylith folks been preaching for years). For LLMs specifically, Specs - OpenSpec, Spec Kit, Kiro, BMAD, Tessl, GSD, etc., and handoffs make things manageable.
> Humans cannot grow a codebase at such insane rates. Well, humans couldn't assemble cars too fast before the conveyor belts either. We're now in the industrial age of making software. Expect things to get very weird and very wild. However, when the car breaks, you don't take it back to the factory - you go to a mechanic. Same for a watch, etc. So, individual expert programmers still will be needed. I don't think the price of fixing still useful but broken software would ever exceed the price of the rewrite.
I don't agree with the premise that AI doesn't remove. It won't do it casually but if there is a genuine simplification to make and you ask for it, AI will certainly do that refactor for you and give you net negative loc in the process. You can also give it design principles to follow from the outset that keeps the output shorter than if you hadn't given any specific guidance.
> However, when the car breaks, you don't take it back to the factory - you go to a mechanic. Same for a watch, etc. So, individual expert programmers still will be needed. I don't think the price of fixing still useful but broken software would ever exceed the price of the rewrite. I stumbled upon the term "disposable software" recently and it immediately snapped into my mental model as the term I was looking for. And with regards to cars and electronics, they have been going the way of being disposable as well - the new cars are far less hackable than they used to be 2-3 decades ago.