Was coding actually ever about the code?

How the introduction and improvement of AI is just another step, albeit a massive one, when it comes to assisting coders in the task of coding.

Let’s start with the basics and some facts, I’m not a young man anymore (as much as my mind wants to think otherwise). I have many years of experience and history under my belt; from discovering the internet in the mid-90’s, so starting as a junior developer, to senior, to division head, to Head of Technology.

After some early attempts to look at AI with, I have to be honest, pre-defined negative views on it (certainly when it came to the hype over the reality), I spent a weekend giving it a go. This was in the early days of AI and after dropping $20 of my own cash, I tried to build something, and it didn’t work correctly. I then spent a period prompting the AI to fix the issues it produced with no luck until I ran out of credits.

My views kind of confirmed, I walked away thinking it was just not ready. I then gave it another 6 months before trying again; this time with a different mindset and more of a plan.

The first time I think I’d fallen into what many might call the ‘vibe code’ trap. Just prompting with no clearly laid out end goal, or at least without a prompt that explained what my end goal might be. This time and thinking about the different approaches made me realise something; AI isn’t a solution machine (it never will be), it’s a ‘next word prediction’ machine, nothing more.

Why do many AI projects fail?

I have read that around 90% of lovable projects fail, along with the fact that 80-95% of AI projects fail or stall in ‘pilot purgatory’, and this made me think why. After all over the last 3 months myself and the team have built something like 15 AI tools / solutions, all of which are outside their pilot stage, and are being used in a business setting without any issue. And the only reason we have been able to produce so many so quickly, when it comes to the code production, is down to AI.

So why are so many projects failing when it comes to AI, however we have had a near 100% objective success rate? I believe these failures fall into the following brackets:

• The tool you have produced has no business / consumer purpose
• The solution is poorly defined or designed (just not well thought out)
• The producer of the solution actually doesn’t know how coding works at a ‘coding level’

The first one is obvious, if you make something no-one wants or needs, it will go nowhere.

The second reason probably the most interesting, I’ll go into more detail on that one later.

The third reason is why I thought about this post in the first place; coding isn’t about the code… but in many respects it has never been (at least since the 90s). Now sure you don’t want to produce bad code, weak security code, or spaghetti code; however learning to code is about the best practices of coding, not really the syntax of your language of choice.

What does learning to code actually teach you?

When I started learning code (as a schoolboy playing with BASIC and Fortran), even though these languages are very different the principles are the same. Collecting data, storing data, ordering data, processing data, filtering data, combining data, separating data, replacing data, displaying data.

So this got me thinking, you need to know, likely properly know, how you might deal with each of these steps (and loads more, that was just a random list I thought of), however the syntax in different languages to achieve each one is a secondary issue.

You might know you need to loop through an array for some reason, you might need to collect some data from different locations to create that array in the first place, you might then need to sort a resulting array by a child key value (instead of the primary key), and then display the results on the screen in a table.

The first language someone learnt was about the application of this thinking, you learn the syntax of that language at the same time as the principle of what you are doing. You might then learn a second language, and then realise the syntax is different but the principle is the same. You then learn a third language and then it hits you, the code isn’t the skill, it’s being a coder that is the skill.

So, the issue became learning all the different syntax for different languages. Well back in the day, you would work out the correct syntax for what you were trying to via a physical book (if you can remember those); it was most likely an O’Reilly book (or [whatever] for dummies). Then in the early 2000s you might have a searchable PDF where you still needed to know enough about the syntax to find how to use it, then websites served as guides to speed up that process, code editors started helping with autocompleting, then search engines started helping, then sites like Stack Overflow… now the first port of call is AI.

You can use AI in your code editor, to fix or write a function for you, this is a massive leap from copying and pasting something from Stack Overflow, but that’s basically the same (not least since AI probably got its answer from Stack Overflow in the first place). But AI can do much more than this, it can make the whole solution.

This has resulted in many developers (coders), certainly the younger ones, to lose the most important aspect of coding; knowing the principles of what you are trying to do. Now other great improvements have helped, for example vite being much smaller and smoother when compared to nginx, Apache, or IIS; however again this might become a skill gap not knowing how these more mature web server solutions work.

Only today I needed to say a system that was working locally on vite offering a localhost:3000 connection so you could see the solution, only to have to place it on a development machine with nginx being the web driver; thus needing to create a reverse proxy in nginx to expose the vite localhost port 3000 experience that was baked into the solution. Sure, it’s possible, but you don’t want AI messing around with your production server’s nginx config.

However, trying to become ‘old man shouts at cloud’, so I will move on. The point is that AI is the biggest leap in assistance, however it’s still just a tool; even if it’s the best tool developers have ever had… but as the base level, coders need to know ‘all the code’ when it comes to the syntax for at least the last 25 years.

A solution is based on how it is functionally designed, not the code it is written in

