People keep searching for the perfect way for coding agents to follow requirements, to review PRs securely, to maintain a deep and readable and technical and formatted documentation. And you have either a new company selling that only them found the perfect solution or someone explaining that we cannot launch real humans to the moon, or create missile embedded code, or a improve MRI machines without the certainty, the quality of human reviewed code.
Every one is screaming and fighting about the right move to do as if nothing exists in the middle.
Really?
It reminds me arguments around micro-services. We are not all Netflix. Or the thumbnails and titles on YouTube videos where they all have the perfect solution (and a face very surprised).
I’m a « seeker of truth » (chercheur de lumière) and I’m afraid of people who claim to hold the truth and think in black-and-white terms. Just take a step back. People compare things with a lot of bias and a very short memory. Was that perfect before AI? Was the code perfectly reviewed? Perfectly aligned with requirements? Without any ‘hallucinations’ from the coders?
But how many lines of SAAQClic code were written by AI? Do you really think it was perfect just because it was created by humans?
I have two decades of experience working in a large ministry. Do you know how much time I had to review code and applications sold to the ministry by big corporation, hands on the heart, selling that as diamonds of engineering, written by trained engineers from the trench, when in reality they were done by interns or juniors straight out of school? What is the relation with AI if the same still happens now?
How many outsourcing projects have failed in Eastern Europe and South Asia due to communication problems with French to English to Local to English to French, poor and badly written requirements, and a lack of recurring control due to the waterfall process. It was bad project management, nothing related to AI. And nothing will change about that, AI or not.
The only change is the actual speed at which the code is generated. And that the source of this code is randomness with statistics.
The guardrails, the reviews, the checks on documentation, the care and love that you have to inject in the craft, the discipline needed to maintain balance between features and technical debt, etc. have not changed.
But that speed amplifies behaviors and results. If you used to accept bad code once a week, now it’s ten times a day. You were thinking ‘Hmm, I think it creates a bit of technical debt but it’s OK now’ from time to time, now it’s ten times a day. You used to think ‘I’ll keep my Friday afternoon to update that part of the documentation, that Definition of Done in these tickets, etc.’, now you are burned by 20 PR reviews generated by agents and it’s only 10 am.
You were a bad engineer? You are now a 10x bad engineer. Congrats. You were a bad project manager, now the result is in two months, not in two years.
And if you were a professional with pride? The effort to keep everything at flow by harnessing, contexting, vibing, skilling, hooking, planing, ultraplaning, clearing, resuming, subprocessing, worktreeing, etc. is overwhelming and changes every week with a new model.
We’re just juniors again, and every day.
Instead of a senior colleague telling us to learn the tools and the shortcuts in our IDE, we now have a swarm of ideas for tests, that change with every new model. With companies spending a LOT of money hoping to be the only survivor of the run.
And uncertainty brings fear, FOMO.
I mean, when you have more process and tools to tests than the flow of new JavaScript Framework, you know that something has gone seriously sideways…
That still created a small shift, instead of teaching your juniors to follow the rules and letting them burn out, from time to time, on chosen problems for them to learn, we tend to adapt ourselves to the way agents work. For example, preparing readable requirements and documentation that will not overtake the context. It’s awful to read it as a human (dozens of small files, instead of a big doc), but makes perfect sense regarding how agents work.
Then there are those who predict that maintenance will be a nightmare. Well, I really do believe that one. Really. But what if we have prepared the system with documentation and tests, and instead of trying to fix bugs written by LLM models from two years ago, we are using the new ones to simply rewrite the whole thing? Just as we start to see that nowadays with some partial SaaS reimplementation from scratch (see “saaspocalypse”).
Just a reminder that ‘old’ people have seen almost all of these problems before, they are not new. The tools are different, the pace is different, the job will be different.
But we just get back to, once again, having to prove that creating computer systems can be a real engineering job, with rules, and craft, and a scientific approach about how to reason to solve problems for our clients. We also have to bear in mind that it’s a business so we have to do all that and also create business value.
And for personal projects, for curious minds, for learning new stuff, etc., what a time to be a dev. I love it.
What about you? Do you ride the wave? Do you feel energized or overwhelmed?