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". Matt covered several areas in his talk, so my goal is to write three posts on the back of of it:
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 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 meI 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:
|
Don't miss my next post! Subscribe to my newsletter and learn a host of useful tips about coding with agentic AI, as well as learn a bunch of useful stuff about effective technical leadership.
You’re constantly balancing competing demands — supporting your team, meeting delivery expectations, advocating for engineering health, responding to leadership and general admin. The result can be a relentless cycle of context switching, long hours, and the sense that you’re never quite doing enough. You may suffer from irritability, concentration difficulties, or even resentment toward the role you once enjoyed. At the same time, the constant stream of meetings, messages, and tickets in...
Participants in a coding workshop I’ve started experimenting with using LLMs to help me build software. One of the first things I did was to watch the video of Llewellyn Falco’s talk about using process files as blueprints for Agentic AI, from Craft Conference 2025. I learnt a lot from this, and it was a great starting point to get me going with LLMs. In that video, Llewellyn does over an hour of live augmented coding on stage. And one of the first things I noticed was that he uses the LLM...
Clare (me) with Emily Bache and some coding workshop participants So, you’re thinking about using LLMs to help you code? Maybe you’re unsure about the negative impacts - on the planet, on the industry, on education, on your ability to actually code. Honestly, apart from a little fence-sitting handwringing I can’t help you much with that, but recently I decided to sell my soul to the devil and start experimenting with using LLMs to help me build software. And you know what? It’s fascinating,...