For a mostly-tech blog, there aren't many posts on falkus.co that mention AI. This mini essay is the first in a probable series on my thoughts around the good and not so good of using AI, specifically to complete work in software development roles.
- Introduction
- The Good: AI Is Brilliant At The Code-Writing Part of Software Development
- Less Good: AIs Encourage Verbose Text
- The Uncanny AI Valley Of Text
- Educating Your Team
- Wrapping Up / Avoiding AI Posts
Introduction
Here is an enjoyable Freudian slip, in the first draft of this post I realised I’d actually written the summary above as using AI to generate work, not complete work. That’s telling! UC Berkeley completed a study 1 that showed AI is causing us to work more, not less. Cursor, the AI coding agent tool, recently released an iOS app 2 where you can manage agents from your phone, so no matter where you are you can be ‘getting work done’. If you stop to think about it, that sounds pretty awful! Anyway, I digress, there’s a whole other post to be written another time about how easy it is to work more with AI coding agents helping.
For those non-developers reading, for this post when I say AI I am mostly thinking about Large Language Models (LLMs). These are token prediction functions. You put tokens (words) in, they predict what comes next. You put in a prompt like ‘write me a function in C that draws a circle’ and the model predicts what would come next, very likely writing a suitable function. Obviously prompts can be much larger and include existing content and codebases etc. When you think about the tech in such terms it’s pretty incredible how well it works.
I am simultaneously optimistic and unsure about the increasing use of AI in day-to-day software dev roles. Judging by chats with peers, plus online content and comments, there is a lot of similar tension being encountered. Something we’ll come back to.
This post isn’t attempting to land on one overall ‘AI is good or bad’ result. As with so many developments, it’s all a bit more nuanced than that.
The Good: AI Is Brilliant At The Code-Writing Part of Software Development
A core part of my day job is still writing software, just like I’ve done for 20-odd years (aside - I can’t believe I’ve been writing software commercially for that long!). Except, this looks very different to how writing software looked even two years ago. Most of the ‘writing’ is actually in prompting and reviewing LLM output and architecting the bigger picture of the product or service being worked on. Hand editing files line-by-line is the exception, not the standard.
Overall, I’d say this is a positive development. LLMs are very good at writing code. It’s the type of task that is fairly predictable and follows clear patterns. There’s loads of training data. Plus it’s often clearly verifiable - an LLM can iterate on a problem until a suite of tests pass for example.
‘The Future Tech Role Is the Product Architect’ by Arjun Kashyap 3 is an interesting take on this hands-off direction of building software:
[…] As agents get better at implementing, testing, and reviewing software, the human role moves toward deciding what should be built, defining how the system should work, and verifying the result. The person who owns all three is the product architect.
Arguably in the past almost all seniorities of software developer were at least partially concerned with those tasks, but now it’s a much bigger piece of the pie.
Agents, when focussed on coding tasks, are also fairly efficient (you can even run a coding LLM just locally on your laptop, e.g. the Qwen3 models). At least, this is compared to generic agentic tasks, see ‘How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks’ 4. The summary repeats this key finding from the other direction, namely how inefficient non-coding tasks can be:
[…] agentic tasks are uniquely expensive, consuming 1000x more tokens than code reasoning and code chat
Coding is currently one of LLMs’ best use cases then. With my developer hat on, I can see first-hand the value, and compared to some other tasks they do it relatively efficiently. Ed Zitron might be writing lots about the massive AI bubble we seem to be in 5, but even if the bubble collapsed tomorrow and we never progressed beyond today’s available models, I feel confident developers would continue finding utility building software with the existing tools.
This is part of the comparison that gets made between the introduction of high-level programming languages vs low-level programming languages. Even if the benefit of high-level languages tapered off after some initial variations were introduced, developers never went back en masse to building software only with low-level languages.
The benefits of not having to spend time deeply learning the assembly language for the specific hardware you were working on, plus the ability to code the program in a higher abstraction, those were major wins. There are trade-offs of course, compilers don’t always produce optimal code, there is even still now a time and place for low-level language optimisation.
I expect whilst LLM development will become the norm, with most software dev roles working primarily as system architects, there will be times where knife-and-forking lines of code is the best way to solve a problem.
Less Good: AIs Encourage Verbose Text
Where I’m less sure on the AI benefit is writing non-code content. For those that don’t know, that’s a big part of most software development roles, especially in remote teams.
Historically you would be writing commit messages summarising what, and importantly why, a change was made. Pull request content, where code branches are merged together, would do the same but consider the bigger picture. You’d be writing documentation about the product or service. Perhaps most importantly, you’d be writing to communicate, understand and challenge ideas within your team and company.
Writing is thinking. It’s also an author’s direct way of communicating with their reader. If you are not writing yourself then arguably you are not thinking as deeply, or communicating as clearly. Worse, you might be lending your authority to ideas that don’t match what you actually think, unintentionally leading others in the wrong direction.
The Uncanny AI Valley Of Text
I have an almost physical aversion to reading big walls of AI text, especially if passed off as written by a human. It reminds me of the Uncanny Valley 6, where the fact it feels close to human but not quite human is what makes it uncomfortable. AI generated content often reads a particular way. It’s often super enthusiastic, overly stylized (take the scattering of emojis in the text for example!), probably giving a ‘balanced’ view beyond the more specific opinion you’d expect. This mismatch of style is very noticeable when you are familiar with the author’s usual tone. It’s a giveaway they didn’t write it.
Perhaps we should lean more into that as a feature not a bug. It might be beneficial if the LLMs had their own voice and style that communicated clearly but was easily identifiable as non-human.
Recent developments suggest we are actually going in the other direction. For example ChatGPT has a pilot running to learn a user’s writing style. 7 I’m skeptical that this is actually a good idea.
Writing used to take a long time. It still does if you’re writing yourself and not with an LLM. This communicated an unwritten fact to the reader, which is that you’d carefully thought about the content, agreed with it and were representing those ideas how you thought best for the target audience. Using AI text to communicate with others breaks all those assumptions.
My belief is that there is a big benefit to the author and the reader when you put in the effort to manually write content.
Educating Your Team
Lots of others feel this way. The general avoidance of big slabs of AI text has resulted in lots of good articles and websites. Some of these are like defensive tools. That is, websites you can send to someone (or your entire team) pre-emptively, or in response, to help explain why you don’t want to read the raw unfiltered output from their LLM. It may be that they’re so excited about the new technology they’ve not yet stopped to think more deeply about whether they are using it inappropriately.
Here are some of the best posts and discussions you can share with your team if they need convincing:
- Workslop is communicating by pasting big chunks of AI-generated text. No one wants to read a wall of AI text proxied by a human. How to protect yourself from workslop is a good post by Sean Goedecke defining workslop and how to explain it to your team.
The core problem with workslop is that the effort involved is asymmetrical, like a denial-of-service attack: it takes almost no effort to produce text with AI, but it still costs effort to read.
- Don’t paste the AI, please. I’d originally seen this on Hacker News 8. The discussion on that thread shows lots of devs resonate with the feeling.
When someone asks you something, they want your answer. Not a wall of ChatGPT text.
- AI;DR (AI; Didn’t Read). A more modern take on the TL;DR (Too long; didn’t read) response. Via Rick Manelius via ‘seclilc’ 9
[…] I am getting to the point where I physically flinch (sometimes dropping my shoulders and hunching, or having a slight eye twitch) when someone I respect sends me unfiltered and unedited AI output.
- Another defensive website you can send to your team, no slop grenade. Their top example where someone asks ‘Should we use Redis or Memcached?’ is very relatable. I can imagine lots of teams having that style of question.
What’s a slop grenade? Pasting a massive AI-generated response into a chat or email where a human would write one sentence. It destroys the medium itself. Nobody writes essays in Slack. It’s only possible because of AI copy-paste.
- I relate also to Tom Bedor’s post on human attention, namely that authors should Show Human Effort.
Attention was already a scarce resource before AI, and it is even more so now. Keeping AI generated content clearly labeled and demonstrating human effort helps show consideration for teammates, and keeps a touch of humanity alive in our work.
Wrapping Up / Avoiding AI Posts
This blog lacks posts covering AI. I’ve partly avoided publishing such posts because AI chat just seems to be everywhere. I think I have some AI news fatigue and don’t want to add to the problem. I miss the days of the regular tech news being new JavaScript frameworks, which felt safe to mostly ignore as boring tech tends to run the world (obligatory reference to an absolute classic talk on why boring technology is the best).
It’s hard to feel quite so blasé about the latest AI news compared to the latest JavaScript news. The AI tooling has already fundamentally changed the look and feel (and pace!) of software roles.
Writing is good for the author who is processing their own thoughts, and there’s lots to think about when it comes to AI and software development. With that in mind, expect to see some more posts on this blog unpacking my understanding of how AI development is impacting those of us building software.
Postscript: Creative Inspiration
We started by considering how good AI is at writing code. That doesn’t alter the experience that writing code by hand can have a certain joy to it. Crafting anything well, software or otherwise, is often fulfilling.
On that note, here is some non-AI inspiration in software development. ThinMatrix and Rooi are two examples of single-person indie game developers that make short videos about their work. Both have a laid back vibe, and neither uses any AI tooling, which is refreshing. Rooi covers avoiding AI in a recent video 10, it’s a really honest take on the tension between how AI would remove some stress from writing code, but also remove what makes the process fulfilling. Perhaps that fulfilment felt by hand-rolling creative code is especially clear when you’re solo building a game, rather than enterprise software. Still, worth some reflection.
These types of channels feel extra interesting and authentic now that almost anyone could drive an AI to build a visually impressive game. That authenticity is perhaps why multi hour long videos by talented developers like René Rebe building USB drivers by hand 11 have millions of views.