This is the first of three articles about how I see AI adoption in software development within companies and how I'm pushing it forward at TRIBBU, my company.
First, I want to talk about the change itself: what's happening to our work and why I think we're facing a change in the level of abstraction. In the second one I'll talk about how we can govern software development carried out by agents. And in the third, probably the most complicated one, about how to lead people through this transition.
Because technology will probably be the easy part.
We're living through a “turbulent” yet exciting period with the arrival of what we somewhat incorrectly call artificial intelligence into our lives.
Although I think software development is where its adoption has gone deepest, little by little it's making its way into every discipline and more and more people are using it to make their day-to-day work easier and better.
It's true that some people use it to do their work for them. Often badly, especially when that work requires judgment.
And it's also true that if an AI can do your work because that work doesn't require judgment, then your job will, sooner or later, be replaced by AI.
But that's not what I want to talk about.
I want to focus on how to lead the transition towards software development with AI inside companies.
And here I see two different problems.
One is how to “evangelize”, more than convince, how to get them to convince themselves, to “convert”, and get developers to see the enormous benefits it can bring, leaving behind bad past experiences caused by using it without judgment or knowledge.
The other one, much more complicated in my opinion, is how to do it well.
Because right now there's a lot of ignorance, very little accumulated experience and, above all, a huge disparity of opinion about how far we're willing to stop doing what until now we considered our job: writing code.
I'm going to address both problems, but I want to start with the how.
Because I think that if we can answer the how properly, solving the first problem will be much easier.
It will be easier for a programmer to accept delegating an increasing part of their work to an AI if they can trust the system through which they do it.
Because let's not fool ourselves: feeling that something artificial is beginning to do what you've spent years doing, what you're good at and, even worse, what you probably love doing, is hard. Very hard.
But denying the evidence, what's happening, won't make it stop happening. Let's not be like little children who cover their faces and think nobody can see them.
And let's be aware that an AI-native generation is taking shape, and we are responsible for training and educating it.
This generation won't be made up of developers who first learned to program and then incorporated AI into their work. That's us.
They will learn to develop with it from day one.
And those who don't adapt will be overtaken, much sooner than we think.
When Was the Last Time You Looked at Assembly?
Let me start with a question, and I hope the metaphor and the distance between the two things are clear.
When was the last time you looked at the assembly generated by your compiler to check that it was managing registers, memory or loop efficiency properly?
Probably never.
And yet there was an entire generation of programmers who did. Who had to.
Because early compilers generated worse code than a good assembly programmer could write. Trusting them blindly was simply reckless.
Those programmers were right at that moment.
The ones who were wrong were those who turned that temporary distrust into a permanent identity.
Those who ten years later were still arguing that a good programmer had to write assembly while the rest of the world had moved up one level of abstraction.
I think we're already inside that same kind of moment with generative AI.
I'm not saying it's exactly the same.
In fact, there are huge differences, as I said at the beginning.
But conceptually, I see that we're facing another leap in abstraction.
Until now we've been incorporating tools that helped us program. Editors. IDEs. Autocomplete. Frameworks. Stack Overflow. Copilot...
All of them, in one way or another, allowed us to write code more easily or more quickly, with fewer errors or by failing earlier.
But we were still writing the code.
With agents, something different is starting to happen. More and more, we're moving away from saying “I want to write this code” and starting to say “I want this to happen”.
This changes absolutely everything.
Because the leap we're trying to make isn't simply from one tool to another, no. We're moving, with all the obvious differences, from assembly to the compiler, except this time the leap is several orders of magnitude bigger. An exponential leap.
A compiler receives high-level code and generates low-level code. And yes, I know, following deterministic rules and within a bounded space. True. That's why I call it an exponential leap, because we're moving into an enormously more open space.
But we're getting an AI to receive an idea, a need, a specification, some constraints or a conversation and produce software.
And as I've already said, there's vastly more space between one thing and the other, and therefore vastly more things that can go wrong.
And this is precisely one of the big differences compared with a compiler. A compiler is deterministic and verifiable. An agent isn't. It can make mistakes in subtle, plausible and difficult-to-detect ways.
And the skeptic who says that the verification problem hasn't been solved is right. It hasn't.
That's why I'm not saying that we can stop verifying what AI does. I'm saying that verifying it by reading every single line it generates can't be the solution either.
We Get Carried Away With AI
At first the experience is spectacular. You ask it for a function. It does it.
You ask it for an endpoint. Same thing.
You explain a small feature and it changes four files, creates the tests and apparently everything works.
And you think: “Holy shit.”
Then you take another step. You give it something bigger. It starts touching things. Changes others. Interprets something differently from what you expected. Suddenly something doesn't add up. You tell it to fix it. It fixes that and breaks something else. You explain the new problem. It tries again. And shortly afterwards you have a mountain of useless, incomprehensible, unfixable and unmaintainable code.
And you don't even really know when exactly it started fucking everything up.
That's when a phrase we've heard quite a lot appears:
“That's where you can tell whether you really know the fundamentals. If you know how things work, you can review what the AI has done and fix it.” Well, yes. Up to a point.
Because let's be honest. There comes a point where not even Uncle Bob would understand a fucking thing about what it has done.
And, besides, there's a much more important problem.
If an AI can produce code much faster than I can read it, trying to control that AI by reading everything it generates simply doesn't scale.
Some people talk about knowledge debt. But I don't think that's quite it. I think we're mixing two different things.
It's like accepting the compiler but insisting on reviewing all the assembly it generates afterwards. It makes no sense. Especially with today's processors, whose assembly code very few humans are capable of understanding.
Or, at least, it can't be the final solution.
The fact that reviewing the code no longer scales doesn't mean the verification problem has been solved. It means exactly the opposite: we need another way to solve it.
Even more so as agents keep getting better and we give them more and more autonomy.
We need rules. A harness. Guardrails. External mechanisms that the agent doesn't control and that allow us to let it work without constantly looking over its shoulder.
Not to tell it exactly how it has to do things. We don't need that anymore. We need to set the limits, prevent certain actions and check that what it delivers meets what we expect.
But I'll talk about that in the second part.
Having the Tool Doesn't Mean Getting Value From It
And here another confusion appears that I see quite often.
Having access to a tool is one thing and knowing how to get value from it is something very different.
Today practically anyone can open ChatGPT, Claude, Copilot or any other agent and ask it to build something.
That doesn't mean anyone can build a good product.
In the same way that having an IDE doesn't make you a developer, having an AI capable of writing code doesn't automatically make you capable of creating software that delivers value.
If writing code had really been the only barrier to creating good products, by now we should be seeing a massive explosion of disruptive applications.
And I honestly don't see it.
What I do see is a lot of vibe coders paying for advertising to try to sell, again and again, variations of the same worn-out product.
Because code was never the product. The user doesn't want or need our code.
They don't want our hexagonal architecture, our patterns, our framework or to know whether we use microservices or monoliths.
They want to solve a problem.
Code was, and still is, the means to achieve that. Or one of them.
The difference is that this means has just become dramatically cheaper and more democratized.
AI is making it extraordinarily cheap to plant software (a brilliant analogy from the great eduferro).
But planting isn't the same as having a good garden.
Someone still has to decide what to plant, when to plant it and what for. Then it has to be watered, pruned, fertilized, whatever no longer serves a purpose has to be removed, and it has to be adapted when conditions change.
Because software isn't something you build and finish. It's a living thing that evolves, and neglecting it is a great way to end up with a garden bed full of shit.
Someone has to understand the problem. Know what's worth doing and what isn't. Choose between alternatives. Prioritize. Make decisions with incomplete information. Validate. Change their mind and iterate.
And, above all, have judgment to know whether what we've created actually delivers any value.
The barrier to creating software is falling.
The barrier to creating value, not necessarily.
Our Work Is Shifting
That's why I don't think the conclusion is that AI is going to replace software development.
I think our work is shifting, because that work, as it exists today, will be replaced.
One level up.
If before we spent a large part of our effort telling a machine how it had to do something through a programming language, increasingly we'll spend more effort defining what should happen, why, under what conditions and how we can know whether the result is correct.
That requires judgment.
Probably much more than we needed to implement many of the tasks we do today.
And this, for me, is where the truly important change lies.
We're not stopping developing software.
We're starting to stop being necessarily the ones who write every single line of it.
And the Window Won't Stay Open Forever
Every change in abstraction level opens a window of opportunity.
It happened with version control, for example. With CI. With cloud. With infrastructure as code.
For a while, those who adopted it well had a huge advantage over those who said: “We're fine like this.”
Then it stopped being an advantage. It simply became the normal way of working.
I think we're in one of those windows now.
Except this time everything is happening much faster.
Not adapting doesn't mean standing still. It means falling behind.
Because while you keep working the same way, the bar for what we consider normal productivity keeps moving, but this time at a speed that makes it increasingly difficult to jump onto the train once it's already moving.
Today, knowing how to work well with agents is a competitive advantage. Tomorrow it will simply be part of the job.
But as I said before, first we have to solve an important problem, because if we're not going to review every single line produced by an AI...
how the hell do we know whether what it has done is actually right?
That's what the second part will be about.
Top comments (0)