Is computer science and coding still useful? Evidence from seven months of directing AI

Many students choose our subject, computer science, because they love coding. But they've been hearing about and finding out for themselves how they can now prompt games and other projects into existence with AI. One of my Y13 students in February was seriously considering changing her university course choice away from CS to something else. I wanted evidence to be able to more confidently give her and others an answer on the value of learning to code and studying CS further.

So on 26th February I got a Claude Code subscription and started prompting the AI. Without a better idea for what to build, I asked for a home page for a photo book system, because I used to run a yearbook company and had toyed with the idea at the time of branching out into other photo books. Within minutes it was ready, and it looked pretty good. Next I asked for something far harder, a whole photo book system. An hour or so later it was done... but it wasn't very good! In fact, it was rather terrible. On the surface it seemed fine, but once you started interacting with it you realised it was a cheap facade with nothing much behind it.

I started again, but this time with a more serious approach of making a system that is production ready. Seven months later, and after thousands of prompts, I have a fully working photo book system. In fact, I've even registered it as a company and have printed around 100 books so far. It's called RGBloom and you can try it and order a book today at https://www.rgbloom.com/ .

Practically none of the code was written by me. I've checked the git diffs, and it's just 8 lines of CSS where I changed some values, plus a string I tweaked in a single line of JavaScript. All the rest of the codebase (and there's over 100k lines of it, plus an equivalent number of lines of tests) was written by Claude Code.

So just how much did I have to do? Let me start with some hard numbers (all are underestimates, as the first month's worth of history was lost on an old laptop):

• -600+ Claude Code sessions
• 6,700+ prompts
• ~50 prompts per active day
• ~11 prompts per session
• 560 words in my longest prompt
• 37 words mean average per prompt

... Claude Code is also telling me that's "roughly the length of three novels" that I've written in my prompts. That's a lot of writing. Maybe that 100+ page NEA our students have to churn out for their A-levels doesn't seem like quite such a waste of time after all?!

Ok, so I'm saying right now today, you can build large systems without writing any code. But you still have to do a lot of writing, in English. But how much technical/CS knowledge do you need? I asked Claude to trawl our sesisons for how many times I'd written some key terms/concepts that come up in the A-level spec:

• heuristic: 13 times
• concurrency: 40 times
• pipeline: 22 times
• caching: 26 times
• queue: 46 times
• hashing: 19 times
• indexing: 46 times
• performance modeling: 19 times
• client-server: 22 times

That's a lot of CS knowledge I needed to prompt the AI to create a large system! And its replies use these terms even more than I do in my prompts. I asked Claude for some examples from my prompts of where I'd mentioned heuristics:

• 5 Apr: "currently, we have a heuristic for whether a background has other items on the same page: if it does, it can't be selected with drag select, but otherwise it can. This is confusing for users…"
• 29 Apr: "we want something really good, so I think v2 with a heuristic approach, though it will likely take several iterations to really nail it; feel free to push back on this if necessary"
• 8 Jun: "As a future todo, we'll want to intelligently bring layouts to the front which eg most closely match the relevant photo aspect ratios, and/or some other heuristics"
• 17 Jun: "make per-spread and whole-book 'Auto-design' more intelligent, taking better account for eg: num photos imported; num unused photos; num empty spreads; orientation of photos vs orientation of frames in layouts; and other useful heuristics. Do not start implementing any changes yet – we need to discuss this more together first."
• 17 Jun (same prompt): "'Switch layout' heuristics is also in scope here. The goal in all of this is to allow a user to very quickly and easily create a good-enough looking book, with only a few clicks…"

And some of my prompts involving mentions of pipelines:

• 8 Apr: "There seems to be a problem at least sometimes in rendering bold text in the export PDFs pipeline. I've noticed this in a cover used in a book template."
• 17 Jul: "I was looking through an ordered book's files and found 2 bug in our export pipeline PDF renderer to do with text (one mishandling \r and the other not using correct glyphs for non-latin fonts…)"
• 17 Jul: "tweak some text items in it to include emoji. Then generate PDFs from that .photobook file via our rendering pipeline, and let me know where to find the output to eyeball."
• 31 Aug: "analyse our photo import pipeline(s), outlining what happens, what gets stored and where, and what's good/bad in terms of memory, cpu/gpu, caching, concurrency, speed and UI/UX."
• 2 Sep: "this should be the main focus of this page – to see how the source image is transformed during the pipeline into different sizes, and what those different sizes are/should be used for."

And on hashes and hashing:

• 7 May: "we should be doing de-dup of photos based on their hash already at upload/import time, so it shouldn't be possible to have the same photo content under different photo ids already"
• 18 Jun: "…the user loaded the editor/page while the server is on one commit, but by the time they press the 'feedback' button the commit has changed… so for this to work effectively the commit hash should surely have to be shipped with the client rather than calculated on the server"
• 30 Apr: "shouldn't the .qa-session-* files also have the unique hash in them? Otherwise what happens if we run 2+ concurrent usability tests?"

Finally, caching:

• 8 Apr: "When flicking between templates, when going back to a template you've already loaded it should be much quicker and smoother. Are we re-fetching the photobook? I feel like some sensible caching would help greatly here."
• 4 Jun: "Did we not have something in place that, when you're looking at one spread, pre-caches images for the surrounding spreads?"
• 18 Aug: "is it possible "42 handed over in under half a second… minutes later" was because iOS had already cached HEIC->JPG conversions for many of the files from the first failed attempt…"
• 31 Mar: "I'm concerned whether we need to update how we deal with caching of spread thumbnails… and photos to take into account the changes."
• 7 Jun: "shows low-res images which don't resolve to high-res ones. I presume this is because navigating within the order flow's preview evicted them from the cache…"
• 2 Sep: "so these are all stored in indexeddb. analyse when they are also active in memory and whether we're doing things right there re caching and memory usage"

Notice that in my prompting I'm leaving a lot of decision making to the AI, but I still needed to know these terms existed and what they meant to write the prompts. So to do well in creating systems, students still need the fundamentals in CS. There's still value in us teaching them.

But what about coding knowledge? I told you I wrote practically none of the code myself. But could I have created it without knowing how to code, and having built systems in the past without AI? No, I really don't think I could, and here's three longer evidenced examples to help support that:

1. Recognising how serious a bug really was (31st July)

"The '… holes in it' massively understates the problem: the user will receive a blank book in the post at the moment if their upload coincides with a deploy. I would have thought a better idea would be to have the temp dir mounted so we're storing files outside of the container… I'd like to know your thoughts on how we can fully fix this critical issue before I agree to anything though."

Claude had described a bug in an order with 'holes in it' and offered a cheap fix. I realised the cheap fix would mean customers potentially receiving blank books through the post (they didn't: it was caught before it affected anyone). I knew the cause was where/how the server stored files: a container's disk was being wiped during a deploy, so partially uploaded photos vanished. My experience and judgement was crucial: knowing how bad that bug was meant knowing what happens in the real world, and my root-cause fix depended on having run production systems previously.

2. Knowing when to push back against over-engineering (4th June)

"I'm quite confused, and that suggests this might be over engineered. How about instead we just get a 2nd cheap server with our hosting provider (in a different data centre) and scp files to there every hour as a backup?"

At the time Claude had designed database backups around a specialised backup tool I'd never used before. It came with an encrypted backup store and a password that, if lost, made the backups unrecoverable. A novice might assume confusion is their own fault, while an experienced engineer knows that a backup you can't explain is one you won't manage to restore if you need to. We didn't end up going for exactly the solution I proposed in my prompt - we landed on a better one.

3. Fixing a whole class of bug, not just the one in front of me (19th June)

"Anything else we can do to guard against this class of bug?"

My first real order on an early alpha had stray text in the top-left corner of the cover PDF I was about to send to print. It looked odd, so I spoke to the customer and they swore it wasn't there - they even showed me a screenshot of the editor to prove it. When I opened the book's saved files in the editor I also didn't see it, yet there it was in the print PDF, so I knew a value had changed somwhere between editor and PDF. In the editor I logged the object to the JavaScript console and noticed its x and y coordintes were both 'NaN', which means 'not a number' - not a good sign! When a book goes to print the JavaScript objects get turned to JSON strings, which don't support 'NaN', instead converting them to 'null'. But if you multiply NaN by a number you get NaN, while null multiplied by a number gives 0. So for the PDF the text was being placed with a valid coordinate (top-left corner, (0, 0)) but wasn't appearing at all in the editor. The AI wrote the code that caused the bug and, once pointed at it, quickly wrote a fix for that one case. But it took someone who has spent years watching values change type at the edges between systems to recognise the clue, and to ask the more important question afterwards. That question led to four layers of protection: the editor no longer writes NaN, existing books in customers' browsers are repaired automatically when they load, and a final check stops any book, however old, from ever sending an impossible position to the printer.

Conclusions

Wrapping up, here's what I think my evidence is telling us and our students:

1. Today fewer and fewer systems, at least ones like mine, need humans to write code
2. Prompting a good system into existence means writing a lot of words
3. Those prompts require a vast range of technical knowledge and expertise
4. To get that knowledge/experience, students must still learn to code and create systems without AI

My conclusions largely align with Simon Peyton Jones' thinking: we must still teach our children to code. And CS foundations matter, probably even more today than they did before AI.

 

By Jake Gordon, head of comptuer science at Cambridge Maths School and founder of RGBloom Ltd. I posted a similar (but less technical) article on the RGBloom blog.