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.” 

What an AI-First Feature Build Looks Like From the Inside

Many talk about going AI-first or building an AI-first feature, but we’re doing it.

In practice, it’s messier and more interesting than most acknowledge.

Right now, our team is working through an AI-first feature. It’s not a proof-of-concept or experiment, but a real feature with delivery commitments. This process clarified often glossed-over topics when discussing AI in software development, specifically: The technology is capable; the hard part is everything else.

The process habits that don’t want to change

The first thing we ran into wasn’t a technical problem. It was a habit problem.

Teams build up layers of process over the years. They follow a specific structure for how stories are written, who needs to be in the room, and what “done” looks like. Those structures that were created worked well enough and for so long that they stopped being deliberate choices and became reflexes.

I like to think of it as SDLC rust. It’s just processes that have been caked on for so long that, when something comes in and hammers them, saying, “nope, now you can do it another way,” people need time to adjust, even when they genuinely want to change immediately.

And that’s where we are now. AI hammers at the fundamentals, and it hits hard.

For teams with a lot of accumulated rust, it can be very disorienting when you try to knock it off and expect the system to work immediately.

You can’t mandate “AI-first” and expect people to instantly rewire their thinking about the SDLC. The change needs to happen, but it’s gradual, and pretending otherwise sets teams up to feel like they’re failing when they’re just adjusting. As we started navigating this, we found our process for documenting new features was changing, too.

How we’re building the PRD with AI  

One of the most concrete changes in how we’re working is how we define and document what we’re building. Before we started this process, there was no formal PRD. Instead, BAs would jump on calls with Product, trying to compile the ask and translate it into user stories, all while referencing a scattered mix of documents, specs, and artifacts that, together, described the feature being built.

It was decentralized, and creating a shared understanding before coding meant a lot of back-and-forth, context-switching, and reliance on tribal knowledge.

The problem with that model isn’t the intent. It’s variability. You have people in that room with very different levels of domain knowledge, all trying to converge simultaneously, while half of them are multitasking. The output reflects that. And the cost in time, in scheduling overhead, in contractor hours add up fast.

To address these challenges in alignment and documentation, we’ve moved to a different model.

The product owner sits down and has a direct conversation with AI. They spend time answering questions, refining the scope, and surfacing edge cases, and it is from this dialogue that the PRD emerges.

With this process, you go from ten people in a meeting to one person in a focused working session. The resulting document is more coherent. It shows a single, continuous train of thought rather than multiple people seeking alignment.

The PRD is faster, cheaper, and yields a cleaner document. But it isn’t finished the moment it’s approved.”

Gaps do happen. The question is how you handle them.

A skillfully crafted AI-assisted PRD will still have gaps. We expected this, but building a feature using this process made it clear. Even with thorough planning, you can hit implementation and find something missed or assumed.

That’s not a process failure, just the nature of complex software. The goal isn’t to eliminate gaps, but to have a solid process for feeding them back into the PRD as they appear.

What we’ve been building to identify and find these gaps is a feedback loop. When a developer hits a gap during implementation, instead of resolving it informally or making a snap judgment, we use AI tooling to generate a structured ticket. The ticket describes the gap:

• What was expected?
• What’s missing?
• What decision needs to be made?

That ticket goes to the BA or product owner, is evaluated, and, if valid, folds back into the PRD.

The PRD remains accurate throughout development, rather than becoming outdated. This might sound like a small detail, but it’s one of the more important process improvements we’ve made.

Watch out for when AI gets confident about the wrong thing.

Here’s something we ran into that I think every team working this way needs to be prepared for.

AI is great at reading a codebase and creating implementation plans. But when it lacks information about your specific system, it might propose the wrong solution with full confidence. It might fill in gaps based on general patterns rather than signaling uncertainty.

We had a situation in which our system had an established approach to record auditing. It wasn’t specifically documented in the context we’d given the AI. So, when that requirement came up, the AI proposed building a set of new tables and columns to handle it.

But that implementation would be completely redundant with what already existed. If someone without deep knowledge of the system had accepted that output, we would have caused considerable technical debt under the impression we were solving a problem.

The fix isn’t better AI. It’s a better context and a developer who knows the domain well enough to catch what the AI doesn’t.”

Building context is unglamorous work, especially in large codebases that were not originally designed for AI-first development. Documenting these key elements is what separates teams that get true value from AI from those that produce polished but sometimes wrong code.

Takeaways from using AI on a real product

A few things I’ve noticed as we’ve worked through this:

Developers are now asked to own the feature end-to-end, not just coding, but understanding. In AI-first development, you need to clearly describe the business problem for AI and critically evaluate its output.

That requires a deeper understanding of the domain. The developers on our team who are picking up this new process best are the ones who have always treated business knowledge as part of their job. The ones who haven’t been are finding this transition harder.

We’re still figuring out developer speed, QA testing, and maintaining quality. AI-assisted development boosts output, but QA still operates at a human pace. We’ve had to add deliberate pauses so developers can collaborate with QA instead of just producing more.

This isn’t necessarily a bad thing. Pausing can help align the direction of a feature across different roles, which helps maintain the accuracy of our outcome. But we are seeing developers take on more in this process, which leaves roles like Scrum Masters trying to shift where their value is used in the SDLC.

What I’d tell a team starting this tomorrow

Don’t expect perfection, expect collaboration.