Now going back to the second of those 3 points, something will fail if it is poorly defined or designed (with the design talking more about the user and data flow); this was the big one for me. When I first looked at AI my prompt and prompting was really simplistic and open to countless interpretations. One of the main issues is one thing AI isn’t is a moody, grumpy senior developer that will tell you that the idea sucks, and you suck, and how you haven’t thought about x, y, or z; that there isn’t a proper plan or brief. Instead, it will just do as it’s told and build what you asked for, adding loads of assumptions along the way as it wants to help. The issue with this is that all the assumptions might start pushing the code or the solution in the wrong direction, as well as building foundations of sand for your project castle. This is where the concept of ‘vibe coding’ comes from in reality; just shooting from the hip with ideas and modifications without any consideration for the ramifications of any of those steps taken.

This approach is great for the AI companies as you will burn through all your tokens fighting with the AI to get it to do what you want, but without you having the suitable technical knowledge, vocabulary, or skills to ask the right things.

This approach is actually along the line of agile development, where you have a loose overall objective, but you break everything down into sprints with story points, aiming for the goal. Where this falls down is that a human developers also has sight of the overall objective, not only the statement but the approach they might take for sprints further down the line (as they can see them coming). An AI can’t do that, mainly since you haven’t told it anything about the client, their approach, your company’s coding standards, that it will obviously need x, y, & z at some point …etc.

The key thing I have found that when it comes to AI being your coding agent, instead of just a developers coding assistant, you need to work within a more classical waterfall approach. You need to write a full technical brief, a full specification document, you need to iron out all the user flow, data flow, data management before entering your first prompt. Looking at the internet nowadays, to ensure this isn’t seen as a backwards step, waterfall has been rebadged as ‘Spec-Driven Development’

Like in the past, this document will take time and effort, countless re-reads, and modifications to ensure how every aspect of a solution is going to work. It requires input from all the stakeholders and, importantly of all, the technical specification needs to be written by someone with enough solid coding knowledge and experience to write with enough technical detail to remove any assumptions.

Without the detail, you just create a devil

When I was Head of Technical Development, this would be like write a brief for a very junior developer, explain in almost too much detail exactly what is required, as being junior they won’t make the same (correct) assumptions a senior developer might; so you have to spell it out.

Now this isn’t having a go at junior developers, we all start without the experience and war wounds of working in the real world; however, at a base level, AI is just like a junior developer, only lightning quick at code production with access to every book. AI doesn’t ‘know what you mean’ by the way you said it, or due to the client the project is for.

This is why I have gone from the approach of vibe coding my way out of all my credits (the way various YouTube and LinkedIn pieces might tell you), to something that’s a lot more boring and less sexy but that actually works.

Spending hours if not days writing out all the specifications, technical details, functionality logic, user management, data management…everything in something like word. Often getting from 12-30 pages long, however having everything covered for the whole project. Then this is turned into a markdown file, converting everything into a format more suitable for an AI system.

Then instead of just chucking all that in a prompt, getting the AI to read and understand every aspect of the project (as they are generally too large to even attempt to one shot it). Then you can ask the AI to break down the overall project into different tasks, sorting out a priority order, but keeping every other aspect of the project in mind. Maybe adding some temp functionality or temp data feeds (as they won’t be build in the early stages), so the front end can be worked out without the back end being ready; again produced in a way that this temp data feed can be removed from the project when it is no longer required).

What is interesting is that this, again, makes the actual code aspect of coding quite low down the list of important things. It also means we are able to build solutions both quickly and correctly; burning many, many fewer tokens with the AI companies as the AI fully understands that was expected of it.

Conclusion

So, in conclusion, the reason 90% of lovable projects fail, and between 80-95% of all AI enterprise projects fail isn’t really the fault of the AI itself. It’s also not usually directly the fault of the users producing these failed projects either. Instead, it is a tedious mix of over-hyping what AI can do, promotional material suggesting your million pound (though most likely dollar) project is just a prompt away (spoiler: It isn’t), and that AI makes everything quicker.

As the title and intro suggested, it makes the production of the coder quicker, but you still need to know the principles of coding, and have the full (and I mean full) documentation of your idea; not just something that’s floating in your head for AI to turn that dream into something that works.

Sure, it’s still true that if no-one wants what you made, this makes no difference; however, I don’t think the AI marketing would warn you about that. Just like they don’t warn you that to get the best results out of AI is to produce the tediously long functional requirements and specifications that has been hated for so long in agency land, they created the whole Agile approach to try and avoid having to do it.

AI is all about that retro documentation – and honestly, that’s not a bad thing. In fact, it might be the best news we’ve had in years. The fundamentals that separated decent developers from the really good ones haven’t changed. The tools have just finally become powerful enough to reward the people who actually think things through properly.

At the end of the day, AI is an incredible assistant, but it’s still just a tool. The ones who will thrive are those who never forgot what coding, and being a coder, was really about in the first place.