It's widely accepted that as AI writes more and more of our code, opportunities decrease for newcomers to gain the skills needed to become professional programmers. At the same time, experienced people bemoan the way AI is causing them to gradually lose the skills they took so long and worked so hard to gain.
Programming, like mathematics and perhaps music, sits in the middle between science and art. As science, it's all about capturing and organising knowledge, and as art, it's the application of creativity to problem-solving. Enjoyment - deep satisfaction or an emotional rush - can be had from either or both of these. But the perception is that AI is depriving us of opportunity, both to learn and to be creative.
Code written by a human reveals a lot about the coder. Their depth of knowledge of the coding language, their creative use of variable and function names, and even the visual layout of a script. You can often tell at a glance whether the writer truly cared about the code they wrote, or whether it was just a means to an end, to ensure their next pay packet arrives on time.
As AI improves, it makes fewer mistakes, but it also produces code that is increasingly hard for any human to read and truly understand. Since the job of a human in the coding loop is increasingly not to write but to validate code, this is becoming a problem. So here's my recent story, a series of happy accidents.
I've been using agentic AI for about a year. First with Copilot in VS Code, then more recently with Claude Code at the command line. At the start, I found Copilot to make a lot of mistakes and to produce rather repetitive, poorly-structured code, but looking back, a lot of that was probably down to my own ignorance of how to control the process.
The biggest problem I had was in validating JS or Python code. There was just so much of it, often using features of both languages I never fully got to grips with. I've never been a first-class programmer and most of my own code is pure vanilla. The project I was working on was AllSpeak, based on an English-like scripting language I'd written years earlier to help me create products without having to be a coding expert. AI gave me the chance to bring it up to date. But it was when Copilot started offering me AllScript fragments - uninvited - that I had a complete rethink.
The assumption usually made is that code must be written in a modern, high-level language like JS or Python. This is quite valid when a human is doing the coding, but it falls down badly for AI. The problem is, these languages are too complex, and they suffer from inconsistencies AI finds difficult to spot. Documentation is often out of date, and new versions of the language can break older code. Additionally, many features of these language are there as guardrails to stop humans making coding errors that gobble up memory or lie in wait to misbehave in the future. Since AI doesn't make the same mistakes as humans it doesn't need these guardrails; in fact it makes AI's job harder, not easier.
An obvious path revealed itself. If the agent was trying to write code in AllSpeak, why not let it finish the job? I built an AGENT.md file that instructed the agent to code in my language wherever possible, and gave links to the repo and to documentation that would help it do this without making errors.
The benefit was immediate. Instead of having to wade through huge piles of JS and Python, I could now see the application being built in something much closer to English. But it went much further than this. Every now and then, the agent would guess at a construct that wasn't valid, using its knowledge of other coding languages. This was usually down to limitations in the available documentation, but I figured that if the agent wanted to use such a construct, as long as it was syntactically valid and consistent with the rest of the language, it should probably be added. So I set up a permanent second session that deals with additions and changes to AllSpeak, and a rule that if the agent can suggest an improvement, it should do so.
Because AllSpeak is growing in this way, it might be regarded as an impediment to coding, given that it was designed in the first place to make coding simpler. But this changes when AI is doing the coding. The human's job becomes not to write code but to read it, and because the language is close to English, the meanings of new syntax can be made fairly obvious. I can pile in a load of new syntax that reduces repetitive boilerplate to a few words. I no longer have to remember all the syntax, merely to recognise it. This is a big difference.
The final part of this story so far (there may be more to come) was that I'm just an individual with a limited budget. Claude Code does a superb job, but it can get expensive. The pricing is non-linear; spending more gives you exponentially more tokens, but I was ending up not using my allowance. Reducing the cost meant I overran and had to top up.
Then I saw a mention that DeepSeek costs about 50 times less (yes, that's 2%) than Claude Code, so I had to try it. And it's true; after a couple of weeks of daily but not intensive work it's cost me $0.46. However, it's not as good at coding as Claude. It's quick, but it makes more errors, and from the verbose output it emits while working, it seems to struggle from time to time. How much of this is down to my still less-than-perfect documentation is hard to tell, but I definitely have to intervene more often. I understand that deepseek-v4-flash is optimised more for managing huge datasets than it is for coding, which could well be the explanation.
But this limitation brings an unexpected benefit. When working with Claude Code, I often felt myself to be merely a bit player. I gave the requests, but then had little part to play in how things were done as mistakes were few and far between. With DeepSeek I feel more like an equal. We have different roles; DS does the coding and I review it. And because it's written in something close to English, I can follow it far more easily than I would have, had it been JS or Python. I can spot things that aren't right and suggest improvements. I've started to feel like a programmer again, that I really have a role to play in the coding process. And that's where the enjoyment has returned.
So what started as a series of serendipitous accidents followed by a cost-saving trial has turned out to be a partnership of equals, restoring my enjoyment of the coding process. One conclusion I draw from this is that maybe instead of always assuming the latest model is better, consider whether it leaves you with a real part to play in that process, or whether you'll get more enjoyment out of taking on the role of teacher and helping a lesser model do its job, while saving money at the same time. Don't forget, happy people produce better results.
