Vibes
Well, Gaza genocide resumed, US is on a worrisome trajectory, no one moved a finger about negligence in the Kartalkaya Resort homicide, the strongest presidential candidate for the next Turkish elections had his university degree revoked and then detained overnight, Tomer Sharon passed away. I can't say this is a great week 🖤
Let's talk about vibe coding and vibe design.
Some people use LLMs to generate text. This capability allows them to write in languages in which they are not strong with grammar. Using this capability, they can emulate tones of speech in contexts they are not knowledgeable about.
Some people use LLMs to generate code. Code generation with LLMs uses the same predictive principles as generating text. That is, the LLM doesn't know what it is coding, it just calculates the most likely piece of code that most likely matches the statement by the LLM user.
Experienced programmers use this predictive capability to automate cumbersome but low-value tasks. For example, adding unit tests to code, revising integration tests for multiple endpoints or porting code from old programming languages of which they may not have a full command. The LLM produces some code, the LLM doesn't know what it does and why it does it, and the experienced programmer makes a call about whether it does what it is supposed to do. This LLM-powered cycle usually saves the experienced programmer's energy for more complex tasks and saves a ton of physical keystrokes.
Inexperienced users, on the other hand, do not have the knowledge to make this judgment call. They do not know how code works. They do not know why LLM-generated code is written the way it is. Remember, the LLM doesn't know this either - it just regurgitates what it has been fed.
So no one in this coding loop, neither the novice user nor the LLM, knows how the code works, what it does and why it does it. This approach is so common now that it has a name: Vibe coding.
Ars Technica has a great article about this:
Benj Edwards
A similar approach is suggested for design by Jakob Nielsen. I must say that his recent AI over-enthusiasm is very cringe and off-putting, but he has many valid points in his blogpost on Vibe Design.
I can see a lot of similarities between the vibe coder and the vibe designer described by Nielsen:
-
A vibe coder doesn't understand what the code does and why it does; a vibe designer doesn't understand what layout and flows do and why they are the way they are.
-
A vibe coder can't fix problems because they are so disconnected from the domain. It is easier for a vibe coder to completely regenerate large chunks of code from scratch until they are bug free instead of trying to debug the code. Similarly, a vibe designer doesn't understand what doesn't work in a flow and can ask for infinite number of alternatives until one "looks right".
-
A vibe coder doesn't care about maintainability, because if there is a problem in the future, they will just regenerate the entire codebase and hope that it works! A vibe designer relies on "AI-generated research" to foresee issues and if the "insights" turn out to be hallucinations, well, they will just ask for alternatives!
Vibe coding can create wonders in areas where we don't care about correctness, edge cases and maintainability. For example, this approach has an amazing potential for creating simulations: very high-fidelity prototypes that are so detailed that they create the illusion that they are actually working.
Vibe design as described by Nielsen, on the other hand, doesn't seem to have a good use case. The only use case I could think of is to give a vibe design tool to a decision maker who doesn't get the field of user experience, let them use it to create millions of alternatives, let them burn themselves out with choice fatigue by reviewing those million alternatives, let them feel designerness in an isolated environment where they can baste in their ego without taking up the time of other people, and then let them finally pick a final alternative. An actual designer takes this piece, fixes what can be fixed at that level, and ships it.
I am not buying into Nielsen's inflated vibe design articulation. However, there is great potential for throw-away programs. This has been a recurring theme in the history of computing. For example, some features of FORTRAN (an old but robust language for data analysis) were built into spreadsheets, so that non-programmers could perform complicated calculations with variables without having to code. This was OK, because these spreadsheets were used only locally, inside small communities. Ironically, you can ask the LLM in Microsoft Excel today to code you very small, very focused python scripts for detailed data analysis that goes beyond Excel's capabilities. (If you don't have Excel, see the video at the end of this issue)
LLM-generated programs have the same great potential and they are exciting if they can be a part of proper user research someday.
This also has implications about what designers do. I hope to write on that in the coming weeks.
Designing with AI 2025
I will be speaking at Designing with AI 2025 in June. I am so excited to share what we have learned from Boost 11 Plus, a math tutoring app for kids in UK. I'm extra excited because, in the organizers' words, "this is not a rah-rah AI conference." I look forward to interacting with the responsible design community that doesn't buy into the hype.
Here is the conference website. You can get a $75 discount if you use the code BILGEN-DWAI2025 at the sign up.
Reads
It's Our Research: In memory of Tomer Sharon. Also have a look at the topics he covered throughout the years on his Speakerdeck profile.