Vibes and Engineering

The Jobs Crisis

My job, as I have known it for the past twenty-five years, is no more.

As someone who's only ever worked at small companies ^[1] or on my own, I probably had to do much more than software developers at large corporate places.

Most of my work life, I've been a solo freelancer, which meant I would spend my time:

• marketing (which for me was mainly in-person networking - the absolute best way to get work)
• pre-sales (talking to prospects about what they wanted, then figuring out what it would entail to build it and coming up with a proposal)
• sales (delivering the proposal, trying to get the contract signed)
• specifications (taking what the client had asked for and turning it into something concrete)
• coding (taking the specifications and turning them into working code)
• operations (taking the working code and deploying it to servers, which then need to be maintained and kept secure)
• support (fielding calls and emails from people who got stuck, didn't know how to use the software or found bugs)
• feedback (dealing with, scheduling, specifying, writing and deploying change requests)

When I started working for Collabor8Online, that took the marketing, sales and some of the support tasks out of the equation^[2] - but we are a small company so everyone gets involved in everything.

That leaves specifications, coding, operations and feedback. And now, these LLM coding agents are coming for the coding part of the job.

This is causing great angst amongst many software people.

Vibes

When I was a teenager, in the late 1900s, I was playing around with "home computers", which became a big deal in the 1980s. I didn't have many computer games, so I tried to learn to programme so I could write my own. In those days, that meant BASIC (we had a Commodore-64) and learning meant books or magazines^[3]. As the 80s progressed, my friends got Amigas and Atari STs (great computers), whilst my dad got given a PC for work (not very good) - so when I went to my friend's, we would fire up AMOS or STOS (versions of Basic that were designed for creating games) and try and create the next big thing.

BASIC was OK^[4] but I never really got it. I could make the computer do things, but it was a struggle and I never felt like I knew what I was doing - the code never sat right in my head. One friend, Ben, who had the ST, started getting frustrated with the limitations of STOS and started learning 68K assembler^[5]. Meanwhile, one of my magazines had an article about Smalltalk.

This blew me away - suddenly, programming made sense. It wasn't about data structures, it wasn't about algorithms, it was about objects sending each other messages. This was something I could easily visualise, it was something I could easily model. I had to learn Object-Orientated Programming.

On top of that, Smalltalk had revolutionary ideas like images, byte-code and garbage collection - as well as an in-built core library with Collections and other useful classes (most programming languages were literally that - just the language and you had to deal with everything else yourself).

I felt that, not only would I be able to write code that I understood, but lots of the minutiae of coding - like keeping track of your memory allocations - would just go away. I was the exact opposite of Ben - he wanted to dive deeper into the machine so he could exert control over what it did. I wanted the machine to handle all the boring plumbing so I could get on with building stuff^[6].

All of this is a long-winded way of saying, I was not an engineer - I was in it for the vibes.

LLMs and Coding Agents

As of last year (2025), vibe-coding became a thing. When I first used Claude Code (exactly a year ago, in February), I was really impressed. Suddenly, here was an AI that could actually do stuff - not just talk to you and sometimes give you made-up answers. And, as a rubyist, who has invested heavily in test-first development, it was perfect. I could write the tests, the specifications, and Claude Code could make them pass.

But I didn't use Claude Code that much.

Mainly because it wasn't like test-first development. That was interactive, taking baby-steps, adding a new clause here, implementing it, refactoring - exploring the problem in front of you. Whereas writing whole tests up-front - that's waterfall on a small scale.

But, recently, especially since the release of Claude Opus 4.5, the coding agents have got a lot better. And people have been learning how to use these tools effectively.

This is an important point.

A lot of developers, who are anti-AI, have basically given the LLM a minimal set of prompts and then been disappointed with the results.

Whereas, I've been using Claude Code for at least a few hours every week for the last year, trying different things and experimenting with it.

These are complex, powerful and often unpredictable tools. You need to learn how to use it effectively - a couple of hours of mucking around is not going to get you decent results.

There's been stuff about commands and skills, about spec-kits, the Ralph Wiggum Loop, about orchestrating swarms of agents in Gas Town. Lots of people have been trying lots of things to make these things more effective. I've come up with a method that is working for me extremely well (and I'll type it up soon).

But the key thing is, the physical act of sitting at a keyboard and typing code. Then running that code and seeing if it works (either through compilation or tests) and assembling all your pieces of code into something that meets the specification. That is no longer part of the job of being a software developer. The agents need guidance from us, but, for the most part, are better at it than us humans.

So the "vibes" part of my job is still alive - talking to humans, dealing with feedback, making it work the way people expect. It's the engineering part that has changed.

But that doesn't mean software engineering is dead.

The difference between "craft" and "engineering" is craft is about making the thing, while engineering is about making sure it meets the constraints around it. There are economic constraints, acceptable tolerances to errors and breakages, safety requirements, social contracts. Those have always been the most important parts of engineering. And now the actual "making" is out of our hands, it's the part we need to concentrate on.