Why Domain Knowledge Is Critical for AI-Driven Development 

AI-driven development is exposing a long-standing divide in software development: the difference between technical fluency and domain knowledge. Organizations that identify and close that divide can create a competitive advantage. 

The conversation about AI-driven development has been laser-focused on the tools: which models to use, which integrations work, and which strategies produce the best output. That focus is understandable. The tooling is new and genuinely impressive, and organizations are right to invest in understanding it. 

However, beneath the surface, a more enduring question is coming back into focus, one that has always defined the role but now carries more weight: what makes a developer valuable? 

The answer is no longer just technical fluency. Today, value comes from combining technical skills with deep business understanding. 

Organizations that recognize this are positioned to get real results from AI. Those who don’t find their weaknesses exposed quickly. 

What AI is making impossible to ignore 

There has always been a difference between developers who understand what they’re building and why, and those who simply execute. 

The first group reads between the lines of a requirements document. They step into a business analyst role when gaps appear and collaborate with QA when it’s time to validate. They ask better questions, connect the dots others miss, and keep pushing until they reach the right answer. 

The second group executes cleanly within well-defined boundaries. But when those boundaries disappear, so does their effectiveness. 

In a pre-AI environment, this difference was manageable. Processes compensated for it, and requirements meetings captured context. Business analysts were there to translate intent, and QA provided a separate validation layer. The system had built-in redundancy because individual contributors weren’t expected to hold the full picture. 

However, AI removes much of that redundancy. Teams get leaner, cycles get faster, and there is less room for handoffs, and the middle of AI development is where that pressure begins to show up. Each contributor must be able to carry more context, and the safety nets are thinner. 

These two groups of developers are not the same, and with the prevalence of AI-driven development, those developers who have domain knowledge will begin to edge out the “strictly execution” developers.

Why execution without understanding is risky in AI-driven development

Pairing AI with a developer who lacks domain knowledge doesn’t just slow things down; it creates confident, polished mistakes at speed. 

AI is exceptional at executing instructions. It is not good when those instructions are incomplete, incorrect, or in conflict with existing system behavior. When context is missing, it loops and fills the gaps with something that looks reasonable and presents it with confidence. 

If the AI doesn’t know how your system handles something — even if it can read the codebase — it’s going to invent a solution. And if the developer reviewing it doesn’t know the domain well enough to catch it, you’ve just introduced technical debt under the impression you were solving a problem.” -Brian Weiss, Senior Consulting Partner 

This isn’t a failure of the AI. It’s a failure of context. 

The developer who can supply that context, evaluate output critically, and catch errors early is not interchangeable with the developer who cannot. The distinction between these skill sets is crucial and is becoming more relevant for each quarter. Key takeaway: Domain context is a differentiator for AI-empowered developers. 

The requirements problem, reframed 

AI-first workflows are forcing a long-standing habit into the open: treating incomplete requirements as someone else’s problem. 

Requirements have never been complete, and they will never be. No document can anticipate every edge case or interaction within a complex system. The gap between specification and implementation is not a failure. It’s part of the work. 

The requirements will never be bulletproof. We don’t exist in a world where they’ll be defined to the nth degree. The question is how useful you are to the organization when an impediment happens.” -Brian Weiss 

The developer who investigates, clarifies, and resolves those gaps is the one who makes an AI-driven workflow function. The developer who waits creates bottlenecks that AI cannot fix, because AI doesn’t know the gap was there in the first place. 

This changes what “good” looks like. It’s no longer about executing well-defined work efficiently. It’s about navigating ambiguity with judgment, knowing when to proceed, when to question, and when to involve others. 

The multi-dimensional contributor 

Developers who succeed in AI environments move fluidly between roles. They build, clarify requirements, validate their own work, and evaluate outcomes. 

The best contributors have always worked fluidly across roles. The growing visibility and consequences of that difference are what’s new. 

AI accelerates output, research shows significant productivity gains, but it cannot make up for a limited job perspective. 

There’s also a practical impact. AI-assisted development can outpace QA. When that happens, the solution isn’t to push QA harder. Developers need to step into that gap. They need to understand and validate behavior, much like what we saw in our own AI-first feature build.

