Composable code, working with AI tools and more, notes from 25th March 2026
Posted by Paul Silver
On the 25th March, eleven freelancers got together in the Battle of Trafalgar to talk tech, self employment, and a fair amount of random nonsense. This is some of what we talked about:
- Preparing a huge update for going live
- Using Claude a lot is changing my relationship with code/projects and I’m not sure I like it
- Finding Claude’s limitations
- Investing – active vs managed funds, working out your ethical boundaries
- Balancing AI tools against each other
- Basic marketing you can always do – post about what you do! – Blog, LinkedIn, etc
- Making an app composable so as to use with AI tools
- Making a TUI (Text User Interface) is not the same as creating a CLI (Command Line Interface)
- App demo
- Supplements (AKA old man corner)
- Quantum physics
- Deciding on degree modules
- American’s relationship with oil
- House further out vs flat in Brighton
- The importance of Power of Attorney
Composable code
Just in case you haven’t come across the term – ‘composable’ is a term for making small pieces of code that do one thing. You then use lots of them together to build up a more complicated program. The most commonly used example of this is command line tools in UNIX and Linux, where you can pipe the output of one tool to another and then get a result out of the other end – lots of little things tied together solve the problem you’ve got.
Composability is good when you’re using AI tools as it gives them small things to use, which are less likely to have mistakes in them and are easier to review.
AI changing your relationship to code
This was an interesting conversation, I’m going to leave names out as I’m not sure if they’d like that bit public – people using the Claude AI tool (and others) to write code for them are finding it is changing how much they enjoy a project. Before, they would work out part of the project and plunge in, and have problems to solve along the way that would potentially be frustrating, but would also be enjoyable.
Now, they are describing the project at length and Claude (or Gemini or whatever) is writing the code, and they’re not enjoying it as much.
This is not an unusual feeling. When I was first freelance, I did a short contract with a company where I would write a technical specification for part of the website they were making, basically filling in the technical details from the user level specification they’d agreed with their client. They’d then agree what I’d written and I’d write the code, then after a while they’d pass the spec to another contractor and they’d write the code, so more work was happening in parallel.
Writing and working to a spec changed my relationship with programming, as I was very thoroughly thinking through and planning out what had to happen while writing the spec, so the code writing was faster and mainly slowed down when hitting problems with a library or an API that didn’t work quite how its documentation said it did. Basically, the spec writing took the fun out of the coding part as you solve most of the problems at that point, rather than when coding.
Which is faster? If you’ve got several people working on a project, or various things that need thinking through, having a technical specification, even it’s being written “just in time,” will be quicker in my experience. When you’re working on something small and on your own, I think sometimes it would, sometimes it wouldn’t. However, I’m generally a plan-first programmer as that works best for me. I’m always working to some sort of spec, even if it’s very loose and scribbled down rather than a formal one.
Next meet up
Our next meet up will be on Wednesday 1st April, 8pm onwards in the Battle of Trafalgar pub in Brighton.