EDGEwise Insights

AI’s impact on software engineering is only beginning. Tools like GitHub Copilot already generate more than half of developers’ code—but coding is just one step.

Imagine DevOps pipelines that repair themselves, QA systems that predict defects, and cloud agents that continuously tune performance. AI will move from being a coding assistant to a delivery partner.

Software will evolve from static releases to living systems that learn from usage, adapt automatically, and maintain stability. The goal isn’t just faster cycles—it’s continuous intelligence: the ability to sense, adapt, and deliver value in real time.

People keep telling me I should write a book. Maybe I will.

Right now all I have is a notes app full of half-formed chapters and way too many stories: the alligator in the rental car in Florida, the elevator incident I still get teased about, the RAID arrays sitting on a big-box shelf like they were holiday specials, the cross-country deployment derailed by weather, sickness, traffic, and raw luck, the uncomfortable meeting where I told a CEO, “You’re not ready yet,” the nights arguing with Codex, and the juniors asking, “Is there still space for us?”

And every time I look at that list, I think, How did all of this end up being my career?

But then I remember the thread running through all of it: Technology never saves the day on its own. People do, when they are supported, honest, prepared, and working with the technology instead of against it.

The future belongs to leaders who can do both: use the technology and elevate the people. I have had the privilege of meeting some. I hope we build more.

When AI becomes the interface, design must account for trust, transparency, and tone. Users need to know why a model responded a certain way. Confidence scores, rationale summaries, and replayable context logs turn black boxes into glass boxes.

Work is also becoming multimodal—text, voice, image, gesture. Designers must choreograph these modes seamlessly while preventing cognitive overload.

Great AI UX feels considerate. It apologizes for errors, offers alternatives, and respects user autonomy. Empathy is not decoration—it’s essential to adoption.

Inclusive design ensures outputs are understandable across cultures and abilities. Accessibility—screen readers, explainability, contrast ratios—is ethical design, not optional compliance.

The best AI isn’t invisible; it’s understandable. Designing for augmented work means making intelligence feel human-centric, transparent, and empowering.

Everyone wants the shiny AI project. Nobody wants the messy, necessary groundwork that makes it actually work.

One Industrial Operator That Got It Right

We were touring one of their facilities, a huge operation, when a manager pointed at a giant whiteboard covered in marker scribbles and said, “This thing has been here longer than I have.” He wasn’t kidding. That whiteboard was running half their business.

This is the truth of most enterprises: AI has to land in the middle of systems held together by a mix of institutional memory, outdated processes, and one insanely organized person who is two weeks away from retiring.

We Didn’t Sell Them Magic

We showed up with data cleanup, analytics, predictive maintenance, process redesign, governance, literacy training, leadership coaching, and the humility to say, “Let’s fix the foundation first.” Not sexy work, but real.

The Moment I Knew They Were Serious

I checked the numbers one afternoon: 95 percent of their people had voluntarily completed AI literacy training. In manufacturing? That is unheard-of. You can’t get 95 percent of people to agree on pizza toppings. But they showed up. They did the work. And slowly, the culture shifted.

The Real Win

They became smarter before they became automated. And that, not the tech, is what made their transformation stick.

The first metric everyone asks of AI is ROI—and the first mistake is defining ROI as cost savings. The true economics of AI revolve around speed, adaptability, and creativity.

Automation once meant doing the same work faster. AI means doing better work differently. A model that drafts three proposals in ten minutes doesn’t merely save time—it multiplies ideation. The metric becomes “time-to-decision” and “decision quality,” not hours reclaimed.

AI allows organizations to make more informed decisions per day—higher “decision density.” It also increases creative throughput: marketing teams generate dozens of campaigns; engineers test multiple design paths simultaneously. These are new growth levers that don’t appear in a traditional P&L.

Economists describe a phenomenon where productivity rises without corresponding layoffs—the “AI dividend.” Enterprises redeploy capacity toward innovation, not reduction. Measuring this requires new KPIs: rate of experimentation, adoption velocity, and human satisfaction.

CFOs need models that capture compounding value:
• Time-to-value – how quickly a model creates measurable outcomes.
• Adoption ratio – percent of workflows augmented by AI.
• Learning rate – improvement in model accuracy or user output per iteration.

AI’s value compounds through acceleration, not subtraction. Companies that measure for creativity, learning, and adaptability will see the largest long-term returns.

I’ve spent enough years in this industry to know that half the things we plan look great in a spreadsheet and then fall apart the second they collide with actual human beings. Or weather. Or a missing cable. Or a manager who suddenly “forgot” to approve something they promised they handled last week.

