How I Use AI to Supercharge My Work as a Solutions Architect

Cowboy Solutions Architect with Superhero Powers, thanks to AI.

Over the course of my career — from working as a q/kdb+ developer at a major bank, to a data engineer at a hedge fund, and now as a Solutions Architect (SA) at Solace — I’ve come to appreciate one simple truth: this job is never just about knowing the technology. It’s about translating complex technical concepts into compelling stories, working prototypes, and real-world solutions, often on very short notice.

As an SA, you are part consultant, part engineer, and part evangelist. You’re constantly bouncing between customer discovery calls, architecture reviews, live demos, and follow-up deliverables. And in this role, time is your most constrained resource. A prospect asks for a proof-of-concept on Friday afternoon. You have a customer call Monday morning and nothing built yet. Sound familiar?

That’s where AI tools have quietly changed the equation for me. Not by replacing any part of what an SA does — the business acumen, the technical judgment, the trust-building — but by dramatically compressing the time between an idea and something I can actually show a customer.

Here’s a concrete look at how I use AI day-to-day.

Never Miss What a Customer Said

One of the most underrated changes AI has made to my workflow has nothing to do with code. Customer calls are dense — a prospect might casually mention a technical constraint, a compliance requirement, or a competing product in passing, and if you’re busy responding, you miss it. I’ve started using Gong to transcribe technical calls (with client permission, of course), and the difference is significant. After every call, I have a full transcript, a log of questions the customer asked, and a quick summary of action items — all without writing a single note in the moment.

This lets me stay fully present in the conversation, which is ultimately what builds trust. And when I need to review exactly what a customer’s CTO said about their latency requirements three weeks ago, it’s right there.

Learning New Technologies, Fast

My background is primarily in backend systems — market data infrastructure, kdb+, messaging middleware. But the SA role constantly pulls you into adjacent territory. Customers ask about infrastructure automation, deployment pipelines, cloud-native tooling — things you may not have worked with hands-on but are expected to have a credible answer on.

Early last year, I wanted to build Terraform configurations to manage Solace objects — VPNs, queues, ACL profiles — so that customers could provision and tear down broker infrastructure programmatically rather than clicking through the UI. While I had some experience with Terraform, it is not something I had used extensively.

Before AI, this would have meant working through the Terraform documentation, the Solace provider docs, and a fair amount of trial and error before producing anything useful. Instead, I described what I needed:

“Write a Terraform configuration using the Solace provider that creates a message VPN, a durable queue with a subscription, and an ACL profile that restricts publish access to a specific topic prefix. Include variables for broker hostname, username, and password.”

Within minutes I had a working starting point — properly structured HCL, the right resource types, and sensible defaults. I refined it, tested it against a local broker, and ended up with a clean, reusable configuration that I can now share with others who want to manage their Solace infrastructure as code. The ramp-up that would have taken the better part of a day took under an hour.

Building Demo Code Without Starting From Scratch

The most time-consuming part of demo prep has always been the scaffolding. Wiring up a publisher, configuring subscriptions, setting up the right topic hierarchy, generating realistic test data — none of it is hard, but all of it takes time. And time is exactly what SAs don’t have.

Last year, I built a trading dashboard demo that you can see here:

[embed]

I needed two publishers running simultaneously: a market data publisher simulating live price feeds for different securities across multiple exchanges, and a Twitter (I am still not used to calling it X) publisher streaming sample tweets about those same securities for sentiment analysis. Before AI, building even one of these from scratch would have taken most of a day. With AI, I described what I needed — the topic hierarchy, the payload schema, the publishing rate — and had working scaffolding for both publishers in under an hour.

Here’s the kind of prompt I use:

“Write a Python publisher that sends simulated market data for securities listed on NYSE, NASDAQ, and LSE to a Solace broker. The topic should follow the pattern marketdata/{exchange}/{symbol}/tick. Publish at 100 messages per second per security with randomized bid, ask, and last price fields."

That produces working code in seconds. I still review it, test it, and tune it — but starting from something functional rather than a blank file changes the entire pace of demo prep. And when you need a second publisher for a completely different data source, like tweets, the same approach applies. Describe the schema, the topic structure, the rate — done.

Frontend UIs: The Unexpected Win

This one surprised me the most. My background is in backend systems, so building a polished, real-time frontend UI was always something I either avoided or had to pull in help for. A working demo that logs messages to a console gets the technical point across, but it doesn’t wow a room.

AI has completely changed this for me. Take the trading dashboard I mentioned above. I needed a UI that showed live market data — prices ticking in real time for different securities across exchanges — while simultaneously running sentiment analysis on a live stream of tweets about those same securities, all powered by Solace under the hood. A year ago, building something like that as a solo backend engineer would have been a multi-week project.

With AI, I described the layout and the data flow, and iterated from there. The result is a dashboard that genuinely impresses in a customer meeting — not just because of what Solace is doing underneath, but because the UI makes the data come alive in a way that a console log never could.

For a backend engineer, the ability to build something that looks like this — without a dedicated frontend developer — is a genuine game changer. The wow factor is no longer gated by your skillset.

Polishing Customer Communication

SA work involves a lot of writing — follow-up emails, technical proposals, architecture summaries, pre-sales documentation. I communicate clearly, but there’s always a gap between a quick draft and something polished enough to send to a VP of Engineering at a major firm. AI closes that gap. I draft the substance; AI helps with the structure, tone, and phrasing. The result is consistently cleaner and faster than anything I’d produce solo under time pressure.

Conclusion

AI tools won’t replace Solutions Architects — and they shouldn’t. The value an SA brings is in understanding the customer’s business problem, knowing which architectural trade-offs actually matter, and earning the trust needed to guide a firm through a significant infrastructure decision.

But AI does raise the floor dramatically. It compresses the time between idea and demo, helps you cover more technical ground with confidence, and handles the mechanical parts of the job so you can focus on the strategic ones.

The SAs who embrace these tools now will take on more complex engagements, move faster, and deliver better outcomes for their customers — not because they know more, but because they can do more with the time they have.

If you’re an SA and haven’t explored what AI tools can do for your workflow, now is the time to start. The competitive advantage right now belongs to whoever adapts first.