Technological Thoughts by Jerome Kehrli

Following this post on linkedin, I thought that I could share one of my own experiences.

A fairly senior developer had an idea for a new product and spent a couple of weeks vibe-coding it. Hundreds of prompts, lots of iterative .md plans and in the end more than half a hundred thousands of lines of code produced in a surprisingly short time.

When the project reached (what was deemed) a first "complete" state, it was handed over to me to take care of the remaining steps, mostly industrialization concerns: CI/CD pipeline and deployment automation, database migrations, security review, that kind of things.

At first glance, I was honestly impressed. That was really a lot of work delivered very quickly.

But as an architect, I tend to look at things through a slightly different lens: overarching structure, code quality, consistency, maintainability, testability... all the boring but essential stuff.
So before jumping in, I spent some time trying to understand where things stood on those aspects.

Well I guess I got a good grasp on the feelings Pandora must have experienced when opening her famous box.

While there were a few good ideas in there and clearly a lot of energy put into it, it was first and foremost lacking consistency all over the place: different architectural patterns used in parallel, some partially applied, some overlapping. Seldom parts of the codebase felt somewhat solid, but most of it was lacking even a minimal design. There was some dead code, quite a few tests but most that didn't pass, and overall again a lack of a clear, unifying structure.

It was the most chaotic codebase I've ever looked at.

The result is that what took roughly two weeks to build would now require a significant amount of time to consolidate, refactor and bring to a proper production-ready state, mostly because it wasn't shaped progressively along the way. I estimated it to 3 months, minimum.

So the "2 weeks" is nothing more than an illusion.

To be fair, even with that, there's still a net gain. If I compare it to building everything from scratch without any AI assistance, I'd probably estimate something like 7–8 months. So ending up around 3–4 months total is still a very decent improvement.

But the second phase, the cleanup and consolidation, is where things can get really tricky and cause quite a bit of a headache if everything is deferred until the end.

The key takeaway

The real leverage with these tools isn't just speed. It's how one uses that speed.

If the architectural thinking, refactoring and validation are done continuously during the process, not postponed, then the outcome is very different. One can still move quite fast, but one also keeps the system coherent as it grows.

In that scenario, I'm pretty convinced the whole thing could have landed in a solid production-ready state in maybe a couple of months, without the heavy stabilization phase afterward.

So the issue isn't vibe-coding itself. It's doing it blindly for too long without stepping back, reviewing and reshaping.

There's a whole world of a difference between "code that works" and "code that's ready to live in production."