That requires a full understanding of both the product and the business. Essentially, developers must proactively ensure quality and be able to answer questions beyond just coding. 

What organizations should optimize for 

Treating AI as a headcount efficiency play is one of the most shortsighted approaches an organization can take. It risks removing the very people who make AI effective. 

The goal isn’t to leverage AI so we can reduce the team. The goal is to leverage AI so we can continue to produce really good velocity at a quality that everyone, including the end user, is happy with.” -Brian Weiss 

The most valuable contributors on the team are those who understand both the system and the business and can move between them. They provide the context AI depends on. They can catch subtle context errors and know when something is right and when it isn’t.

The developers that end up being your most foundational people are the ones who understand the business as well as they understand the system and have the relationships to go with it. Those are the ones you can’t afford to lose.

Organizations that get the most from AI aren’t the ones with the most advanced tools. They’re the ones that retain and build domain knowledge, and structure their teams to use it well.  

The change that actually matters 

The conversation about AI needs to move beyond tools and into capability. What are we building in our people? What do we value? What does “good” look like when execution is increasingly automated? 

The answer points to the same qualities that have always separated strong contributors from average ones: curiosity about the business, sound judgment in ambiguous situations, and ownership of outcomes. 

AI raises the bar.  

The organizations that succeed will be the ones that invest in people who can meet it. If you’re figuring out how to build that capability, that’s exactly what we help with. 

Once a Rōnin, Always a Rōnin. A Conversation with Software Developer Austin O’Byrne

Some people find their way to a career in tech through a perfectly mapped-out plan. Austin O’Byrne is not one of those people, and that’s exactly what makes his story worth telling. 

Austin is a software developer at Rōnin Consulting, currently embedded with a defense client and six years in with the company. He joined in March 2020, has worked across healthcare, distribution, and defense since, and shows no signs of going anywhere. As it turns out, when the culture fits, and the owners are as invested in your growth as you are, six years go by fast. 

From Thompson Station to the Air Force to UTC 

Austin grew up in Thompson Station, TN, and graduated from Independence High School in 2013. Right out of high school, he enlisted in the Air National Guard. Not because he had a grand military calling, but because he needed a practical way to pay for college. While most of his classmates were headed straight to a college campus, Austin spent 2014 in basic training, then shipped off to technical school at Keesler Air Force Base in Biloxi, MS, where he trained as a server IT technician. 

He didn’t start college until January 2015, enrolling at UTC for a computer engineering degree, a hybrid program that split time between computer science and electrical engineering. That meant writing code and soldering circuits in a lab.  

“We’d put wires in the breadboard, test the circuit, and solder it all togetherr before turning it in,” he said. “I wish it were a lot cooler than it sounds. I was basically just building circuits that added binary digits.” 

Along the way, he also picked up an internship at TVA, mostly setting up desktops and watching the real IT guys work, but it gave him a foothold and made him realize what he wanted to do in his career, and what he didn’t.  

How he made his way to Rōnin 

After UTC, Austin landed a full-time role at Northrop Grumman in Huntsville, AL — a defense contractor gig that required a security clearance and meant showing up to a secure systems integration lab every day. It was not a remote gig, and he couldn’t have any outside connections.  

He worked there until early 2020, then interviewed at Rōnin in February and got the offer in March. He moved back to the Nashville area, bought a house in West Nashville, and has been there ever since. 

Since joining Rōnin, Austin has worked across several client engagements, and it’s the variety, he says, that keeps him engaged. 

“It’s nice when I get to jump around. Staying somewhere too long, I just get kind of tired of it.” He says. 

But the variety isn’t the only reason he’s stayed with Rōnin. “The people are great. The owners have been very good to me. It’s hard to want to leave.” 

How Enzo vibe-coded his App with AI

Enzo will be the first to tell you he’s not a frontend guy. But that didn’t matter.

He pointed Claude at the Rōnin website, told it to pull the color scheme and design language, described how the game worked, and let it build. His strategy, one he swears by, is to nail the design up front so it stays consistent all the way through.

Fix it later,” Enzo says, “and you’ll always miss something.”

The result is a clean, fully functional web app where the whole team can submit their picks, track standings, and watch the carnage unfold in real time. You can check it out here: (should we share it – or just show photos)?

