Rich Hickey on AI: Why "Thanks, AI" is a Warning, Not a Celebration

TL;DR

Rich Hickey, the creator of Clojure, has expressed skepticism about the role of Artificial Intelligence in software development, arguing that it can bypass the critical phase of struggle and understanding that is necessary for building better software. He warns that relying on AI can lead to junior developers becoming 'framework assemblers' rather than engineers. This perspective has sparked a necessary debate in the industry about the use of AI in software development.

In the world of software engineering, few voices command as much respect as Rich Hickey, the creator of Clojure. Known for his profound talks like Simple Made Easy and the philosophy of "Hammock Driven Development," Hickey has always championed deep, deliberate thought over furious typing. Recently, discussions around his perspective on Artificial Intelligence—often summarized or captioned as "Thanks AI"—have sparked a necessary debate in our industry.

As a Generative AI developer and Shopify expert who uses these tools daily, I found Hickey's skepticism to be a grounding counterweight to the current hype cycle. It forces us to ask: Are we using AI to build better software, or just to write more code faster?

The Conflict: Hammock Time vs. Instant Generation

Hickey's philosophy rests on the idea that the hardest part of software isn't typing the syntax; it's understanding the problem. "Hammock Driven Development" posits that you should spend significant time away from the keyboard, closing your eyes and thinking through the system's state, transitions, and failures before you write a single line.

Generative AI, by contrast, is an engine of instant gratification. You type a prompt, and you get a solution. The danger Hickey identifies is that this bypasses the critical phase of struggle. When we let an LLM solve the logic puzzle for us, we rob ourselves of the mental context required to debug it when it inevitably breaks (or simply hallucinates) six months down the line.

The Junior Developer Trap

One of the most concerning points raised in these discussions is the impact on junior engineers. Experience is often the sum of our failures and the hours we spent banging our heads against a wall until a concept clicked.

If a junior developer relies on AI to handle every difficult algorithm or architectural decision, they risk becoming what some call "framework assemblers" rather than engineers. They might produce working apps, but they lack the intuition that tells you why a certain database schema will fail at scale. As Hickey suggests, the path to mastery requires traversing the landscape yourself, not taking a helicopter ride to the destination.

The Commoditization of Syntax

However, there is a flip side. If AI is excellent at repetitive, boilerplate code, perhaps that is exactly what we should offload.

In my work with Shopify and Next.js, there is a lot of "plumbing"—setting up API routes, configuring Tailwind classes, or writing standard GraphQL mutations. Letting AI handle this drudgery is a net positive. It clears the mental clutter, allowing senior engineers to focus on the exact thing Hickey prizes: system design.

The key is the distinction between implementation and intent. AI can handle the implementation, but the human must provide the rigorous intent. If you don't know what good code looks like, you can't verify if the AI did a good job.

My Take: The "Editor" Mindset

Rich Hickey's warning is valid: we cannot abdicate our responsibility to think. But we also shouldn't ignore the most powerful lever for productivity we've seen in decades.

The solution is to shift our mindset from "Writer" to "Editor."

1. Design First: Do the Hammock time. Sketch the architecture. Define the data models. Do this without AI.
2. Generate Second: Use AI to fill in the implementation details based on your rigorous design.
3. Audit Ruthlessly: treat AI-generated code with more suspicion than human-written code. Read every line.

Frequently Asked Questions

What is Rich Hickey's perspective on AI in software development?

Rich Hickey believes that AI can be a hindrance to software development if it is used as a crutch, bypassing the critical phase of struggle and understanding that is necessary for building better software. He argues that AI can lead to a lack of intuition and deep understanding of the problem, resulting in developers who are merely 'framework assemblers' rather than engineers. This perspective is reflected in his philosophy of 'Hammock Driven Development'.

How does Rich Hickey's 'Hammock Driven Development' relate to AI?

Rich Hickey's 'Hammock Driven Development' is a philosophy that emphasizes the importance of deep, deliberate thought in software development. It involves spending significant time away from the keyboard, thinking through the system's state, transitions, and failures before writing a single line of code. In contrast, AI-powered development tools can provide instant solutions, bypassing this critical phase of struggle and understanding.

What are the implications of Rich Hickey AI skepticism for junior developers?

According to Rich Hickey, the reliance on AI can have negative implications for junior developers, as it can prevent them from developing the intuition and deep understanding of software development that comes from struggling with difficult problems. Junior developers who rely on AI may become proficient in assembling frameworks, but lack the skills and knowledge to debug and maintain complex systems. This can limit their career growth and potential as software engineers.

You Might Also Like

Related posts about AI & Automation: Claude Opus 4.6: 1M Context Window Goes GA — What Developers Need to Know, AI SEO Tools for Shopify: What Actually Works in 2026, Claude Code Remote Control: Code from Your Phone Now Possible

Conclusion

"Thanks, AI" shouldn't be a sarcastic dismissal of the technology, nor a blind acceptance of it. It should be a reminder that tools serve the craft, not the other way around. As we rush to integrate Generative AI into our workflows, let's ensure we aren't outsourcing the one thing that makes us valuable: our ability to reason clearly about complex systems.