So when people ask me why agents matter, I don’t give them a slick keynote answer. I tell them stories.

The Alligator, the Elevator, and the RAID Arrays

A long time ago, I was in the middle of a nationwide infrastructure refresh. I was sitting in a bland hotel room around 7:15, drinking a cup of coffee that tasted like burnt cardboard, when one of my Florida techs called to say he couldn’t make his installs.

I braced myself for a dead car battery.

Nope.

“There’s an alligator in my car,” he said.

Not metaphorical. Not cute. A real alligator. In his real car. Blocking the driver’s seat.

Fast-forward a few hours: I’m rerouting sites, soothing a customer, and wondering why project plans never include a section titled “Unexpected Wildlife.”

Then there was the time two of my coordinators decided the customer elevator was the right place for some… extracurricular activity. We fired them immediately and then spent the next 48 hours scrambling to undo the scheduling wreckage they left behind.

And of course, the legendary RAID story: thousands of dollars of high-end arrays delivered to a giant big-box retailer in the Midwest, where a well-meaning worker slapped price tags on them and placed them neatly on a shelf between discounted microwaves and Bluetooth speakers.

I remember the photo. And the sinking feeling. And the deep, resigned sigh.

Where Agents Fit Into All of This

This is why I take glossy AI narratives with a grain of salt the size of a brick.

Real work is messy.
Real operations are unpredictable.
Real teams are human.

Agents matter because life is chaotic.

And I learned that long before AI existed. Back then it was just me, a pager, and whatever chaos showed up that day.

Agents don’t eliminate the chaos; nothing does. But they give you a faster, calmer, more disciplined way to respond before everything burns down.

They can:

• reroute
• reassign
• notify
• document
• update
• escalate
• and recover

…all while the rest of us are still saying, “Wait, start over, what happened?”

The Quiet Shift

The first time I saw an agent pick up slack without being prompted, I didn’t feel excitement. I felt relief.

And for the first time in years, the technology actually felt like a partner instead of another thing I had to babysit at 2 a.m. while everyone else slept peacefully, blissfully unaware of the fires we deal with.

The Point

Agents don’t change the world.
They change how much of the world you’re forced to carry on your shoulders.

And if you’ve lived long enough in this work, that is more than enough.

Most modernization programs are scoped as technology projects and then quietly fail as operating model problems. The aging platform is real. So is the brittle integration, the unsupported database, the pile of manual workarounds. But replacing the platform rarely fixes the thing that actually costs you money.

Here is the pattern we see most often. A finance system gets replaced on time and on budget. Eighteen months later, support costs are higher than before go-live, three business units are still exporting data into spreadsheets, and the old system is still running because one regulatory report depends on it. The project hit every milestone. The enterprise got more complex anyway.

That happens because legacy systems are almost never just software.

The system is the smaller half of the problem

A platform that has been running for fifteen years has absorbed the way your organization works. It holds approval logic that lives nowhere else. It supports workarounds that frontline staff invented to keep service moving. Its reporting database feeds executive dashboards, regulatory filings, and a dozen ad hoc spreadsheets that no longer have a clear owner.

So your architecture diagram shows applications, databases, and APIs. Your real dependency map is wider. It includes who touches the system, which controls run through it, which decisions rely on its output, and which manual steps surround it. When you don't understand that map, modernization turns into guesswork. You replace the application but keep the manual approvals. You move the data without resolving who owns it. You migrate reports without asking whether anyone still trusts or needs them.

What you end up with is the same business, relocated onto newer infrastructure, at higher cost.

Replacement without redesign creates a dual-cost trap

The most expensive failure mode is the parallel-run period that never ends.

You are now paying for the new platform, the integration work, the change program, and the new support model. You are also still paying for the old environment, because the dependencies that kept it alive were never closed out. A reporting feed still pulls from it. A business unit refuses to cut over because nobody accounted for its local workflow. An audit control still references the old process.

Picture the numbers. Let's say the legacy estate costs $4M a year to run, and the modernization program adds $6M annually during transition. The business case assumed the $4M would drop to near zero within twelve months of go-live. Instead, eighteen months out, you are still carrying 70 percent of it because four dependencies were never resolved. That gap is not a rounding error. It is the difference between a program that pays back and one that quietly becomes permanent overhead.

