AI & Tools

How I Use AI and Code Assistants Every Day as a Solution Architect

I wrote my first line of production code in 2004, in a language and an era where "assistance" meant a colleague two desks over and a printed API reference. Twenty-two years, three industries, and one AI-driven analytics platform later, I now spend a meaningful chunk of every working day alongside an AI coding assistant. I was skeptical when this started. I'm not anymore — but not for the reasons most of the hype cycle suggests.

The Boring Stuff First

The most immediate, least glamorous win is boilerplate. Spring Boot configuration, DTO-to-entity mapping, Flyway migration scaffolding, JUnit test stubs, standard CRUD controllers — the kind of code that's necessary but has no interesting decisions in it. I used to write it from muscle memory; now I describe the shape I want and review what comes back. The time saved isn't dramatic on any single file, but multiplied across a sprint, and across a team, it adds up to real capacity that gets redirected toward the things that actually need a human's judgment: data modeling, integration contracts, failure handling.

The second daily use is one I didn't expect to matter as much as it does: reading unfamiliar code. When I inherit a legacy carrier-integration module or step into a codebase a contractor wrote two years ago, asking an assistant to summarize control flow, flag suspicious patterns, or trace how a specific field moves through a pipeline is faster than doing it manually line by line. It doesn't replace understanding the system — it accelerates getting to the point where I can start forming an opinion about it.

Where It Actually Saves Me Hours

Three places, consistently. First, first-draft documentation — architecture decision records, runbooks, API documentation. I still edit heavily, because tone and emphasis matter and an assistant doesn't know what the last three postmortems taught the team. But starting from a draft instead of a blank page changes documentation from a task I postpone to one I actually finish.

Second, exploratory SQL and JPQL. When I'm trying to understand data shape in an unfamiliar schema, or sanity-check whether a proposed index will actually help a query plan, having an assistant generate candidate queries I can run and inspect is faster than writing them from scratch, especially against schemas with fifteen years of accumulated tables and no one left who remembers why half of them exist.

Third, and maybe most useful in my current role at Apollo: rapid prototyping for VisionWare+, our warehouse analytics platform. Standing up a throwaway visualization or a quick data transformation to validate an idea with stakeholders used to cost half a day. Now it costs an hour, which means I can test more ideas before committing engineering time to the ones worth building properly.

The assistant hasn't changed what good architecture looks like. It's changed how cheaply I can explore the space of bad ideas before landing on a good one.

Onboarding My Team Faster

Leading engineers across Advatix and now Apollo, I've watched AI assistants shrink the time between "new hire" and "productive contributor" more than any single practice change I've made in fifteen years of team leadership. A junior developer unfamiliar with our microservices conventions can ask the assistant to explain why a service is structured a particular way, get a reasonable first answer, and come to me with a sharper question instead of a vague one. That doesn't remove the need for mentorship. It changes what mentorship spends its time on — less "here's how our codebase works," more "here's why we made that trade-off, and here's what I'd watch out for."

The Line I Don't Cross

None of this extends to decisions with real consequences. Architecture choices, data consistency guarantees, security boundaries, anything touching a transaction boundary or a customer's data — that's still fully mine, reviewed the same way it would be if a human junior engineer had written it, which is to say: carefully, and with the assumption that it's probably missing something the author didn't think to check. AI-generated code gets the same code review rigor as anyone else's, not less. Often more, because the failure modes are different from a human's and I haven't fully internalized all of them yet.

What I'd Tell Someone Starting Out With This

Treat it like a very fast, very well-read junior engineer with no memory of your specific system and no stake in the outcome. It's excellent at patterns it has seen a thousand times. It's unreliable exactly where your hardest problems live — the specific, contextual, "why does this warehouse's carrier integration behave differently on the third Tuesday of the month" kind of problem that took me years to get good at noticing. The judgment to tell the difference is still the actual job. AI just changed how much time I get to spend using it.

← Back to all posts