We're using AI to skip the best parts
One thing that’s been bothering me lately is the predominant focus on using AI to complete more work faster, instead of using the time we save with its help to do less but more polished work. Everyone is excited about building whole systems in a weekend, which pushes some sensationalists into proclaiming the death of the SaaS model or even worse – the death of our whole profession. I think all this excitement is somehow missing the point and jumping to conclusions without reviewing the real bottlenecks of delivering software.
How doing better work, faster, can still create waste
In my practice of the so-called agentic engineering I’ve noticed the following pattern: Even though I am accelerating the delivery of things and the perceived quality seems to be very good (better code, more tests, all delivered quickly) I tend to get more waste – modules that does not fit the big picture of a project, several iterations on a seemingly simple database designs and whole functionalities that ultimately do not get used at all. And keep in mind I’m a professional with a ton of experience, I have good judgement, I have the ego of a critical thinker. Why is this happening to me?
Learning and growth most often come from working within constraints and the struggle of failing and finding alternative solutions – and with LLMs we are speedrunning those. Working faster means that we don’t have enough time to dive deeper into the root cause of a problem or actually decide if we need to do something about it at all. Which is why I think the near perfection, that a clever use of LLM can get you, creates an illusion of completion. The quick iteration steers our focus from the task at hand more to the technical execution. And it’s too good not to – we get the dopamine hit from the happy client, we finally have time to write documentation and tests, not to mention the quick buck. In just one year, things that might have taken me a week or two, I can now do in just an afternoon.
Every now and then I come back to the slogan on this sticker: “Just because you can, doesn’t mean you should”. With LLM assisted development we get so much for free (OK not really, but it does feel like it’s for free), that I fear we collectively focus more on the act of producing, rather than planing carefuly or investing our focus and energy in delivering something for the long term.
Most of the great inventions came from place of scarcity, when people were forced to carefully plan their work before jumping into action. Creative work is at its best when it pairs the freedom of unbound experiments with the act of rigorous editing. Not everything we do (however perfect it is or seems to be) justifies its own existence. That’s why ideas need to breathe – we do something, observe it and then decide how to make it better. It is in this act of a pause where a lot of the work gets done. Quite often making it better means just not doing anything at all; without being judgemental about the things we produce we are far less critical about the process and are losing control over them.
Tempo and Rhythm
This whole situation reminded me of a conversation with my mentor at PMI from last year. We were discussing agile and how important it is for the team to be consistent while performing work and how going too fast or too slow can hinder the end result of their efforts. He pointed me to the difference between tempo and rhythm. As a musician I really liked the analogy. Tempo is all about how fast (or slow) you play the part and rhythm is the pattern we play in a coherent and predictable manner, something that somebody can dance to. Besides catchy melody, good songs usually have tempo shifts and use interesting rhythms. Even crazy shit like Meshuggah is something you can tap to. It takes a bit of effort for the patterns to become legible, but once they lock in, they become the only thing that makes sense — and you wonder how you ever missed them.
In the field of software development the rhythm is in the cycle of designing, building, testing, refactoring and discussing a piece of a program. Which is a complex pattern itself, and just like in music complex patterns are very hard to be played fast initially. A lot of my peers are obsessed with speed and quantity they can deliver with LLM assisted development. People, liberated from the need of practice jump straight into doing and when they are done with it, they default to moving on to the next task or even the next project. No time for retrospective thoughts, lessons learned or judgements. Which is kind of sad and a huge miss on the opportunity to meaningfully become better and by extension be able to deliver better work in the future. In the past we were forced to slow down by the reality of writing software by hand and, naturally, had much more opportunities for an interesting rhythm: thinking–doing–thinking–failing–thinking–trying again. Just like Meshuggah we needed rigorous practice in order to perform complex patterns fast. Now we bias towards delegating this practice to a machine and robbing ourselves of the act of growth, which ultimately puts the quality of our work at risk.
The code is rarely the problem in IT projects. The bottlenecks are always around creating collaborative environment, understanding the client needs and delivering something that can stand on its own without doing too much or too little. Yes, creating another SaaS in a weekend is impressive, but it misses the point of building software – to automate a process and free people to focus on the actual stuff that moves their companies forward. This rush of code generation is more of a flex: “Look now I can do it myself, I don’t need anyone” – it makes you feel powerful but only for a while. To actually deliver long-term value you have to first understand the problem at hand, live with it for some time, and only then try to solve it. Another common missconception in our industry is that software can ever be done. When a program is delivering on its promise, the people using it expand on it. Want more out of it. This is why the end product also has to hold up — be secure, maintainable, and be something you'd actually want to support a year from now. Yet another area that needs big picture thinking that needs human in the loop and can not be fully delegated to an LLM.
The three stages of work
I've come to think of any project as having three stages — the thinking work upfront, the (hopefully) lean execution in the middle, and the solid delivery that either validates or exposes the first two.
In my opinion the first part – understanding what we are about to do is the most important, sadly it’s the one that we usually cut corners with. As makers we are subconsciously inclined to jump straight into action, as professionals – pressured by tight deadlines. It seems that we never spend enough time doing the prep work and this leads to a lot of frustration and waste down the road. This is exactly where AI can help us slow down and do better. Let's use it to question our own assumptions rather than generate answers. Personally answering more questions takes just as long, but it makes you more focused and keeps you in the problem solving mode for longer. Collaborating with an LLM will not accelerate this stage, but it can help you improve your understanding and provide the groundwork for a better solution. This is why I don't like all these videos on YouTube teaching you how to generate PRDs fast – by saying “you are an experienced business analyst” you are prompting your creativity away. Without the struggle of finding a solution, it's hard to feel invested in implementing it. Not only is this a missed opportunity for growth and learning – it numbs your attachment to the work itself and makes it much harder to build the motivation to see it through.
Another way of using AI without losing my own agency is creating many more prototypes and POCs in order to preview the vision for a project in practice earlier. This is what is great about code now being much cheaper – a year ago we couldn't do this. Now, after we’ve done the heavy lifting of understanding the problem, we can prototype with minimal investment and validate our ideas early and at more points during the project lifecycle. It’s our taste that’s most useful here. Having good taste comes with years of practice – experiments, successes, failures and building biases. No machine can tailor the client experience like that because this is a very personal ability. The Paris Fashion Week still exists despite most people buying cheap knock-offs from TEMU. There’s a reason for that: Good design needs professionals who can justify their own taste and use it to cut out the bullshit. We should not delegate our judgement to anything else.
I learned how to code out of necessity – I never fully enjoyed everything involved in it, but this was the price I had to pay in order to be able to create something out of nothing. I kept improving my craft with the clear understanding of what I enjoy (learning, creating systems, building smart UIs, sharing the joy of a great program with its users) and what I absolutely hate (fixing bugs, creating yet another boring CRUD interface, managing CI and deployments). LLM-assisted coding can now help me focus on the stuff I like – instead of writing tests for example, I can explain what is my definition of a good test and then send it over for the machine to do it for me, while I tinker with the UX or improve the project with what I’ve learned from my last demo.
This is also where I struggle the most with tempo and rhythm. With Claude I can build something good and feel good about it, then wait for 5 minutes until I see the next one. This TikTok-ifies the whole process and makes me lean dangerously into multitasking several features at once or trying to juggle between creator and editor modes, which gets me out of the flow. What I started doing (and encourage others to try) is to schedule more demos to balance the acceleration in the build process. I want to introduce more points at which we can discuss and improve on what we are building, more opportunities to stop and ask ourselves “Are we still on the correct path?”. With the current state of LLM proficiency we are already living in a sci-fi future and we need to change and improve the process, not the tools. It's counter intuitive for me to jump straight into the next thing, while I can use these powerful tools to make the current one better. And acknowledging when something is good enough is still matter of professional judgement.
Even with all the AI in the world, companies will still need somebody to rely on for a serious solution. An experienced professional with taste that can help defining the “what” and then delivering a solid “how”. Somebody to own the production and the risks. Inside companies, LLMs will empower a lot more people to move faster without waiting for a developer or budget. Which is great – more time for both of us to focus on the work that actually matters! In the age of bespoke software (and cheap effortless slop) we would need better and more open SaaS products that can give our clients solid foundation and even smarter and more adaptable consultants to lead these projects to success. Let's stop participating in this diversion and go back to the thing we need now more than ever: keep improving our craft. In the end of the day we are signing off whatever we make, AI-assisted or handmade, with our names. And I want to be able to put my name under my work with confidence and pride.
PS: Hey, hello there! I’m Vestimir, a maker and occasional artist. This is my first post in ages. Last time I wrote about pricing and the fear of big tech screwing up indie apps (foreshadowing is a literary device). Write back if any of this resonates with you – let’s make the web fun again.