Often I will accidentally click the LinkedIn icon on my phone when I’m aiming for something else, and in the moments before I close it again I will read a post that sounds a lot like this:

I (an employee in the LLM marketing industry) spoke to a software engineer at a “prestigious” tech company (that sells LLM products) and they told me they HARDLY EVER review their LLM-generated code anymore because it’s just so good! You don’t need to know what goes on inside anymore!

If you’re still writing code by hand in 2026, you need a reality check, and FAST!!

Often this is automatically translated in my mind to:

I (an employee in the burger marketing industry) spoke to a cook at “XYZ Burgers” and they told me they HARDLY EVER eat anything else, because their burgers are just so good! You don’t need to know what ingredients are in your food anymore!

If you’re still eating food that isn’t burgers (bought at “XYZ Burgers”) in 2026, you need a reality check, and FAST!!

However, disregarding the obvious marketing angle, the technology is progressing quickly and any genuinely forward-thinking engineer should be giving their LLM usage serious thought.

It’s totally possible that the technology could lurch forwards again in the next few years and make this article redundant, but at this stage I put it to you that we should all review every single line of LLM-generated code, for the following reasons:

Black Boxes Aren’t New (Or Good)

Firstly, in my opinion, treating AI code as a black box is not a new concept. Non-technical CEOs have been treating their software engineering teams as a black box for decades now, and the result has always been shitty products “directed” by people that don’t understand them deeply enough to make insightful leadership decisions.

Windows gets worse every single year, and has been since long before AI was on the scene.

I don’t believe a software engineer that isn’t involved in the granular details and decision making of their code can become familiar enough with the nuance of their domain that they can make insightful high level decisions. Sure, it’s nice to have the option to delegate low-impact work to LLMs, but I can’t see that trading away your core understanding is beneficial long-term.

It has been the case on almost every single significant project I’ve worked on that the most significant big-picture revelations only became apparent after understanding the minutia.

Do you think it would be sensible to try to design a nuclear reactor by treating uranium as a black box material whose inner workings aren’t your concern, as long as the output seems right according to your limited picture of the domain? Or is it possibly helpful to know about the atoms and how they interact inside?

We’ve previously had company “leadership” disconnected from the implementation, and the result has been engineers that are misaligned and products that are largely stagnant and uncreative. Now we’re lucky enough to have the actual software engineers disconnected from the implementation too, and we’re already seeing greater levels of stagnation than ever.

Staying Sharp Is Important, Actually

Secondly, we all know that LLMs aren’t capable of creating solutions outside of the domain of their training data. They can be excellent at coalescing data from across the breadth of that data into combinations that are genuinely useful and appear novel, but there are many problems that they just can’t solve.

For example, at The Running Algorithm we use many genuinely novel statistical models and methods that have not been created before and do not exist in any training set, and they work extremely well. As a test, I have tried to prompt all major LLMs to reproduce our solutions, or solutions of similar quality, and they are unable to do it without such leading questions that the solution must already be understood in depth by the prompter.

This is just the necessary reality of their training process. They are statistical models that predict statistically likely next tokens. A genuinely novel discovery or innovation is, by definition, not a statistically likely next sequence in a backwards facing dataset.

I do not believe that a programmer that delegates such a large percentage of their day-to-day work to LLMs without working through the provided solutions could possibly stay sharp enough to solve genuinely novel problems when they arise.

…What If They Don’t Arise?

The uncomfortable reality at this time, in my eyes, is that the majority of companies simply do not create products that are genuinely novel, provide any genuinely novel value, or use any novel methods to do so.

The writing on the wall isn’t that software engineering and writing code are done for because they can’t possibly keep up with LLMs, but that so many companies are done for because their product doesn’t offer anything more than a variation on an existing theme - now easily reproduced by any competitor or customer.

Companies yapping on about agentic development, loop-engineering, and all the other modern jargon, are all engaging in a race to the bottom that doesn’t work out well. Having previously established their market presence by being the first on the scene and out-working the competition, as opposed to out-thinking it, the only way to stay ahead is to use LLMs, agents, and “Ralph loops” to continue to pump out derivative features that already exist in similar products.

But…

LLMs really are very useful for many things, it is common sense that having access to such fast and free-form “intelligence” should be useful for something, even if that something isn’t producing masses of garbage code.

In my current workflow, I’ve experienced significant speed-ups from using LLMs, for example:

• Reviewing my changes for common bugs and points of fragility
• Suggesting test cases that aren’t currently implemented
• Flagging when documentation needs to be updated as a result of changes
• Cracking through trivial tasks with very little cognitive overhead (often HTML & CSS changes)
• Frequent security reviews
• Searching and digesting documentation quickly

These are all mechanisms that provide me with a tangible, demonstrable velocity increase while allowing me to stay sharp on my granular decision making, and familiar with the depth of the domain.

Conclusion

The opinion that you don’t need to thoroughly check (and be a part of the production of) LLM-generated code is derivative, leads to a reduction of genuine conceptual progress, and harms your long-term development as a software engineer & critical thinker.

If you’re finding that you don’t need to review your code because the LLMs keep acing it, I would encourage you to ponder as to whether or not your code actually does anything complicated. If management is pressuring you to increase AI at the cost of quality, you might actually infer that the product just isn’t sophisticated enough to stay ahead without riding the slop train with everyone else. Users do not want one trillion basic features, they almost always want a small number of precise and thoughtful features implemented properly by someone that really understands them.

LLMs are powerful and you should think deeply about how to utilise them to greatest effect, but please review your LLM-generated code. Further, please stay in the habit of writing at least some code by hand. Don’t let your fundamental skills and domain expertise atrophy over time through lack of use. Your users, mental health, and wider society will thank you for taking pride in the quality of your work.