This is a sequencing and governance failure, not a vendor failure. The fix is a harder definition of "done." Go-live is not done. Data migration is not done. Done means the old dependency is gone: retirement criteria met, controls revalidated, reporting feeds cut over, and staff operating in the new model without falling back.

Do the unglamorous work before you pick a platform

Platform selection gets the executive attention because it is concrete and easy to present. Operating model design gets skipped because it is messy and slow. That order is backwards.

Before you commit to a replacement, answer a short list of uncomfortable questions:

• Which workflows are you redesigning, and which are you just replicating in a newer tool?
• Which reports are still genuinely decision-critical, and which survive only out of habit?
• Who owns each data domain after migration?
• Which integrations are mandatory, which are temporary, and which are obsolete?
• What does the legacy system need to satisfy before you can switch it off?

Then map dependencies before you set a timeline. You are not trying to produce a perfect diagram. You are trying to surface the handful of dependencies that can blow up your sequencing, inflate your cost, or block retirement. That same exercise tells you where not to start. Some systems are too entangled to go first. Some processes need to be standardized before you automate them. Some data needs an owner before it gets migrated. Sequence the work by operational risk, not by which platform is loudest in the room.

Retirement is a workstream, not an afterthought

Organizations over-invest in implementation and under-invest in shutting the old thing down.That imbalance is where the dual-cost trap comes from.

Retiring a legacy system takes more than moving users. It takes evidence that the business processes have actually transitioned, that reports have been rationalized, that integrations have been replaced or removed, that controls have been validated, and that records have been archived to policy. It also takes someone with the authority to enforce all of that. If business units can keep their local exceptions indefinitely, the old environment stays alive. If nobody owns decommissioning, decommissioning does not happen.

So treat retirement as a managed workstream with an owner, closure criteria, and a tracked list of blockers that get escalated when they stall. Measure progress against the actual reduction in operating burden, not against go-live dates.

Readiness is more than training

The people side of modernization gets filed under "training," which is too small a box. A team can be fully trained on a new platform and still revert to old routines on day three, because the new reporting process does not answer the question the manager actually needs answered. So they keep the spreadsheet.

Real readiness means role design, decision rights, escalation paths, data stewardship, and clear ownership of each control. People need to know how work is supposed to move through the organization now, not just where the buttons are. Change holds when the operating model moves with the technology and not before or after it.

The test that matters

A modern platform sitting on top of unclear ownership, duplicated reporting, and unresolved integrations is not a modern operating environment. It is a fresh coat of paint over the original problem, and it usually costs more.

The honest measure of a modernization program is not whether the old platform is gone. It is whether the organization can finally stop operating around the constraints that kept that platform alive. Understand the operating model before you replace the system. Map the dependencies before you set the dates. Redesign the workflow before you automate it. Validate the controls before you cut over. And retire the old estate with the same seriousness you brought to standing up the new one.

Strategic Systems exists to keep modernization from becoming permanent overhead, by mapping dependencies, sequencing the work by risk, and enforcing retirement until the old cost is actually gone.

That is the difference between modernization as intent and modernization as controlled execution. Programs that skip it do not modernize the organization. They extend the cost of the old one.

‍

AI transformation isn’t just about smarter models—it’s about operational maturity. The enterprise now runs on a tri-layered stack linking DataOps, ModelOps, and AgentOps into one continuous feedback system.

DataOps ensures clean, governed pipelines. Without it, models learn from noise. It merges DevOps discipline with data stewardship—versioning datasets, automating validation, and enforcing lineage.

ModelOps manages training, deployment, and monitoring. Tools like MLflow or Databricks Model Registry track experiments and automate retraining. Success depends on continuous evaluation—precision, recall, and fairness tracked like uptime metrics.

AgentOps governs autonomous workflows—how agents invoke APIs, coordinate tasks, and learn from results. It defines approval hierarchies, audit logs, and sandboxed environments.

Data feeds models → models inform agents → agents generate new data → data feeds models again. Each cycle improves accuracy and efficiency. Observability platforms close the loop, turning raw activity into insight.

Organizations that connect DataOps, ModelOps, and AgentOps form a living infrastructure—a self-learning enterprise where improvement is built into the workflow itself.

There’s one sentence I’ve had to say more times than I care to remember: “You’re not ready yet.” Every time I say it, I can feel the room tighten.

One Conversation I Still Remember

I was meeting with a CEO who wanted to deploy agents as fast as humanly possible. The CIO looked exhausted. Someone else was nervously clicking a pen. I could feel the pressure for me to say yes.

Instead, I said, “You’re not ready yet.”

