BONUS Thinking Like an Architect in the Age of AI-Assisted Coding With Brian Childress

BONUS: Thinking Like an Architect in the Age of AI-Assisted Coding

How can engineers leverage AI to write better code—and think like architects to build systems that truly scale? In this episode, Brian Childress, a CTO and software architect with over 15 years of experience, shares hard-won lessons from teams using AI coding tools daily, and explains why the real challenge isn't just writing code—it's designing systems that scale with users, features, and teams.

The Complexity Trap: When AI Multiplies Our Problems

"Most engineering projects and software engineers themselves lean more towards complexity, and I find that that complexity really is multiplied when we bring in the power of AI and its ability to write just tons and tons and tons of code."

Brian has observed a troubling pattern: AI tools can generate deeply nested components with complex data flows that technically work but are nearly impossible to understand or maintain. When teams don't guide AI through architectural decisions, they end up with code that becomes "a little too complex for us to understand what is actually going on here." The speed at which AI produces code makes understanding the underlying problem even more critical—we can solve problems quickly, but we must ensure we're solving them the right way.

In this segment, we mention our longer AI Assisted Coding podcast series. Check that out for further insights and different perspectives on how our software community is learning to make better use of AI Assisted Coding tools.

Vibe Coding Has Its Place—But Know Its Limits

"Vibe coding is incredibly powerful for designers and product owners who want to prompt until they get something that really demonstrates what they're trying to do."

Brian sees value across the entire spectrum from vibe coding to architect-driven development. Vibe coding allows teams to move from wireframes and Figma prototypes to actual working code much faster, enabling quicker validation with real customers. The key distinction is knowing when to use each approach:

• Vibe coding works well for rapid prototyping and testing whether something has value

• Architect thinking becomes essential when building production systems that need to scale and be maintained

What Does "Thinking Like an Architect" Actually Mean?

"When I'm thinking more like an architect, I'm thinking more around how bigger components, higher level components start to fit together."

The architect mindset shifts focus from "how do I work within a framework" to "what is the problem I'm really solving?" Brian emphasizes that technology is actually the easiest part of what engineers do—you can Google or AI your way to a solution. The harder work is ensuring that the solution addresses the real customer need. An architect asks: How can I simplify? How can I explain this to someone else, technical or non-technical? The better you can explain it, the better you understand it.

AI as Your Thought Partner

"What it really forces us to do is to be able to explain ourselves better. I find most software engineers will hide behind complexity because they don't understand the problem."

Brian uses AI as a collaborative thought partner rather than just a code generator. He explains the problem, shares his thought process, and then strategizes back and forth—looking for questions that challenge his thinking. This approach forces engineers to communicate clearly instead of hiding behind technical jargon. The AI becomes like having a colleague with an enormous corpus of knowledge who can see solutions you might never have encountered in your career.

Simplicity Through Four Shapes

"I basically use four shapes to be able to diagram anything, and if I can't do that, then we still have too much complexity. It's a square, a triangle, a circle, and a line."

When helping colleagues shift from code-writing to architect-thinking, Brian insists on dead simplicity. If you can diagram a system—from customer-facing problems down to code component breakdowns, data flow, and integrations—using only these four basic shapes, you've reached true understanding. This simplification creates that "light bulb moment" where engineers suddenly get it and can translate understanding into code while in flow state.

Making AI Work Culturally: Leading by Example

"For me as a leader, as a CTO, I need to show my team this is how I'm using it, this is where I'm messing up with it, showing that it's okay."

Brian addresses the cultural challenge head-on: mid-level and senior engineers often resist AI tools, fearing job displacement or having to support "AI slop." His approach is to frame AI as a new tool to learn—just like Google and Stack Overflow were in years past—rather than a threat. He openly shares his experiments, including failures, demonstrating that it's acceptable to laugh at garbage code while learning from how it was generated.

The Guardrails That Make AI Safe

"If we have all of that—the guardrails, the ability to test, automation—then AI just helps us to create the code in the right way, following our coding standards."

The same engineering practices that protect against human errors protect against AI mistakes: automated testing, deployment guardrails, coding standards, and code review. Brian sees an opportunity for AI to help teams finally accomplish what they've always wanted but never had time for—comprehensive documentation and thorough automated test suites.

Looking Ahead: More Architects, More Experiments, More Failures

"I'm going to see more engineers acting like architects, more engineers thinking in ways of how do I construct this system, how do I move data around, how do I scale."

Brian's 2-3 year prediction: engineers will increasingly think architecturally because AI removes the need to deeply understand framework nuances. We'll have more time for safeguards, automated testing, and documentation. But expect both sides of the spectrum to intensify—more engineers embracing AI tools, and more resistance and high-profile failures from CEOs vibe-coding production apps into security incidents.

Resources for Learning

Brian recommends staying current through YouTube channels focused on AI and developer tools. His top recommendations for developer-focused AI content:

• IndyDevDan

• NetworkChuck

• AI Jason

His broader advice: experiment with everything, document what you learn as you go, and be willing to fail publicly. The engineers who thrive will be those actively experimenting and learning.

About Brian Childress

Brian Childress is a CTO and software architect with over 15 years of experience working across highly regulated industries including healthcare, finance, and consumer SaaS products. He brings a non-traditional background to technology leadership, having built his expertise through dedication and continuous learning rather than formal computer science education. Brian is passionate about helping engineers think architecturally and leverage AI tools effectively while maintaining simplicity in system design.

You can link with Brian Childress on LinkedIn.