​

(This is the first post in a series of three - part 2 and part 3 may not be published yet.)

I was at the always-informative Manchester Tech Festival the other week, where I saw a great talk by Matt Squire, CTO of Fuzzy Labs, with the title "Are We the Last Programmers? AI and the Future of Code". I’ve started experimenting with using LLMs to help me build software, so I'm particularly interested in this topic.

Matt covered several areas in his talk, so my goal is to write three posts on the back of of it:

• ​What's the best way to build software?​
• ​How does agentic AI affect the next generation of coders? (may not be published yet)
• ​If just anyone can build software, will programming die? (may not be published yet)

​
This is the first of those posts.

And yeah, obviously, the title of this post - What's the best way to build software? - is very broad. Answers to that question could go in many different directions. But what's interesting to me here is the questions Matt asked in his talk about whether building software and writing code are necessarily the same thing. And further to that, the history of visionaries who have made it their job to demystify the writing of code.

Matt told us about the origins of the turtle drawing tool, and the associated Logo programming laguage, which were developed by Seymour Papert in the 1960s, to help teach children how to program computers. Papert's goal was that programming should be open to everybody, and that it should fun and easy for children to grasp.

Papert's belief was that computer languages should support human creativity. Smalltalk was built on similar principles - designed to be simple, intuitive and accessible. Grace Hopper invented one of the first compilers, for the COBOL programming lanuage. She designed COBOL with the aim of it being a natural language, that could be understood as readily as possible without specialist training.

What if we could automate the typing of code? That gives us more space to think about taking a complex problem and breaking it down into simple parts. Then we can focus on problem decomposition and system design. Matt's point was that we want to build fluency in reading, debugging and evaluating code. He quoted Brian Kernighan (co-author of the first book on the C programming language): "Debugging code is twice as difficult as writing it". He also quoted Edsger Dijkstra: "Computer science is no more about computers than astronomy is about telescopes."

Matt talked about cultivating domain knowledge and building user empathy, suggesting that we could have more room to think about these things if we were no longer concerned with typing code into a machine.

Matt's overarching point was that currently, we assume that programming computers is about typing code into a machine, but what if that were to change? What if some of that could be abstracted away and we could focus more on the wider issues? Code is the output of building software, but it's not the outcome.

Many people rightly point out that typing is not the bottleneck when building software, but the combination of typing, semantics and syntax can certainly be a distraction.
​
I confess I'm still not sure that LLMs can be used to completely distance the software builder from the writing of code, but I certainly have seen how LLMs enable me to create systems in languages I'm not intimately familiar with. And yes, many caveats are required, but it is now possible for people not trained in the writing of code to build small functional apps.

I wouldn't currently advise anyone who doesn't have intimate experience of software development to try and build anything other than a hobby app with the aid of an LLM, but I'm very much in favour of making software development easier and more accessible. More on this when I discuss the next element of Matt's talk: "How does agentic AI affect the next generation of coders?"

In the meantime...

Come on this journey with me

I plan to keep writing about this topic. I’ve already got a raft of draft posts in pocket. I love to learn, and I love to teach (and I’m really bloody good at it). I use teaching as a way of deepening my own knowledge and pushing me to learn things more effectively.

If you want to know more, you can do the following:

• Read some advice on getting started with LLM-augmented coding​
• ​Subscribe to this newsletter​
• Sign up for a workshop in building robust maintainable software using genAI:
  • 25th Nov 2025: A one-day workshop at Software Architecture Gathering in Berlin
• Keep an eye on my socials (LinkedIn, BlueSky, Mastodon)
  • …and my events page…
  • …for new workshops and training sessions
• ​Read the testimonials​
  • …about the above workshops and others

​
🔗 Want to share this article or save it for later? Here’s a handy link for you!​