But like so many development projects, there was a hiccup. Enzo was pulling live game data from ESPN, but ESPN quietly changed its data structure mid-tournament. And that type of bug, which may have taken a while to find or fix, took him only 20 minutes.

The app was then posted to Rōnin’s internal GitHub repository with all the artifacts and deployment scripts, so technically anyone on the team could have pulled it down and asked Claude to patch it themselves. It was that easy.

You built a POC with AI tools, but now you’re stuck.

AI tools made it easier than ever to build a proof of concept (POC). What happens when you need to go further?

It always starts with excitement. You had an idea, used an AI-assisted tool to bring it to life, and suddenly it’s something real. It’s a working prototype you can demo and, in some cases, begin using.

But then the questions begin:

• How do real users log in?
• How does this connect to our actual data?
• What happens when more than five people use it at once?
• Can this pass a security review?

Just like that, you hit a wall. And you’re not alone. According to Microsoft’s AI Strategy Roadmap, roughly 75% of organizations remain stuck in the Exploring, Planning, or Implementing phases of AI adoption, even after their first POC was built and delivered. The technology worked, but the path forward just wasn’t clear.

So, what do you do if you’re stuck?

The POC wall is a real thing

We see this pattern regularly. The proliferation of AI-assisted development tools such as Replit, Lovable, Base44, Claude Code, and others has made it faster and more cost-effective than ever to create software prototypes. More ideas get tested, and more founders can validate before they spend serious money.

This AI technology has given teams an opportunity to show stakeholders something tangible. That’s a genuine advancement. However, these tools are built for speed and accessibility, not necessarily for the architecture a production system requires.

They’re built to get you from an idea to “it works,” not to “it’s secure, it scales, it integrates, and it meets our industry’s compliance requirements.” The barrier to getting where you need to go usually isn’t the technology itself. It’s everything that surfaces when you try to go further: data that isn’t connected, security requirements that were never considered, compliance gaps that nobody had looked at closely.

The POC did its job. It just wasn’t built to carry the weight of what comes next.

You don’t have to start from scratch

A common fear is that everything built is worthless, and that you’ll have to throw it away and start over with a traditional development shop. That’s rarely true — and it’s worth saying clearly: you’re on the right track.

The fact that you got to a working prototype means the idea has merit. The instinct to build before you invest further. That’s exactly right. A POC built with intention carries real value. The UI decisions, the workflows, the user experience logic, all of these represent hard-won thinking about what the product is actually supposed to do.

In many cases, it’s the most honest picture of the vision that exists. Our job isn’t to demolish what you’ve built. It’s to figure out what’s worth keeping, understand the intent behind it, and rebuild the foundation so it can withstand real-world use. That means preserving what already works and replacing fragile or placeholder components with production-grade architecture to meet the compliance requirements your industry demands.

What you built in Claude Code, Lovable, Replit, or Cursor wasn’t wasted time. It was the fastest, smartest way to prove the concept. Now it’s time to build on that foundation, not start over.

The stakes are higher in regulated industries

For organizations in healthcare, financial services, or defense, the POC wall isn’t just a technical inconvenience; it’s a compliance and risk-exposure issue. A prototype that handles real patient data or financial records without proper access controls, encryption, or audit logging isn’t just unfinished; it’s a liability.

AI POCs often surface problems that were already present but invisible: outdated documentation, data inconsistencies, and security gaps. That’s not a failure. It’s valuable intelligence, but only if you have the right team to act on it. Catching these things before mass production or enterprise deployment is exactly the right time to address them.

What this looks like in practice

If you have a POC and have hit a wall, our team is ready to help. At Rōnin, we start every engagement with a direct conversation and a series of questions:

• What did you build?
• Why did you build it?
• Who is it for?
• Where did it break down?

From there, we give you an honest read on what it would take to get to production. Some issues have straightforward technical solutions. Others are more complex. Either way, we begin by separating what’s fundamentally flawed from what simply needs refinement, then we scope the effort clearly, so you know what you’re actually signing up for.

Engagements typically fall into a few patterns: a full architectural rebuild on top of a solid UI, a targeted fix for a compliance or security gap, or simply picking up where an AI tool left off. The shape of the work depends entirely on what you’ve built and where it needs to go.

