@MikeBenkovich

I've been thinking a lot lately about AI and what it means for the future of software development. There are people who use AI, and there are people who build AI. But there's another group that I think is going to be much larger, and potentially more interesting. These are the people who use AI to build software systems.

For years we've relied on specialized software engineers to translate business requirements into working applications. We gather requirements, design the solution, write code, test, deploy, and maintain it. Along the way we've developed entire professions around making sure these systems are secure, reliable, scalable, and able to work with the other systems in our enterprise.

Now AI is changing who can build those applications.

A business analyst, accountant, or operations manager can describe what they need to an AI tool and have it generate something that looks and behaves like an application. They may not understand C#, SQL, JavaScript, or how to build an API, but they understand the business problem they're trying to solve. And in many cases that's enough to get started.

Is this something fundamentally new? Or have we seen this kind of transformation before?

I think we have. And to understand where we're going, it's worth looking back at how we got here.

Remember When We Needed a DBA?

Back in the 1990s, relational databases were becoming the backbone of enterprise applications. SQL Server, Oracle, DB2, and other database engines gave us powerful ways to store, organize, and retrieve information. But working with those systems required specialized knowledge. We needed people who understood indexes, transactions, stored procedures, backups, security, and how to keep the database running.

Enter the Database Administrator, or DBA.

As enterprises grew, I would argue that the responsibilities quickly evolved into two important branches, one that focused on the database engine performance and the other on the application data. Where does customer information live? Which system owns it? What relationships exist between orders, customers, invoices, and products? How do we ensure data integrity when multiple applications need the same information?

This second group became increasingly concerned with data architecture, business meaning, and establishing a trusted source of truth. Both roles were important, but they were solving different problems. One made sure the database worked, the other made sure the information could be trusted.

Then Developers Started Taking Control

But working with DBA's acted as a brake as well, slowing down things and asking for additional review and approval before carving out the data structures much like a sculptor chisels stone. Does the data already exist? Who else uses it? Who owns it and ensure that a change in one place is reflected in all the others? The governance of the data was owned and managed by the people who owned the engine that stored it.

But as our tools and frameworks evolved, developers became more capable of working directly with databases the value of that central governance comes into question. Do we really need this? As the developer tools and languages evolved it became easier to work with data, with things like object-relational mapping, code-first development, and frameworks that could generate database schemas from application models.

Instead of sitting down with a database designer to define every table, column, and relationship, we could define our classes in code and let the framework handle much of the storage implementation. That was a pretty big deal!

With NoSQL, document databases, and cloud-native architectures we started questioning whether every application really needed to share the same relational database. Microservices took that idea further. Rather than having one enormous SQL Server containing data for every application, we could design smaller services that own their own data. Each service could choose the storage technology that made sense for its workload.

An order service might use SQL. A product catalog might use a document database. An event-processing service might use a distributed key-value store.

We were no longer limited by the size of a single database engine. We could scale services independently, distribute workloads, and let development teams make decisions closer to the problems they were solving. Of course, code-first, NoSQL, and microservices weren't all part of one coordinated evolution. They solved different problems and often worked together. But they contributed to a common shift.

Developers were gaining more control over how their applications stored and managed data.

And that created some interesting challenges.

Just Because You Can Doesn't Mean You Should

Think about what happened as applications started owning their own data. The customer service has a customer record. The billing service has information about that same customer. The shipping service needs an address, and the support system maintains information about customer interactions. Each service might be perfectly designed for the job it performs.

But what happens when the customer changes their address? Which system knows first? Which one is authoritative? How do the others find out? Or what happens when Finance and Sales have different definitions of an active customer?

Now we have a problem that isn't about SQL Server performance, indexing, or even which database technology we selected. It's about how our systems work together. We didn't eliminate the need for data architecture by making it easier for developers to create databases.

If anything, we made the architectural questions more important. We moved the responsibility for storing data closer to the application, but the enterprise still needed to understand what that data meant and how it related to everything else.

I think we're about to experience a very similar transformation with AI.

