Coincidentally, “Chat Box” experiences are popular amongst software engineers. This is because they don’t need to build intuitive, usable, UI. It can be abdicated the LLM under cover of ‘articulate it in words’ and when it doesn't work ‘you’re dumb if you can’t write words’ because you used terms, language, and phrasing that doesn’t steer the magic text box in the way the user hoped. Developers build their beautiful cathedral of magic behind that veil, and avoid having to consider how easy or difficult it is to use.

This is similar to what I hate about calling a support centre — opaque processes & systems that have no clear path through them, and where I am left to coerce someone to perform an action on my behalf that should be a trivial click or tap. Instead I’m left with tools that try to be unnecessarily familiar & friendly. The call center, and most certainly not the LLM, aren’t actually happy to help me resolve my billing issue, or change the time of my appointment.

Is this a sign I’m old, and will forever be behind the future? Probably.

Have we abdicated the ability to just do something with pleading a magic number machine to do it for us?

Also probably.

Optimisation is the original sin of tech.

Why do they persist? I just want to do a thing, but you force me to call, when it’s a very simple transactional task.

I’m not saying we don’t need to call a human occasionally, but that should be about discovery, or sales, not ‘fiddle with my service’.

You have to be intentional with your remaining minutes — dealing with other people’s bullshit is not a valuable use of those minutes.

At work: I value, care, and have strong feelings about, how we approach work. What are the systems, the culture, the way we work? Are we being honest with what we’re trying to get done? Do they let us focus on the problems to be solved? Specifically: the problems the customer wants solved? These can be technical, but don't end up in the nitty gritty of ‘which specific design pattern should we use’, or ‘which library should we use’, or even ‘how should these components specifically fit together’. The most impactful, and durable decisions are about the guiding principles that we use to make decisions — what cultural values do we embrace to make decisions (both formally, and informally).

It’s not process, it’s aligning on the shared value. It’s about communicating.

Technical roles often advertise the criticality of technical decisions — but often they are uninteresting, low-impact considerations. The decisions are, in isolation, arbitrary. They’re just one of many ways to skin the proverbial cat. What is more interesting to me is how it fits in to the context of our culture — is this the right way for us?

However, in personal projects: I’m focused on those technical choices — that specific component relationship, the uniqueness of my use case. I enjoy it — because it’s for me. I’m not making it for someone else, whose goals are different from mine. I don’t have to walk a mile in someone else's shoes.

Is this because I’m less technical these days? Or is it because I see those fine details as ephemeral, and actually the why & how we decided is the truly durable artefact?

Slack (and Microsoft Teams) creating tools to auto summarise threads while also offering to generate replies to those same messages is a canonical example.

Yes, you are a busy person; yes, you need the highlights; but at the same time most chats that justify summarisation are filled with nuance. Do you trust the AI to capture all the nuance? It can barely capture nuance today. It’s also a symptom of the fact that people don’t care enough to put the time & energy into understanding what is happening in their job and/life.

The excuse: “Oh, but they’re busy people, and you can’t expect them to do everything perfectly. Sometimes they need the tl;dr”. Sure, but it’s careless — it permeates everything “Oh, i’m so busy, let the AI summarise it”.

But! Conversations are two sided! Generating emails, generating content, to convey information in a textual form is predicated on an expectation that the other side will read it. It’s the generation of significant amounts of text that the other side is assumed to read. But it won’t be. It’ll be summarised into empty calories.

AI writeth. AI readeth.

• Refactoring code, to make it ‘better’. Better for whom? The customer? Or engineering?
• “Cost Efficiency”, without the expectation of passing any savings on to customers
• Increasing customer usage for no other reason than to increase revenue (either because you bill based on usage, or because ads pay for everything. Or the really ambiguous ‘if they use it more, they’re less likely to cancel’)
• Contorting your changes & features because your business team made long-term commitments related to maintaining status-quo to lock-in a deal (E.g., supporting legacy UI because the contract said that this must be maintained)
• Focusing solely on driving a business metric up-and-to-the-right while actively harming the customers’ experience & value, but makes the organisation feel successful.

These ideas infect your tech organisation driving you to make unnatural decisions that are in direct competition with the “right thing” for your customers. Look at 90% of successful tech organisations and really think about why they behave the way they do. You’ll see this lurking right behind the thin veneer of ‘we love our customers’.

We’re not altruistic. We’re mercenary.

How effective they are is dependent on the inputs (materials, model) and the skill of the operator. You have to model the entire shape of your output(s) to be successful. But the operator has to understand how to ensure a successful print with the appropriate level of intervention that matches your needs & expectations.

At the low end, you have Creality producing affordable, powerful — but limited — 3D printing accessible to anyone. At the high end you have LPBF machines from EOS that will print you a metal component for a plane or rocket in highly complex shapes.

LLM coding tools such as Codex, Claude Code, OpenCode, and GitHub Copilot CLI are the 3D printers of the software world, and they’ve already transformed what is possible, and the way that the possible is achieved. The hope is they will produce from fixes to features to entire products.

And, just like 3D printing, their adoption & usage is unevenly distributed.

Your coding agent output is dependent on your input materials (specs, details, guidance) how you operate it (follow on prompts, skills, reference materials, validation).

It’s the difference between a useful print, and a pile of plastic goo.

This is both grandiose (look what I did!) and self important (look what I did!). And LLM coding agents are radically changing the connection between you & the materials.

It’s fine that it’s changing.
Code becoming an unimportant detail is fine.
Software Practitioners will be fine.
I will be fine.

But the refrain of “the code was never the point” in response to the lamentation of this foundational shift is dismissive & lacks nuance — it lacks respect.

The journey mattered to those on the fucking journey. It actually wasn’t just about the destination, it was how you got to where you were going.

And it does matter that people feel a sense of… sadness? Loss? that the thing they honed, pined for, and got lost in, is going away. What’s being lost — what’s going away — is not the “typing at the keyboard to put arcane incantations into the ether”, it’s how it feels when you manifest something useful from nothing and share with an audience — a sense of accomplishment.

The LLM is the Temporal Loom.
And we're The TVA.

I continue to be a believer in “goggles” being “the future” — The Chat Box™ can’t be it. Nor can it be screaming into the void, hoping it screams back.

Public companies that make $10bn in profit every quarter, but don’t increase that profit, are perceived as effectively $0-revenue businesses.