Category: Programming

Vibecoding Demo

I released a short demo of AI assisted vibe coding to the youtube channel. Basic games like this are one of my favorite use cases for vibecoding. LLMs are pretty good at it and the pay off is quick. Back in my teens I tried to learn programming to make games. I’d have gotten a lot farther if we’d had AI then instead of trying to figure out C++ from a two inch think book!

To learn more about AI assisted ‘vibecoding’ check out the book Code Without Learning to Code at https://codewithoutlearningtocode.com.

An Excellent AI use case: Generating PlantUML and Mermaid schemas.

If you’ve ever worked with PlantUML or Mermaid before it’s easy to forget the domain specific language used to build the diagrams. You sketch out your whiteboard diagram, discuss it with coworkers and are ready to start on your architecture document only to sit there stumped trying to remember how to convert your drawing into PlantUML.

Well the good news is that Claude can do it for you. Just take a picture of your whiteboard and Claude can convert it into Mermaid or PlantUML for you. I tried both and Claude is better at Mermaid but can do PlantUML.

Unfortunately, Claude’s first attempt had an error. I fiddled with it a bit in the editor, but Claude was able to fix it faster than I was.

Claude fixed the issue and I was able to generate the following PlantUML visualization.

Here is the original image compared against the PlantUML Claude generated. The relationships are correctly mapped even if the physical placement is a bit different.

Lastly, I asked Claude to do the same thing with the Mermaid diagram visualizer. Mermaid does the same things as PlantUML, it’s just newer and easier to use.

To my surprise Claude not only managed to do it in one attempt. But Mermaid is built into the Anthropic UI.

If you’re ever stuck trying to remember the PlantUML DSL just ask Claude to do it.

Trying a new language won’t solve your development problems. 

I’ve had a conversation where someone proposes trying a new language like Go or Scala or Typescript for new development several times. Typically, the argument is that we have problems x, y and z with our current language and they would all be better under $new_language. The arguments are always things like x has better performance, y has better typing, z is more functional. 

There is no free lunch within modern programming languages. There are no opportunities to switch to a new language without paying new costs. Java requires a lot of boiler plate and is very heavy weight. Typescript is async by default and has non-reliable typing. Go has a litany of problems (tool chain, exceptions, generics, etc) downstream of Google making all the serious decisions for the language. Rust is very strict and gives you excess performance you can’t use. 

Switching between any of the modern languages means trading some benefits for some negatives. Unless you have a serious problem with your current language you are unlikely to gain anything. 

An exception is switching from Ruby, or Python to something like Java or Go. Then you would gain a lot of performance. But first ask yourself whether any of your services max out a single server. Are you even using instances larger than your laptop? Can the performance problem be solved by a refactor and re-architecture in the same language? Re-writing is time consuming and if your team already knows Ruby a re-architect in the same language will usually be faster and produce better code. 

Programming languages have trade offs. Switching is an expensive process. It always takes longer and costs more than you expect. And after it all by switching languages you are just switching old problems for new problems. 

Please don’t learn software architecture off the internet 

The internet isn’t the best place to learn software architecture. While you can quickly read about dozens of novel ways to structure software applications the internet tends to pull people towards poor solutions. 

Software architectures are ways of structuring software to support various demands. 

– development speed

– hardware platform (web, mobile, point of sale, drone, etc)

– team structure 

– ability to scale aggressively (If we get a big customer can we scale 100x quickly)

– correctness       (How often do we produce an incorrect result)

– recoverability    (how quickly can we recover from failures)

– supporting a particular load range (100-300 request/second)

– software engineering team competency

The problem is that the internet talks about interesting architectures preferentially over appropriate architectures. If you learn about architectures on the internet you will hear primarily about solutions developed for global scale corporations. These corporations typically employ the highest paid, most experienced engineers on the market and have large operating margins to work with. 

These ‘cool’ architectures typically support billions of operations per day and involve the efforts of 100s to 10,000s of engineers. Then the architect for a team of 20 engineers reads a blog post and decides we need ‘microservices’ or we need ‘event driven’. This sounds reasonable in a meeting. We ‘need to be able to scale if we get a big client’ sounds true. But it’s not. 

People do not understand software scaling. To humans ‘one million records a day’ sounds like a lot. To computers that is only 11.5 records per second, something a single virtual machine running python can handle easily. 

One million 10KB records per day is a problem you buy one hard drive per year to solve. 

If you primarily learn about software architecture online your focus is driven towards optimal hyper scale solutions for hyper competent teams. Your team is not likely to be hyper scale or hyper competent. The ‘software best practice’ for normal teams is not the same as for google. Finding the appropriate software architecture for your company probably requires logging off and talking to experienced ‘enterprise’ engineers.