AI Is Doing for Applications What Code-First Did for Data

Consider a business user who needs an application to manage a departmental workflow. Historically, they might create a spreadsheet, build an Access database, use a low-code platform, or submit a request to IT. If the requirements were complex enough, a developer would get involved to build the application.

Today, that same business user can sit down with an AI development tool and describe what they want. "I need an application to track customer requests, assign them to team members, notify people when something is overdue, and provide a dashboard showing what's happening." AI can help create the user interface, define the data structures, write the business logic, and connect the pieces together.

With the right tools and deployment environment, that user may be able to produce something useful without writing much code at all. That's exciting! Think of all the ideas that never got built because there wasn't enough time, budget, or development capacity. We're lowering the barrier to creating software.

But here's where my database analogy comes back.

Just because someone can create an application doesn't mean they understand how that application fits into the enterprise.

Does it need its own customer database? Should it use information from the CRM system? Where do the business rules come from? Who is responsible for keeping the information accurate? And what happens when someone in another department asks AI to build something that does almost the same thing?

Are We About to Repeat an Old Mistake?

I've worked with organizations where different departments had their own databases, applications, spreadsheets, and reporting systems. Each solved a real business problem. Each had a reason for existing. But over time, the organization struggled to understand which information was correct, which system owned a particular business process, and how changes in one application affected everything else. 

We spent enormous amounts of time integrating systems that were never designed to work together. Microservices and cloud-native architectures gave us better ways to distribute those systems, but they didn't automatically solve the enterprise architecture problem. 

Now imagine what happens when creating applications becomes dramatically easier. Instead of needing a team of developers to create a departmental system, a business user can ask AI to build one.

And another.

And another.

We could end up with hundreds or thousands of independently created applications that work perfectly well on their own but have very little understanding of each other. The technology may be new, but the problem sounds awfully familiar.

So Where Does That Leave the Software Engineer?

I don't believe AI means we no longer need software engineers. I think it means we need to reconsider what we're asking them to do. The database evolution didn't eliminate the need for specialized expertise. It changed where that expertise was most valuable. As developers took on more responsibility for creating and managing application data, we still needed people who understood performance, integrity, ownership, and the relationships between systems.

Now AI is giving more people the ability to create software.

But creating an application and engineering a system that belongs in an enterprise are not necessarily the same thing. Maybe the biggest change ahead isn't how we write code. Maybe it's how we ensure that all the independently created applications and services actually work together.

And that raises some interesting questions.

• When anyone can create an application, who decides whether we need another system?

• Who owns the data, the business rules, and the relationships between systems?

• If AI builds an application, who is responsible for maintaining it when the business changes?

• And if writing code is no longer the defining skill of a software engineer, what is?

I think the answers will have a lot to do with the next evolution of enterprise software architecture.

In the next post, we'll look at what happens when everyone becomes a software builder, and why making it easier to create applications might make enterprise architecture more important than ever.

What do you think? Are we heading toward another generation of disconnected departmental applications, or will AI give us a better way to build systems that work together?

I'd love to hear what you're seeing in your own organizations.

- Mike

TechMasters has always been about helping people find their voice, develop their skills, and have the confidence to share their ideas. This month, TechMasters alumnus and former club president Glenn Leifheit took those skills to one of the most recognized speaking stages in the world: TEDx.

Glenn recently spoke at TEDx Parrish Street 2026, sharing his message about mental resilience and the power of “mind workouts.” Drawing on his experiences in technology, leadership, mentoring, and personal growth, Glenn challenged his audience to think about how we can intentionally exercise our minds to become more resilient.

For those of us who knew Glenn during his years with TechMasters, seeing him on the TEDx stage is particularly exciting. Glenn served as President of TechMasters and has remained an advocate for communication, mentorship, and personal growth throughout his career. He may also be one of the first TechMasters alumni to take the TEDx stage — an accomplishment worth celebrating!

Toastmasters is about much more than learning how to give a speech. It's about finding your voice and gaining the confidence to use it. Glenn's journey is a great example of where that can lead.