You don’t have to scrap what you have, and we’re not starting; we’re just helping you up over that wall and getting your POC back on track so you can start using it in practice.

The path forward

The POC wall feels like a dead end. It isn’t. It’s proof that your idea has enough merit to handle real-world complexity, and that’s not a small thing. The organizations that successfully cross from POC to production aren’t necessarily the ones with the biggest budgets or the deepest technical bench.

They’re the ones who are honest about what’s missing and find the right partner to close the gap.

Your idea is still good, and your POC still has value. Now it’s time to build it into something that lasts.

From Dugout to Desktop: A Conversation with Adam Berry

There’s a version of Adam Berry’s life where he spent his twenties in a minor league dugout somewhere in the Southeast, chasing a career in professional baseball.

There’s another version of his story where he stays in retail management, keeps climbing toward running his own territory, and trades work-life balance for the demands that come with that kind of ambition.

But neither of those happened.

Instead, Adam Berry is a software architect at Rōnin Consulting, where he’s been since 2019 and where, if he has anything to say about it, he’ll stay. He found his way here through a canceled basketball game, a wine night, and a two-hour conversation with a stranger.

This is that story.

Indiana roots, Tennessee dreams

Adam grew up in rural Indiana, the kind of place where farming isn’t a lifestyle choice; it was the family business. His dad, his uncle, and his grandfather before them ran a Massey Ferguson agricultural implement dealership.

“It was a big farming community,” he says. “We had a family farm, and we still do.”

Taking over the family business wasn’t part of Adam’s path; his was to leave Indiana to play college baseball. He earned a scholarship to King College in Bristol, Tennessee, and came south to play. What he didn’t know yet was that the sport that brought him to Tennessee would eventually lead him somewhere else entirely.

It began during his freshman year, when he was living in a dorm with no cable. But it had something better: a T1 line. At the time, most people at home were still using slow dial-up. A T1 connection was roughly 25 times faster, and in the late ’90s to early 2000s, universities were among the only places that had them.

Having grown up on dial-up, this was a different world entirely.

“We had a fast pipe, which opened up so many possibilities,” Recalls Adam. “I taught myself how to build simple web pages first, then just kept iterating and learning more advanced techniques for the time.”

By the end of his freshman year, Adam was running the college athletics website as a work-study job. A mentor on the tech side of things had taken him under his wing and helped him develop what was, at that point, still just a hobby. But it was a hobby that had legs.

A major built for one

Adam’s undergraduate degree technically lives in the business college, and he has a piece of paper that says “online media and marketing.” What it doesn’t say is that Adam was the first online media and marketing major at his school because the university created the major specifically for him.

“They created that major for me based on my interest, essentially,” he says. “The guy that was mentoring me was like, we’ve been trying to spin this up. You’re the perfect candidate.”

He did all of this while playing college baseball on scholarship, until an injury led to surgery. At the end of his senior year, his body was sending a clear message: it was time to move on.

“It was hard, but it was the right decision. I had another year of eligibility left after redshirting my sophomore year following arm surgery, but there were no graduate degree options available there at the time.  Baseball is a humbling sport. We all get told at some point we’re done. I was fortunate to play as long as I did, and fortunate to have had people in my life who helped me prepare for that eventuality.”

The hobby he picked up during his freshman year, building websites, ultimately made the transition into a computer science degree possible.

“I walked into a master’s in computer science program with no formal undergrad foundation outside of one C++ course, ” he says. “I went from practicing baseball four to six hours a day to sixteen hours a day at a computer, just trying to absorb as much information as possible. It was definitely like drinking through a firehose at times.”

He came out the other side with a master’s degree and a desire to put it into practice.

Living that consulting life

Three years in and looking for that next growth opportunity, Adam moved into consulting.

“I had a colleague who was a consultant that I worked closely with. Over the course of a year, we had talked through the logic, pros/cons, and necessary preparation to make the move.”

When a recruiter called, it was his wife, Hollie, who encouraged him to take the leap.

“I was prepared,” he says. “I had a very specific list of what I was looking for. She said, ‘I can do that.’ I said, OK, let’s go.”

