I’ve been invited recently to a roundtable discussion with other engineering leaders in Austin (big thanks to Jordan Kelly for organizing this!) where we discussed how is AI affecting the engineering teams — from the structure, to the way they operate, to morale and so on. One emerging theme throughout these conversations was the level of trust most teams and leaders put in the code generated by AI. From what I could gather this is quite a big concern for most teams and adds up to the reasons for slow adoption of some of these tools; so I decided to synthesize some of those discussions in a blog post.

A lot of the leaders during this session raised concerns around “vide coding” and AI code generation regarding the quality of the code generated. “How much can we trust the code generated by AI?” emerged as a major concern. Makes sense: if you need your engineers to evaluate every piece of code generated, that ends up hurting the team more than helping — we all know that writing code is easier than understanding someone else’s code. Even more so, these LLMs have been trained effectively on the whole internet, including all the good code that’s out there, the “meh!” code and — more to the point — the terrible code available on so many websites and Github repositories. “Statistically speaking, you are likely to get a mix of excellent and terrible code, so why would we trust this code?” asked my peers. “There is no guarantee that this code is going to hold up in production and not crash my stack.” they continued.

I asked the table how many are using open source libraries (say from Apache Software Foundation, or Spring, or Eclipse, or OpenJS)? — and as to be expected most hands went up. Furthermore, a lot of them confirmed to using a whole bunch of npm packages in their NodeJS projects… and Python packages … and Java libraries… And guess what? 99.9999% of the time nobody bats an eyelid on including one such package, let alone poking their nose in the package source code! We just take it for granted that each of this packages does what it’s supposed to — and even more: that it does it well! And this came from years of building up trust in the “open source” brand. Let’s remember that in its infancy, there were lots of companies who would not go anywhere near open source because of the trust factor; in fact, there are still companies which prefer to do a full implementation in-house rather than rely on open-source (I’m not going to name and shame, there are reasons behind this approach, but believe me that such companies exist).

And what changed for us to get here? Not much really, when you think about it! Arguably the code quality in the open source community has gotten better: we learned from each other, from previous mistakes and successes and the overall code quality has improved. But the major thing that has changed is our attitude towards it: there were early adopters, these early adopters have shown others that you can build products based on open source! And paved the path for more to follow, then more, then more, until in the end the open source “brand” got enough trust that nowadays we don’t think twice before adding a new npm package to our project! We don’t question if the code is correct, or optimal, and just assume that it is! (And then support the consequences when something as simple as an lpad package gets removed from the npm repository!) But we accept that this is a risk, and we have put in various guardrails for it (automated testing, fast CI/CD pipelines, rapid failovers etc), because the risk is counterbalanced a lot by the velocity our engineering teams gain from adopting open source packages! (And by the way, a lot of the open source adopters have zoomed past their competition in the early days, who were too busy reinventing the wheel!)

And if you think about it, using an open source package is not that different to AI-generated code: a 3rd party we know very little about in a way generates code for us! Do you trust it enough to add it to your production stack? Right now it seems the overall level of trust is low across the ecosystem — there’s the builtin human inertia, we want to see others who jump in first, and built our trust in this based on their success stories. (And sadly the people who are posting nowadays about their latest projects built via “vibe coding” are not helping: I am yet to see a project that is worth more than a prototype!) Same as we did with open source. Same as we did when ecommerce emerged: a few years ago it was “guaranteed” that nobody would put their credit card on the internet, right?

But same as with open source and with the others, these things are going to get better, the code quality will improve, the tools will get better and our approaches for dealing with the risk that comes with this are going to allow us to adopt it much more effeciently. We are at the beginning of this transformation, and some have already made the mental leap required to adopt this AI generated code methodologies; we all need to adjust our thinking here I think, trust will eventually build up in this and if we are the last ones to jump on this bandwagon, we’ve probably lost the race.