Congratulations, Glenn, from your friends at TechMasters. TechMasters for the win!

Products and services do not sell themselves.  People do. 

So it is with Techmasters, a Toastmasters club.  The club occasionally take opportunities to “sell” our group to likely prospects. 

Our “prospects” were attendees of Minnebar on May 2.  As billed on Minnebar’s website, it is the big day to join 1,400+ technologists, builders, designers, founders, and curious minds at Best Buy headquarters in Richfield, MN for the largest technology unconference in the country.  It was founded in 2006.  An unconference(or BarCamp) is a user-generated conference that is participant-led.  There are no keynote speakers or formal workshops, and all sessions are led by people from the tech and business communities. 

Our “sell” of Techmasters involved holding an abbreviated Toastmasters meeting that was open to Minnebar attendees.  The main portions of the meeting were table topics, a prepared speech, and evaluations.  Table topics are impromptu speaking for one to two minutes. 

Khalid Mohamoud of Techmasters gave the prepared speech titled “To Speak Good”.  Khalid chose to become a member of Techmasters after browsing through online info on the 50-plus Toastmasters clubs in the Twin Cities metro area. “I discovered my way of speaking at Techmasters”, states Khalid.  “In the business world, a person is so busy that there is not always time to concentrate on improving communication”.  At Techmasters, Khalid can concentrate on just that. 

Today’s Relaxation meeting was all about the theme “Serenity Now”—a little calm, a little chaos, and a lot of fun. We had 16 people join in, with Loras leading a website review and the team rolling through updates from David, Kyle, Brad, Tony, and Benko to keep things moving and productive.

Then things got creative fast. We heard everything from Michelle’s invisible Disney adventure to Hazel bending time, Mitch going full secret agent, and Khalid channeling Reality TV / Mr. Beast energy. Nathaniel went big with singularity vibes, Sam took us into the Inferno Dallol Depression, and Darryl brought an icebreaker on zig-zag careers. Shoutout to Khalid as the Wise Old Owl, Sam & Darryl for the Word Picture, and Alicia as Better Evaluator—proof that serenity doesn’t always mean quiet… sometimes it means laughing together.

Techmasters is for working on improvement in speech and leadership but we do take time to enjoy life also.  All work and no play makes Jack a dull boy!  On Friday, February 6, a group of us met at Wooden Hill Brewing in Edina for chat, drinks, and chow.  We strive for quality in our work and good times in our recreation.

Imagine you’re handed a pile of bricks, lumber, and nails—no blueprint, no plan, no guidance—and told, “Build me a fortress that will stand for centuries.” You start stacking bricks, hammering boards. You hope your walls are straight, your gates secure, your ramparts high enough to repel invaders. You pray you remember every measurement, every joist placement, every bolt torque.

That… is how most organizations still build their cloud environments today. We hammer in security rules by hand. We patch servers one by one. We scramble to recover from failures without a guide. And when disaster strikes, the walls collapse like a house of cards.

Now, picture a different scene: You stand at your keyboard, you click run—and lines of code that you defined every server, every network, every firewall rule start running. You press Deploy, and in minutes your fortress rises, identical in every test environment, every region, every time. No guesswork. No finger-crossing.

• Consistency in Every wall is laid true to the requirements and design.

• Secured Every gate is reinforced with best practices and security guidlines in mind

• Every tower has a lifeline (backups and DR).

Your environment is no longer a fragile assembly of one-off changes. It is a living artifact, defined in Code, versioned in Git, peer-reviewed, tested like your application code.

Why You Can’t Afford to Wait

• Human Error becomes a myth: No more fat-fingered deletions or midnight firefights.

• Configuration Drift is dead: What you tested in staging is exactly what runs in production.

• Recovery is an automated heartbeat: Spin up the exact replica of your world in another region in minutes.

• Compliance & Audit happen by default: Every change is a pull request you can trace, review, and rollback.

• Cost Control is built-in: Tear down ephemeral environments the moment you’re done with them—no more orphaned servers quietly burning your budget.

