Part of “Conquering Entropy”

Most of the issues I have with AI-generated code are related to trust. Do I trust the person who wrote this ticket? Do I trust that the engineer who opened this PR understood the ticket and guided the coding agent to implement it properly? Do I trust the coding agent’s implementation? Do I trust our test suite to catch regressions before they hit production? Do I trust our CI/CD to properly build, test, and deploy our change? Do I trust our observability setup to alert us when the ai-generated code breaks production? Do I trust the AI SRE (Site Reliability Engineer) to properly diagnose the issue and help us mitigate it? Do I trust GitHub not to have an incident when we need it the most?

Trust is hard to earn and easy to lose. So I think it’s crucial to foster a culture of trust within the engineering team. You must trust engineers to do the right thing.

Encouraging Accountability

I find it helpful to clearly communicate something like this: “You are accountable for what you ship. If this breaks production and you authored the PR, you should be there to fix it.”

If engineers are made accountable for the code they ship, they should be given the agency to produce it with their preferred methods. Even if you’re not AI-pilled, you have to admit that AI agents do generate a lot of code very fast. Code still needs to be generated, and the expectation is that now it’s cheap to generate a lot of it. To cope with this, engineers must be allowed to put some measures in place to ensure the quality of the codebase does not degrade.

In a healthy organization, the engineers should trust each other to only push code of reasonable quality. I say reasonable because it’s not pragmatic to obsess over quality and try to ship always 100% perfect code. Even before coding agents most code was already a buggy mess! So it’s understandable when a “good enough” solution is delivered. Often, we trade speed of delivery for quality, and incur some technical debt.

Here are some practices I have found useful to facilitate engineering accountability in this new era of coding:

Coding Guidelines

Have a clear technology strategy: take some time to decide what matters for your codebase and invest in clear guidelines. Both for humans and for the coding agents. Even if the humans don’t read the guidelines, their coding agents will, and will follow them (mostly).

Deterministic Tooling

Make heavy use of deterministic tooling to ensure code quality. Typed languages, linters, dead code detection, security scans, CI/CD, and so on. All of these tools existed before coding agents and help us in the fight against slop. (Stay tuned for a follow-up post with specific recommendations!)

Enforce Small PRs

Empower the engineers to reject unreviewable PRs. If possible, codify this criteria so any unreviewable PRs are immediately rejected. Of course, make sure to leave room for exceptions.

Own the Tests

Write test cases by hand. This is similar to the job of a business analyst. Deeply think about the feature and define proper test scenarios. Discuss this within the team. Coding agents can implement the tests, but they should be defined by humans.

Taste in Product

Work in tandem with product to have a coherent product vision. It’s very easy to go crazy with AI and implement whatever feature comes to mind. Make sure you only implement useful features that actually bring value to users!

Prototype

Throwaway code. Since code is very easy to generate now, it’s a good opportunity to try different approaches. Don’t just let the coding agent generate one solution. For example, try three radically different approaches and pick the one that best fits the problem and existing system.

Focus on the Outcome

Be pragmatic about the result. Sometimes the code is not the result. The result is a report, or a tool that helps you accomplish something else. For cases like this the quality of the code is not that relevant as long as the result is useful.

What’s Been Changing

Ever since coding agents became popular, my company’s monorepo line count has exploded. The number of pull requests (PR) has roughly doubled (conservatively), and so has the review burden on all engineers. People think the biggest problem now is that there’s too much code to review. But there’s way worse stuff!

Other negative consequences I have noticed:

• Degraded shared understanding of the system, since most code is not written by hand anymore. We are missing this step, which helped us solidify our comprehension of the system and strengthen our mental models.
• Artifacts which are difficult to understand. For example, tickets heavily written by AI, system design documents, code comments and documentation. This is due to the way LLMs write. People are calling this new language “Claudish” and I hate it because it muddles communication.
• Jumping to conclusions too fast. As difficult as the LLM output can be to understand, sometimes it can be very convincing and people let their guard down and easily trust it. I think we need to “trust but verify” even harder nowadays.

I see a lot of anxiety and worry over what the profession is becoming. This one’s tricky and I’m afraid I don’t have any useful actions to help with this. Personally I have chosen to take advantage of the current tools and focus on maintaining a system that I can be proud of. But in a few years we might not even need humans for this.

More now than ever, it’s essential to be able to trust each other and the code we deliver.

AI Contributions Are Staying

In some open source projects (like Zig, NetBSD, GIMP or QEMU), AI contributions have been banned. Reasons vary, but I see a common thread: lack of trust. Slop, spam, untrusted code, no accountability, licensing.

Within a company, it’s not often feasible to ban AI contributions, as the business also expects that the engineers deliver at an accelerated pace. And the incentive within a company is usually to deliver more, show higher performance, get your promotion, salary increase, etc. So as long as there’s a tool that improves productivity (or looks like it does), people will use it.

I used to think that if AI usage kept incurring higher and higher costs, it would collapse and everyone would go back to writing code by hand. But I don’t think this will happen anymore. There’s many “good enough” open models that can be self-hosted right now, and they’re only going to get better. Some companies are already experimenting with this to reduce their dependency on the big AI providers.

So it looks like AI usage will not stop. I like it (societal and economical consequences aside). It’s allowed me to have a greater impact that I could have had before by doing a lot of the grunt work that is necessary but I never had the time for. Also allowed me to get so much more done on my side projects in which code quality is not the focus. It’s also fun to tinker with. I have tried many different setups and enjoy discussing these with my colleagues.