Silence followed, the kind that stretches longer than it should. For a second, I wondered whether I had just ended the engagement. Then he said quietly, “Okay. So what does ready look like?” And that is when the real conversation began.

Readiness Isn’t Sexy

People imagine readiness as some kind of strategic milestone. It isn’t. It is basics:

• data that isn’t a landfill
• governance that is more than a slide deck
• processes that didn’t freeze in 1998
• grown adults who can communicate without emotional arson
• expectations that exist in reality, not the metaverse

And sometimes it is even simpler:

• “Stop emailing spreadsheets around at midnight.”

AI Doesn’t Fix Dysfunction. It Makes It Worse.

If your workflow is broken, agents will break it faster. If your data is garbage, AI will produce artisanal, handcrafted garbage at scale. If your governance is weak, your risk curve goes vertical.

I have underestimated some teams before, and I have been pleasantly wrong. But I would much rather be wrong in that direction than let a company set itself on fire because saying “no” felt uncomfortable.

The Price of Admission

Readiness isn’t a vibe. It is the price of admission to AI. And companies that swallow the hard truth, the ones who accept “you’re not ready yet” without flinching, are always the ones who win later.

AI is not a department; it’s an operating model. The AI-first organization treats learning, adaptation, and automation as core management functions.

Digital-first companies digitized existing processes. AI-first companies redesign them for cognition—systems that observe, decide, and act.

AI Councils oversee governance and investment. Human-AI Orchestrators bridge business context with technical capability. Chiefs of Automation coordinate cross-functional initiatives. HR redefines roles around augmentation, not replacement.

An AI-first culture rewards curiosity and data-driven experimentation. Training is continuous literacy. Employees learn to question model output as naturally as they once checked spreadsheets.

Leaders move from control to coordination—guiding dynamic systems instead of static hierarchies. Success is measured by how quickly the organization learns.

AI-first is not a technology strategy; it’s a transformation philosophy. Organizations that build learning into their DNA—across people, processes, and platforms—will define the next decade of enterprise leadership.

I’m a Minnesota Vikings fan, which means I live in the strange middle ground between trusting data and trusting vibes. Fantasy football made this worse in the best possible way. It trained my brain to think like a scientist and react like someone who just spilled hot coffee in their lap. I know what EPA is. I also believe in momentum. These two things should not coexist peacefully, but here we are.

Fantasy turned me into a numbers person. I draft based on opportunity instead of names. I watch snap counts the way normal people watch sunsets. I check matchup reports and injury updates like they’re medical charts for loved ones, and then I do the least scientific thing possible with all of that information and start somebody because he “feels right.” Every season the analytics show up confident. Strength of schedule, efficiency trends, projections that sparkle like movie trailers that turn out to be terrible. Mike Tyson once said everyone has a plan until they get punched in the face. Vikings fans don’t even make it that far. Ours usually lands around the opening kickoff.

Sometimes analytics gets it hilariously wrong. The Minneapolis Miracle broke every algorithm known to man. The playoff game in New Orleans was supposed to be a funeral and turned into a jazz parade. For one night, numbers cried and Vikings fans pretended they understood physics.

But sometimes the models get it right and I pretend I didn’t hear them. The NFC Championship against the Eagles came with warning labels everywhere. The defense was held together by hope and duct tape. The offense was riding momentum like a surfer who borrowed a board. The spreadsheets were deeply uncomfortable with our chances. I responded by googling Super Bowl merch and acting like this was all perfectly reasonable behavior.

The Brett Favre sequel season felt the same. The data said the arm was fading and turnovers were on the way. I chose to believe in movie endings instead of spreadsheets. It did not work out.

Then came the playoff game against the Dirty Birds. The matchups were bad, the trends were ugly, and every model in existence quietly shook its head. I ignored all of it. By the first quarter my hat was airborne. By halftime I was pacing the house in two hoodies. By the end I was standing shirtless in my Uncle Dave’s freezing garage with steam rolling off me like I’d wandered into the wrong Marvel movie. That was not analytical thinking. That was a live demonstration of ego, emotion, and bad judgment.

Fantasy football is the reason Vikings fans are still functioning members of society. It lets us win even when we’re losing. When the Vikings fall apart, at least my wide receiver still shows up for me. Fantasy is emotional insurance. It keeps you engaged when your actual team is turning Sundays into personality tests. You learn to live with risk, adjust in real time, manage resources, and accept chaos with a straight face.

Which is why there’s more truth in fantasy football than anyone wants to admit.

