30 years ago, I enrolled at a technical university in the Department of Artificial Intelligence. Few people realise that AI has been around for over 60 years, and that neural networks were being programmed on computers from 40 years ago with 16 kilobytes of memory.
At university, we didn’t just study the mathematics behind neural networks – we also designed them, starting with equations on paper and ending with the code. Fun fact: even in our first year, we were writing self-learning games as part of our coursework.
Many people have heard about the limitations and artefacts of neural networks, but not everyone understands the fundamental reasons behind them. Very few people realise that prompting doesn’t solve the problem entirely. Engineers at Figma AI explicitly warn about this: "going hands-on is often faster, more natural, and token efficient than prompting".
Before I move on to examples of how AI is used in the design department, let me show my hobby programming project and demonstrate how to use AI properly.
To celebrate the 50th anniversary of the classic text-based RPG ‘Colossal Cave Adventure’ – the forerunner of all role-playing games – I decided to port it from a PDP-10 mainframe to a 40-year-old home computer with 16 kilobytes of memory. The original game was written in Fortran, the compiled file takes up 60 kilobytes, and it seems impossible to port it to a less powerful computer. But if you know me, you won’t be surprised – I believe that nothing is impossible. Another reason why the project appealed to me was that I would have to train Claude Code to programme for a platform it wasn’t previously familiar with.
After analysing the Fortran source code, Claude Code concluded that porting the game was impossible (unless the text data was split into 10 small files and loaded one by one during gameplay). Of course, you should never take AI at its word when it says something is impossible (it simply means that the neural network hasn’t been trained on such tasks).
But this is where Claude Code proved useful: I asked it to carry out a statistical analysis of the game’s text messages and identify which characters were used least frequently. I then created an alphabet consisting of 40 characters, retaining only capital letters, punctuation marks and a few digits. The remaining digits in the text had to be replaced with words (for example, ‘one’ instead of ‘1’). I packed this alphabet into an encoding similar to Radix-50 – so that 3 characters could fit into a 16-bit word. I also considered the idea of adding ESC-sequences to extend the alphabet, but analysis showed that this would not yield any benefit, but would only complicate, slow down, and increase the size of the code.
Claude Code helped me with the analysis and created a Python script to convert ASCII text into my format – that’s where the real benefit lies. The danger, however, was that Claude Code tried several times to steer me down the wrong path, dissuading me from good solutions. In other words, without a high level of expertise in programming and optimisation, you risk being led in the completely wrong direction, and you won’t even realise it.
The next stage in porting the game involved rethinking the huge jump tables: I noticed that one of the table’s columns could only contain the values 1, 2, 3 or 4. I suggested replacing a single table with 4 separate ones to get rid of that field. In each record, in addition to saving 1 byte, I managed to save another byte that was used to align the record to even addresses. There were other tricks involved in optimising the tables – I had to come up with them myself, whilst I asked Claude to carry out the conversion.
As for the quality of the code, it was terrible, as if it had been written by a schoolboy who’d only just picked up a book on assembly language programming yesterday – everything was written in a very straightforward manner, the algorithms were sub-optimal, and there was a lot of unnecessary code. And this despite the fact that I trained Claude Code on 40 of my own programmes – well-written and well-documented. The problem is that Claude Code draws on a huge array of industrial code written in the 1970s–1990s for the PDP-11, and its quality is mediocre. I had to rewrite absolutely all the assembly code generated by Claude Code. But I have to admit there was a benefit: at least I didn’t have to read the Fortran source code – Claude Code did that for me!
My Facebook post on this received a huge response, and at first many people said that I was simply using AI incorrectly. However, once they had delved into the details and explored the issue more deeply, almost everyone agreed that the problem cannot be solved, and that there are fundamental reasons for this relating to the architecture of LLMs and the dataset on which commercial models are trained. I have high hopes for technologies such as Microsoft’s upcoming Frontier Tuning, which will allow models to be genuinely fine-tuned using my own data, gradually replacing the publicly available training dataset. This also applies to design – the future lies with DesignOps, who will train local models.
For now, however, I have arrived at what I consider to be the optimal scenario for using AI assistants: to carry out intellectual work independently and not ask the AI what is best, but to assign tasks related to testing, statistics, conversion and formatting to the agents. This is the only way to achieve the ‘impossible’. Using this approach, I’ve created a system utility for macOS – you can find it on the App Store.