You’re going to be changing the engine while the car is moving, because that’s the reality of how technology shifts happen inside organizations with real roadmaps and real commitments. Build grace periods into your process. Build feedback loops. Design for gaps rather than hoping they won’t appear.  We all need to wear multiple hats to make a feature a reality.

Invest in context before you invest in tooling. The AI is only as useful as the information you give it about how your system works and what your business needs. That documentation work is foundational, and only your team can do it.

Put your domain knowledge where it matters most. The developers who know the business as well as they know the code are your most valuable people in this model. Make sure they’re the ones guiding the AI, not the ones watching from the side.

These key takeaways are forming our approach. We’re still figuring this out and that’s the most honest thing I can say. But we’re learning fast, and our lessons are worth sharing.

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?”

How I Built a Mobile App Without Coding

What I learned by taking an AI development experiment all the way to the Apple App Store

I gave myself a challenge: build a full-featured mobile game without writing a single line of code.

Not a prototype. Not a proof-of-concept. A real app, ready for the App Store, with daily puzzles, AI-generated content, friend groups, leaderboards, push notifications, actual authentication, admin controls, profile management, etc.

The result is Puzoozle, a puzzle game where players scramble images, compete with friends, and solve AI-generated daily challenges. It’s not perfect, there are a dozen more features and enhancements I could add. But that’s not the point.

The point is I didn’t write any of the code to make it. I just talked to Claude Code.

What tools I used to build an app without coding

With Puzoozle, I wasn’t trying to reinvent gaming. It’s built on a familiar concept (picture puzzles) because my goal wasn’t innovation. It was exploration. How far could I build an app just through a conversation with Claude Code?

Turns out, it’s a lot, and the game I built includes everything you’d expect from a mobile app, from push notifications to private friend groups and full user management.

All of it was built using Claude Code, Anthropic’s tool for agentic coding (aka vibe coding). But I wasn’t asking for isolated functions or copy-paste code snippets. I was having full architectural conversations.

The process was simple. I would describe what I wanted. Claude Code would propose a plan, and then I would review it. We’d bat it back and forth, then I’d have Claude Code implement it.

Sometimes it nailed it on the first try. Sometimes it didn’t. But when it didn’t work correctly – that’s where the real breakthrough happened.

Letting Claude Code debug itself

It didn’t take long for me to hit a frustrating loop.

I’d request a feature, giving Claude Code broad instructions and the freedom to interpret how to implement my request with a UI that fits the theme I had described.

However, when I ran the app, something would sometimes be off. A notification would appear under a window. A button wouldn’t respond correctly. A new UI element would run off the screen.

Each time this happened, I’d have to give Claude Code more context about the problem it had just created, restart the application in my mobile simulator, navigate to the page, take a screenshot, send it to Claude Code, and point out what was wrong. It was painful and time-consuming, and Heaven forbid it got it wrong a second time.

I worked with Claude Code this way for a while, and I kept thinking that I needed to address it, and surely there is a better way.

So, I took steps to remove myself from this inefficient loop as much as possible. Using MCP (model context protocol), I wired Claude Code into additional tools so it could interact autonomously with the development environment. With these new tools, Claude Code could:

• Deploy the app to the simulator.
• Launch it and interact with it.
• Take screenshots of what it was seeing.
• Evaluate the visual output against what it was supposed to do.
• Identify problems on its own.
• Fix issues and try again.

Once that was connected, everything changed.

Claude Code would implement a feature, deploy it, run the simulator, click around, take a screenshot, realize something wasn’t right (oh, I don’t see the pop-up where it should be), figure out what went wrong in the code, adjust it, and try again. All without me stepping in.

I’d watch it work through the problem. It was like watching someone else debug code, except that someone was the AI that wrote the code in the first place.

Watching that happen feels like a fundamentally different development model. The validation loop is tightened, and problems are caught and fixed within minutes rather than requiring my intervention each time.

The taco lunch moment

The most surreal moment happened at a taco lunch with my family.

I showed the game to my kids, and they started playing with it, solving puzzles, and drawing things. And, of course, their suggestions for improvement were immediate.

My son: “I’d really like to play my own puzzles I just made.”

My daughter: “Dad, can you add shapes, text, and more colors?”

My son: “I think I crashed it when I went to publish my puzzle.”

In the old world, I’d say, “Yeah, that’s a good idea, I’ll add it to the backlog,” or “I’d better try to recreate that issue,” and maybe get to it in a few weeks. Or I’d forget entirely because, you know, life. It’s a side puzzle game, after all.

But in this new world, things are different. I opened GitHub on my phone right there at the table (and for sure caught some stray eyes from my wife while doing so) and created a few new issues in my project. I typed quick descriptions of what they wanted, asked Claude Code to come up with a plan, and if everything was clear enough, implement it.

We finished our tacos. Drove home, and when I walked in the door a couple of hours later, all their features had a plan written out and had been coded up on a new branch.

I pulled down the branch on my laptop. Validated Claude Code’s implementation on my iPhone simulator, then had it deploy the updated app to my phone.

“Hey, kids, come look. Here are your features from lunch.”

They thought it was super cool to see their ideas already implemented. So did I, honestly.

It took just a couple of hours from idea to implementation, and largely because we kept eating tacos. Features that would have taken me an evening or two to code manually, test, and integrate properly – took hours.

The conversation between “we should build that” and “it exists and works” has essentially collapsed. The friction is gone. It’s just conversation and validation now.

Ready to try Puzoozle? Download it now from the App Store and solve some AI-generated puzzles. See for yourself what’s possible when AI does the coding.