I am basically Spock, but if Spock panic-started the wrong flex player and yelled at the TV.

And then there are my Packers friends from Wisconsin — Steven, Trever, Likhita, Victor, and David — who get to treat all of this like a nature documentary. Their team replaces quarterbacks the way normal people replace phones, while I’m over here trying to heal generational trauma with spreadsheets and hope. They nod politely when I explain regressions and matchups, then remind me that they’re “pretty good again” like it’s a law of physics.

But here’s the real point hiding under all of this purple chaos.

Fantasy football and NFL fandom accidentally teach something organizations still struggle with.

It takes both.

Analytics by itself is not wisdom, and instinct by itself is not strategy. The real edge comes from living in the uncomfortable space between them. From knowing how to read a model without surrendering your judgment to it. From trusting your experience without pretending it’s immune to being wrong.

The fantasy managers who win year after year aren’t the ones who blindly follow rankings. They understand what the rankings are actually saying. They know when the data is screaming something important and when it’s just making noise. They don’t get intimidated by dashboards, and they don’t let ego overrule evidence. They respect the model without worshiping it. They trust their gut without confusing it for genius.

That same balance is what separates strong companies from struggling ones.

In the real world, machine learning and analytics now shape how supply chains run. Forecasting systems predict demand. Optimization engines decide how much inventory to carry. Algorithms route trucks, manage suppliers, and flag risk before humans can even spell “disruption.” But containers still go missing. Ports still clog. Weather still laughs at forecasting. Customers still change their minds for reasons no equation understands.

When the model is behind the reality, people make the difference.

The businesses that win aren’t the ones who treat analytics like religion or treat instinct like magic. They build teams that understand both. People who aren’t scared of numbers and aren’t in love with them either. People who listen to data with humility and challenge it with confidence. People who make the call instead of waiting for permission from a spreadsheet.

That’s the same skill fantasy football teaches by accident.

It’s what Vikings fans practice every year.

And it’s what winning organizations eventually figure out.

If you want to outperform competitors, build better forecasts.

If you want to lead, build better judgment.

Now if you’ll excuse me, I have analytics to review…

…and then immediately ignore in favor of vibes.

‍

I didn’t set out to build SERVE because I needed another project. I built it because I was tired of watching services organizations suffer through the same painful cycle: inconsistent estimation, padded pricing, tribal-knowledge proposals, outdated templates buried in inboxes, inaccurate projections, and messy handoffs. So SERVE became my attempt to fix something nobody else seemed interested in fixing.

In simple terms, it is our system for estimating work, pricing it fairly, generating proposals and SOWs, handing everything to resource management, and continuously improving through machine learning that compares estimated hours to actuals. It is not flashy. It is not a platform. It is the plumbing that makes a services business run without chaos.

The Migration From Hell

There was a night, close to midnight, when a migration script kept failing. Same error, over and over. I was tired, irritated, and questioning every life choice that led me to be debugging Prisma migrations after hours instead of doing something normal with my evening.

Codex kept suggesting fixes. And I kept swatting them away, stubbornly convinced I was right.

It turned out the bug was a single invisible character, the kind of tiny mistake you can only find after you have gone through emotional stages usually associated with losing a relationship.

When it finally worked, I laughed. The kind of laugh that is 40 percent relief and 60 percent “I cannot believe I spent three hours arguing with an AI.”

The Terminator, Minus the Murder

Codex didn’t get annoyed. It didn’t sulk. It didn’t decide to try again tomorrow. It didn’t care that I was tired or cranky. It just kept offering ideas, calmly and relentlessly, like the Terminator if the Terminator’s mission was to nudge a sleep-deprived human toward productivity.

Meanwhile, I was doing normal human things:

• doubting myself
• getting frustrated
• threatening to burn the whole repo down
• refreshing Stack Overflow like a security blanket

Codex didn’t flinch. And that, strangely enough, kept me going.

What AI Actually Did

AI didn’t architect SERVE. AI didn’t magically make me a genius. What it did was expand my endurance. It unblocked me. It kept me from quitting when irritation usually wins. It made the work feel less lonely during the hard parts.

The Realization

Here is the truth nobody says out loud: AI will not turn a beginner into a senior engineer, but it will turn a capable problem solver into someone who can build a full MVP. A real one. One worth handing to a senior team.

That matters. It matters for businesses, for speed, for capability building, and honestly, for anyone who has ever sat alone late at night wondering whether an idea is worth finishing. Because sometimes all you need is a partner who doesn’t get tired.