A painter and decorator uses the same tools as an artist. Both use paint and brushes. Nobody confuses the two.

This isn’t a slight against painters and decorators. They are skilled professionals, who take pride in their work, and deliver genuine value. The distinction here isn’t about quality or effort. It’s about the relationship each has with the medium. The artist is trying to say something with it. The painter and decorator is simply trying to finish the job well, and move onto the next one. Both types are entirely valid and necessary. Problems only arise when someone conflates the two, or when an outside force insists the distinction no longer exists.

Software development has always had both types. The artisans are the folks for whom the craft itself is the point. They care about architecture, systems thinking, design patterns etc. They might be TDDers, though not always. They’re still thinking about a problem in the shower, two days after thinking they’d solved it. They probably have strong opinions on the if keyword.

The painters and decorators are the competent professional practitioners. They write good code, ship features, and go home. They know they’re not artisans, and they’re not trying to be. For them, it’s a skilled trade, and a good job. They probably have families and a social life etc.

These two groups have coexisted in the industry probably for as long as there has been an industry. What’s changed here is that for the first time, it’s become difficult to mistake one for the other. And that’s down to the LLMs.

For the painters and decorators, the LLMs have been an unambiguous gain. The LLMs tackle all the tedious work. The tests, the boilerplate, even some light design / refactoring. It’s all taken care of. For these folks, their tickets close faster, their output certainly feels faster. For them, the output is the point, their goals are to ship features, and so the LLMs are a straightforward improvement. I’ve come to understand this, rather than look down on it, as I once did.

For the artisans, it’s a lot more complicated, and that’s what I’m trying to unpick here.

The AI companies

The narrative being pushed by the AI companies and tech leaders is that “coding is the bottleneck”. I honestly don’t think I’ve heard people say that before LLMs arrived. “It’s always a people problem” is the term you’d always hear at a well-regarded consultancy I worked for a while back.

Indeed, “a developer’s job isn’t to write code, it’s to solve problems” is a quote from Martin Fowler. Which I had always taken to mean, it’s not the amount of code produced, but the matter of was the problem solved? Recently, I’ve seen this phrase be used by others to mean it’s ok for the LLM to write code, because that’s not your job, which I found quite unnerving. We are starting to reframe our phrases to support a new paradigm.

At some point over the last 18 months, we have slowly drifted into a switch in our workflows.

In the traditional workflow, a developer would write some code, then raise a pull request to have that code reviewed and ultimately merged into the default branch. I might review that PR, then approve it, and it gets merged in. If that PR was later found to have introduced a bug, I might take some of the blame for not spotting the issue, but the author of the PR would certainly be the one to fix the bug.

It is widely accepted the author owns the bug, even though there is a degree of “blame culture” at play here. Certainly, the author will bear the brunt of the blame, but they will also get all of the credit.

Here’s the switch we’ve fallen into: the LLM writes the code, the developer reviews the code. If any bugs are found, that’s on the developer. Suddenly, the reviewer is now the owner.

Except we’re not really the owner. We’re just accountable. The LLM wrote the code. It gets the credit. If anything goes wrong, that’s on the developer. The developer gets the blame.

This is a much bigger problem than simply an ego wanting to write the code. The skills needed to review code are built on those needed to write it. And those skills are maintained through practice. Over time, you erode your skill set. Dull knives do not cut better.

Yet we’re still going along with the idea that the LLM is better than the human for writing code. We’re now coming up to 3.5 years since ChatGPT was released to the public. And do not misunderstand me here, the LLMs are astonishing technology. Very exciting, and very useful. Back when GPT was released though, we all thought humans would be irrelevant in 6 months. It was frightening, but very exciting too.

Jump 3.5 years to now though, and the progress has been….well, human. Infrastructure has been built, investments made, billionaires made, deals made. The improvements to LLMs and AI in general have been relatively pedestrian. Even the agents were actually available to be built back in 2023. They just took more than a year for the human teams to build them into the products.

The problem with this is that the teams were clearly busy trying to add features that would be appealing to investors. This distracted them from fixing the issues that prevents the LLMs from writing code unsupervised. The nature of LLMs means that realistically they can never truly fix this. They are stochastic pattern matchers, not thinking AI. The core reliability issue remains.

Github Copilot’s own team won’t let us set it as a PR approver. I can understand why to a certain extent (someone is bound to try and sue Github for a bug released to prod, right?). That said, I think as an industry we don’t accept that the review is to blame for bugs going to prod, don’t we? At least, we did before LLMs and the switch.

I don’t enjoy reviewing code. It is tedious, and disruptive. It can take a widely varying amount of time to complete. Plus the review is requested at someone else’s discretion. I can’t plan around it, or make time for it. And so the context switch is inevitable. And then there’s the amount of files changed in a PR. Humans can be very unfair with this, and the LLMs are not necessarily any better…as the humans pushing them may want more changes sneaking into this PR.

So no, I don’t enjoy reviewing code. And yet the workflow being pushed on us is that our new role is to review code, because LLMs will handle the bottleneck. Which of course is writing code.

Except that isn’t the bottleneck. As I’ve just hinted above, the bottleneck is everything else, including the reviews. That PR needs to get to the main branch quickly, otherwise there will be merge conflicts. Continuous Integration is still paramount.

For the last 7 years or so I’ve been tracking my time with Timeular (now Early). As a result, I’ve got a reasonable idea how much time I spend coding. I say reasonable because I have a time tracker dodecahedron, and sometimes I forget to flip it onto the correct task. Even so, over time I figure the numbers effectively normalise and are certainly good enough to drive indicators from.

