Read the Code... Don’t Read the Code... but at Least Understand Your Business

TL;DR: Not always. It depends on what you are building, where it is being used, what happens when it fails, and what the market expects from you.

There is a growing argument that, if an LLM or coding agent writes the code, an engineer must read every line before it is released.

I understand the instinct, but I do not think the answer is that simple.

My perspective on this has changed as my day-to-day role has moved from almost entirely hands-on engineering into a combination of product, technology and leadership. I am now less interested in whether someone followed a particular coding workflow and more interested in whether we can justify how a product was delivered.

This article will not cover the personal learning value of reading and understanding the code. That is an article for another day.

Instead, I want to look at the question through three lenses:

• Velocity
• Risk
• Security

Through these three lenses, I think we can make a confident judgement about how we deliver products built substantially through LLM-generated code, and how much trust we place in the output.

This is not a course on agentic engineering or a list of skills, prompts and tools that will fix everything. These are my thoughts on how product and technology teams should approach the question.

One principle sits behind all three areas: accountability does not transfer to the LLM.

The model might generate the output, but the team still owns the consequences.

Velocity

Velocity is an interesting one because it is heavily influenced by the market in which you operate. Many of the organisations I work with in the oil and gas industry are understandably cautious about AI. A B2B marketing application is likely to face a lower barrier.

That does not mean one industry is innovative and the other is not. It means the consequences of being wrong are different.

A marketing application suggesting a poor headline is annoying. A system presenting an unsafe or incorrect operational recommendation is something else entirely.

These differences dictate the responsible velocity of a business. Developers and technically minded leaders can sometimes struggle with that distinction. There are reasons why some long-lived systems remain on older versions of .NET, and why safety-critical systems use independent implementations, layers of verification and lengthy assurance processes.

Velocity matters, but so do safety, risk and security.

Agents can reduce the time it takes to write code. They cannot prompt away customer assurance, regulatory obligations, procurement, operational validation or the time it takes to earn trust.

Fast code is not necessarily fast adoption.

At this point, someone will normally point towards a particular workflow, skill file or collection of specialised agents. These can be useful, but they do not remove the wider constraints.

A fun experiment is to give an LLM a large application and ask it to “make the application SOC 2 compliant”. It will probably produce an impressive-looking list of changes. It may update code, add documentation and confidently declare progress.

However, compliance is not a property that can be applied to a repository in a single pass. It involves people, processes, access controls, operational evidence, incident response, suppliers and behaviour over time.

The agent might accelerate part of the work. It cannot redefine what the work is.

There is a valid argument for using agents to deliver products and features faster in heavily regulated industries. We should create space to explore what that looks like. However, the industry, its customers and its governing bodies still influence the true velocity of bringing that product to market.

Not every industry is subject to the same scrutiny. Where the consequences are low, the change is reversible and the market accepts rapid experimentation, get those agents working.

You still need to decide where the output will be checked, what evidence is required and what happens if it is wrong.

I have fallen into this trap myself.

I have looked at a migration or technical change and thought, “We can get this done over the weekend.” I was often looking only at the technical challenge. I had not fully considered the product requirements, business risk, customer expectations, validation or the effect on the rest of the organisation.

I was trying to force a velocity that the domain was not ready for.

My perspective is different now because I work across product and technology. I can bring those external factors into the technical delivery process. I can also give work to an agent with more confidence because, as a team, we have developed the guardrails, standards and patterns we expect it to follow.

Those standards are not hidden inside someone’s head. They exist within the product and technical domain in a form that both people and agents can access.

I will also put my hand up and say that I have deployed code without reading every line of it.

That was true before the age of coding agents. If the tests passed, the behaviour was correct and I understood the system, I was sometimes comfortable releasing it. My confidence came from my experience with the language, the architecture and the delivery environment.

These days, my lens is broader.

Did we solve the right problem? Do the tests demonstrate the right behaviour? Can we detect a failure? Can we reverse the change? Does the level of review match the potential consequence?

Reading the code can provide evidence, but it is not the only evidence available.

This is where product and technology teams need to come together. Moving quickly is not simply a matter of spinning up more agents and hoping for the best.

There may be an initial slowdown while requirements are made clearer, standards are codified, tests are improved and review gates are agreed. Once that foundation is in place, velocity can increase, even within a cautious industry.

Technology Choice Is a Business Decision

There is another decision hidden within this discussion: what technology are you allowing the agent to use?

Would I build a product in Haskell? Potentially. It has a powerful type system and may prevent entire categories of errors. But I would still need to justify the decision. Can we recruit people who understand it? Can the existing team support it? Does it integrate with the systems our customers already use? Can someone diagnose a production problem at two in the morning?

The point is not that Haskell is a bad choice. The point is that a technically defensible choice can still be the wrong business choice.

Go provides an interesting contrast. It has a comparatively small language surface, static typing, established formatting and relatively opinionated tooling. That does not make Go automatically safe, but it can reduce the number of ways that people and agents solve the same problem. Consistency makes generated code easier to understand, review and maintain.

Node and Python offer enormous velocity and rich ecosystems. They also make it remarkably easy to add another package, introduce another pattern or solve a problem through a dependency nobody has properly assessed. They are not unsafe by default, but their flexibility demands stronger governance.

This matters even more with coding agents. An agent will often select the shortest path towards completing the task. It may choose a familiar framework, find a package that appears to solve the problem or introduce a new architectural pattern because it works locally.

Those are technical decisions, but they are not necessarily business decisions. Before accepting the output, someone still needs to ask whether the choice fits the expected life of the product, the skills of the team, the deployment environment, the security requirements and the market in which it will operate.

