Clojurians Log v2

yes, humans are lazy by default (using system2 requires much more energy and effort than just going by gut)... so once you see many correct solutions from the LLM, it is easy to fall into this trap

Yup, my anecdotal experience seems to correlate this with narrow-minded "AI will change the future of humanity" type of drinking the AI hype kool-aid

It feels like belief

to make matters worse, there have been some high profile people online who have made the "I trust the AI" a part of their identity and flaming people who don't

but, perhaps that's just a reflection on typical online spaces and personalities... not necessarily about AI

Same kind of behavioral patterns seem emerge around all hot topics, that is true, so this may be more like a feature of humanity 😅

Also, three finns walk into a slack thread… and talk English!

Absolutely. It's named automation blindness. Here's Doctorow's example outside of software: The US TSA routinely fails "red team" attacks where a gun or knife is smuggled into luggage. (But they are really good at detecting water bottles.) It's just how we're wired.

what’s the project that you are referring to?

spec based prompting in general, really

e.g. https://techcommunity.microsoft.com/blog/azuredevcommunityblog/moving-beyond-prompts-a-practical-introduction-to-spec-driven-development/4511012

I've been using writ, and it works alright.

You're right that LLMs can ignore a spec when it feels like it. But Microsoft's article is poor prompting. Better workflow: • tell it to generate a real spec - OpenAPI, clojure.spec, Zod, whatever • review that the spec has in fact the desired shape • now, tell it that the end goal is to generate <thing> while satisfying <spec> at various parts of its pipeline (e.g. rest api, tests, type annotations, etc) That's a deterministic, verifiable goal that cannot generally be cheated. LLMs are very good at perservering towards a specific end condition, using a hard check (the schema validation) as a feedback loop.

That's basically the allium workflow as I understand it.

Would be nicer if the default output for the spec was in edn tho https://github.com/juxt/allium

Honestly, this feels sooooo Waterfall-ish Like, make a "design", make some "guardrails", now tell a programmer (the LLM in this case) to implement what you said while obeying the guardrails...

Inclined to agree somewhat, but that kind of gets back to my observation that llm prompting is retreading the history of system design only to arrive at a buggy, overengineered version of how we use malli/clojure.spec

@mauricio.szabo and it is waterfall 😄, for example Kent Beck defined it as such in his presentation, see https://clojurians.slack.com/archives/C03RZGPG3/p1791108623082899

does it matter whether it's waterfall or not? What matters is the outcome. Software must have a purpose. If you succeed, great. Whether you did it with LLMs or without, agile or waterfall, these are means to an end.

All approaches to process have their own up/downsides, waterfall is by its nature rigid and promotes validation in the end and requires big-design-up-front. With more agile processes you can usually respond better to change. Of course you can get working software done with all processes but I posit that some processes are better than others. Kent's presentation is a good take on this topic, I recommend it.

Yes, and using LLMs shifts the costs in many ways. I don't think we can "waterfall bad" as we used to.

I hope we are smart enough to avoid the pitfalls of waterfall even in the era of LLM's 🙂

with LLM's the waterfall is basically you not the entire company or department 🤔

Using LLM's and agentic development feels like a waterfall project where you are the project manager and responsbile for all requirements. It does feel like re-inventing the wheel and LLM's non-deterministic output mimics waterfall projects with real humans to an extent 😂

YMMV, I'm not saying it is like this everywhere, people did succesfully use waterfall processes.

time will tell all of this. I don't like the framing, that's all. We're anchored to the ways of the past. Let's try and forget what waterfall or agile meant, what using clojure vs java meant, and focus on the goals. Software needs to work (for whatever definition of work per project), be maintainable, amenable to change etc. We use clojure or java, waterfall or agile, TDD, functional core imperative shell... These choices/tools carry properties we can use to efficiently deliver the software's requirements. If tomorrow a coder from the future comes and gives us a USB stick with a new language and methodology that deliver better results, won't we use it? Will we stay an agile clojure TDD developer because they are familiar, easy? LLMs are just another tool (automation if you must). It has a set of properties, and tradeoffs. Evaluate it based on its properties.