That was the beginning of roughly 14 years of consulting, bouncing between engagements at insurance, sports marketing, healthcare, education, and fintech companies. He was good at the work, and many of his roles turned into “we’d like you to stay.”

“There is no bigger compliment to my work than being asked to stay or be extended past the original terms. I’ve been fortunate to have one or both in all of my engagements.”

The wine Wednesday that changed everything

Adam’s wife, Hollie, had been teaching alongside a colleague, Allison, for a couple of years, but their husbands had never met.

One evening, the teachers got together for a wine night. Adam had a rec league basketball game, until it got canceled, and Hollie told him to come out. He drove over, met Chuck Harris, one of the owners of Rōnin Consulting, and they talked for a few hours.

Adam had just rolled off a contract, and Chuck was building a team. By the end of the night, Chuck said exactly the kind of thing Chuck would say: I think we can help each other here.

Within days, Adam had met with the other owners, Byron and Ryan, and he soon came in as a consultant in August 2019, somewhere around employee 11 or 12.

“It was truly like everybody was one ship steering in the same direction,” he says of those early days. “I’d run through a brick wall for Byron. There was so much to desire when it was that small. Top down, just good people.”

Six years and counting

Adam is currently on an engagement with a fintech client, working across data and analytics. In six years at Rōnin, he’s worked across multiple clients and found what he spent his whole consulting career looking for: a home base.

He’s honest about what the consulting life is: the peaks, the valleys, the projects that are green-field and exciting, and the ones that are maintenance work and just as necessary. “Happy is a fluctuating state of mind for me,” he says. “Am I happy all the time? No. But I’ve done this for 20 years. There are peaks and valleys.”

What keeps him at Rōnin? “I am thankful and grateful to be surrounded by some really good humans. We consistently deliver at the highest level for our clients. That is a standard I am extremely proud to be a part of.”

If Rōnin ended tomorrow, he says, it would crush him. For a guy who spent 14 years in consulting, accepting that every gig eventually ends, that’s not a small thing to admit.

“I’ve never had the thought that this job is my last. It was always: the consulting gig isn’t going to last forever. But I can honestly say I would love for my work at Rōnin to be my last job.”

Talk with a Rōnin: From Data Streams to River Currents with Travis Buck

In fifth grade, Travis Buck begged his parents to let him attend high school summer school for computer programming. They thought it was a strange request. Computers, after all, were just bricks back then: expensive, clunky, and not exactly a clear path to anything.

His parents said yes anyway. And Travis never really stopped.

“I saw what was going on,” he says. “I just knew I needed to get back into computers.”

When the internet was taking shape, Travis was right there, building and hosting websites in the early days of the web. That curiosity never left him. Over the next few decades, he built a career that took him through Wells Fargo for 16 years, a stint as head of IT at a law firm, and seven years leading technology at a credit union, before a well-timed call from a Rōnin recruiter changed everything.

The call that changed it all

Travis wasn’t actively looking for a new job when a Rōnin recruiter found his LinkedIn profile. But the credit union he worked at had started showing signs — management shifts, people being let go for vague reasons — and his instincts were telling him to pay attention.

“I could feel the writing on the wall,” he says. “So when I got a call from someone at Rōnin, it was perfect timing.”

But, coming from large corporate environments, Travis was skeptical of this smaller consulting firm. “I was very concerned and a little apprehensive,” he admits. The recruiter told him that the owners are “gamers and developers,” Travis recalls. “And I thought, what kind of an outfit is this?” The answer, it turned out, was exactly the kind he’d been looking for.

After a sit-down interview with co-founder Ryan Kettrey, he quickly changed his mind. “These guys knew their stuff, and it was immediately obvious.” Taking that call was exactly the right move. “The stress level where I was before was Mach 9. With Rōnin, it’s just… peaceful.”

The many projects of Travis Buck

Three years in, Travis has worked across multiple Rōnin engagements, moving from project to project and picking up new challenges along the way. His current work centers on building an operational data store that consolidates disparate data into a centralized, reportable system without the complexity of a full Kimball data warehouse.

“It’s been fun,” he says. “If you like to solve problems and make people happy, we’re in the right business.”

He credits Rōnin’s accessible leadership for making the work sustainable. “I have no hesitation reaching out to Chris, Ryan, Byron, or whoever I need,” he says. “That’s the thing when you work on new projects here. You just know you have backup.”

