Posted in:

Anyone who's tried using the frontier AI coding assistants such as Claude Code or Open AI Codex will know that they can rapidly accelerate development, generating new code much faster than a typical human developer.

But that still leaves a big question - is AI-generated code ready to deliver and safe for production? It's one thing for your code to be "demo-ready", but that's not necessarily the same thing as it being secure, resilient, observable, and cost-effective etc.

In my latest Pluralsight course, "Production-ready Ai-assisted Development and Workflows", I try to offer some practical guidance for how we can take advantage of the power of AI code generation while still ensuring that we deliver high-quality code.

Of course, this is a very fast-moving space, and so I don't presume to have all the answers. Best practices are emerging (and then being discarded) at a very rapid rate. Let me just highlight a few of the key topics I cover in the course...

Code Review

One of the biggest issues many companies are currently struggling with is what the future of code review looks like. Code review was already often a bottleneck, as it's hard to find sufficient time to thoroughly scrutinize someone else's code, especially if the changes are widespread or in an area you're not familiar with.

AI-generated code exacerbates this existing problem by greatly increasing the volume of code that requires review. This raises the question of whether it's feasible for humans to review all AI-generated code, and I've even heard some people advocating for just relying on AI code review.

AI can produce genuinely good insights in code reviews, but it can also be unnecessarily pedantic, and miss the big picture of the why behind the feature. The types of problems that an experienced human developer who understands the full system and how it is actually used by customers in production, are exactly the types of issue that an AI code review will miss.

So I still believe there is value in taking time for human review of AI-generated code, especially when it touches on business logic or critical parts of infrastructure. Let the AI code review do a thorough first pass and pick up on the most obvious mistakes, but humans still have value to add at this stage, and reading the code is also beneficial for keeping on top of how exactly things work.

Testing

Another big transformation that AI-generated code has brought is the speed and ease with which we can generate significant numbers of automated tests. It is now genuinely possible to get near complete code coverage with unit tests, and much less painful to get more complex integration-testing scenarios set up.

All of the projects I've used AI on have much more comprehensive test coverage than previous projects, as I can easily generate smoke tests, performance benchmarks, load tests and much more.

However, there is a real danger of a false sense of security from having a high volume of AI-generated automated tests. In particular, if the AI has misunderstood the requirements at the implementation stage, then the tests it generates will simply mirror the implementation - they won't discover gaps. So again, the ability of human QA engineers to think like a customer and make sure that the system is being executed in ways that correspond to real-world usage patterns remains extremely valuable.

Technical Debt

I've written a lot over the years on this blog about the problem of technical debt, and it's not yet clear exactly how AI-generated code will change this picture.

On one hand, you could argue that AI-generated code tends to adhere to good coding practices such as well-named methods and variables, with clear comments, and follows industry-standard approaches. And in theory, at least, you ought to be able to ask an AI coding assistant to do a round of technical debt cleanup after each round of development.

But despite these advantages, I still think there is a real danger of rapid accumulation of technical debt with AI-generated code. Despite our best efforts to provide these models with sufficient context, they always inevitably work with a limited, local picture of the codebase they're working on, and the decisions they make will therefore sometimes cause problems later down the line.

As a simple example, I've found AI coding assistants to tend towards over-complicating things, adding parallel implementations or complexity ostensibly for good reasons (such as backwards compatibility and or reliability). So there is a real concern that too many such decisions will eventually lead to a system that's so tangled and complex that the AI agents start missing important things when attempting future development.

Maintaining Ownership

Another topic I explore in the course is the importance of maintaining "ownership" of your code. AI-coding assistants can seem like a magical short-cut. If you've been assigned a particularly complex development task, instead of deeply thinking through the problem yourself, you could simply ask the AI to do the heavy lifting for you. It can try to make sense of the requirements, make the architectural decisions, implement all the code changes and test it, just leaving you to rubber stamp it at the end. It will even output a beautifully formatted (and convincing sounding) report explaining everything it's done.

The danger is, this can lead to something that has been called "cognitive surrender", where it's easier to just go along with whatever the AI is suggesting rather than taking the time to truly understand it yourself. This not only means you end up developing a product that you don't understand, but you also miss out on key opportunities to course correct along the way. Perhaps worst of all, it means that if everything goes wrong in production, you're completely clueless about how to resolve the situation, as you don't know how the system works. You've ended up entirely reliant on the AI-assistant, and adding little to no value on top.

The future of AI-generated coding

Of course we are continuing to see improvements both to the LLMs, and to the coding "harnesses" that are built around them, and so hopefully some of the pitfalls that are possible at the moment will be more easily avoidable going forwards.

On the other hand, others point out that there are still some fundamental limitations with LLMs that may mean they never quite reach the level of reliability we'd like, and there are concerns that the cost of tokens is going to cause some companies to back away from their aggressive adoption.

Whatever the future holds though, we owe it to ourselves to find ways to use the tools we currently have at our disposal as responsibly as possible to generate high-quality software products that can be delivered to production with confidence. If you're a Pluralsight subscriber, I hope that you'll find my course helpful as you navigate how to build production-ready software using AI-assisted tooling.