I had a chance to ask Rich about the subject at the latest Conj. I admit, my question was too vague, I asked him: "what are your thoughts on how AI is reshaping our industry?", to which he vaguely replied that he's "not participating in this [experiment]", he admitted that he hasn't explored LLMs too deeply and he simply thinks they are not good, not to mention tons of other concerns - moral, economic, etc. I said, "well, I wish I had the luxury to choose, but many of us have no choice here, we're simply forced to use the darn thing..."
It is very difficult to disagree with anyone of the caliber such as this man, but I wanted to steer the conversation away from the generative aspect of LLMs and focus on the consumption side, because frankly, these "tools", and I think even though I might agree with Rich that LLMs by themselves are not tools, the harness I built to work with them definitely is one. I think there's an immense value there, way before you even start talking about code-generation, or code at all. I think I have failed to explain my points, because a talk we both wanted to see was about to start.
I think I get where you're coming from. Both the immense respect for Rich Hickey and the disagreement with him. I hopefully don't have to say much for the respect part - he has repeatedly changed how I think about my craft for the better. As I've mentored others, I've often pointed them to talks of his that were relevant to what they were missing. And that's all without using Clojure. But I definitely use ideas from Clojure in other languages where it fits.
On the LLM front, it's been a fascinating journey for me. I started with the private beta of Github Copilot. I was an instant convert for the "better code completion" aspect. But my first attempts with coding agents were rough enough that I stayed away.
I'm now retired, but I want to understand how things are evolving. So two months ago I volunteered to automate a cartography data pipeline for an educator. I have a background in all aspects of the project. It's not simple - there are several data sources from governmental and corporate sources that need to be integrated together, and most of them are updated every few minutes. New maps need to be available within ~5 minutes of a data source updating. All this with many GB of data and running on a low powered machine, taking less than 2GB of RAM.
I bought some DeepSeek tokens and went to work. A few weeks later a mentee went to work at OpenAI and gave me a "friends and family" Pro level plan. I'm converted, and I absolutely see it as a tool in the sense Rich describes. I even question whether any "software engineers" using it, but not as a tool, are doing it right (I'd love to be educated if I'm wrong!).
I'm still learning, but that's part of the disagreement I have with Rich's take. He mentioned feedback. I often watch the "reasoning" process the agent goes through to see the approach it's taking. It's not at all unusual for me to steer it when I see it going in a direction I don't like. I've also found an incredibly powerful pattern where I can explore the approach I want to take for a part of the system with the agent. I have it create prototypes with different strategies (streaming vs. in-memory, different data structures, relying on various libraries, etc.) and then I have it characterize trade-offs between the prototypes (performance, memory usage, conceptual simplicity, code simplicity, etc.). This allows me to make informed decisions about which approaches to pursue further, and my decades of experience in software engineering constantly go to good use here.
It's also given me the time to go far deeper into things I never could have justified. Of course the project has 100% code coverage and branch coverage. It also has hundreds of property-based tests. And thousands of Lean proofs of the behavior of the algorithms, along with conformance tests that the code and the Lean adaptation of that code behave the same way. And lots of TLA+ verification of the overall flow of the system. None of that proves there are no bugs or that this is the right system, that's all on me. A month in I would have said I was fairly happy with the quality. Now I'm proud of the quality.
As I've gone through this process, I've dug into the code for patterns I don't like, and had the agent clean them up, all the while distilling guidance. I've had a lot of luck with that guidance being followed once I figured out the right place to put it and to reference it. I've spent entire days doing nothing but giving prompts to do specific refactoring. The beauty is that large refactorings don't involve the same boredom interrupted by anxiety they used to for me.
English prose (documentation, comments in the code, etc.) is what I've been the least happy with. An hour ago I had the idea to give it ~1,000 lines of my HN comments and ask it to characterize the style and tone of the technical parts. Then I told it to turn that into guidance. Then I told it to rephrase that same guidance in a way that follows the guidance. I would never mistake the result as my own, but it's much, much better than what it was producing before. While I've been writing this comment, it's been applying it to all prose in the project.
This very much feels like a tool that is letting me shape the project (and shape the tool itself). But it's letting me do it at a higher level. It handles the code so I can fully focus on the architecture, algorithms, and quality. This alone makes me think that the best simple guidance for quality results is dozens of prompts per day, not a handful (when a day is 100% focused on development). When you can't think of dozens of prompts, think and explore more (the agent can help with that!). That does require you know what quality is and how that can be achieved.
To reconcile this with what Rich is saying. I suppose he's right that it's not a tool for writing code. But it very much feels like a tool I'm wielding to do software engineering at a far more powerful level than I could have done without it. The resulting project has "me" everywhere in it. The people who know my work the best would look at this project and know that it's mine. Perhaps not the code, but the algorithms, the data flow, the approach to documentation and testing, etc.
For anyone curious, the project is getting close to 200K lines. About 25% of that is the code that is the data pipeline. About 25% is documentation. About 50% is testing and verification. One reason this is possible is that I'm working alone and have full control over the process (what I spend before it became free, how it's built, what my process is, and even the product definition within the constraints of what's valuable to the intended user). All told, it has been about 6 weeks of full time work worth of my time.
The next experiment... a web front-end to this system for the general public. This is not at all in my wheelhouse, so it should be interesting to see how much my blind spots cost me.
> I suppose he's right that it's not a tool for writing code.
I think that's exactly what he means.
> But it very much feels like a tool I'm wielding to do software engineering at a far more powerful level than I could have done without it.
Ya, I'm not sure if he heeds a warning that AI is slowly moving to automate all that as well. Only 2 years ago it couldn't automate writing all of the code for example, it's possible in 2 years it has automated most of that higher level as well, and therefore software making becomes same as ordering a sandwich, just tell it the app you want and you get it. Or if he's just trying to make the reader realize they've given up coding and are losing that skill (or if new to coding are not learning it by using AI), and for better or worse is on the reader to decide.
Hello rented_mule! I’m also working on a cartography pipeline using public data sources, I’d love to hear more and to share ideas, my email is my HN username at duck dot com
It reads to me that your main focus is still on the composition side - the generative aspect of LLMs, which is where Rich's skepticism leans. I'm currently building massive ETL pipelines that involve sifting through tons of heterogeneous types of data. That's the consumption side I'm talking about. Being able to extract semantic value from dissimilar sources and deductively and inductively draw conclusions about all sorts of things - the shape of data, behaviors, payloads, endpoint constraints, etc. - is enormously useful. Before LLMs, painstakingly analyzing every corner case was awfully time-consuming yet unavoidable. It's like looking for a bunch of needles in a random-sized pack of haystacks where the shape, color, density, or magnitude of each needle and haystack can't be easily predicted. It's like using human labor vs. machines to collect, I dunno, cotton. It almost makes no sense not to use machines, except maybe for specific cases where the type of cotton is too fragile or expensive. Of course, machines can miss, but in general, humans would be still sloppier, just because humans do get tired, get hungry, get distracted, etc.
That is the side of LLMs that often gets ignored, with the main focus being on the composition, which still raises some questions and skepticism, and for good reasons too. But I can absolutely vouch for LLMs being enormously useful on the other side.
> it's very difficult to disagree with anyone of the caliber of this man
Did you seriously write this with a straight face?
Or really? I can ask you the same question about your very comment. How often do you travel to a conference that's been held for almost 20 years, face the person founded the entire "ethos" - the whole reason for that conference, stand in a circle of people highly respecting that person and try to debate and argue? I guess, judging by your comment, I'd say you just might. Well, I couldn't do it so easily.
I agree with how you handled the situation and this comment.
Though, it makes me think of the quote "Science advances one funeral at a time" - Max Planck
Afaik, Planck didn't use the exact wording (someone simplified it into that, but it's not the literal quote), and it would be huffy of me to even categorize my brief conversation with Rich in that way. Who knows, if I had more time, I could maybe convince him to try to be less skeptical about LLMs. He's not a dogmatist; he's very practical, and things explained pragmatically can change his stance about anything.
I got the impression that comment was less about confronting Hickey to his face, and more about hero worship in general.
When you place someone on a pedestal, you make it hard to evaluate them critically. The remaining Clojure community has a problem with it.
Yes. This is about hero worship.
The clojure community (what remains of it, as you say) is extremely guilty of this. They love repeating everything he says like it's the word of god. Try to explain the benefits of static typing to them and they just drop into an infinite loop of quoting Hickey.
I can't believe you're doubling down on your senseless take even after my explanation and downvotes of your initial comment. Congratulations, you just made everyone reading this exchange a little bit more stupid.
I don't get it, are you unaware of the basic norms of actual human communication or something? Please explain to me how you envision arguing with someone, anyone, in a place and time like that. Or are you suggesting I should have been heckling him about static typing right there, on the spot, in front of other people? Otherwise, I suppose I'm worshiping and I should admit I'm in a cult?
> more about hero worship in general.
Oh, grow the F up. I can't believe I have to explain the basic tenets of human communication here - stuff that children learn before they turn eight. Once again, I wasn't chatting with the guy at a random bus stop, at an airport, or on my personal podcast - we were at a Clojure conference, surrounded by people who flew all the way to Charlotte from places like Sydney and São Paulo. Of course, basic human decency dictates letting him talk instead of constantly interrupting him and vigorously arguing. Not only out of respect for the person, but for other people too. There's a time and a place - you need to know when to "evaluate critically" and when to STFU. It has nothing to do with the so-called "worshiping" you're implying.
My comment is not blind hero worship without actually addressing any of the arguments made by the person in question.
Hickey's article is terrible. He's arguing semantics and then patting himself on the back. Anyone who can't see that is willfully blind.
This also isn't the first time Hickey engenders this kind of blind hero worship. He has been spouting nonsense about Haskell for years, for example. Clojurists don't understand enough of it to understand how silly the things are that he's saying, but they sure as hell will repeat it everywhere.
> Clojurists don't understand enough of it
Au contraire. Many Lispers are well-versed in Haskell and different kinds of type systems. Coalton, core.typed, Typed Racket, Malli - these don't exist just for the sake of it. And many constantly disagree with Rich, with Halloway and other clojure.core members about all sorts of things. The "Maybe Not" talk got a lot of pushback, and most of it came from clojurists. The majority of them are pragmatists - they use whatever makes sense. In many cases, the specific dynamism of Lisp fits much better than the rigidity of Haskell-like type systems. They use static types where the invariants are stable and dynamic data where the shape is open or changes often. Many work that way, often by validating with Malli at the edges and keeping the core loose. It appears to me that you're blindly "worshiping" whatever or whomever. I gave you the exact example where I was [respectfully] disagreeing with Rich, and you decided to turn it inside-out, just to make it fit your own, totally imagined narrative - now who's blind here?