Ben “Baz” Vale: Try many approaches. Ship one.
By Ricky Robinson
If you asked me what might make an ideal background for an engineer at Shorthand, I might say tools for print publishing crossed with video game development.
One gives you structure, narrative, and respect for content. The other brings interaction, rapid prototyping, and moments of delight that make things feel alive. Together, that’s someone who understands both how stories are made and how they come to life.
That’s Baz.
Welcome to the first in our series of one-on-one discussions with members of the Shorthand team. In this series, you'll meet the people who build Shorthand, our company and its products. You'll learn about what drives them, how the work they do helps to build a beautifully informed world, and why they love being part of our band of geeks with art and heart. Let us know what you think.
Now, back to Ben, or Baz as he's known.
Before joining Shorthand, Baz had two distinct careers.
The first was in game development, where he spent 15 years working across everything from Game Boy to Xbox and mobile. It was a time when constraints were real—tiny amounts of memory, limited processing power, and no room for inefficiency.
“16 megahertz processor, like eight kilobytes of RAM. I couldn’t use the divide symbol for the first five years of my career.”
It forced a certain way of thinking. You had to be sharp. You had to make things work.
Later, he moved into web development, working on tools for print publishing—books, magazines, scientific content. Different domain, same kind of challenge: take something unclear, and figure out how to make it real.
“We’ve got this crazy idea… I don’t know if it’s possible at all, but could you find a way to do this?”
But there was a problem.
A lot of the work never shipped.
“I did heaps of really cool work that just never saw the light of day.”
That’s the kind of thing that slowly kills motivation. Interesting problems, no real-world impact.
Shorthand was the opposite. Real customers. Constant publishing. Work going live all the time. That mattered.
Baz doesn’t spend much time debating ideas.
He builds them.
“If there’s an idea, I have to throw a prototype together immediately.”
And not just one version.
“I would generally have two or three opposing ideas… that compete to become the winner.”
That’s the loop:
Try stuff.
See what works.
Kill what doesn’t.
Ship the winner.
A lot of code gets thrown away.
“A big part is… knowing it wasn’t the right thing and then just delete it.”
That sounds brutal, but it’s the point. You don’t get attached. You optimise for outcomes, not effort.
AI has only amplified this. Where before you might try one or two approaches, now you can run several in parallel. The cost of being wrong has collapsed. The only thing that matters is how quickly you converge on something that works.
That mindset shows up clearly in the Creative Companion.
The goal wasn’t to bolt AI onto the product. It was to make the product better for the people already using it.
“I wanted it to be a tool that people who were already really good… it would just make them better.”
In practice, that means removing friction.
Small things, but meaningful:
- fixing repetitive formatting in one go
- rearranging charts instantly
- making quick UI changes without hunting through menus
“Remove the label on the right… why waste my time?”
It’s not about replacing the user. It’s about speeding them up.
One of the more interesting shifts has been how the AI itself is built.
Early on, everything sat in one large system prompt. It worked, but it got bloated. Harder to control. Slower. Less precise.
So Baz changed it.
“We took the size of it down… and moved a whole bunch of those things into tiny little skills.”
Instead of one general-purpose brain, the AI now pulls in specific capabilities as needed. The result is sharper, faster, and more reliable.
A good example is chart sections. Before, the AI would generate multiple frames with essentially the same chart repeated. Structurally correct, but not useful.
Once it understood the intent—that charts are there to tell a story over time—the output changed completely. Data evolves across frames. The story becomes clear.
That shift—from structure to intent—is where things start to get interesting.
Ask Baz what “great” looks like, and the answer isn’t more features or more control.
It’s the opposite.
“We’ve already picked all the best kind of stuff… it’s almost impossible to make something bad.”
Great is:
- intuitive
- fast
- occasionally surprising
Those small moments where something just works—or does something slightly better than expected—matter more than any feature list.
There are trade-offs.
When generating a full story from a prompt, for example, the choice was to optimise for speed over perfection.
“You want something really fast that’s pretty good… not something excellent that takes a long time.”
Because the output isn’t the final product. It’s a starting point. Something to iterate on.
That pattern shows up everywhere:
Automate the tedious parts.
Speed up the loop.
Keep control with the user.
What’s changed most over the past year isn’t just the product. It’s the pace.
“The bottleneck isn’t… you don’t have enough staff… it’s reviewing all that work.”
Building is no longer the constraint.
Judgment is.
What’s worth shipping? What’s not good enough yet? What do you throw away?
Those decisions matter more now than ever.
Looking ahead, the next frontier isn’t more text generation.
It’s visual understanding.
“Being able to look at exactly what you can see on the screen… and make design decisions based on visuals.”
In one demo, the AI didn’t just suggest improvements—it applied them. Adjusting focal points, fixing contrast issues, improving readability.
That’s a different class of capability. Less about executing instructions, more about understanding outcomes.
Across everything Baz has worked on—games, publishing tools, AI—the pattern is consistent.
Try stuff.
See what works.
Throw the rest away.
Ship one.
Now it just happens faster.