This isn’t a “nice to have.” It’s the difference between surviving the next storm or watching your walls crumble.

The Forge: Tools of the Trade

• ARM Templates & Bicep: Native Azure blueprints with first-class support and modularity.

• Terraform: Multi-cloud sorcery that speaks the language of AWS, GCP, and Azure alike.

• Pulumi: Write your infrastructure in C#, TypeScript, or Python—turn your Dev skills directly into cloud metal.

Each of these is your blacksmith’s hammer, your crucible for shaping resilient infrastructure.

Call to Action — Five Minutes to Build Your First Wall
I’m asking for five minutes—a small investment for a giant leap in reliability. In five minutes, I’ll show you how to:

1. Define a simple network, a VM, and a load balancer in code.

2. Deploy it repeatedly, in any region, with zero manual steps.

3. Tear it down when you’re done, so you only pay for what you use.

By the end of that demo, you’ll see how IaC transforms your cloud from a labyrinth of one-off scripts into a codified, battle-tested fortress.

The choice is yours

You can keep building with mortar and guesswork. You can cross your fingers and hope nothing breaks. Or… you can forge your infrastructure in code, version it, test it, and trust it to stand against any siege.

Which would you rather have—sandcastles or stone fortresses?

Five minutes is all it takes. Let me show you the blacksmith’s forge. Let’s build something that lasts.

Craftmanship

In a world now shaped by lines of code and machine-learned patterns, a quiet revolution hums in the background—AI. It's no longer science fiction or Silicon Valley secret sauce. It's here, in our browsers, our inboxes, our pockets. It writes, it reasons, it even reflects. And the playing field? It’s flattening faster than ever.

With tools like ChatGPT, anyone can draft a proposal, outline a sermon, brainstorm a business plan, or even compose a poem. What once required a team of experts or years of experience now takes a well-phrased prompt and a few seconds. It's as if the gates of capability have been thrown wide open—and everyone is handed a key.

And yet, like a chisel in the hand of an artist—a Michelangelo who sees David within the marble—a tool’s power is not in its edge but in its vision. The chisel is lifeless without the hand that guides it. The masterpiece is not in the tool, but in the eye that sees what is possible and the hand that makes it so.

For example, I use AI when I work on these reflections. Not to create the thoughts, but to clarify them, suggest wording, and massage phrasing. It helps me find the words I’m reaching for—the turn of phrase just out of reach, the tone that best fits the story I’m trying to tell. It’s like having a second set of eyes on the page—one that helps me refine, not define, what I want to say.

In woodworking, you can’t just turn on a table saw and expect a masterpiece, it takes learning and respect. A router in the hands of a novice can ruin a beautiful slab of walnut. A dovetail jig—when misunderstood—turns precision into frustration. These tools are not inherently magical. They multiply the intention and skill of the one who holds them.

So it is with AI.

These tools don’t make us obsolete. But not learning them might. When innovation gallops forward like a stallion in full stride, standing still is the same as falling behind. If we treat these tools with suspicion or apathy, we risk becoming craftsmen in a world of machines, holding chisels while others operate laser cutters.

The danger isn't just being replaced—it's becoming irrelevant by refusing to adapt.

And this is not only a personal warning—it’s a call to leadership. If we’ve been given the experience of years, the scars of failure, the insight of context—then we have a responsibility to bring others along. To not just use the tools ourselves, but to teach them. To demystify them. To be the older carpenter who shows the apprentice not only how to use the saw, but how to respect it.

This moment in time isn't just about productivity—it’s about legacy.

Because while AI can replicate content, it cannot replace character. It cannot teach common sense. It cannot walk with someone through the slow grind of growth or the sacredness of learning by doing. That’s our role. That’s our gift. To reach back while we step forward.

The tools are changing. The craft is evolving. But the need for wisdom, courage, and mentorship? That has never been more vital.

What do we do?

Learn the tools—explore the possible with them. Share them. Teach your team. Teach your kids. Learn out loud so others can learn with you. Because staying relevant isn’t just about surviving—it’s about making space for others to thrive.