Life on the road (literally)

When Travis isn’t architecting data solutions, he and his wife of 30 years are most likely somewhere off the grid. The couple, now empty nesters, are avid outdoorspeople who spent years kayaking remote rivers for 10 days at a stretch: no services, satellite phone only, occasionally going over 5-to-10-foot waterfalls along the way.

“Our kids think we’re crazy,” he says. “Our daughter is more… bougie. Our son gets it.”

These days, the adventures happen from a fifth-wheel RV. This summer, they’re anchoring near Sturgis, South Dakota, with plans to roam through Wyoming and beyond. Travis is even scoping out inflatable kayaks to bring along so they can hit some waterways.

His wife, the accounts payable manager at Block, is currently hybrid and working toward full remote. Once that happens, the freedom to roam will get even bigger.

“We’re kind of loners,” Travis laughs. “I think that’s why I like the remote job.”

Three years in, and no signs of stopping

Travis has been with Rōnin for three years, and unlike the corporate uncertainty he left behind at the credit union, this stretch has been heading in the opposite direction entirely. The stress that once ran at Mach 9 has given way to something steadier: a team he trusts, leadership that picks up when he calls, and work that keeps him thinking.

“I have no hesitation reaching out to whoever I need,” he says. “You just know you have backup.”

For someone who spent years navigating the politics of large institutions, that kind of support isn’t something he takes for granted. At Rōnin, he’s found a place where the work is interesting and the support is real.

“I love the challenges and the people,” he says. “Keep it coming. What else can you ask for?”

By the end of this year, there is no excuse for a developer not to be able to do a whole scrum team’s worth of points per sprint.” – Byron McClain

 

Why waterfall thinking suddenly makes sense again

The waterfall methodology didn’t fail because planning was bad; it failed because coding took so long that requirements went stale. When you waited 6 months to see results, the world had already changed. Your business learned something new. Your carefully crafted specs became obsolete before the first deployment.

But if AI can code your comprehensive specs in a day? Suddenly, front-loaded planning isn’t a liability anymore; it’s the optimal strategy.

Byron puts it this way: “Back in the day, waterfall was a big deal. You would spend a lot of time creating the product requirements document, and it took a long time. That’s why agile happened: you could start iterating tiny little chunks so people could see it and make changes along the way. But now, coding can happen almost instantaneously. What happens to the cycle? Well, now the risk profile completely changes.”

AI agents are context-consuming machines

Feed them a small set of requirements (agile-style), and you will incur context loss and constant manual work to maintain architectural coherence.

But if you feed your AI agent comprehensive upfront specs (waterfall-style), it will consistently execute from start to finish.

“You’re gonna have to spend more time up front,” says Byron. “You need to get really, really good context of what you want to build and then decompose that into tasks. When you do that, the coding aspect will be super short, and we’re going to reach a point where it’s instantaneous.”

Following this thought process, you could spend three days on discovery, have AI code within a single day, and still iterate faster than traditional agile sprints ever allowed. The rapid feedback loop isn’t lost; it’s just moved.

You’re not going back to 18-month waterfall death marches. You’re front-loading your process with planning and intensive criteria, then executing and iterating at speeds agile never allowed.

The proof is in the execution

Byron worked under the same criteria he used when transferring a legacy video game from Microsoft to Mac. He and Claude spent significant time upfront understanding the entire 900,000-line codebase, generating a detailed 14-phase plan with specific tasks. Only then did any code get written, and he did it all within 4 days.

Some will argue that this is premature, that AI agents aren’t reliable enough yet, or that we’re relying too heavily on a single exceptional example. Which is fair. But even if Byron’s 4-day port becomes a 2-week port for most teams, that’s still a 4- to 5x productivity increase, and that directional shift remains true even if the magnitude varies.

So here’s the reality: for AI agents, agile’s piecemeal iteration becomes a handicap. You’re optimizing for a constraint (slow coding) that no longer exists, while ignoring the new constraint AI introduces (agents that need comprehensive context to excel).

This doesn’t mean agile principles are dead; human-in-the-loop and feedback remain very important. What it means is that the cadence and approach need to shift.