I agree that the connotation regarding the term waterfall is mainly negative and as such not very productive framing for discussion nor dialogue. I would still strongly recommend to think this from the process point of view since we are wiser thatn 30 years ago. And FWIW AI is not just a tool (IMO), so we must think it in larger perspective. It may be a disruptor (in many senses) and we don't not know to what extent.

> Can you achieve this level of stability with LLMs? Can I, no. Can someone else, proficient with LLMs, who understands the system, and doesn't just vibe-code one-shot the implementation, yes. LLM usage is not black and white. You can use it to automate the boring parts, once you have complete understanding, if that is what the system being built requires. LLMs are not magic. It allows slop coding a 200k loc implementation of X for a novice. It also allows carefully implementing a well-thought out system, provided you use it responsibly (i.e. with your brain).

Who knows. Everything's happening so fast, we have no time to map the territory. My take is there's an order of importance here, and LLMs are eating up the lower layers, moving upwards. For my work, LLMs were useless 2 years ago. Beginning of this year they became useful and I would let them write the boring parts, reviewing every loc. By the end of this year I'm not writing code, I'm working on things I'd need months to ramp up to be able to tell whether the thing is right or wrong. I still have to gather information, understand the goal and the requirements, deliver the best code I can, then hand it to a domain expert to validate, then iterate. Where we'll be in a year, it's hard to tell.

For me, it does matter if it's waterfall or not. And that's what I don't like about the AI cult (at this point, I can't call it anything else): we already answered these questions in the past. We already decided that lines of code is a poor measurement, that doing "more" is not always desirable (heck, DHH did a book about that, and then "forgot" at his last keynote!), we knew already that waterfall is prone to error because of the "telephone game" effect it has in each step (client asks something that is interpreted by PM, that is interpreted by the analyst, that is interpreted by the programmer LLM, etc... an we knew that in 1970. Also, "code" is not the outcome - we moved (or tried to) away from Waterfall because it didn't deliver what people wanted, developers didn't feel empowered, decision concentration was on the hands of few and it did deliver unreliable/buggy software (besides delivering something different that the client wanted - again, the "telephone game") and I have seen this same mistaken being repeated (and even people calling LLMs "agile" because they are delivering "faster" and with "slower cycles" which was never only the point of agile)

Nowadays, because of "AI-Assisted bugfixes" I have seen (at my current job, btw) people not delivering the correct fix to a bug - which is crazy to me, because when a LLM says "the bug is in this function" I see very few pushbacks (usually people deliver the fix "just in case, it's easy anyway and Claude will write it to me") and then... sometimes, things get worse

For me, it does matter if it's waterfall or not

very interesting, I'll need a little time to process the idea, but on its face seems like a useful comparison and the movie looks cool, added to my watchlist, thanks!

I find it peculiar that LLMs are the closest thing to "the deal with the devil" that we have experienced so far. Or fel powers from Warcraft universe. Insanely powerful, yes, but you pay for it with your soul. 😈

It is idea from a movie, where Jarek Nohavica is in alcohol rehab. He says there, that different people have different situation, when they become alcoholics. Drinking alcohol = walking uphill. Some people can drink all their life, and nothing bad happens. Their hill is very tall, so they never become alcoholics. Other people's hills are not that high. They can become alcoholics after 10, 5 or even 2 years. Once you are on the top of the hill, things start going downhill for you. Jarek Nohavica who said this analogy is a famous Czech musician. His best friend, who played with him, became an alcoholic. He started forgetting words during concerts, etc. -- I think @dj942 is trying to make a point, that a developer can go uphill, and add features and code, and it works well, and he is productive. But everyone has some place, when the code becomes unmaintainable. Then, everything goes downhill. It might depend on how much reviews you do, what model you use, what language, framework, how big steps you do. Some people might never reach the top of the hill. Some people reach it very fast.

I've hit that hill many times with my projects esp with the older models. The newer models seem to be able to break through that hill a lot better. I've not hit a hill at all with Sova though, codebase is massive and I'm still landing features as fast as I can think of them. I'd like to think that it's because of the spec system I've made, but there's a lot of things in play so hard to pinpoint exactly why this project is so easy to keep evolving.

and for me it wasn't really about the older projects being completely unmaintainable, I just hit get to a point where I start getting friction that makes landing new things a lot more difficult which is probably what we've all experienced.

but that hill thing is definitely a phenomenon I've relayed in my own words many times to different people