And when the world asks, “What makes you different from the machine?”—show them your scars, your stories, your steady hand. Show them your heart.

Because AI may change the craft—but it will never replace the craftsman.

In the grand cathedral of existence, each of us is akin to a stained-glass window—distinctive in design, hue, and purpose. These windows, when illuminated by the sun's rays, project a kaleidoscope of colors, captivating all who behold them. Similarly, our individual talents and gifts, bestowed upon us by the Divine, are meant to shine brightly, casting our unique light into the world.

Yet, how often do we, like chameleons, attempt to blend into the tapestry of societal norms? We mute our vibrant colors, fearing that standing out might lead to isolation or judgment. But consider this: a stained-glass window devoid of light remains dark and unremarkable. Its true beauty emerges only when it allows light to pass through, revealing the intricate artistry within.

Elisabeth Kübler-Ross, a pioneering psychiatrist best known for her work on the stages of grief and the inner journey of the soul once observed, "People are like stained-glass windows. They sparkle and shine when the sun is out, but when the darkness sets in, their true beauty is revealed only if there is a light from within." This profound metaphor underscores the importance of nurturing our inner light, especially during times of adversity. It's not the external validation that defines us, but the internal radiance that we cultivate and share.

Imagine a garden where every flower strives to be a rose, dismissing its inherent nature. The result would be a monotonous landscape, lacking the diversity that makes a garden truly enchanting. In the same vein, when we suppress our individuality to conform, we rob the world of the rich tapestry of human expression intended by our Creator.

Reflecting on this, it's evident that our preoccupation with social acceptance can be a dimmer switch on our potential. We were not crafted to be mere reflections of societal expectations but to be luminous beings, each contributing a unique shade to the mosaic of life. As the Apostle Paul reminds us, "We have different gifts, according to the grace given to each of us." Embracing these gifts is not an act of defiance but an act of faith and gratitude.

Therefore, let us endeavor to polish the panes of our souls, allowing the light within to shine unhindered. Let's celebrate our differences, understanding that, like stained glass, our diversity creates a masterpiece that is both beautiful and divine. In doing so, we honor not only ourselves but also the Artist who designed us with intentionality and love.

Call to Action:

Take a moment to ponder: Are you dimming your light to fit into a mold never meant for you? What unique colors and patterns has the Divine Artist painted within you? Embrace them. Let them shine. For in the symphony of light and color that is humanity, your note is essential, your hue indispensable.

Winnie the Pooh once said, “Nothing is impossible. I do that every day!”—a phrase so delightfully whimsical, it could only come from a bear who lives on honey and wonder. But as endearing as it sounds, living that out feels less like a gentle stroll through the Hundred Acre Wood and more like sprinting up an escalator that’s going down, arms full of tangled responsibilities.

Lately, I’ve been racing from thing to thing like a circus performer juggling flaming bowling pins on a tightrope. I’ve got to be at the airport by 8:45. I’ve got to fix the demo before the big presentation. I’ve got to keep the clusters alive. I’ve got to remember passwords, pack chargers, chase deliverables, answer emails, and do my job. Get out of my way—I'm coming through like a freight train with no brakes, trying to arrive everywhere all at once.

In the chaos, it’s easy to forget something essential: Who gave me this plate I keep piling so high? And am I even walking in the direction that plate was meant to carry me?

Chris Stefanick, who shares his heart through the Hallow app and his podcast, recently spoke of a book that caught my attention: The Ruthless Elimination of Hurry by John Mark Comer. Even the title is a paradox—how do you “ruthlessly eliminate” something as slippery and seductive as hurry? It clings to us like static on a sweater. But the truth in his message is profound: we must intentionally, courageously, even ruthlessly step off the treadmill we so often mistake for the path.

In one of his men’s devotionals, Stefanick reflects on the idea that rest isn't a reward for work—it’s a rhythm for life. Like the beat in a piece of music, the rests give the song shape. Without pauses, it's just noise. But in our modern cadence, where faster means better, and more means worthier, rest feels like weakness. It’s the skipped step we promise ourselves once we’ve “earned” it… but never quite do.