The role collapse is coming

As if the resurgence of waterfall didn’t already throw us, here’s where it gets uncomfortable for many organizations and employees: a role change is on the horizon.

“The titles and job roles are gonna collapse,” Byron predicts. “Instead of having a BA, a developer, and a QA engineer, you’re gonna just have a solution engineer.”

This doesn’t mean specialization will disappear; complex domains will still require deep expertise. But the walls between specific tech roles are coming down. A BA who can’t understand the development or technical context will struggle, just as a developer who can only write code will find their skills commoditized.

This isn’t a layoff narrative. It’s a skills evolution.

The best BAs will become solution architects. The best developers will become technical strategists. The best QA engineers will become validation specialists who design automated testing frameworks rather than manually click through interfaces. The work isn’t disappearing, it’s elevating.

Byron predicts that the future belongs to “solutionists,” or people who can:

• Sit with the business and extract precise requirements.
• Break down complex problems into clear, executable tasks.
• Frame problems in ways that AI agents can understand and execute.
• Put on the QA hat to validate outputs.
• Revise based on business feedback.

The coding part? That’s becoming the easy part. It’s everything else that needs to catch up.

The companies that will win using AI coding agents

The organizations that thrive won’t be the ones that get the best AI tools first (everyone will have access to similar tools). They’ll be the ones who reimagine their entire SDLC around the new constraint of human understanding, not machine execution.

That means flipping your resources with more time in discovery and less in development. It means tighter spec discipline but looser code reviews, because the code quality problem largely solves itself when you give AI agents explicit directions.

It means building cross-functional “solution engineers” instead of maintaining siloed specialists who hand off work at each stage. Your QA approaches need to scale with code output, not linearly with headcount.

The shift isn’t about implementing new tools. It’s about restructuring everything that happens before and after the code gets written.

We’re not all ready, but it’s happening anyway

Our customers are already saying it: “We don’t want to get rid of people. We want to do more.”

That’s the transition path. Companies won’t or don’t need to downsize their engineering teams. They will be able to significantly increase their output and tackle ambitious projects they previously couldn’t justify.

But this will only work if they fix the SDLC first.

Agile and sprint planning were designed for a process where coding was the bottleneck… and right now that world has just imploded.

How We Ported 600,000 Lines of Code in 4 Days Using the Ralph Wiggum Loop

In four days, our Rōnin co-founder, Byron McClain, ported a 600,000-line video game from Windows to macOS, without writing a single line of code himself.

The game? Command & Conquer: Red Alert, the 1996 real-time strategy classic from Westwood Studios.

The experiment? Take an open-source game engine built exclusively for Windows, completely rebuild it to run natively on macOS, and do so entirely using Claude Code, an AI coding agent, paired with the Ralph Wiggum Loop methodology.

When we asked our co-founder, Byron McClain, why he chose to test AI coding agents on a 28-year-old video game, his answer was simple: “I’m not a game developer. I know Jack about how to develop a game.”

And that was exactly the point.

“I wanted to find the edges of Claude Code,” Byron explains. “I needed something gigantic and pre-existing that I could try this on, but it would need to have very clearly defined goals. I don’t know how to do any gaming, anything. So I thought, here’s a perfect test: take something I’ve never done before and see what Claude Code paired with the Ralph Wiggum Loop could actually handle.”

Turns out, it can handle quite a bit.

Using Claude: greenfield vs. brownfield

When testing new AI coding tools, most people start with greenfield projects, or building something new from scratch. It’s easier. There’s no existing code to untangle, no legacy dependencies, or any architectural decisions made 30 years ago that you have to work around.

At Rōnin, we have already tested Claude Code on greenfield work. It performs well. You can take a product requirements document, feed it into Claude, and watch Claude generate a functioning piece of software phase by phase.

But brownfield projects? That’s where things get interesting. With a preexisting codebase, you need some prior knowledge of what you’re looking at. A developer must understand context and navigate and update code they didn’t write. This is exactly the challenge Byron was looking for.

The Red Alert engine was the perfect stress test. At over 600,000 lines of code, it represented decades of Windows-specific development. Every system dependency would need to be identified, isolated, and replaced with macOS equivalents. The windowing system, graphics rendering, audio processing, file system access, network multiplayer protocols, all of it had to be rebuilt.

