Before I start, I should mention that I have not yet tried out vibe coding myself. I use AI every day for programming related tasks, but I still write the code myself, for myself. This blog post was inspired by a dream I had last night, after having spent a stressful week thinking about these sort of things. I had to write it down to get it out of my head and make some sense of it.
I started programming "real" applications with Borland Delphi in the late 1990s, when I was a teenager. My first database applications were two-tiered Delphi user interfaces on top of Paradox databases. I did not know SQL and relied only on Delphi's ready-made database components. The user interface was therefore 100% driven by the database schema. It worked, it got the job done, and you could tell that it was a Delphi application only by looking at it.
Then the three-tiered paradigm showed up. You were now supposed to have an application server between the UI and the database. Business logic. Business objects. Web services. Thin clients. Web clients. APIs. I learned PHP and MySQL. Then Java, Spring, and Hibernate. I built UIs with Swing and Eclipse RCP because the old web 1.0 user interfaces felt too restricting.
I heard about Vaadin the first time when I was interviewing for a position at the company (then called IT Mill). I got hired and started my professional journey into web application development with Java.
Back then, our motto was "thinking of U and I". When we gave trainings to other companies, we started by saying that "to the end user, the user interface is the product". Proper UX design was key in all customer projects we delivered. This was a long step away from the data-driven CRUD user interfaces that I used to build with Delphi a decade earlier.
As I worked on customer projects, the biggest challenges were not actually in the user interface, but in the backend. I made lots of mistakes while also cleaning up other peoples' mistakes. Many problems could have been avoided with better architectural design decisions. I learned domain-driven design, first the tactical part, later the strategic part. I read about architectural styles and object oriented design patterns. Decoupling. Separation of concerns. Abstractions. All these helped me build better systems, although it took a while to find the right balance between them.
I started to see system design and coding as a craft, and finished code as an art. There is beauty in well designed and well written software. I bet that's what tailors, carpenters, blacksmiths and other craftspeople thought right before the industrial revolution.
Now look around us. Everything, from clothes to furniture to household items to houses, is streamlined and functional and boring. Mass-produced. Non-customized. Cheap. And gets the job done.
Is this what is happening with the software through the AI revolution? If the code is generated by an AI, the most important artefacts become the specifications and the database. If these are designed well enough, the rest can be generated. And if it can be generated, it can be thrown away and re-generated in the future when a better model comes along.
Is this going to lead us back to the data-driven programming model of the 1990s, where user interfaces where just a thin layer on top of the database? They were ugly, but they worked. If you can get them generated by an AI for a fraction of the cost it would have taken to build them manually, is poorer UX an acceptable trade off? To many people and companies I think it might be.
This in turn makes me question the need for many of the design patterns that I have learned to use and even take for granted. The design patterns we use today were built by humans, for humans. Their intention was to make code bases easy to read, understand, maintain and extend, over long periods of time. If the code base can now be auto-generated, does it matter how it is structured?
Should our focus as developers shift to writing good specs and creating good database schemas, and just accept whatever the AI spits out as long as it makes the tests pass and gets the job done? Do we need to worry about separation of concerns? Decoupling? Layers? Extendability? Should we still think about database normalization or try to design database schemas that are more humane, as they could be used as a basis for UI generation? Should we still be teaching and writing about coding patterns these days? Or should we focus on architectural patterns and start treating the code itself as human-readable byte code?
I know I will continue to make hand-crafted applications on my free time, because I enjoy it - just as there are still carpenters, tailors, and blacksmiths making things by hand (with some help of modern power tools). But professionally, I'm writing documentation and examples for other developers - and AIs - to learn from. And now I'm not sure what level of detail I should focus on. What I have built my career on, and gained all my experience from, appears to become more and more outdated as time passes.
Top comments (0)