I confess, I struggle with this. I love being productive—crossing things off my list is like taking a victory lap around the day. I like feeling capable, on top of things, in control. It’s addictive, like standing atop a tower built from checkboxes. But sometimes I wonder: am I really keeping my cup half full, or am I just upgrading to a bigger cup?

How do I pause when everything feels so urgent?

How do I trade my sprint for a stroll without guilt chasing me down like a shadow that won’t be left behind?

How do I hear the still, small voice when my world is a blur of movement and motion?

The truth is, rest doesn’t come naturally—it comes intentionally. It’s like Sabbath bread, baked on purpose and shared slowly. It’s like watching the sun rise, not because you have time, but because you make time. Rest is the holy permission to just be, not because we’ve done enough, but because we are enough.

Maybe slowing down is not a failure of ambition, but a recalibration of direction. Like a ship adjusting its sails to catch a better wind. Maybe being still isn’t stopping—it’s anchoring. And maybe that plate I’ve been piling high wasn’t meant to be a platter of performance, but a place-setting for presence.

Call to Action:

What would it look like today to ruthlessly eliminate hurry from your soul—even if just for a moment? Could you choose to sit, to breathe, to listen? Could you set down the to-do list and pick up your life? Could you let your cup be filled—not with more, but with meaning?

Because sometimes the most radical thing you can do is not conquer the day, but simply be in it.

Went on a retreat this weekend, and there was a talk that dove into an interesting way of looking at things. Instead of doing things so that I have and I can then declare what I am, we look at what I am, so therefore I have some things, which mean that I do things. To me it was an intriguing way of looking at life, that as a christian I am loved by God, that being loved I have security to know that I am empowered by his love to do things which are aligned with his mission. 

I do --> I have --> i am

vs

I am --> I have --> I do

---

Are You Climbing the Wrong Ladder? The Power of Being Before Doing

We’re taught from a young age that success follows a simple pattern: Work hard (Do), get the rewards (Have), and then you’ll be happy (Be).

It sounds logical.
It even seems to make sense.

But what if that ladder we’ve been climbing is leaning against the wrong wall?

Chasing Success, But Feeling Empty

A friend of mine once poured everything into getting a promotion. Early mornings, late nights, checking emails at all hours—he was doing everything he could to climb higher. And eventually, he got it.

The title. The raise. The corner office.

But something strange happened.

He wasn’t any happier. In fact, he felt… the same. A little emptier, even.

Because deep down, he realized he had spent years chasing something he thought would define him, instead of defining himself first.

Flipping the Script: Be → Have → Do

Most people live by the idea that if they just work harder (Do), they’ll get what they want (Have), and only then will they feel like the person they want to be (Be).

But the truth is, it works the other way around.

Be → Have → Do.

• Who you are determines what you have and what you do.
• When you start with identity, the right actions flow naturally.
• Instead of waiting for success to define you, define yourself first.

Success isn’t about climbing faster—it’s about making sure your ladder is against the right wall.

The Power of Identity

Think about it.

If you see yourself as a leader, you act like one.
If you believe you’re confident, you carry yourself that way.
If you know you’re disciplined, your habits reflect it.

But if your identity is tied to external validation—titles, money, or approval—then you’ll always be chasing something outside yourself, never truly arriving.

Call to Action: Start With Being

Here’s the challenge: Flip the script.

1. Decide who you are first. Instead of waiting to feel confident, choose to be confident. Instead of chasing success, start with the mindset of someone who already has it.
2. Let identity drive action. When you focus on being, the right habits follow naturally.
3. Trust that the results will come. The right identity creates the right actions, and the right actions lead to success.

Final Thought: Who Are You Becoming?

At the end of the day, it’s not about what you achieve—it’s about who you are.

So instead of asking, “What do I need to do to be successful?” ask:

“Who am I becoming?”

Because when you start with being, the doing and having take care of themselves.

And maybe—just maybe—you’ll realize you don’t need to climb higher.

You just need to make sure your ladder is leaning against the right wall.