Stop writing the same concerto

There’s an old jab at Antonio Vivaldi, usually credited to Stravinsky:

“Vivaldi didn’t write 500 concertos; he wrote the same concerto 500 times.”

It’s unfair to Vivaldi, who was a genuine innovator. But the joke lands because we all recognize the thing it describes: work so faithful to the strict rules of music theory that every output is predictable.

I come at this from an unusual angle. Before I got into software engineering, I spent 20 years as a professional organist and conductor, and I played bassoon and French horn along the way. I’ve performed music that follows the strict rules of music theory to the letter and music that throws those rules away, and I know which performances audiences talk about on the way home.

Some developers want their AI to be exactly that. Same prompt in, same code out, every time. I think that instinct is understandable, and I think it’s wrong. Building VoxyAI, where every model runs on your own hardware, has convinced me that the variety is the point.

From rules to expression to chance

Western music spent three centuries slowly letting go of predictability, and each step made it more alive. I lived inside this history for two decades, from the organ bench, the podium and the middle of the orchestra.

The Baroque and Classical eras prized form. Vivaldi was technically Baroque, but the ideal carried straight into the Classical period of Haydn and Mozart. Sonata form, balanced phrases, a key you leave and return to exactly as expected. The genius was in mastering the rules, and a trained listener could often predict where a movement was going. It was beautiful, and it was close to deterministic.

The Romantics broke the mold on purpose. Beethoven stretched the forms until they cracked. Berlioz wrote a symphony about an opium dream. Liszt and Wagner bent harmony toward pure feeling. The question stopped being “is this correct?” and became “does this move you?” Two Romantic composers handed the same theme would give you two completely different pieces, and that was the point.

The 20th century invited chance in. Stravinsky’s Rite of Spring caused a near-riot in 1913. Then John Cage composed Music of Changes by consulting the I Ching, and Terry Riley’s In C gave performers 53 short phrases and let them decide when to move on. No two performances of In C are the same. Nobody calls that a defect.

The arc is clear. The more music embraced variation, the more room there was for surprise. That’s the arc I see in software right now.

Deterministic is the wrong goal

For fifty years, software meant determinism. A function given the same input returns the same output. Compilers, databases and payment systems depend on it, and they should.

So when developers meet a language model, the first instinct is to tame it. Set the temperature to zero. Pin the seed. Write a prompt so rigid the model has nowhere to go. Then complain that it still drifts.

I think that’s fighting the instrument instead of playing it. A language model doesn’t look up an answer. It samples from a space of plausible answers. Asking for the same output every time is like hiring a jazz trio and asking them to play a Vivaldi concerto.

Variation gives you things a deterministic tool never can:

• Options. Ask twice and you get two approaches to the same function. Sometimes the second one is the one you wanted.
• A way out of dead ends. When a model gets stuck on a bad idea, a fresh run or a different model often walks right past it.
• Something to compare. Two different answers tell you more than one confident answer. Where they agree, you can relax. Where they differ, you should look closer.

This doesn’t mean anything goes. Determinism still belongs somewhere: in your tests, your type checker and your build. Let the model improvise, and let your tests keep time. The creativity happens in generation. The rigor happens in verification. Mixing those two jobs up is how people end up disappointed with AI.

Same prompt, different models

Running models locally makes the variety impossible to ignore. Ask a few of them to write the same function and you’ll get a small ensemble, each with its own voice.

A compact model answers almost instantly and gets the common case right, but it may skip the edge cases. A mid-sized general model writes cleaner, more complete code and explains itself well. A reasoning model like DeepSeek R1 thinks out loud first, takes longer, and is more likely to catch the off-by-one you’d have shipped. Different training, different size, different personality.

None of them is “the right answer.” They’re different interpretations of the same score. Sometimes the fast model’s version is exactly enough. Sometimes you want the one that agonized over it.

On a cloud service you rarely see this, because you get whatever model the provider picked. On your own computer, the models are yours to swap, compare and keep. That changes how you work. Trying another model costs nothing but a few seconds.

Picking the right player for the part

If variety is good, choosing among it shouldn’t be a chore. That’s why VoxyAI recommends models based on two things: what your computer can run, and what you’re trying to do.

Your hardware sets the stage. Running a model is mostly about memory. VoxyAI checks how much your computer has and only shows models that will run well on it, with each one’s size, memory needs and what it’s good at. No guessing, and no downloading 40 GB only to watch your computer grind to a halt.

The job picks the model. Dictation wants speed. Coding wants quality. A tricky bug wants reasoning. So VoxyAI lets you set a different model for each kind of task. Here’s what it suggests on a computer with 24 GB of memory:

A computer with more memory gets bigger models. One with less gets smaller ones that still feel quick. Everyone gets a sensible starting lineup.

A second opinion is built in. With two or more models, VoxyAI can use one as a judge to check another’s answer for clear mistakes. That’s the ensemble idea put to work: one model improvises, another listens critically.

Be willing to try things

The developers I see getting the most out of local AI aren’t the ones with the perfect prompt. They’re the ones willing to experiment. A few habits that help:

• Run it twice. If the first answer is close but not quite right, ask again before you rewrite the prompt.
• Switch models when you’re stuck. A different model brings a different set of instincts. Treat it like asking a colleague.
• Match the model to the moment. Use a fast model for quick edits and terminal commands. Save the reasoning model for the bug that’s eaten your afternoon.
• Let disagreement guide you. When two models write different solutions, the difference usually points at the part of the problem you haven’t thought through.
• Keep your tests strict. Experiment freely in generation, because your tests will catch anything that doesn’t hold up.

None of this is wasteful when the models run on your own hardware. There’s no meter running, so curiosity is free.

Write a different concerto

Vivaldi’s critics weren’t really complaining about repetition. They were reacting to the absence of surprise. The music that followed him earned its place by taking risks: Beethoven bending the rules, Cage handing decisions to chance, Riley trusting the players.

AI-generated code is at a similar turning point. You can spend your energy forcing every model into the same predictable shape. Or you can treat the variety as a resource: try a different model, run it again, compare the takes, and let your tests decide what ships.

I built VoxyAI so that kind of experimenting is free, private and one click away. Every model runs on your own machine, recommended for your hardware and the job in front of you.