(Source : https://medium.com/kairi-ai/how-to-vibe-code-without-creating-tech-debt-04b3ce7d29e1

How I personally use AI

For me, AI is a coding assistant. A very powerful one, but still really just an assistant.

I use it for things like these (among others):

• writing utility functions I don't want to spend time on
• helping with large refactorings
• generating straightforward unit tests
• wiring things end-to-end (API - service - DB - migration script)
• quickly prototyping ideas

Basically, all the repetitive or low-value parts where it's amazingly helpful.

And every time it produces code, I go through it carefully. Line by line when needed. And quite frankly, I do have very frequently things to say on these lines.

But then where it really shines as well is outside of pure coding:

• challenging design ideas
• helping explore (and even deploy!) unfamiliar tech
• debugging tricky issues
• spotting potential performance hotspots or security concerns
• etc.

Sometimes it misses obvious things and that's fine. But sometimes it surfaces insights surprisingly fast, and that's where it really feels like a force multiplier.

At the end of the day, tools like Codex or Claude Code feel like superpowers.
But they're MY superpowers, not autonomous developers.

So how much faster in the end?

I'd say that my extensive use of both Claude Code and Codex (they each have their own strengths) gives me roughly a 4x boost in my overall TECHNICAL productivity.
(They definitely don't help with slides though. Forget about that. It's rubbish.)

And that kind of gain is amazing. A real game changer.

Test Driven Development is a development practice from eXtreme Programming which combines test-first development where you write a test before you write just enough production code to fulfill that test and refactoring.
TDD aims to improve the productivity and quality of software development. It consists in jointly building the software and its suite of non-regression tests.

The principle of TDD is as follows:

1. write a failing test,
2. write code for the test to work,
3. refactor the written code,

and start all over again.

Instead of writing functional code first and then the testing code afterwards (if one writes it at all), one instead writes the test code before the functional code.
In addition, one does so in tiny small steps - write one single test and a small bit of corresponding functional code at a time. A programmer taking a TDD approach shall refuse to write a new function until there is first a test that fails - or even doesn't compile - because that function isn't present. In fact, one shall refuse to add even a single line of code until a test exists for it. Once the test is in place one then does the work required to ensure that the test suite now passes (the new code may break several existing tests as well as the new one).
This sounds simple in principle, but when one is first learning to take a TDD approach, it does definitely require great discipline because it's easy to "slip" and write functional code without first writing or extending a new test.

In theory, the method requires the involvement of two different developers, one writing the tests, then other one writing the code. This avoids subjectivity issues. Kent Beck has more than a lot of examples of why and how TDD and pair programming fit eXtremely well together.
Now in practice, most of the time one single developer tends to write tests and the corresponding code all alone by himself which enforces the integrity of a new functionalities in a largely collaborative project.

There are multiple perspective in considering what is actually TDD.
For some it's about specification and not validation. In other words, it's one way to think through the requirements or design before one writes the functional code (implying that TDD is both an important agile requirements and an agile design technique). These considers that TDD is first and foremost a design technique.
Another view is that TDD is a programming technique streamlining the development process.
TDD is sometimes perceived as a way to improve quality of software deliverables, sometimes as a way to achieve better design and sometimes many other things.

I myself believe that TDD is all of this but most importantly a way to significantly reduce the "Total Cost of Ownership (TCO)" of software development projects, especially when long-term maintenance and evolution is to be considered.
The Total Cost of Ownership (TCO) of enterprise software is the sum of all direct and indirect costs incurred by that software, where the development, for in-house developped software, is obviously the biggest contributor. Understanding and forecasting the TCO and is a critical part of the Return on Investment (ROI) calculation.

This article is an in depth presentation of my views on TDD and an attempt to illustrate my perspective on why TDD is first and foremost a way to get control back on large Software Development Projects and significantly reduce their TCO.

After almost two years as Head of R&D in my current company, I believe I succeeded in bringing Agility to Software Development here by mixing what I think makes most sense out of eXtreme Programing, Scrum, Kanban, DevOps practices, Lean Startup practices, etc.
I am strong advocate of Agility at every level and all the related practices as a whole, with a clear understanding of what can be their benefits. Leveraging on the initial practices already in place to transform the development team here into a state of the art Agile team has been - and still is - one of my most important initial objectives.
I gave myself two years initially to bring this transformation to the Software Development here. After 18 months, I believe we're almost at the end of the road and its a good time to take a step back and analyze the situation, trying to clarify what we do, how we do it, and more importantly why we do it.

As a matter of fact, we are working in a full Agile way in the Software Development Team here and we are having not only quite a great success with it but also a lot of pleasure.
I want to share here our development methodology, the philosophy and concepts behind it, the practices we have put in place as well as the tools we are using in a detailed and precise way.
I hope and believe our lessons learned can benefit others.
As a sidenote, and to be perfectly honest, while we may not be 100% already there in regards to some of the things I am presenting in this article, at least we have identified the gap and we're moving forward. At the end of the day, this is what matters the most to me.

This article presents all the concepts and practices regarding Agile Software Development that we have put (or are putting) in place in my current company and gives our secrete recipe which makes us successful, with both a great productivity / short lead time on one side and great pleasure and efficiency in our every day activities on the other side.

I've been working a few years ago on an architectural concept for some very specific piece of software my former company had to develop. The technical challenges were huge and the field was pretty complex. In addition, the timeframe was very little and we have had to rush a lot to get it ready and prototyped in time.

In the end we screwed up ... totally. The concept was miles away from what was required and we pretty much had to start it all over. Months of work were just good enough to be thrown away with the trash.

Not used at all to such failures, I decided to take some time to understand what happened, what went wrong.

My investigations led to the following story, a pretty funny though quite common developer tale.