Slow Programming: An Exit from "Hotel LLM" Hell?

This post came about following my Bluesky post and a response video from Kevin Powell. My thanks to him.

----- 

"We are all just prisoners here

Of our own device"

 - Hotel California by The Eagles

In this post, I want to make the case for slow programming.¹ This is a reflective approach that prioritises coding as craft. I view it as a way to overcome the walled garden of LLMs, which can seduce us from expanding our knowledge and skills. Before getting into the details, let's look at some recent examples where generative AI's contracting horizon has had a negative impact on businesses. 

Tailwind is perhaps the premier CSS framework provider. Their business model is to upsell developers visiting their documentation pages to TailwindPlus, a paid-for library of pre-built UI components. In January 2026, they had to lay off 75% (3 people of 4) of their engineering team, leaving only the three co-owners and one part-time member still employed. Adam Wathan discussed (post, podcast) how this was due to generative AI eating their profits. When developers rely on LLMs to help write their code, reading documentation is no longer critical to workflow and so a business model that relies on developers' curiosity and learning falls by the wayside. To put that in concrete numbers, visits to Tailwind's docs are down about 40%, with an associated drop of ~80% in revenue.

The same issue can be seen in other sectors. AI summaries in search have meant a catastrophic drop in visits (/sales) for businesses (e.g. recipe writers) reliant on search referrals to make money. Newspapers and publishers have been dealing with similar issues for years. To stay afloat, their solution has been to either erect a paywall, which The New York Times has done very successfully, or partner with an LLM provider, see: Financial Times / OpenAI, The Guardian / OpenAI, Taylor & Francis / Microsoft.⁴

Such partnerships seem unlikely for small software companies or indeed anyone creating content for a technical audience. Are OpenAI likely to pay for the content from your favourite educator on YouTube? Will Microsoft pay developers and software engineers for their documentation contributions on GitHub? I think not!

Today LLMs are the default route to content access. The walled garden of the LLM means users never leave the chat window (or a search page), even if they feel they want to. Everything -- or at least everything they think -- they want is right there, right in front of them. So, what is to be done? I don't claim to have the answers but I can offer some provocations.

As a former university professor, it may not surprise you to hear me say that non-engagement with content is an educational issue. Broadly speaking, we need to develop working environments where continuous professional development (CPD) is seen as core to building and maintaining a highly-skilled workforce. In the case of developers, we need to rethink what it is to be an expert and how expertise relates to LLM use. Employers should create working conditions that encourage developers to move beyond the seduction of the LLM. To aid this process, we need to be clear about what motivates people to improve their knowledge. Matthew B. Crawford, a bike mechanic and philosopher, in his book Shop Class as Soulcraft argues that motivation is deeply rooted in the relationship between thinking and doing.² LLMs change the nature of knowledge work and thus the relationship between thinking and software development. Developers have been pretty vocal about this change. Writing in The Register, software engineer Alain Dekker encourages us to "stay in control and think for yourself", noting that his experiences with AI programming have been "mixed". Edd Gent, writing in the MIT Technology Review (paywalled), finds that "initial enthusiasm is waning", and although productivity may be increasing (10% is suggested), there have been associated "sharp declines in several measures of code quality". Furthermore, many coders like to code (shocker!) and one suggested to Gent that "[i]t’s just not fun sitting there with my work being done for me [by AI]". 

What is clear from these comments is that the seduction of the LLM can be broken but only if supports are put in place to make it a reality. Taking a step back to look at the fundamentals, we can say that developers want to: 

• Value their work
• Think critically
• Work creatively 
• Solve problems in a way that produces excellent code.  

Put simply, they want to engage in "meaningful work".³ The question is does their working environment -- both the tools they use, including LLMs, and the place where they work -- support them to do so?

What do LLM providers need to do to help developers (a) break out of the walled garden and (b) engage in meaningful work? I argue that developers must engage in slow programming. I'm under no illusions that this seems idealistic but nevertheless it is critical that we explore it. One very simple suggestion is to meet people where they're at. A starting point for slow programming are the links provided by LLMs to the resources they use to generate their outputs. In slow programming, these are a gateway out of the walled garden and into proven resources that help build knowledge and skills. A developer would take the time to explore the links provided and use this new knowledge (plus their own searching) to interrogate the LLM output. This should be seen by employers as second nature (and also to ensure quality control). Although, such a practice is often viewed as being in tension with the need for efficiency, I would argue that slow programming encourages developers to take a critical stance as an orientation towards continuous improvement of their own capabilities. The ability for LLMs, not only to prompt users to explore the suggested resources (in the Tailwind case, their documentation) in detail, but also to understand when such prompts need to happen. This would make LLMs a truly supportive learning tool, parking for a moment the very significant issues surrounding the ethics of knowledge production.

On the other hand, envisioning such a future again leaves power in the hands of the LLM providers. Returning to the Tailwind figures, visits to their documentation are down 40%. But what about the other 60%? What encouraged them to visit Tailwind? Could they be slow programmers? What would an alternative future look like when the motivation is to increase their numbers? We could imagine LLM over-reliance being subverted by building communities of slow programmers who advocate for tools that support the craft of coding. 

This is no doubt a challenge. Computer scientists, albeit with various levels of success, have engaged with such "value-drive" visions before. I am reminded of Niklaus Wirth's classic paper, "A Plea for Lean Software" (paywalled / alternative). In making the case for developing software in a lean manner, so that that "systems can be built with substantially fewer resources in less time than usual", he too went against the prevailing practices of the day. We can and must do the same.  

Addressing new ways of mediating the relationship between thinking and software development in the age of LLMs means thinking big. Following in Wirth's illustrious footsteps is something we can be proud of. 

[-- This post is linked on my Mastodon and Bluesky socials. You can follow your preferred community's discussions there. --]

Footnotes

¹ Similar to, and inspired by, the Slow Food movement. 
² For those interested in the broader area, see research on situated cognition. 
³ As distinct from what David Graeber termed Bullshit Jobs (book).

⁴ Others are suing, see: Reddit / Anthropic; [list].