“We coded this 100% with AI” or “Software development will be fully automated in X months” are claims we are seeing more frequently these days. Meanwhile, programmers who are actively solving real-world problems are finding these statements hard to relate to. While there is no denying the impressive performance of coding agents, at the project level the time savings seem more modest. So, what explains the discrepancy?

Recently, at Inscripta, we designed and implemented a system for a client. A couple of months after delivery, the client told us they were struggling to extend the codebase. The changes they needed didn’t seem overly complex, and we were wondering why they couldn’t simply use Claude Code or GPT Codex to make the required modifications.

One of us said, “They just need to adjust the prompts based on their updated specifications, set up some test cases, and monitor the behaviour iteratively for improvements and regressions.” That’s when someone else chimed in, “But that’s coding, isn’t it?”.

That comment really struck a chord with all of us. The view of software development that CXOs and marketing teams are taking may be too narrow. When developers tell them that AI did 100% of the coding, what gets overlooked is all the computational thinking that went into ensuring that the code actually works.

A couple of recent examples should illustrate the point:

Anthropic’s C Compiler: A few days ago, Anthropic posted that they asked Claude to build a C compiler, and then “(mostly) walked away”. The technical blog that the tweet points to clearly shows that, while the achievement itself is impressive, the claim is (mostly) untrue.

First, the agent orchestration involved is quite novel and nontrivial. Second, significant effort seems to have gone into creating high-quality test cases. Third, active context-management and problem decomposition appear to have been important. Finally, using GCC as an “oracle” was crucial to unblocking the agents, which were otherwise getting stuck on the same bugs and “overwriting each other’s changes”! There are other tasks the blog mentions that demonstrate a deep software engineering-mindset. The two-week process involved $20,000 in API costs, and resulted in a compiler with clear limitations (GCC dependency, not very efficient output code, no assembler/linker), which, of course, may be addressed as more work is done on the project, but are important to note nonetheless.

Google’s Year of Code in One Hour: Late last year, a Google Software Engineer posted that Claude Code built in one hour what Google had taken a year to implement. While technically true, the claim omitted important context which, to be fair, the engineer added after looking at reactions to her post: They had iterated over various ideas over a year, and then prompted the system with the best ideas that survived, for Claude to build a “toy version” in an hour.

The later claim is a more nuanced one, and deserves to be highlighted: “Once you have the insight and knowledge, building isn’t that hard anymore.”

In both cases, the headlines oversimplify and misrepresent the true nature of the work involved. These claims are then amplified by the media, creating a distorted perception of how AI is used in software development and overlooking the critical human effort that still drives the process.

See our recent blogpost on “what still matters” for programmers in the AI-coding era, which expands on this point. Software development is not merely the translation of specifications into code; it is the process of discovering, testing and refining those specifications through the act of programming.

Get in Touch
To schedule a demo and discuss how we can customize our solutions to meet your requirements, drop us a line at contact@inscripta.ai.