In the various roles I’ve had in that time, my coding time has varied between 25% and 65%. Currently, it’s around the 65% mark. Recently I’ve started tracking the ‘thinking’ and non-typing activities (including reviews) separately from the ‘coding’ and typing sections, to give a better indication. From this small subset, I can see that I actually code for roughly 30% of my time.

So that’s around 2.5hrs per day coding, leaving 5.5hrs to everything else. About half that time (15%) is spent on ‘interruptions’. And yet, and unfathomable amount of money, time and energy is being spent trying to get me to spend less time on the job I’m paid to do, rather than reduce the interruptions.

Best case scenario, I’m expected to swap my current coding time for reviewing time. Worst case scenario, I’m expected to write lots of upfront documentation too. And indeed, this is the current approach being recommended by the AI companies and tech leaders. Specification Driven Development. Upfront documentation, because the LLMs are only producing bad results because the stupid developer can’t write a prompt correctly.

So instead of writing code using a precise language, we’re expected to write lots of documentation and specs using an ambiguous language. There is a reason why we invented programming languages, but we’re expected to ignore that.

Where it doesn’t fit my workflow

Of course, this new workflow isn’t new at all. It’s waterfall. For some reason it has been decided that the developer should write the specs, and test the output but not write the implementation.

This is an entirely valid workflow for some companies, and projects. It may even be the best use of your staff. I would say though, most companies likely have folks already that are far better at writing specs and documentation. They’re more experienced. They’re business analysts.

Similarly, they may well have folks that can test the output far better than the developers too. They’re Quality Assurance.

The developer has no role in this workflow. They are redundant.

I have no issue with this. I don’t like this workflow. I didn’t like it before the LLMs, and it is no better now. I sincerely believe it is entirely valid to replace the developer with LLMs / agents here, and let the BAs and QAs build the product.

I rejected waterfall long ago. Not because it is slow, but because it typically leads to the wrong solution being built. I prefer agile. I prefer incrementally building the solution. And so I’ve tried this with LLMs today.

I’ve experimented with me writing the test, and the LLM writing just enough code to pass, but I don’t get the same itch scratched as when I do it all myself. In part that’s the LLM doing a tad too much in its implementation step, but it’s also that I like the code to look a particular way. I’m sure I could put together an agent workflow that handles the TDD flow just the way I like it, but by now I’m thinking I’m missing a trick.

My fear with surrendering too much of my intellect to the LLMs is skill atrophy. Throughout my life I’ve noticed that the use of tools for convenience has often meant that I forget how to do the simple things. I noticed this with calculators at school, with grammar and spell checkers in word processors and mail clients, and I’ve felt it while using the LLMs and Copilots. It’s crucial to keep your knives sharp.

And then there’s the understanding. Anyone who has ever been a lead developer on a project understands this really. If you’re not writing the code day-to-day, or at least not much of it, you have to work a lot harder at understanding it.

These days, it’s harder. You have an LLM to ask about it, sure, but it’s not as easy as talking to a human. In a few years’ time, people will start to discover what they’ve really lost. That lack of understanding will almost certainly compound, and folks may find it hard to refactor their way to understanding a code base they never built.

Where does it fit then?

Let me state clearly at this point, I am not proposing for a moment that we stop using LLMs. These things are incredible and obviously can be put to great use.

I’m also aware that the “artisans vs everyone else” framing can easily become something akin to gatekeeping, which is absolutely not the intention.

If you’re new to software development, or you’re interested in getting into it as a career, I think vibe-coding is a great entry point. You’ll get results quickly, plus you’ll see the limitations where your beginner’s ignorance meets the eager to please nature of the LLMs. Some folks will drop off at this point, but I think a good number will have their interest piqued and will want to learn more about engineering. If I were learning to code today, I would be neck deep in LLMs.

Another great use is prototyping, or sketching out an idea, before building it with discipline later on. I use LLMs to sketch out an idea, so I can get fast feedback on how I want it to work, and whether it’s a good idea in the first place. One example is I built an Github Action that I use in my local self-hosted runners that performs an adhoc code review on my local LLMs. It’s a little rough, but the speed of development offsets the lack of quality. I wouldn’t do this for a commercial product, and even the functionality in this GHA is going to be replaced by a proper cli tool within a few weeks.

The use case worth being cautious about is claiming professional credit for the vibe-coded output. We will see this from various angles over the next few years I’m sure, and perhaps my view on it will change during that time. Obviously, the most likely example of this will be folks taking on full development work off the back of using Claude Code etc. In a lot of ways, I don’t think I could blame the folks, and in a way they’re doing everyone a favour. We need to see how far these tools can go, and so we do need explorers.

The bigger caution I think has to go to the skilled craft-folk. We are being pushed so hard to create by proxy of the LLMs, and it’s blurring the line of authorship. This is getting so difficult that in reality we are likely to attribute the authorship to the LLM if there is any doubt.

My own workflow

So finally, let me describe how this actually plays out in practice.

This started with me being unhappy that I was expected to hand the part of the job I like to a computer, while it left me with the part I don’t. So I thought to myself, why can’t it do the bit I don’t like instead, and it can leave me to the bit I do like.

I TDD my code. The tests are the spec, and they run automatically in the pipeline. I tell my LLM to check the code coverage is good, then to review the change set for security, maintenance, and quality issues. If there are no issues, it auto-merges the PR into my code base. If there are issues, I have to address them or resolve them, and the PR will auto-merge when it is ready.

The review stage for me is a “last chance”, second pair of eyes. It’s to give the code a once over to see if there are any obvious issues. Other than that, the quality is entirely in my power to improve. And I don’t lose any knowledge or understanding.

My knives are very sharp indeed.

We have artisan coffee, artisan bread, artisan cheese. Will we have artisan software? I expect so. LLMs haven’t changed what artisan software is. They’ve just made it necessary to say it out loud.