Companies are racing to adopt AI. Developers are experimenting with increasingly powerful coding agents. Businesses want projects delivered faster. But faster development doesn’t automatically produce better software.
In this episode of Develpreneur, Rob Broadhead and Michael Meloche talk with Kevin Riedl, founder of Wavect, an AI-native software agency in Austria. Kevin shares what he has learned building software with AI, helping organizations adopt it, and balancing automation with proven engineering practices. We cover what AI-native means, why quality assurance still matters, and how developers can use AI without sacrificing security, reliability, or maintainability.
This episode fits Season 29, Build a Career Beyond the Code. Writing code keeps getting easier. Knowing what to build, how to validate it, and whether it solves the right problem matters more every month.
About Kevin Riedl
Kevin Riedl is the founder of Wavect, an AI-native software agency based in Austria that works with clients internationally. His work covers software engineering, artificial intelligence, product development, and helping organizations build effective technology solutions.
Through Wavect, Kevin helps businesses with AI-assisted development, software modernization, and improving their engineering processes. He emphasizes practical results, established engineering principles, and reliable software over adopting technology because it’s popular. He also shares insights on AI development, emerging tools, software engineering, and technology trends through his professional content and Wavect’s online resources.
Connect with Kevin Riedl:
LinkedIn: https://www.linkedin.com/in/wsdt/
Wavect: https://wavect.io/
What Does It Really Mean to Be AI-Native?
Startups use the term “AI-native” to describe their business models. Established companies are restructuring around it. Software teams are working it into their development processes. Kevin thinks organizations should be careful about what the term means.
Being AI-native doesn’t mean putting AI in every application or discarding decades of engineering experience. It means knowing where AI adds value and pairing it with proven development practices.
Kevin calls AI one of the most significant tools developers have received in decades, but it’s still a tool. Developers still need to understand architecture, security, testing, requirements, and the business problem in front of them.
Some organizations treat AI as a replacement for their existing processes. They assume that because AI can generate code, it can also make every architectural decision, understand every requirement, and catch every problem. It can’t. Good AI-native development combines what AI does well with human engineering expertise.
The goal isn’t to use AI everywhere. The goal is better software, with AI used where it makes sense.
Just Because AI Can Do Something Doesn’t Mean It Should
AI capabilities have expanded quickly. Modern tools can write applications, deploy infrastructure, drive browsers, analyze repositories, run tests, and help gather customer requirements. Work that once took specialized knowledge or significant time can now be partly automated.
That doesn’t make automation the right call every time.
Experienced developers know the pattern. AI produces an answer that looks reasonable but misses key context. The code works, but it ignores performance concerns, security requirements, or existing architectural decisions. The model repeats approaches that already failed, or its changes break something elsewhere in the application.
The risk grows with the responsibility. Asking a model to explain a function carries little risk. Letting it modify an entire application or deploy infrastructure carries a lot more.
Kevin keeps human expertise and quality assurance at the center. Developers need to understand what the AI is doing, spot its mistakes, and set up controls that keep those mistakes out of production.
AI speeds up development. Developers still own the results.
AI Adoption Is Not the Biggest Challenge. Governance Is.
Michael asked about companies that introduce AI without preparing their people. Some buy tools, hand out licenses, and expect productivity to jump. Others build controlled environments, train employees, and phase AI into existing workflows.
Kevin says that at many companies, getting employees to use AI is no longer the hard part. They’re already experimenting, sometimes without their employer knowing.
The hard part is setting rules and making sure people understand them.
Kevin described a large enterprise that had invested in its IT department, written internal policies, and provided approved AI tools. Employees still had personal smartphones. If they wanted help with a problem, they could photograph their screen and send it to a public AI service.
Locking down company computers doesn’t fix that.
Organizations need to teach employees what information they can share, which tools are approved, and how to use AI responsibly. Kevin compares it to cybersecurity awareness training. Employees learned to spot phishing and suspicious emails. Now they need to learn the risks of sharing information through AI platforms.
AI governance has to be part of daily operations, not a policy people read once and forget.
Start With Simple AI Guardrails
When Michael asked what organizations should do to protect themselves, Kevin said it depends on the business. A small software agency has different needs than a large financial institution or a multinational enterprise.
His advice is to start with the basics instead of trying to solve every problem at once. Simple policies and employee education cover many of the most common risks. Start with the mistakes most likely to happen in normal AI use.
Practical guardrails to start with:
- Protect confidential information. Never put sensitive business data, customer records, credentials, or proprietary information into unapproved AI services.
- Establish approved tools. Tell employees which AI platforms they can use and what restrictions apply.
- Provide ongoing training. Cover AI policies in onboarding and reinforce them as tools change.
- Maintain human oversight. Require review before AI-generated changes reach production systems or customers.
- Define quality standards. Set testing requirements, acceptance criteria, and review processes for AI-assisted work.
- Adapt policies to the business. Account for industry regulations, company size, customer expectations, and how sensitive the information is.
None of this is new. These practices build on existing software development and security principles. Organizations don’t need a new management philosophy to introduce AI responsibly. They need to apply established principles to a new technology.
Kevin’s advice: get the fundamentals right first. Organizations that follow simple policies consistently prevent many avoidable problems and can build more sophisticated governance over time.
Managing Context in AI-Assisted Development
Rob raised another challenge: managing context.
AI tools can now work across entire repositories instead of single functions. Larger tasks need more information about the application’s architecture, dependencies, requirements, and existing implementation. The question is how much the model actually needs.
Too little context leads to wrong assumptions. Too much drives up token usage, slows responses, and buries what matters.
Kevin says developers are experimenting with tools that trim unnecessary context and make information easier for AI to process. Some compress command-line output. Others organize repository information into structured knowledge representations. These techniques can cut token consumption and help AI focus on the relevant parts of a project. Kevin mentioned significant savings reported with combinations of context-management tools, though results depend on the tools and workloads.
The takeaway isn’t that every developer should adopt a particular optimization framework. The technology changes too fast for any single tool to stay the obvious answer. Developers should understand how context affects AI performance and try approaches that improve efficiency.
Good Documentation Makes AI More Effective
Rob tied context management to something developers have talked about for decades: documentation.
Well-run software projects already have clear requirements, API definitions, architectural diagrams, and technical documentation. These let developers understand a system without reading every line of code. The same applies to AI.
When developers give AI accurate, structured information about an application, the AI spends less time figuring out how the system works and more time on the actual problem. Clear documentation cuts unnecessary context and makes responses more relevant.
Take an AI agent working on an API integration. It works better when the endpoints, request formats, authentication requirements, and error-handling rules sit in one place. Without that, it has to search multiple files or guess at the implementation.
That changes what documentation is for. It no longer serves only to onboard developers or maintain legacy systems. It’s now part of the information infrastructure that supports AI-assisted development.
It still has to be accurate. Outdated or conflicting documentation misleads AI as easily as it confuses a human developer. The better the information we provide, the better the results.
Vibe Coding vs. AI-Assisted Software Engineering
One of the best parts of the interview covers the difference between vibe coding and professional AI-assisted development.
As AI coding tools improve, developers write less code by hand. They describe requirements, review generated implementations, and guide AI agents through tasks.
Kevin says the line between vibe coding and AI-assisted engineering increasingly comes down to the experience and judgment of the person directing the work.
A developer who understands software engineering can have AI generate large parts of an application and still control its quality. That developer can evaluate architecture, spot missing requirements, review implementation decisions, and check the software against its acceptance criteria. Someone without that experience may end up with an application that looks functional but has serious problems.
Kevin shared an example. A client used AI to build an e-commerce application. The tools produced software, but the application wasn’t usable at first. Kevin’s team found the problems and organized them into GitHub issues so the client’s AI agents could fix them. The first review produced about 70 issues, and a second round found roughly 30 more. Further iterations improved the application, but the project showed a clear limit.
AI can generate code. It doesn’t automatically know whether the result meets professional quality standards.
What matters isn’t who wrote the code. It’s whether someone understands what needs to be built and can verify that it works.
Quality Gates Are More Important Than Ever
AI speeds up implementation, which increases the amount of software that needs review.
A developer can now generate several features in the time it once took to build one. Those features still need testing, integration, review, and validation against business requirements. Without quality gates, teams push problems through the pipeline faster instead of delivering better software.
Kevin points out that experienced engineers know what to check. An application can pass a simple demo and still hide serious defects.
Quality gates set consistent expectations throughout development. They can include automated tests, code reviews, security checks, integration testing, and acceptance criteria tied to the original requirements. The specific controls vary by project, but the goal stays the same: verify that the software does what it should.
This matters most when AI agents handle multiple development tasks with little human involvement. The more you delegate, the more you need reliable ways to evaluate the results.
AI may shorten the time it takes to create software, but it doesn’t remove the need for testing. In many cases, it makes testing more valuable.
Building a Career Beyond the Code
Kevin’s perspective ties directly to our Season 29 theme.
As AI gets better at generating software, developers need to think about how their skills stay valuable. Knowing a language or framework still helps, but implementation alone no longer gives the same competitive edge.
Developers who see the larger picture will be better positioned. That means understanding customer requirements, identifying business problems, designing maintainable systems, evaluating technical decisions, managing security risks, and making sure applications meet expectations.
A developer who can explain why a solution makes sense provides more value than one who just generates an implementation. A developer who catches an architectural problem early can save an organization significant time and money.
AI gives experienced developers more leverage. They can apply their knowledge across more work and spend less time implementing individual functions and more on design, validation, integration, and problem-solving. That advantage depends on continuing to build those skills.
Learning to use AI matters. Learning to evaluate its output may matter more.
Final Thoughts: Build Better Software, Not Just Faster Software
Adopting AI and using it well are different things.
Becoming AI-native doesn’t mean replacing developers, dropping established engineering practices, or automating every task. It means knowing where AI creates value and building processes that let teams use it responsibly.
Organizations need clear guardrails, accurate documentation, sound security controls, and reliable quality assurance. Developers need to understand the systems they build and recognize when AI produces an incorrect or incomplete solution. Teams need to focus on outcomes, not the volume of code generated.
AI helps us move faster, but speed alone doesn’t create value. Customers care whether software solves their problems, runs reliably, and supports their business. The developers who succeed will combine AI capabilities with practical experience, critical thinking, and strong engineering judgment.
That’s how we build better developers and better software.
Stay Connected: Join the Developreneur Community
👉 Subscribe to Building Better Developers for more conversations on momentum, leadership, and growth. Whether you’re a seasoned developer or just starting, there’s always room to learn and grow together. Contact us at [email protected] with your questions, feedback, or suggestions for future episodes. Together, let’s continue exploring the exciting world of software development.