An agent being able to build something is not, by itself, a reason to build it that way.

Risk

Risk is not something we can remove completely.

We encounter it every day, whether we are driving a car, crossing a road or swimming in the sea. That does not mean we wrap everyone in cotton wool. We assess the situation, understand the possible consequences and decide whether the risk is acceptable.

Our personal appetite for risk differs. Some people are happy to jump out of an aeroplane. I am not. I am, however, comfortable swimming in rough seas, others are not.

Over time, we build experience that informs the risk engine in our brains. Businesses need to do something similar for the products, technologies and markets in which they operate.

Agentic engineering carries significant risk.

Did the agent produce something that looks convincing but is functionally poor? Did it understand the requirement? Did it fix the correct problem? Did it remain within scope? Did it make a locally sensible change that damages the wider system?

AI is not uniquely capable of producing bad code. Humans have been doing that for years. If you say you haven't then you are a liar...

The difference is the speed, scale and confidence with which an agent can produce it.

An agent can create a wrong solution that is internally consistent, tested against its own assumptions and presented with complete confidence. That can make the mistake harder to recognise.

Engineers are responding by creating controls in the form of skills, plugins, rules, automated reviews and orchestration systems. These can help, but we need to be careful not to confuse guidance with evidence.

A skill file saying “follow our architectural standards” is not proof that the architectural standards were followed.

These systems may reduce known risks, but they cannot decide the organisation’s appetite for risk. They also cannot determine the business consequence of getting something wrong unless we have made that context available to them.

A coding agent may know that a function returns the correct value according to its tests. It may not know that the value will inform an operational decision, appear in regulatory evidence or change how a customer allocates millions of pounds.

That is where technical risk must be translated into product and business consequences.

What happens if the change is wrong?

Does a user see an incorrect label, or do they lose their work? Can we roll back the change in seconds, or does it permanently alter customer data? Does it affect a marketing workflow, a payment, an access-control boundary or an operational recommendation?

The required level of review should follow the consequence and reversibility of the change, not simply whether it was written by a person or an agent.

A low-risk visual change behind a feature flag may be suitable for automated tests, a brief behavioural review and rapid release.

A change affecting authentication, tenant isolation, financial calculations, customer data or safety-related decisions should receive much stronger scrutiny. That may include detailed code review, independent testing, domain validation and explicit approval.

Reading every line of code is one form of risk control. It is not a complete risk-management system.

A human can read every line and still miss that the feature solves the wrong problem. A reviewer can skim a 2,000-line pull request, approve it and create the appearance of control without providing meaningful assurance.

Conversely, a well-designed test suite can provide strong evidence about known behaviours without requiring a person to manually inspect every implementation detail.

The best approach is normally a combination of controls.

The business defines its appetite for risk. Product translates the risk into customer and operational consequences. Technology decides which engineering controls are appropriate. The team then gathers enough evidence to justify releasing the change.

The aim is not to eliminate risk.

The aim is to make it deliberate.

Security

Security overlaps with risk, but it deserves its own lens because a seemingly small technical change can create a disproportionately large blast radius.

“It passed the tests” can be dangerously comforting when discussing security.

Tests only prove the things we chose to test.

An agent may introduce a dependency with a known weakness, request broader permissions than necessary, expose an endpoint, log sensitive information or weaken validation because doing so makes the immediate task easier.

None of these behaviours necessarily look obviously wrong when reviewing the feature in isolation.

An agent also does not automatically understand the trust boundaries of your organisation. It does not know which data is sensitive, which systems are exposed to customers, which permissions are excessive or which operational controls exist outside the repository unless that context has been provided.

Security therefore needs to exist within the delivery system, rather than depending on someone remembering that an agent wrote the change.

That means deciding what an agent is allowed to access and modify. Can it read secrets? Can it access customer data? Can it alter infrastructure? Can it deploy directly to production? Can it approve its own changes?

The answers should be based on the possible consequence, not on enthusiasm for the technology.

The same principle applies to the generated code. Static analysis, dependency scanning, secret detection, access-control tests and appropriate security reviews should form part of the normal path to production.

For higher-risk changes, additional scrutiny may be required. Authentication, authorisation, tenant isolation, cryptography and infrastructure permissions are all areas where plausible-looking code is not enough.

This does not mean agents cannot contribute to security-sensitive work. They can help apply known patterns, identify common weaknesses, improve test coverage and make controls more consistent.

The danger comes when assistance is mistaken for assurance.

The more code we generate, the more changes we need to validate. If AI increases development throughput by a significant amount, security cannot remain a manual checkpoint at the end of the process. It needs to become part of the path that makes rapid delivery possible.

Good security controls should not exist solely to slow teams down. They should provide a safe and repeatable route through which teams can move faster.

So, Do You Need to Read the Code?

Not always. There are changes where I would be comfortable relying on clear requirements, automated checks, behavioural testing, observability and the ability to roll back.

There are other changes where I would expect detailed human review and independent validation. In some cases, reading the code is only the beginning of the required assurance.

The threshold should be determined by what happens if the output is wrong.

Is the failure easy to detect? Is the change reversible? What is the possible blast radius? What evidence will customers, regulators and the market expect? Does the team understand the domain well enough to recognise a plausible but incorrect solution?

When the consequences are low and the recovery path is clear, move quickly. When the consequences are serious, slow down and gather stronger evidence.

The question should not be:

Did an AI write this?

It should be:

What happens if this is wrong, and what evidence do we have that it is right?

I do not need to place blind trust in the agent. I need to trust the people, controls and delivery system surrounding its output.