Use Your Brain: Engineering Standards in the Age of LLMs – P. Galeone's blog

Use Your Brain: Engineering Standards in the Age of LLMs

Jul 26, 2026

8 minute read

Author: Paolo Galeone

Software development is not a niche anymore. The advent of LLMs made it possible for everyone to write their own software - and this is a good thing. However, I see a huge number of software engineers (the real ones!) falling into the vibe-coding trap. Those people were used to design - think! - and later implement. Now, instead, they are just producing a huge amount of dubious quality code, something that I would expect from the average Joe, not from a qualified software engineer.

To be clear: I’m sharing my own philosophy here, not preaching a gospel. I’m not trying to convince anyone to adopt my workflow.

The velocity trap

LLMs produce code at the speed of light, they crunch and generate tokens1 and give you pretty much what you asked for. Depending on the codebase size and status, the usage of LLMs should be correctly guided - and companies and solo-developers are not following any clear guideline apart from “deliver fast”.

Delivering fast is perfect, if and only if, you are developing your own script, for yourself, starting from an idea and seeing it working in minutes.

Delivering fast becomes a problem when the tool you developed exits your garage and starts being used by others. Immediately, issues start to pop up and you have to fix them. You can ask an LLM to fix them - and this is precisely how you’ll lose control of your codebase.

Let’s think about the concept of code ownership for a second.

Is a fully generated codebase really your codebase? I have a rule of thumb for understanding it.

If you can explain how the code works and pinpoint bugs on your own, it’s your codebase. But if you rely on an LLM for every single edit, you aren’t managing software - you’re just letting an AI manipulate random code you no longer understand.

When the codebase you’re working on is not yours and it is a massive work being developed by several developers over the years - delivering as fast as possible is still a goal (not the only one. I’m not a fan of speed at all cost. I prefer well designed solutions, with initial effort and a steady ramp up afterwards). You can develop as fast as possible with the help of AI - but you need to be very careful about everything that’s committed, potential side effects, tests to be kept up-to-date and best practices to respect. At the very end, even if the LLM generated part or even all the code, you should be able to tell what the LLM did. If, instead, you just throw an LLM over any open issue and no software development process is stable and mandatory, then this codebase goes out of control quite fast, and no-one knows what’s happening anymore very quickly.

Being pushed to deliver as much value as possible in the shortest time possible, makes everyone a cowboy coder - every good software development methodology is seen as a problem, not as something that brings value (here’s the trap). After all, what really matters (and - in pathologic organizations - what is measured and evaluated as a good thing) is the development speed, isn’t it?

Ownership vs Custodianship

Do you want to move fast only? Or do you want - also - to build something maintainable, scalable, secure and that you really own?

If you’re a pure cowboy, you just care about getting things done as fast as possible, and perhaps delegate the maintenance of your code to someone else after doing the first PoC - understandable, but it’s not scalable and whoever inherits your cowboy-developed codebase is going to look at that code, wondering if rewriting it from scratch makes more sense, and blaming you for your (not really yours) design decisions.

Being a cowboy you have no ownership, you are acting as a custodian rather than an owner. The whole mental model and the relationship with AI changes when you’re an owner vs a custodian. The cowboys see the codebase as a black box more or less, they just know what goes in, what comes out, but the internal logic is blurred. They rely on the LLM to do the heavy lifting, from design to execution and debugging.

The fun part is when bugs happen: they can’t debug their own (own?) code, and they can only hope the LLM knows how to fix the code.<br>Of course the core value is raw speed and immediate output (fast fast fast!).

Who wants to be a cowboy? I, as a software engineer, don’t. I see myself, and all the software engineers, being owners rather than custodians. The owner mental model is different: they have a complete map of the system in their head, they know why a specific architecture was chosen and where the edge cases hide. How changing something in a module affects other dependent modules. Their relationship with AI is more healthy too: they use the LLM as a productivity/speed booster. Every output is reviewed and the committed code can be explained, line by line. In case of bugs,...