Twitxy Saved

Daniela Petruzalek

Verified account This account is verified. Learn more

@danicat83

Senior DevRel Engineer @Google | Go, Gemini & AI Agents | Keynote speaker | Retro games, anime & cats =^.^=
London, UK danicat.dev Joined April 2025
574 Following 528 Followers 1.4K Posts

Latest posts 5

Pinned post

Daniela Petruzalek Verified account @danicat83
If AI brings us the promise of the future, why are we still stuck in the past with chatbots in Markdown?

Most AI applications today still work like a terminal from decades ago: you type a prompt, the agent runs a tool, and it dumps a wall of text back at you. Modern agentic interfaces should not only use richer UI elements, they should also adapt to what the user needs instead of forcing everything through a static, one-size-fits-all screen.

That changes how we think about frontend development. Instead of designing hardcoded application screens upfront, we design a shared catalog of UI building blocks and let the agent assemble the interface on demand.

Google's open Agent to User Interface (A2UI) protocol was built for this. Your frontend keeps full control over styling and native components, while the agent decides what to display based on context across three primitives:

• Catalog: The menu of UI components (charts, gauges, tables, 3D views, buttons) shared between the backend agent and the frontend client.
• Surfaces: The live UI canvas that updates in real time as the agent streams structured JSON messages.
• Actions: Two-way events that turn a click on a table row, graph node, or button directly into the next turn of the conversation without typing a follow-up prompt.

In my latest article, I used A2UI and Genkit to give my diagnostic agent, AIDA, the modern glowup she deserves, with dynamic UI elements rendered on-demand and human in the loop tool approvals for the most critical operations.

Read the full article on danicat.dev:
danicat.dev/posts/designin…

Companion repository:
github.com/danicat/go-aida
Daniela Petruzalek Verified account @danicat83
Unpopular opinion: frontier LLMs are great and all, but they are not the best for focused work.

Don't get me wrong. Gemini 4 Argon is very good, but I still prefer to use Gemini 3.8 Flash for most of my work.

Why? Response times!

Gemini Flash allows me to stay in the loop the whole time. I have an idea, prompt it, and a few seconds later I get a response. Most of the cases my first idea is a very bad idea, and this gives me the opportunity to course correct.

Now take Argon. I can give it my first idea, and it will go off to work on its own for dozens of minutes, if not hours, then come back with a response. By the time the response gets to me, I completely forgot what I was doing. And my first idea? Still a bad idea that I had no opportunity to refine before investing this much time and tokens.

The long feedback loop from Argon prevents me from getting in the zone. It removes me from the design process. It makes my job less fun to do. Can it produce awesome results? Yes, it can. But at what cost?

Flash tier models are more collaborative than Pro or Argon tier, so I have much more joy working with them.

This led me to think: when should I use one or the other?

Flash will continue to be my default for the foreseeable future for active building during business hours.

Argon territory is everything async: detailed reports, hard bug fixes, thorough code reviews, offline thinking and agent dreams.

Argon is also great when you need to validate and improve Flash results. This is when I'm already done with most of the iteration and just want to wrap things up.

TL;DR: It's not a matter of which model is the best, but when you should use each of them to make you more productive.

How do you split your work between fast models and deep reasoning models?
Daniela Petruzalek Verified account @danicat83
Details like this made me feel in love with this game.
Metal Gear Network - MGN Verified account @MGSMGN 5d
Metal Gear Solid(1) has a lot of interesting and fun Easter eggs. One that’s often missed today: if you play with the audio set to Mono and call Campbell during the Hind-D battle, you’ll get this humorous, fourth-wall-breaking codec interaction.
View quoted post on X
Daniela Petruzalek Verified account @danicat83
Everyone on my timeline is arguing about which is the best LLM, and here I am unironically telling people to read a 40-year-old book about Lisp as inspiration for the future.
Daniela Petruzalek Verified account @danicat83 Oct 29
When foundation models have all the knowledge of the world baked into their weights, what's left for the humans?

Humans should be the beacon. Exactly because models know all, every path looks equally plausible. They cannot prioritise and sequence information to create with taste. This is where our new job kicks in: as if we were spelunking in a dark cave, we hold the flashlight, pointing at the path and deciding where the model should focus next.

There are few books that I've read in my life that I consider to be evergreen. One of those is Structure and Interpretation of Computer Programs (aka SICP). Why is this book relevant now? Because of the way it describes programs and how we as engineers "conjure spells" to build them:

"People create programs to direct processes. In effect, we conjure the spirits of the computer with our spells... The programs we use to conjure processes are like a sorcerer's spells. They are carefully composed from symbolic expressions in arcane and esoteric programming languages that prescribe the tasks we want our processes to perform."

We are still in the business of conjuring processes to instruct the computers. Only the language in which we craft our spells has changed. Now that we write those spells in plain English instead of arcane symbolic expressions, orchestrating agents and ensuring they are on the right track is the most important part of the job.

SICP also captures how we structure those systems:

"Master software engineers have the ability to organize programs so that they can be reasonably sure that the resulting processes will perform the tasks intended. They can visualize the behavior of their systems in advance... Well-designed computational systems, like well-designed automobiles or nuclear reactors, are designed in a modular manner, so that the parts can be constructed, replaced, and debugged separately."

If you take the quote above and replace the word "programs" with "agents," the whole framework still stands. We need to learn how to structure our agentic coding processes so that they produce well-designed computational systems.

And SICP's warning holds just as true today:

"Like the sorcerer's apprentice, novice programmers must learn to understand and to anticipate the consequences of their conjuring. Even small errors in programs can have complex and unanticipated consequences... Real-world programming, however, requires care, expertise, and wisdom."

If we don't anticipate the consequences of what we conjure, an unguided agent will multiply small structural flaws faster than we can even realise them.

Moving faster doesn't replace the need to build mental models. Our core work is structuring context, constraints, and feedback loops so agents build what we actually intended. If anything, our job has become harder: technical knowledge has become a commodity, but taste and critical sense are still sparse.

Ultimately, we're still sorcerers conjuring the spirits of computers. It's just our spells that have crossed yet another level of abstraction.

Read the full post:
danicat.dev/posts/20261028…
View quoted post on X