Skip to content

LLM and Coding

Understanding coding

No Silver Bullet: Essence and Accidents of Software Engineering Accidental complexity relates to problems that engineers create and can fix. For example, modern programming languages have abstracted away the details of writing and optimizing assembly language source code and eliminated the delays caused by batch processing. Essential complexity is caused by the problem to be solved, and nothing can remove it; if users want a program to do 30 different things, then those 30 things are essential and the program must do those 30 different things (Fred Brooks)

  • The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.
  • I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.
  • If this is true, building software will always be hard. There is inherently no silver bullet.

Eight Myths on Software Engineering and GenAI: Examining the most common misconception Developers don’t actually spend most of their time writing code, with studies at Microsoft and elsewhere showing it’s closer to 14 percent. That means AI code generation, even when it works well, touches a surprisingly small slice of the actual job….The overall development cycle is only as fast as its slowest phase, and coding is often not the slowest phase (ACM Queue, May 2026)

If you thought the speed of writing code was your problem - you have bigger problems When you optimise a step that is not the bottleneck, you don't get a faster system. You get a more broken one….Where's the actual bottleneck? If it's not writing code (and it almost never is), then where should you be looking? Walk the value stream. Follow a feature from "someone had an idea" to "a user got value from it."...The bottleneck is understanding the problem. No amount of faster typing fixes that (Andrew Murphy, March 2026).

The future of software engineering is SRE Writing code was always the easy part of this job. The hard part was keeping your code running for the long time. Software engineering is programming over time. It's about how systems change…People don't buy software, they hire a service…And that takes work. A lot of work. Because the first 90% to get a working demo is easy. It's the other 10% that matters (Swizec Teller, January 2026).

Your LLM Doesn't Write Correct Code. It Writes Plausible Code. One of the simplest tests you can run on a database: Doing a primary key lookup on 100 rows. SQLite takes 0.09 ms. An LLM-generated Rust rewrite takes 1,815.43 ms. It’s not a misplaced comma! The rewrite is 20,171 times slower on one of the most basic database operations….LLMs optimize for plausibility over correctness. In this case, plausible is about 20,000 times slower than correct (Horoshi, March 2026).

Code is a liability (not an asset) Tech bosses don't understand this. They think AI is great because it produces 10,000 times more code than a programmer, but that just means it's producing 10,000 times more liabilities…Writing code that works, without consideration of how it will fail, is a recipe for catastrophe…AI can write code, but AI can't do software engineering (Cory Doctorow, January 2026).

AI: Considerations for people who make decisions Bert Hubert (July 2026).

  • Someone who has never been able to program returns to the office on Monday with a fairly functional app. That’s genuinely astonishing…At the same time, there is no guarantee that such an app will turn out to be maintainable, complete, useful, or secure upon closer inspection. In fact, it usually isn’t.
  • And that brings us to a central problem: a great deal of AI is being evaluated by people who simply aren’t qualified to evaluate it. Who can tell whether an app is actually good? That would be … the people who deploy and maintain these kinds of applications in practice…. Do the backups work? Is logging useful? Do users actually understand how to use the app? Can the help desk diagnose problems and resolve them? Does it crash on certain Samsung or Apple phones? Or, as happened with a recent Rabobank app update, does it get confused when you rotate your phone? Is the code readable and maintainable? Is the data storage GDPR-compliant? Where is the data actually stored?
  • It takes experience and expertise to judge whether an application is any good. AI enables many people to build things they could never have built before. Unfortunately, those same people then often decide for themselves that what they’ve built is good. That’s particularly problematic when the person in question occupies a senior leadership position.

Where Does the Foundation Come From? AI can compress, but not replace. For engineers with grounding, AI is a multiplier; without it, AI creates a productivity illusion in which output outpaces understanding. (The Official ACM, August 2026).

  • I have been a software engineer for more than 20 years and can undoubtedly say that I am a more productive engineer with agentic AI in the loop. In areas that I am already an expert, I am at least two to three times more productive, and agentic AI has also enabled me to venture into areas that I normally would not have contributed to.
  • However, the reason I am able to get this boost is that I can lean on my 20 years of experience for a foundational understanding of what is happening, can stay in planning mode for hours asking the right questions, and can critically inspect the generated code—spotting shortcomings and raising the right follow-up questions.
  • The interns were drowning in information. They had no mental model to anchor anything to, no vocabulary for what the code was doing, no instinct for which questions were the right questions to ask the agent in the first place. Giving them more powerful tools didn’t help them. It was making it worse, because each tool produced output they then had no basis to evaluate.

Productivity Claims