And Byron wanted to try it in Rust, a modern systems programming language, to prove Claude could handle not just porting but modernization.

Enter the Ralph Wiggum Loop

Claude Code has a feature called “plan mode” where it scans your entire codebase, asks clarifying questions, and generates a structured approach to whatever you’re trying to accomplish. “Having Claude in plan mode to plan out all the phases is extremely helpful when tackling something this massive,” Byron explains.

But plan mode alone wasn’t enough for a project this size, because even with these planned steps, someone still had to babysit Claude through execution. A human needed to answer questions, approve each step, and tell it when it was okay to move to the next phase. For a 600,000-line project? That would mean constant human intervention.

But Byron found another way, by means of the Ralph Wiggum Loop. Which is essentially “danger mode” for Claude Code and a way to run the AI agent autonomously without constant human approval.

Here’s how it Ralph Wiggum works: You break your project into phases, then break each phase into discrete tasks with clear acceptance criteria. Claude runs through each task, checking whether the criteria are met. If the criteria are met, it moves to the next task. If not, it keeps iterating until it gets it right or until it hits a predefined escape hatch and stops.

The human’s role is now to check in every 30 minutes or so, see where things stand, and kick off the next phase when one is complete.

Talk with a Rōnin: Hard Questions, Hardware Answers with Joe Hegeman

If you’ve ever worked on a Rōnin project that involved embedded systems, hardware constraints, or a deceptively simple question like “Why are we using containers?” there’s a good chance Joseph Hegeman was involved.

Joe is an Enterprise Architect with over three decades of experience building software across platforms and technologies. He joined Rōnin Consulting three years ago, bringing deep expertise in mobile development, embedded systems, and modern .NET, backed by a love of hardware and games, and a steady presence that teams rely on when complexity hits.

From mobile to embedded (and everything in between)

Before Rōnin, Joe spent years as a mobile developer, working across Android and iOS. “I did Android and iOS and embedded development,” he said. “iOS with Swift, Kotlin, Objective-C, Java. I’ve kind of gone through all of it.”

That background made the transition to his Rōnin project of embedded systems feel natural. Today, Joe works on systems that operate in trimmed-down environments, often close to the hardware. “Sometimes with these embedded projects, you don’t even have a user interface,” he said. “You’re just making sure everything connects and behaves the way it’s supposed to.”

Finding Rōnin at the right moment

Joe wasn’t actively job hunting for a new career when Rōnin entered the picture. “I hadn’t looked at any other recruiters,” he said. “And the moment I did look, it just happened to be for a job at Rōnin.”

What followed stood out immediately: responsive conversations, honest discussions about the work, and direct access to leadership. “I talked with the recruiter,  and then immediately with the two founders, Ryan and Byron,” Joe said. “It felt very real and very direct.”

Even the offer process felt different. “I sent them a very detailed spreadsheet,” Joe recalls, laughing. “I broke down compensation, PTO, training…everything I could think of. But what really mattered most wasn’t the negotiation itself, but the engagement. They responded on a Friday night. That told me a lot.”

Rōnin truly is an “open door policy.”

After past experiences where support felt distant, Rōnin’s culture was a shift Joe noticed immediately.

“They say it’s an open-door policy,” he said. “And it actually is.”

Joe describes a workplace where leadership is accessible, and problems are addressed head-on. “If there’s an issue with a client, you’re told, ‘Bring it to us,’” he explained. “And if it’s serious, the leadership actually steps in and helps. I don’t think most consulting companies do that.”

That sense of trust and support has shaped how Joe approaches his work at Rōnin, and how long he plans to stay…which is as long as he can.

Joe Hegeman is the hardware guy (and proud of it)

Within Rōnin, Joe is known as the hardware person. In his spare time, he builds computers regularly, experiments with different configurations, and keeps a close eye on how software actually runs on physical systems.

“I’m a hardware junkie,” he said. “When new things come out like phones, watches, hardware, I like to understand how they work.”

Joe isn’t interested in trends for their own sake; he cares about what’s practical, scalable, and reliable, and about understanding how things are built so he can continually improve how he works. That, and he just loves to tinker.