Where's the Shovelware? Why AI Coding Claims Don't Add Up If so many developers are so extraordinarily productive using these tools, where is the flood of shovelware? We should be seeing apps of all shapes and sizes, video games, new websites, mobile apps, software-as-a-service apps — we should be drowning in choice. We should be in the middle of an indie software revolution. We should be seeing 10,000 Tetris clones on Steam…Nobody is shipping more than before (Mike Judge, September 2025).

No, AI is not Making Engineers 10x as Productive 10x productivity means ten times the outcomes, not ten times the lines of code. This means what you used to ship in a quarter you now ship in a week and a half. These numbers should make even the truest AI believer pause. The amount of product ideation, story point negotiation, bugfixing, code review, waiting for deployments, testing, and QA in that go into what was traditionally 3 months of work is now getting done in 7 work days? For that to happen each and every one of these bottlenecks has to also seen have 10x productivity gains. Any software engineer who has worked on actual code in an actual company knows this isn't possible (Colton Voege, August 2025).

Productivity Surveys

Stack Overflow data reveals the hidden productivity tax of 'almost right' AI code The 2025 survey of over 49,000 developers across 177 countries reveals a troubling paradox in enterprise AI adoption. AI usage continues climbing—84% of developers now use or plan to use AI tools, up from 76% in 2024. Yet trust in these tools has cratered….Only 33% of developers trust AI accuracy in 2025, down from 43% in 2024 and 42% in 2023. AI favorability dropped from 77% in 2023 to 72% in 2024 to just 60% this year…Developers cite "AI solutions that are almost right, but not quite" as their top frustration.

DORA Report 2024 – A Look at Throughput and Stability This report is showing that AI has a negative impact on throughput, stability, and time spent on valuable work.These statistics seem to be saying that code generation is not the bottleneck… We can make individuals more productive at creating more code, but that is not the same as making our entire SDLC more effective and more stable….We thought the bottleneck was developers writing code, but in fact the bottleneck is putting good code into production.

  • Update 2026 AI now has positive impact on time spent on valuable work and slightly positive on throughput of individuals. But it still has negative impact on stability. A notable portion (30%) reports little to no trust in the code generated by the AI.

Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity - METR When developers are allowed to use AI tools, they take 19% longer to complete issues—a significant slowdown that goes against developer beliefs and expert forecasts. This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.

  • Update May 2026: We attempt to capture gains due to AI in terms of ‘value’ (how much more value are you creating with AI), rather than ‘speed’ (how long would it have taken you to do these tasks without AI). These can give different answers in principle, in particular if using AI changes the distribution of tasks you work on. For example, researchers could use AI to quickly build an interactive dashboard for their data, which would have taken significantly longer without AI but isn’t that important for their project. Participants self-reported a median 1.4–2x change in the value in their work due to AI tools. The median self-reported speed change is 3x.

Agentic Engineering Guide

Agentic Engineering Patterns - Simon Willison Coding practices and patterns to help get the best results out of this new era of coding agent development we find ourselves entering. I’m using Agentic Engineering to refer to building software using coding agents—tools like Claude Code and OpenAI Codex, where the defining feature is that they can both generate and execute code—allowing them to test that code and iterate on it independently of turn-by-turn guidance from their human supervisor.

Writing code is cheap now (Simon Willison) Delivering new code has dropped in price to almost free... but delivering good code remains significantly more expensive than that. Here's what I mean by "good code":

  • The code works. It does what it's meant to do, without bugs.
  • We know the code works. We've taken steps to confirm to ourselves and to others that the code is fit for purpose.
  • Your job is to deliver code you have proven to work There’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers…and expects the “code review” process to handle the rest. This is rude, a waste of other people’s time.…We need to deliver code that works—and we need to include proof that it works as well. Not doing that directly shifts the burden of the actual work to whoever is expected to review our code.
  • It solves the right problem.
  • It handles error cases gracefully and predictably: it doesn't just consider the happy path. Errors should provide enough information to help future maintainers understand what went wrong.
  • It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future.
  • It's protected by tests. The tests show that it works now and act as a regression suite to avoid it quietly breaking in the future.
  • It's documented at an appropriate level, and that documentation reflects the current state of the system - if the code changes an existing behavior the existing documentation needs to be updated to match.
  • The design affords future changes.
  • All of the other relevant "ilities" - accessibility, testability, reliability, security, maintainability, observability, scalability, usability - the non-functional quality measures that are appropriate for the particular class of software being developed.

Coding agent tools can help with most of this, but there is still a substantial burden on the developer driving those tools to ensure that the produced code is good code for the subset of good that's needed for the current project.