Develpreneur: Become a Better Developer and Entrepreneur

A successful technology career does not always follow a straight path. Developers and IT professionals often start with a clear idea of where they want to go, only to find that layoffs, industry shifts, burnout, and unexpected opportunities can completely change their direction. In this episode of Building Better Developers, hosts Rob Broadhead and Michael Meloche welcome Ryan Drumheller to discuss his journey from hands-on technology work to leadership, consulting, and eventually entrepreneurship. About Ryan Drumheller Ryan Drumheller is a technology leader, entrepreneur, author, and co-founder of Dogleg Digital. With more than two decades of experience spanning IT operations, infrastructure, development, technical leadership, and business strategy, Ryan has focused much of his career on connecting technology with the people and organizations it serves. He graduated from Western Governors University and advocates for professional education, mentorship, and continuous learning. His book, From Firewalls to Fairways: How a Career in IT Led Me to Golf, shares lessons from his career and explores how setbacks and unexpected opportunities can lead to personal and professional reinvention. Connect with Ryan and learn more about his work: LinkedIn: https://www.linkedin.com/in/ryan-drumheller/ Personal website and book: https://ryandrumheller.com/ Dogleg Digital: https://doglegdigital.com/ Finding a Passion for Technology Ryan's interest in technology began long before he entered the professional world. As a child, he struggled to find a traditional artistic outlet, but computers gave him the freedom to experiment and create. He spent countless hours taking computers apart, putting them back together, exploring early internet technology, and learning how systems worked. That curiosity eventually led him through technical support, networking, development, engineering, and leadership. While his technical skills opened doors, his ability to connect with people helped shape the next stage of his career. Michael related to Ryan's experiences, having grown up during the same era of dial-up internet and bulletin board systems. Their conversation highlighted how early experimentation developed problem-solving skills that remain valuable today. However, Ryan acknowledged that his curiosity sometimes created challenges in professional environments. He frequently wanted to understand why a problem existed rather than simply applying the requested solution. Over time, he learned to balance his desire to explore with the practical needs of the business. Building a Technology Career in the Age of AI As their discussion shifted toward artificial intelligence, Michael asked an important question: How should developers entering the industry today build the experience needed to remain valuable? Ryan emphasized that AI has fundamentally changed the opportunities and expectations facing technology professionals. While AI can generate code and accelerate development, understanding how systems operate remains essential. Developers must recognize mistakes, evaluate security concerns, and determine whether a proposed solution actually works. Rather than relying exclusively on one technical specialty, Ryan encourages professionals to develop multiple complementary skills. Understanding different technologies, industries, and business processes creates opportunities that cannot easily be replaced by automated tools. The objective is not to compete against AI at everything it can do. Instead, developers should combine their knowledge with AI to deliver better results. When the Traditional Career Path Stops Working Ryan's career followed a familiar progression from individual contributor to technical leader. However, professional success did not provide immunity from organizational changes. After losing one position, Ryan completed approximately 20 interviews and found another opportunity within 35 days. That role allowed him to work internationally, expand his experience, and continue growing professionally. Unfortunately, another organizational shift eventually eliminated that position as well. This time, Ryan encountered a very different employment market, influenced by economic uncertainty and the rapid adoption of AI. Michael shared a similar experience involving the elimination of his team following a corporate acquisition. Their discussion reflected a growing concern among experienced professionals: Even a strong technical background and years of demonstrated performance do not guarantee employment stability. These experiences encouraged Ryan to reconsider what he wanted from the next stage of his career. Networking Is More Important Than Ever One of Ryan's strongest recommendations for professionals navigating career uncertainty is to build meaningful relationships before they urgently need them. He considers LinkedIn a valuable platform for sharing expertise, discovering opportunities, and connecting with people already working in roles or industries of interest. However, he cautions against approaching every interaction with the expectation of receiving something in return. Instead, networking should begin with curiosity. Ask questions, participate in discussions, share useful information, and develop genuine relationships over time. For professionals who feel overwhelmed by networking, Ryan recommends simply starting. A few meaningful interactions can create opportunities that would never emerge from submitting another application. Turning Career Setbacks Into New Opportunities Ryan eventually discovered that consulting was not necessarily the professional environment where he felt most comfortable. Although he possessed extensive technical expertise, he found selling his personal services more difficult than communicating the value of a tangible product. That realization helped him revisit an earlier business idea that eventually evolved into Dogleg Digital, a technology ecosystem designed for the golf industry. His path toward entrepreneurship was not an immediate success story. Ryan described Dogleg Digital as his fourth attempt at building something. Each previous experience provided lessons about his strengths, his interests, and the type of work he wanted to pursue. Ryan's perspective challenges the idea that a career setback represents permanent failure. Experimentation, changing direction, and learning from unsuccessful attempts can all contribute to finding a better opportunity. From Firewalls to Fairways: Lessons Beyond Technology Ryan's book, From Firewalls to Fairways, connects his professional experiences to the lessons learned during a round of golf. Each chapter uses a different hole to explore topics such as career development, networking, salary negotiations, leadership, setbacks, and personal growth. The golf analogy reflects an important reality: Careers rarely unfold exactly as planned. Sometimes the best opportunity comes from reassessing the situation and choosing a different direction. For developers concerned about AI, employment uncertainty, or professional stagnation, Ryan's journey provides a valuable reminder that technical expertise is only one component of a sustainable career. Learning to build relationships, recognize opportunities, and adapt to change can be just as important as learning another programming language. Join Rob Broadhead and Michael Meloche for Part 2, where Ryan explains how he turned an industry problem into a product and why AI is changing the way developers build, test, and deliver 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. Additional Resources Career Improvement – From Better Developer To Better Career Lifelong Learning Habit: The Career Advantage That Outlasts Talent Security Awareness: Protect Your Code, Your Career, and Your Future Building Better Developers Podcast Videos – With Bonus Content

Artificial intelligence is rapidly changing what it means to be a software developer. Writing code is becoming easier, AI agents can complete increasingly complex assignments, and developers can accomplish tasks that previously required entire teams. However, the ability to generate software does not automatically mean the software is useful, secure, scalable, or even correct. That raises an important question for developers at every stage of their careers: If AI can write much of the code, what skills will define the difference between junior, mid-level, and senior developers? In Season 29, Episode 14 of the Develpreneur Podcast, Rob Broadhead and Michael Meloche continue their conversation about building a career beyond the code. This time, they focus on the evolution of vibe coding, the increasing importance of engineering judgment, and why developers must learn to manage AI agents like members of a development team. Vibe Coding Is Evolving Into AI-Assisted Engineering Vibe coding began as a way to describe building applications through natural-language instructions rather than manually writing every line of code. A developer could explain what they wanted, allow an AI tool to generate the implementation, and make adjustments through conversation. That approach is evolving rapidly. Developers are beginning to use specialized agents for planning, implementation, testing, documentation, and deployment. Instead of a single assistant generating snippets of code, AI can participate in much larger portions of the development process. Rob observes that this changes how developers should think about their roles. When several AI agents can work on different assignments, the developer begins functioning more like a development team leader than an individual programmer. The value moves from typing instructions into a source file to coordinating work, reviewing decisions, and making sure the final solution meets the intended goals. What Separates a Junior Developer From a Senior Developer? Traditional career progression has often been tied to experience with programming languages, frameworks, architecture, and increasingly complex technical assignments. Junior developers learn how to implement features. Mid-level developers begin taking ownership of larger components. Senior developers understand broader systems, evaluate tradeoffs, mentor others, and take responsibility for technical outcomes. AI complicates that progression. If a junior developer and a senior developer both have access to tools capable of generating sophisticated code, the difference between them cannot be measured simply by how much code each person produces. The distinction increasingly becomes the ability to evaluate what AI creates. Can the developer identify missing requirements? Can they recognize security concerns? Do they understand why one architectural approach is better than another? Can they explain what happens when the application needs to scale? Do they know how to test and verify the result? These skills have always mattered, but AI makes them even more visible. Technical Knowledge Is Not the Same as Practical Experience Michael shares an example from his experience teaching Java boot camps. Some students could study a certification guide, memorize the material, and pass a technical examination without having much practical experience building software. Others had spent years developing applications and could solve complex problems but struggled with certification tests. The certification demonstrated knowledge of specific material. It did not necessarily demonstrate the ability to engineer a complete solution. AI introduces a similar challenge. Someone who knows how to use AI tools effectively may produce impressive applications without fully understanding the underlying systems. That does not mean their work has no value, but it does mean employers and customers need better ways to evaluate their capabilities. Developers must demonstrate that they understand what they are building, not simply that they can get AI to build it. The Software Development Lifecycle Is Becoming More Important One of the biggest changes AI introduces is a shift in how developers spend their time. Historically, software implementation consumed a substantial portion of a project's schedule. Developers spent hours writing classes, creating interfaces, connecting APIs, and implementing business logic. AI can reduce much of that implementation effort. However, the remaining stages of the software development lifecycle still matter. Requirements must be understood. Solutions must be designed. Systems must be tested. Applications must be deployed. Security must be evaluated. Users must confirm that the software actually meets their needs. Rob emphasizes that developers increasingly need to understand the complete lifecycle, from initial requirements through deployment and ongoing improvement. Michael points out that this transformation has been developing for years. Organizations have already been moving testing and DevOps responsibilities closer to development teams. AI accelerates the expectation that developers understand more than their individual specialty. A developer who can connect the entire process becomes increasingly valuable because they can recognize problems that arise between traditionally separate responsibilities. Quality Assurance Cannot Become an Afterthought One of the dangers of AI-assisted development is confusing the speed of implementation with the quality of the result. AI can generate large amounts of code, but that does not guarantee that the code is correct. It may misunderstand requirements, introduce security weaknesses, create unnecessary dependencies, or produce a solution that technically works but fails to solve the customer's actual problem. Michael emphasizes that quality assurance remains essential. As implementation becomes faster, developers should spend more time verifying what has been produced. Automated tests, integration testing, user acceptance testing, and critical reviews are necessary to ensure that faster development does not produce larger collections of defects. The opportunity AI creates is not simply to deliver more features. It is to spend more time making sure those features work correctly and provide value. Learn to Manage AI Like a Development Team Managing AI agents requires many of the same skills used to lead human developers. You need to communicate expectations, establish boundaries, review progress, provide feedback, and determine whether the work meets the requirements. Michael suggests viewing AI agents as team members that need direction and supervision. Even developers who have not held formal leadership positions can begin practicing these skills through AI-assisted development. For example, you might assign one AI agent to design a feature, another to implement it, and another to review the result. However, someone still needs to determine whether the implementation meets the business need. That responsibility belongs to the developer. This process also helps developers develop better technical communication skills. If an AI agent consistently misunderstands an assignment, it may indicate that the requirements were incomplete or unclear. Learning to provide better direction can improve your interactions with AI and your communication with human coworkers. Business Value Matters More Than Software Output Rob returns to a fundamental principle of successful software development: the value of software comes from the problem it solves. Building another dashboard is not necessarily valuable. Adding another feature does not automatically improve a product. Increasing the number of lines of code does not make an application more useful. The important question is what changes for the user. Does a new feature eliminate unnecessary work? Does an automation reduce mistakes? Does a dashboard help someone make a better decision? Does the application make a business process faster, more reliable, or easier to manage? These are the outcomes developers should focus on. Rob uses the simplicity of the original iPod as an example of how removing unnecessary complexity can create a better user experience. More features often introduce more testing requirements, maintenance concerns, and potential points of failure. The best solution is not always the one that does the most. Sometimes the most valuable engineering decision is knowing what not to build. AI Does Not Belong in Every Solution The increasing accessibility of AI has also created a temptation to use it everywhere. Michael cautions against online promises that suggest building a collection of AI agents will automatically create passive income or effortless business growth. Those systems require development effort, maintenance, subscriptions, processing costs, and ongoing supervision. Rob expands on the point by explaining the importance of deterministic software. Some tasks benefit from AI's ability to analyze information and handle ambiguity. Others need predictable behavior and repeatable results. For example, a system gathering specific information from a website may benefit from AI during exploration or when handling unexpected page changes. However, the actual collection of known data fields may be better handled through conventional programming. Developers should evaluate where AI creates meaningful value and where simpler technology produces a more reliable and economical result. AI should be a tool selected for a reason, not the automatic answer to every technical problem. Practice Building and Managing Your Own AI Project Developers who want to prepare for this changing environment do not need to begin with an enormous project. Rob suggests choosing a small problem and using AI to develop a complete solution. It could be a personal automation, a simple game, a productivity utility, or an application that addresses a recurring frustration. The important part is working through the complete process. Define the requirements. Explain the desired result. Review the proposed architecture. Let AI assist with implementation. Test the output. Identify problems. Correct them. Deploy the application and evaluate whether it accomplishes the original goal. Pay attention to how often you need to redirect the AI. Those moments reveal where communication, architecture, and engineering judgment are required. You are not just practicing prompt writing. You are developing the skills needed to direct technical work. The Future Developer Is a Solution Provider The role of a software developer has never been limited to writing code, even if many organizations have measured productivity that way. AI is making that distinction impossible to ignore. Developers who focus exclusively on producing code may struggle to differentiate themselves as AI-assisted development becomes more accessible. Those who understand the full software lifecycle, recognize business needs, manage AI agents, and verify results have opportunities to provide much greater value. The developer of the future needs to be comfortable working across technical disciplines while maintaining the judgment to recognize when specialized expertise is necessary. Key Takeaways AI-assisted development is moving beyond basic vibe coding toward coordinated agent-based workflows. Developer seniority increasingly depends on judgment, problem-solving, and responsibility rather than coding speed. Understanding the complete software development lifecycle creates stronger career opportunities. Faster implementation should create more opportunities for testing, verification, and quality improvement. Treat AI agents like junior team members that require clear instructions, boundaries, and review. Focus on measurable customer outcomes rather than the number of features or lines of code produced. Use AI where it adds meaningful value and conventional software where predictability is more important. The question is no longer simply whether you can write the code. It is whether you can define the right problem, guide the development process, evaluate the result, and deliver something that makes a meaningful difference. That is what it means to become a developer beyond the code. 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. Additional Resources AI-Native Development Without the Hype: Kevin Riedl on Building Better Software With AI AI-Assisted Rust: Building Reliable Software Through Compilers, Testing, and Modern Tooling Simplifying Software Delivery Before AI Amplifies Your Chaos Building Better Developers Podcast Videos – With Bonus Content

Artificial intelligence has changed the way developers write code, search for jobs, and present their professional experience. Resumes can be generated in seconds, proposals can be polished instantly, and technical answers are available with a simple prompt. However, all of this convenience creates a new challenge: How do you distinguish yourself when everyone has access to the same tools? In Season 29, Episode 13 of the Develpreneur Podcast, co-hosts Rob Broadhead and Michael Meloche explore how AI is changing hiring, professional development, and the way developers communicate their value. As part of the season's theme, Build a Career Beyond the Code, they discuss why technical skills alone are becoming less effective at setting candidates apart and why critical thinking, authentic experience, and demonstrated problem-solving abilities matter more than ever. The Problem With AI-Generated Resumes and Proposals AI has made it easier than ever to produce professional-looking resumes and proposals. A candidate can enter a job description into an AI tool and receive a document that addresses nearly every requirement. Similarly, consultants can generate detailed proposals that appear to align perfectly with a customer's needs. The problem is that these documents are becoming increasingly similar. Rob compares this shift to the transition from standard-definition television to high-definition broadcasting. When everything became clearer, details that previously went unnoticed suddenly became obvious. AI is having a similar effect on professional communication. It has exposed how much of the traditional job application process relies on formulas and predictable language. Recruiters and hiring managers are becoming familiar with AI-generated responses. A polished resume may help someone enter the hiring process, but it does not necessarily demonstrate that the candidate has the experience or judgment required to perform the job. The real challenge is no longer simply getting someone to see your resume. It is convincing that person to have a meaningful conversation with you. Your Technology Stack Is Not Your Entire Professional Story Developers traditionally describe their experience through programming languages, frameworks, databases, and platforms. A resume might highlight Java, Spring Boot, AWS, React, Python, or dozens of other technologies. While these skills remain relevant, they do not tell the complete story. Knowing how to write code is only one part of being a successful developer. Employers and customers need people who can recognize problems, evaluate alternatives, make informed decisions, and deliver solutions that create measurable value. Rob suggests shifting attention away from simply listing technologies and toward explaining the problems you have solved. Consider the difference between stating that you developed a Java application and explaining that you redesigned a business process, eliminated repetitive manual work, addressed performance problems, or improved the reliability of a critical system. The technology describes how you accomplished the work. The problem and its outcome explain why the work mattered. Show Your Work: Critical Thinking Is the Differentiator Michael draws an interesting comparison between software development interviews and solving math problems. In school, students are often required to show their work rather than simply provide the final answer. The process demonstrates whether they understand the underlying concepts and can apply them to different situations. Software development interviews should follow a similar approach. AI can generate an answer to a coding problem almost instantly. However, that does not mean the person using AI understands the problem, recognizes potential limitations, or knows how to adapt when circumstances change. A stronger interview focuses on the candidate's reasoning. What problem are they trying to solve? What information do they need? How would they approach the design? What happens when their initial solution fails? How would they explain their recommendation to someone without a technical background? These questions reveal abilities that are difficult to evaluate through memorized answers or automated coding exercises. Michael also emphasizes the importance of communicating with nontechnical stakeholders. Developers frequently work with business owners, managers, and customers who care more about results than implementation details. Being able to explain complex technical decisions in understandable language is an increasingly valuable skill. AI Is Changing the Hiring Conversation Both Rob and Michael discuss how AI is introducing new complexity into the hiring process. Michael shares experiences with candidates relying heavily on AI during interviews. Instead of responding naturally, some applicants appear to be generating answers in real time. This makes it harder for interviewers to determine whether they are evaluating the candidate's knowledge or simply the output of an AI tool. At the same time, interviewers are becoming more sophisticated in how they evaluate applicants. Rather than relying exclusively on technical questions, employers can ask candidates to explain previous projects, describe unexpected problems, and discuss how they adjusted their approach. Those experiences provide a more authentic view of someone's capabilities. A developer who can explain a difficult production issue, describe why a design decision failed, and show how the team recovered demonstrates practical experience that goes beyond a collection of keywords. Do Not Confuse AI Assistance With AI Dependence AI can be an excellent tool for preparing resumes, practicing interviews, researching companies, and organizing professional experience. It can help developers identify gaps in their explanations and discover better ways to communicate their accomplishments. However, the value comes from using AI to strengthen your own knowledge rather than replace it. Rob points out that AI-generated suggestions must be evaluated carefully. A response may sound complete while including unsupported assumptions, unnecessary details, or information that does not accurately represent your experience. Michael adds that newer AI tools and models are not always automatically better for every workflow. Developers need to evaluate the reliability of the tools they use rather than constantly adopting the newest model simply because it is available. The key is maintaining control over the process. Use AI to prepare, refine, and challenge your thinking, but make sure the final result accurately represents what you know and what you have accomplished. Just Because AI Can Do Something Does Not Mean It Should Rob closes the discussion with an example from his own AI-assisted development work. While working on a project, an AI assistant began identifying additional improvements in related environments. Some recommendations involved security, infrastructure, and other technical areas. Although the suggestions might have been useful in another context, they were outside the project's intended scope. Rob had to explicitly instruct the AI not to make those changes. This illustrates one of the most important responsibilities developers have when working with AI: determining which recommendations actually matter. Without clear boundaries, AI can turn a relatively focused task into a much larger project. Developers must recognize when additional complexity creates value and when it creates unnecessary work or risk. The ability to make those decisions requires experience, judgment, and a clear understanding of the intended outcome. Building a Career Beyond the Code The software industry is entering a period where simply producing code is becoming less distinctive. AI can assist with implementation, generate documentation, and automate repetitive tasks, but it still requires thoughtful direction and meaningful evaluation. Developers who want to remain competitive need to strengthen the abilities that connect technical work to real-world results. That means learning how to communicate, solve problems, evaluate tradeoffs, demonstrate experience, and explain the value of the work they perform. The strongest professional story is not a list of technologies. It is a collection of problems solved, challenges overcome, lessons learned, and outcomes achieved. Key Takeaways Use AI to improve your resume and interview preparation without allowing it to misrepresent your experience. Focus on the problems you have solved rather than relying exclusively on technical keywords. Be prepared to explain your reasoning, decisions, challenges, and lessons learned. Practice communicating technical solutions to nontechnical audiences. Evaluate AI recommendations instead of accepting them automatically. Document your accomplishments so you can provide real evidence of your professional value. As AI continues to reshape software development, the ability to demonstrate genuine experience and sound judgment will help developers distinguish themselves from increasingly automated competition. Your value is not simply that you know how to write code. It is that you know how to use technology to solve meaningful problems. That is how you build a career beyond the code. 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. Additional Resources AI Workflow Automation: Start With the Problem, Not the AI Building Trust in the AI Era | Amit Zandberg Developer Career Growth: The Evidence That Gets You Promoted Building Better Developers Podcast Videos – With Bonus Content

AI is an essential tool for many developers, but using it well takes more than picking the most powerful model. As adoption grows, developers and businesses face new questions about cost, performance, infrastructure, and matching the right technology to each task. Knowing when and how to use each option is becoming a core engineering skill. In this episode of Develpreneur, Rob Broadhead and Michael Meloche continue their conversation with Kevin Riedl, founder of Wavect, an AI-native software agency in Austria. Building on our last discussion about AI-native development and software quality, we dig into the technical and business decisions behind efficient AI-powered systems. Kevin shares his views on local AI models, cloud services, model routing, orchestration, token optimization, and shifting expectations for software development. We also talk about how smaller companies can compete with larger ones by using AI strategically, without piling on cost or complexity. This episode fits Season 29, Build a Career Beyond the Code. Generating code is getting easier for everyone. Designing efficient systems, controlling costs, and delivering real business outcomes is where the value is. 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. His approach emphasizes practical results, thoughtful technology decisions, and using AI to create measurable business value. He also shares insights on emerging AI tools, software engineering practices, 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/ Local AI vs. Cloud AI: Which Makes More Sense? As developers get comfortable with AI, many start thinking about running models locally. Instead of relying on ChatGPT or Claude, they consider buying hardware and hosting their own AI infrastructure. Michael brought this up while talking about his experiments with Apple Silicon, including Mac minis and a Mac Studio. Powerful consumer hardware gives developers more room to experiment with local models and build private AI systems. Kevin says the decision often comes down to economics. Local AI keeps improving, but cloud-based frontier models are still cheap compared with buying and maintaining the hardware needed to approach their capabilities. For many individuals and small businesses, running advanced models locally would cost more than a commercial AI service. That doesn't mean local AI has no value. Running models locally gives you more control over your data, less dependence on outside providers, and a good fit for workloads that run continuously. It also lets developers see how models behave outside the interfaces the major AI companies provide. The real question is whether the investment supports an actual business or technical need. A company sending occasional requests will likely do better with a cloud subscription. An organization running AI workloads around the clock may find dedicated hardware increasingly attractive. Kevin recommends understanding both approaches instead of assuming one always wins. Why Developers Should Experiment With Local Models Even if cloud AI makes financial sense today, developers should know the alternatives. AI providers keep changing their models, capabilities, pricing, and services. A business that depends on one provider may eventually hit limits that affect its costs or operations. Understanding local AI gives you another option. Kevin suggests Hugging Face as a starting point for exploring available models. The platform hosts a large collection that developers can evaluate for different workloads. Tools like Ollama make it easier to run supported models on local hardware, compare capabilities, and learn the limits of smaller models. Experiments should have a purpose. A developer might test whether a local model can summarize documents, classify information, process internal records, or handle repetitive tasks without sending data to an outside service. Those jobs don't necessarily need the most advanced model available. Once you know which tasks a local model can handle, you can design systems that balance performance, cost, and privacy. AI Model Routing: Choosing the Right Model for Each Task One of the most interesting topics in our conversation was AI model routing. Many developers pick a single AI platform and use it for nearly everything. The same advanced model summarizes emails, writes documentation, analyzes complicated architecture, and produces production code. It's convenient, but it isn't always efficient. Kevin believes model routing will become an important part of AI development. Instead of sending every request to the same model, a routing system evaluates the task and picks a model that fits its requirements. It works like assigning work on a development team. You wouldn't put your most experienced architect on every small documentation update or routine data-processing job. You don't need the most powerful AI model for every request either. A model-routing strategy might look like this: Simple classification: Use a smaller model to categorize emails, documents, or support requests. Document summarization: Use a model that can handle the required context without extra reasoning overhead. Code generation: Pick a model suited to the complexity and requirements of the task. Architecture analysis: Use a more capable model when the work needs deeper reasoning and broader context. Sensitive internal processing: Consider local models when privacy requirements rule out external services. Complex problem-solving: Escalate difficult tasks to a more advanced model when simpler approaches fall short. The goal isn't to pick the cheapest model. It's to find the least expensive model that can reliably do the job. A model that's too limited can cost more in the end if it produces wrong results or needs repeated attempts. Kevin stresses that routing has to balance capability and efficiency, not just price. For developers building AI-powered applications, this is another place to apply traditional engineering principles. AI Orchestration: Letting Models Work Together Model routing gets even more powerful when combined with orchestration. Instead of relying on one model to complete an entire workflow, developers can build systems where a more capable model coordinates several specialized agents or smaller models. Kevin described an approach where a higher-level AI system decides what needs to be done and delegates tasks to other models. That mirrors how software teams divide work. A senior engineer defines the overall architecture while other team members build specific components. An AI orchestrator can take a larger objective, break it into manageable tasks, and assign each one based on the capabilities it needs. A development workflow might use separate agents to analyze requirements, generate code, review changes, run tests, and summarize results, with the orchestration layer coordinating the work and deciding when more is needed. This can reduce how much expensive model processing goes to routine tasks. Orchestration also adds complexity. Developers have to consider how agents communicate, how results get validated, and how the system handles failures. The goal isn't to build as many agents as possible. It's a workflow that produces reliable results with reasonable resource use. Kevin also noted that existing AI development tools already include some orchestration features. Try those before building a complicated custom solution. Sometimes the Best AI Solution Doesn't Use AI Rob raised another point: what happens when an AI workflow becomes predictable enough that it no longer needs AI? Software development has always meant finding repeatable processes and automating them. Once the rules are clear, developers can often build deterministic solutions that give consistent results. AI doesn't change that. Kevin says that if a task requires deterministic behavior, use deterministic technology instead of adding a language model. If a system needs to validate a known data format, calculate a specific value, or apply established business rules, conventional software is usually more consistent and cheaper. AI earns its place when a task requires interpretation, reasoning, or handling information that doesn't follow a predictable structure. Developers can get so focused on integrating AI that they overlook simpler options. A well-designed application may use AI for some tasks and conventional code for others. The best architecture isn't the one that uses the most AI. It's the one that solves the problem efficiently and reliably. AI Is Raising Customer Expectations for Software AI adoption is also changing what customers expect. Developers can build prototypes and minimum viable products faster than ever. Applications that once took weeks can become working demos in days. Kevin points out that customers know this. When software gets easier to produce, they expect more. That adds competition. A functional application no longer gives the advantage it once did. More businesses can build software, more entrepreneurs can test ideas, and more developers can bring products to market. As the number of solutions grows, standing out takes more than the ability to generate an app. Businesses need to deliver better outcomes. That might mean understanding customers more deeply, designing better experiences, solving more valuable problems, or delivering a level of quality competitors overlook. AI lowers some barriers to development. It doesn't create a successful product on its own. Why Expertise Still Matters in an AI-Driven Market As AI becomes more accessible, developers may wonder whether their experience still counts. Kevin's view is that it counts in different ways. If everyone has similar AI tools, the advantage shifts to how well those tools are used. Experienced developers understand architecture, integration challenges, security requirements, performance, and maintainability. That lets them recognize when an AI-generated solution is appropriate and when it needs more work. Business knowledge matters more too. A developer who understands the customer's problem can steer AI toward a useful solution. A developer who only generates code may build an impressive application that misses the actual business need. This ties directly to our Season 29 theme. The future of software development isn't about learning to prompt AI. It's about understanding how technology supports business goals and how to deliver reliable solutions. AI provides leverage. Expertise determines how well you use it. Reducing Token Costs Without Overcomplicating Your Workflow Michael raised a practical concern for independent developers and small businesses: controlling AI expenses. Large organizations may have big budgets for AI experimentation. Smaller companies have to be more deliberate. Subscriptions, API usage, and automated agents get expensive fast when nobody tracks consumption. Kevin recommends getting the fundamentals right before investing in optimization frameworks. One of the most effective moves is keeping clear documentation and giving AI systems the context they actually need. Developers can also use tools that trim unnecessary context, compress verbose command output, and organize repository information more efficiently. Kevin mentioned several approaches worth exploring: AGENTS.md files: Document project instructions, development conventions, and quality expectations for compatible AI coding agents. Context-management tools: Try utilities such as RTK AI and Lean Context to cut unnecessary information sent to models. Repository knowledge tools: Experiment with graph-based approaches that help AI understand relationships within a codebase. Model routing: Give simpler tasks to less expensive models when the results are acceptable. Agent orchestration: Configure agents to pick appropriate models and reasoning effort for delegated tasks. Clear acceptance criteria: Define what successful completion looks like before letting AI implement a solution. These techniques can cut token usage while keeping developers in control of their workflows. Kevin also cautions against spending too much time optimizing every detail. For smaller organizations, getting the most useful fundamentals in place may be enough, with no elaborate AI infrastructure required. The aim is to spend less time managing AI and more time delivering valuable work. Stop Focusing on Perfect Prompts and Start Defining Better Goals One of Kevin's most practical recommendations changes how developers talk to AI. Instead of spending hours crafting elaborate prompts, he focuses on clear goals, requirements, and acceptance criteria. That's traditional software engineering. Before development starts, teams should know what they're trying to accomplish, document the requirements, and decide how success will be measured. AI doesn't change that. Rather than giving an AI agent a long series of instructions covering every implementation detail, give it a clear objective and the information it needs to finish the job. The agent works toward that objective while the developer checks whether the result meets the requirements. If you want a new feature, don't just ask for it. Define the expected behavior, required integrations, security considerations, and acceptance tests. The workflow becomes more structured. AI handles implementation while developers make sure the solution delivers the intended outcome. It also raises the value of testing, because acceptance criteria give you a measurable way to decide whether the work is done. Documentation and Testing Remain Essential Across both parts of our conversation, Kevin keeps returning to established software development principles. Documentation, requirements, testing, and quality assurance still matter as AI tools get more capable, and they may matter more as developers hand more responsibility to AI agents. Clear documentation helps agents understand the system. Well-defined requirements keep them focused on the right problem. Acceptance criteria give you a way to evaluate results, and automated and manual testing help catch defects. Kevin also discussed how AI agents can take part in testing, including end-to-end testing and work with emulators or connected devices. That can speed up validation, but developers still need to understand what's being tested and whether the results mean anything. A passing test doesn't guarantee an application meets every business requirement. An AI-generated test suite can also miss scenarios an experienced tester would catch. Combine automation with engineering judgment. AI can do more of the work, but developers remain responsible for the quality of the finished product. Building a Competitive Advantage With AI Near the end of the conversation, Kevin shared his view on using AI to build a business. Calling a company AI-native is unlikely to stay a meaningful advantage. As more organizations adopt AI, the technology becomes part of the expected baseline. Businesses will have to show how they use it to deliver better products, services, and customer experiences. Kevin gave an example from Wavect's own marketing. After relaunching its website and applying new approaches, the company saw a substantial increase in online impressions. The lesson is that businesses willing to experiment, learn, and adapt can find opportunities slower competitors miss. Those opportunities may not last. As more companies adopt similar techniques, the advantage fades. Businesses need to keep improving instead of leaning on one tool or strategy. AI lets you accomplish more with limited resources, but success still depends on choosing the right activities. For independent developers and small software companies, that creates room to compete through specialization, customer understanding, quality, and responsiveness. The goal isn't just to work faster. It's to use the extra capacity AI provides to deliver something more valuable. Final Thoughts: Use AI Strategically, Not Everywhere The first stage of AI adoption was about discovering what the technology could do. Developers experimented with code generation, documentation, automation, and increasingly sophisticated assistants. The next stage is using those capabilities efficiently. That means knowing when local AI makes sense, choosing appropriate models, managing context, controlling token usage, and designing workflows that balance automation with reliability. It also means recognizing when traditional software is the better answer. Developers who understand these tradeoffs build systems that are more efficient, maintainable, and valuable to customers. Technical knowledge alone won't be enough. Developers will need to combine engineering experience with business understanding, problem-solving, and the ability to evaluate emerging technology. The most successful ones won't necessarily use the largest models or the most complicated agent frameworks. They'll know which tools to use, when to use them, and how to turn those capabilities into meaningful results. That's another step toward building a career beyond the code. 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. Additional Resources AI Governance and Guardrails: Don't Automate the Chaos Why AI Readiness Matters More Than AI Adoption AI Capital Strategy: Why Founders Need More Than Funding in the Age of AI Building Better Developers Podcast Videos – With Bonus Content

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. Additional Resources AI Communication Skills: Salvatore Manzi on Staying Human in an AI-Driven Workplace Developer Tools That Transform: Habits for Smarter Development AI Data Sovereignty: Why Owning Data Means Owning the Future Building Better Developers Podcast Videos – With Bonus Content

Smarter AI development is not about using the most advanced tool or building the most complicated solution. As AI makes software development faster and more accessible, developers and business owners face a different challenge: deciding what is actually worth building. The ability to create something quickly does not eliminate the need to validate the idea, maintain the finished product, or determine where human judgment still matters. In part two of our conversation with Alane Boyd, Co-CEO of Biggest Goal, Develpreneur: Building Better Developers explores what happens after a company moves beyond basic AI experimentation. Rob Broadhead and Michael Meloche talk with Alane about AI agents, vibe coding, custom software, minimum viable products, human oversight, and the growing temptation to build simply because AI makes building easier. For developers building a career beyond the code, the lesson is especially relevant. AI has dramatically reduced the effort required to turn an idea into working software, but the business questions surrounding that software have not disappeared. In many cases, those questions have become even more important. About Alane Boyd Alane Boyd is Co-CEO of Biggest Goal and a serial entrepreneur whose background spans technology, operations, sales, marketing, automation, and business growth. She has built SaaS businesses and describes herself as a two-time SaaS founder with successful exits. Biggest Goal's current work focuses on hands-on AI training and implementation for leaders and teams, including helping organizations move from basic AI experimentation toward repeatable systems and practical business workflows. Alane is also a published author, mentor, speaker, and podcast host. Her work increasingly focuses on practical AI fluency: helping businesses understand where AI belongs in their operations, how teams can use it consistently, and where human expertise should remain part of the process. Learn more about Alane and her work through Biggest Goal and connect with her on LinkedIn. Smarter AI Development Goes Beyond Chat Many people still use AI primarily through a chat interface. They enter a prompt, receive an answer, copy the output somewhere else, and repeat the process. Alane sees organizations beginning to move beyond that model toward AI workflows, connectors, scheduled tasks, skills, and agents. That progression can eliminate much of the manual movement between systems. Instead of repeatedly copying prompts and outputs, businesses can build processes that automatically trigger AI and move information where it needs to go. At the same time, tools such as Claude Code have made development accessible to people who would not traditionally consider themselves developers. Alane sees value in that shift because people outside software development can finally see some of what happens behind the scenes when software is created. However, creating an application is only one part of software development. The excitement of building something can hide the long-term responsibility that follows. Someone still has to maintain the application, troubleshoot failures, adapt to changing requirements, manage dependencies, and determine what happens when the original creator no longer wants to spend time supporting it. Michael sees the same issue when talking with people who have created applications using AI. They are excited because the application works, but they have not necessarily considered what comes next. AI Makes Building Easier, Not Maintenance Optional This creates one of the biggest challenges surrounding AI-assisted development. A founder can now describe an idea and begin creating software without fully understanding the lifecycle of the product being built. The first version can feel almost magical. AI writes code, creates interfaces, troubleshoots problems, and helps someone move from an idea to something tangible much faster than traditional development allowed. That speed can create the impression that software has become a one-time project. It has not. Alane points out that maintaining what you build can become a significant burden. A founder who creates a custom platform may eventually discover that the software requires constant attention. What started as an exciting experiment can become another system the founder is personally responsible for keeping alive. This is where smarter AI development requires thinking beyond the initial build. The important question is not simply, "Can AI build this?" It is also, "Do we want to own and maintain this after AI builds it?" Build Versus Buy Still Matters AI has made the traditional build-versus-buy decision even more interesting. If AI can create custom software faster and cheaper than before, building something yourself can look like the obvious choice. Alane's experience suggests otherwise. Before selling one of her previous companies, she merged with a competitor. Both companies had developed software, but one had built a SaaS product that customers could purchase while the other had proprietary software designed primarily for internal use. When the combined company eventually evaluated those systems, the proprietary software was the first to be shut down. The reason was business value. Internal proprietary software had limited marketability compared with a product customers were willing to purchase. The company had invested resources into creating and maintaining something that ultimately had little independent value during the sale process. That experience shaped an important principle in Alane's approach: build what people want to buy. For developers, that does not mean custom software is always the wrong decision. It means the ability to build something is not enough justification for building it. An existing platform may already solve the problem while another company absorbs the cost of maintenance, upgrades, security, and continued development. AI changes the economics of building software, but it does not eliminate those considerations. Validate the MVP Before You Keep Building Developers like to build. That is one of the reasons many people become developers in the first place. Give a developer an interesting problem and enough time, and there will always be another feature worth adding. AI can amplify that instinct. Alane recommends returning to a familiar startup principle: the minimum viable product. Before investing heavily in development, determine the smallest version of the idea that can test whether somebody actually wants it. That means asking practical questions early: Will someone pay for this? What is the smallest version we can put in front of a customer? Which features are actually required? Can we validate demand before investing more development time? Are we solving a real customer problem or simply enjoying the build? Alane acknowledges that she has fallen into the same trap herself. It is easy to believe a product needs every feature before customers can see it. The problem is that developers can spend months or even years creating something without discovering whether there is a viable market. Time is a resource. A product that consumes a year of development without generating revenue may eventually become difficult to justify, regardless of how technically impressive it is. Talk to Customers Before Building in a Vacuum Alane references the early Dropbox story as an example of validating demand before completing a product. Rather than waiting until every part of the platform existed, Dropbox demonstrated the concept and gathered interest from people who wanted the solution. The broader lesson is more important than the specific example. Developers and founders need feedback from potential customers before disappearing into build mode. Friends and family are not necessarily enough. The useful feedback comes from people who might realistically use or purchase the product. Those conversations can expose incorrect assumptions long before they become expensive features. AI makes this even more important because the barrier to building has dropped dramatically. When a new feature can be generated quickly, it becomes easy to keep adding functionality without stopping to ask whether anyone needs it. Smarter AI development requires resisting that momentum. Build enough to learn, talk to users, and then decide what deserves to be built next. Do Not Make the Solution Harder Than the Problem Developers and founders also have a tendency to make solutions more complicated than necessary. AI gives us even more ways to do that. A developer can open an AI coding tool, create custom logic, and continue refining an increasingly sophisticated solution. However, the same problem might be solved with a scheduled task, an AI skill, a simple automation, or an existing product. Alane encourages teams to focus on the job that needs to get done rather than the technology they want to use. The question becomes: What is the quickest, cheapest, and easiest reliable way to accomplish the goal? Sometimes that answer will be custom software. Sometimes it will be an AI agent. Other times, the answer may be a much simpler workflow. That distinction matters because every custom solution creates ownership. Someone has to maintain it. Someone has to understand it when it breaks. Someone has to modify it when the business changes. Smarter AI development includes knowing when not to develop something. Keep Human Judgment in the Loop One of the clearest guardrails Alane provides is that judgment should not be handed entirely to AI. AI can process information, identify patterns, generate options, and perform repetitive tasks, but Alane draws a distinction between having data and exercising judgment. People can fall into the habit of asking AI to provide the answer instead of using it to support their own decision-making. That becomes particularly risky when the result is going directly to a customer or influencing an important business decision. Human review should remain at critical decision points. A person should determine whether the result is correct, whether it makes sense in context, and whether it represents the quality the organization expects. That does not mean humans are perfect. People made mistakes before generative AI existed, and human review never guaranteed flawless results. The point is that organizations already needed quality control. AI does not remove that responsibility. For developers, this resembles the testing and review processes that already exist around software. Automation can produce a result quickly, but speed does not prove correctness. Someone still needs to determine whether the output actually satisfies the requirement. Process Mapping Before AI Automation Knowing where humans belong in an AI workflow becomes easier when the organization understands the process being automated. Unfortunately, Alane frequently finds that teams cannot clearly explain their own processes. Different employees may perform the same job in completely different ways. Information moves through different applications, folders, and manual steps depending on who completes the task. Trying to automate that environment creates unnecessary complexity. Alane uses process mapping to make the workflow visible. One practical technique is asking someone to record a Loom video while completing the process. The recording creates a transcript and shows which systems the employee moves through along the way. AI can then help transform that information into a process map. Once the process is visible, the team can review it together. They can identify unnecessary steps, determine where AI can help, and decide where human review needs to remain. This is another place where smarter AI development begins before anyone starts writing code or configuring an agent. Understanding the process first makes it much easier to choose the right technology. Start Small with AI Automation Alane is also a strong advocate for starting small rather than attempting to automate an entire business process at once. New client onboarding provides a useful example. A complete onboarding process may involve creating billing records, scheduling meetings, building a presentation, creating shared folders, sending messages, and performing several other tasks. Trying to automate the entire workflow at once creates a large project with many failure points. Instead, Alane recommends identifying one time-consuming piece. Creating the onboarding deck might be an ideal starting point. The organization already has information from the sales call and an existing presentation template. AI can use the transcript and template to create a first draft of the onboarding deck. A human then reviews it. That final review matters because a transcript does not necessarily capture everything a person understood during the conversation. A customer may technically agree with something while their tone suggests it is not actually a priority. The person who participated in the conversation can recognize that nuance and adjust the final presentation. Once that small automation works reliably, the organization can move to another piece of the process. Alane describes this as breaking implementation into phases instead of attempting to automate everything at once. Smarter AI Development Is About Outcomes One of the most useful themes from the conversation is the idea of focusing on the job rather than the technology. Developers naturally enjoy technology, and AI provides an almost endless collection of new tools to explore. However, customers do not generally care whether a problem required an elaborate AI agent, a custom application, or a scheduled task. They care that the problem was solved. That changes how developers should evaluate AI opportunities. The goal should not be to create the most impressive technical implementation. It should be to find the simplest reliable approach that produces the required result. That may mean building less. It may mean purchasing software instead of developing it. It may mean using AI for one step instead of automating an entire workflow. It may also mean leaving a human in the process because human judgment provides more value than another layer of automation. Those decisions require skills that go beyond writing code, which is exactly why they matter for developers building a career beyond the code. Build Less and Learn Faster Smarter AI development requires a change in mindset. The question is no longer whether we can build something. AI has made the answer to that question increasingly likely to be yes. The more important questions are whether we should build it, whether somebody wants it, who will maintain it, and whether a simpler solution already exists. Those questions force developers to look beyond implementation and consider the business surrounding the technology. Start with the MVP. Talk to real customers. Map the process before automating it. Choose the simplest tool that can reliably complete the job. Keep humans involved where judgment and quality matter, and expand automation only after the smaller pieces work. AI gives developers an extraordinary ability to build faster. The advantage will come from knowing what is worth building in the first place. 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. Additional Resources Developer Tools That Transform: Habits for Smarter Development AI Governance Framework: Why Guardrails Help AI Move Faster AI Workflow Architecture: Building Smarter Systems Instead of Bigger Tech Stacks Building Better Developers Podcast Videos – With Bonus Content

Building an AI-ready organization requires more than giving employees access to ChatGPT, Claude, Copilot, or another AI platform. Without training, standards, and a clear understanding of where AI belongs, organizations can create more confusion and expense instead of improving productivity. The technology may be new, but many of the problems it exposes have been hiding inside businesses for years. In this episode of Develpreneur: Building Better Developers, Rob Broadhead and Michael Meloche talk with Alane Boyd, Co-CEO of Biggest Goal, about what businesses are learning as they move beyond experimenting with AI. Alane has built and scaled technology companies, including two SaaS platforms and a social media agency. Today, much of her work focuses on helping organizations implement AI, train their teams, and create scalable systems that make work easier rather than simply adding another technology to the stack. The conversation quickly reveals an important distinction. AI adoption is not really about purchasing AI tools. Building an AI-ready organization starts with understanding how work gets done and deciding where AI can genuinely improve that work. About Alane Boyd Alane Boyd is Co-CEO of Biggest Goal and a serial entrepreneur whose background spans technology, operations, sales, marketing, automation, and business growth. She has built SaaS businesses and describes herself as a two-time SaaS founder with successful exits. Biggest Goal's current work focuses on hands-on AI training and implementation for leaders and teams, including helping organizations move from basic AI experimentation toward repeatable systems and practical business workflows. Alane is also a published author, mentor, speaker, and podcast host. Her work increasingly focuses on practical AI fluency: helping businesses understand where AI belongs in their operations, how teams can use it consistently, and where human expertise should remain part of the process. Learn more about Alane and her work through Biggest Goal and connect with her on LinkedIn. Moving Beyond AI Experimentation For many people, the first experience with generative AI was simple experimentation. They opened a chat window, entered prompts, generated content, summarized documents, or tried whatever interesting use case appeared online. That experimentation helped people become comfortable with the technology, but organizations are now asking a more difficult question: How do we turn that experimentation into a repeatable business process? Alane sees this transition with both individuals and organizations. Solopreneurs may want to move beyond basic prompting and learn how tools such as Claude Cowork can become part of their workflow. Larger organizations face another challenge because they need multiple employees to use AI consistently. They also need policies that prevent AI adoption from becoming what Alane describes as the "wild, wild west." Many organizations already have employees using several different AI platforms. Those employees may be paying for separate subscriptions, developing their own prompting techniques, and solving similar problems without sharing what they have learned. Management eventually sees those subscriptions and begins asking what everyone is actually doing with them. That is when AI stops being an individual productivity experiment and becomes an organizational challenge. It is also where the work of becoming an AI-ready organization really begins. An AI-Ready Organization Needs Training Michael shared an example that will probably sound familiar to many developers. One organization provided employees with AI development tools and effectively told them to use the technology to meet an aggressive deadline. There was no meaningful training, shared handbook, or established standard for how the tools should be used. The AI helped the development team meet a deadline that likely would have been impossible otherwise. However, the lack of planning created another problem: consumption. Developers burned through available AI tokens quickly, forcing the organization to rethink how accounts and shared resources were allocated. Alane has seen similar situations. One organization decided to skip training and purchase Claude subscriptions for its employees instead. Within days, employees exhausted their available usage and the company had to address the consequences. The problem was not that the employees had access to AI. The problem was that nobody had taught them how to use it effectively. Alane compares the situation to introducing any other workplace technology without establishing expectations. Give an organization Slack or Microsoft Teams without communication standards, and employees can quickly become overwhelmed with messages. AI follows the same pattern because employees naturally develop their own habits unless the organization provides guidance. When Alane asks employees to share their screens and demonstrate how they use AI, she often discovers inefficient workflows that generate poor results while consuming unnecessary resources. Better tools do not automatically create better processes. Teams still need training. Start with AI Champions Organizations do not necessarily have to create an AI strategy from scratch. Alane recommends looking first at the people who are already experimenting with the technology. Those employees can become AI champions. Instead of limiting AI adoption to the technology department, companies can create a cross-functional group of employees who already understand some of the possibilities. Representatives from sales, marketing, operations, development, and other departments can identify useful applications within their own areas while sharing what works across the organization. This approach also helps companies address different comfort levels. Some employees naturally experiment with new technology and learn by trial and error. Others prefer structured instruction before changing how they work. Neither group represents an entire organization, so an implementation strategy needs to account for both. Cross-department AI champions can help bridge that gap. They can demonstrate practical use cases, answer questions, and provide examples that are relevant to the work people actually perform. More importantly, they help an AI-ready organization develop shared practices instead of allowing every department to create its own isolated approach. Not Every Task Needs AI Another mistake is assuming that once an organization has AI, every task should involve it. Alane encourages companies to think carefully about where AI creates meaningful value. Different teams also have different needs. Software developers may legitimately consume far more AI resources than employees performing other tasks because AI can dramatically accelerate certain areas of development. A content team, however, may not need the same allocation. In some cases, writing an email manually may actually be faster than prompting AI, reviewing its response, correcting it, and rewriting the result. The goal is not maximum AI usage. The goal is better work. Organizations should ask where AI can handle repetitive processing, organize information, analyze transcripts, move data, or perform other behind-the-scenes tasks. They should also identify where human expertise still produces a better result. That distinction matters because poorly implemented AI can actually increase costs. A company may purchase more subscriptions and consume more computing resources without gaining meaningful productivity. Training helps employees recognize which jobs are appropriate for AI and which jobs are better handled directly by a person. AI Often Exposes Problems That Already Existed One of Alane's most important observations during the conversation is that many problems blamed on AI existed long before AI arrived. Companies frequently struggle with inconsistent processes, missing documentation, scattered files, and employees completing the same task in completely different ways. AI does not create those problems. It makes them much harder to ignore. Alane sometimes begins working with an organization only to discover that the company does not even have a consistent shared folder structure. Before building sophisticated AI agents or automations, the organization may need to solve much more basic operational problems. This creates an important lesson for developers and business leaders. Automation works best when the underlying process is understood. If nobody can explain how a process is supposed to work, automating it may simply make the confusion happen faster. In that sense, AI can act as a diagnostic tool. Attempting to implement it forces organizations to ask questions they should have asked already. Where does information live? Who owns a process? What is the standard procedure? Which version of a document is authoritative? Where should a human review occur? Those are not AI questions. They are business process questions, and answering them is an important part of creating an AI-ready organization. AI-Ready Organization Foundations Come First Some organizations simply are not ready for advanced AI implementation. Alane has encountered companies whose technology and processes were so outdated that Biggest Goal ultimately determined it was not the right partner for them yet. That does not mean those companies can never use AI. It means they have foundational work to complete first. An organization may need to establish shared storage, document its standard operating procedures, modernize parts of its technology stack, or determine how information moves between departments. Once those foundations exist, AI becomes much easier to introduce because there is a stable process to improve. This idea is especially important for developers. Technical teams are often asked to automate a process before anyone has clearly defined that process. The temptation is to start building immediately, but sometimes the correct first step is helping the business understand what it is actually trying to automate. AI Can Reveal the Value of Automation Alane shared an example from her own business that demonstrates what happens when a process is well suited for automation. Her company and business partner produce a podcast, and the production workflow previously required roughly 30 hours of human work each week. Much of that work involved moving information from one place to another. A transcript needed to become a description, content needed to move into a blog, and information had to travel through several steps before publication. These tasks were necessary, but they did not require 30 hours of human judgment. An AI agent workflow changed that equation. Removing repetitive data movement from a person's workload did not eliminate the need for people. It allowed people to spend their time on work where their judgment, creativity, and expertise mattered more. This is a much more useful way to think about AI adoption. Instead of asking, "How can we use AI?" organizations can ask, "Where are people spending time on work that does not require a person?" That question usually leads to better opportunities. Build the Organization Before Building the Automation For developers, the conversation with Alane highlights a familiar engineering principle: technology cannot compensate indefinitely for a broken process. AI may make development faster, accelerate research, automate repetitive tasks, and connect systems in ways that were difficult only a few years ago. However, those capabilities still depend on organizations knowing what they want to accomplish. Before implementing AI across a team, businesses should establish several basic foundations: Identify the processes employees are already following. Determine where information and authoritative data should live. Establish policies for approved AI tools and appropriate usage. Train employees instead of simply purchasing subscriptions. Create AI champions across multiple departments. Identify tasks where AI creates measurable value. Preserve human review where judgment and quality matter. These steps are not as exciting as building an AI agent, but they are essential to an AI-ready organization. Establishing them first makes agents and other automation far more useful when the organization is ready for them. AI Is a Business Process Conversation One of the biggest shifts happening with AI is that the conversation is moving beyond technology teams. Organizations are beginning to realize that AI adoption involves operations, leadership, training, culture, budgeting, and process design as much as software. Developers have an important role in that transition. Technical professionals understand what these tools can do, but the most valuable developers will also understand when those capabilities solve a real problem. That means asking questions before building, understanding the workflow surrounding the technology, and recognizing when an organization needs process improvement before automation. AI can make an efficient organization faster. It can also expose every inconsistency hiding underneath an inefficient one. The difference comes from what the organization does before it starts automating. Building an AI-Ready Organization Building an AI-ready organization does not begin with buying licenses. It begins with understanding how the organization works. Companies that skip that step may still get impressive short-term results, especially when motivated employees find creative ways to use AI. Over time, however, inconsistent processes, missing standards, uncontrolled costs, and fragmented workflows become increasingly difficult to manage. The better approach is to treat AI as another part of the organization's operating system. Train people, establish standards, identify useful processes, and give employees a way to share what they learn. Most importantly, fix the organizational problems that AI exposes instead of assuming another AI tool will solve them. For developers building a career beyond the code, that creates an opportunity. The future is not only about knowing how to use AI. It is about understanding the business well enough to know where AI actually belongs. Additional Resources Why AI Readiness Matters More Than AI Adoption AI Governance Framework: Why Guardrails Help AI Move Faster AI Governance Framework: Why Every Business Needs Guardrails Before AI Building Better Developers Podcast Videos – With Bonus Content

Success stories often sound much cleaner after the fact. Someone starts a company, grows it, sells it, and moves on to the next opportunity. What usually gets left out are the mistakes, difficult decisions, and moments when the business almost did not survive. In Part 2 of our conversation with Glenn Poulos, we get into that side of entrepreneurship. Glenn has started companies, sold companies, worked through an acquisition, nearly lost a business, rebuilt, sold again, and eventually became a buyer himself. That experience has given him a perspective you do not get from simply reading about entrepreneurship. Some of his most valuable lessons came from the deals and decisions that did not work as expected. About Glenn Poulos Glenn Poulos has spent more than four decades working in technical sales, entrepreneurship, and business leadership. After beginning his career in electronics, he entered technical sales in 1985 and founded his first technology distribution company in 1991. He later co-founded Gap Wireless, which grew into a major Canadian distributor serving the mobile broadband and wireless industries before being acquired in 2022. Today, Glenn is President of ProgUSA, a U.S.-based company serving power utilities and service organizations with electrical test and measurement equipment, technical support, service, and calibration. He is also the author of Never Sit in the Lobby, which shares practical lessons from his career in sales and business. Connect with Glenn on LinkedIn or learn more about his work through his website. A Successful Exit That Wasn't So Successful Glenn's first company was eventually approached by a well-known public company interested in acquiring the business. The offer looked impressive. Glenn and his partners would receive some cash, but most of the value came through millions of shares in the acquiring company. On paper, Glenn became a multimillionaire and one of the company's largest shareholders. There was one major problem. He could not immediately sell those shares. Within roughly 18 months, the acquiring company went bankrupt, and the shares became worthless. Glenn had sold a valuable business but received nowhere near the value he expected from the transaction. That experience taught him a lesson that would influence future deals: the number written at the top of an acquisition agreement does not necessarily equal the money you will eventually receive. It also taught him something about due diligence. The buyer had thoroughly investigated Glenn's company, but Glenn and his partners had not done the same investigation of the buyer. Because it was a public company and a recognizable name, they assumed that was enough. It wasn't. Due Diligence Goes Both Ways This is an important lesson for developers, consultants, and founders because we often focus on proving ourselves. A potential employer interviews us. A client evaluates our proposal. An investor examines the company. An acquiring company reviews the books. But evaluation should work in both directions. Glenn later realized that more investigation might have uncovered warning signs within the company acquiring his first business. That experience changed how he approached future transactions. The same principle applies outside acquisitions. Before accepting a major client, investor, partner, or even a new job, ask what you need to know about the other side of the relationship. A recognizable name does not eliminate risk. Growth Can Take You Away From What You Do Best Glenn's next company eventually became highly successful, but getting there was not a straight line. By 2019, the business was in serious trouble. Part of the problem was expansion. The company knew how to buy technology from manufacturers and sell it to customers. Because they were successful at that, it became easy to assume they could move into adjacent businesses. Why not install the technology too? Why not expand into another product category? Those ideas sound reasonable until the new business requires completely different expertise, employees, equipment, inventory, and risk management. Glenn calls what happened the "reverse Midas touch." Instead of everything turning to gold, new ventures began creating problems. The company eventually found itself about $1.3 million in the hole. The solution required difficult decisions. Glenn and his partner dramatically reduced the size of the organization, transferred a problematic service division, exited another difficult product area, and refocused on the company's core strengths. Those decisions helped turn the business around and ultimately positioned it for a successful sale. There is a valuable lesson here for technical professionals. Being good at one thing does not automatically mean you will be good at the thing next to it. Expansion needs more than opportunity. It needs the right expertise and someone capable of owning it. Be Careful With the Money Attached to Growth Another theme in our conversation was financing. Glenn is careful to point out that his experience comes primarily from running traditional operating businesses rather than venture-backed startups. Within that context, he prefers avoiding outside money for as long as practical. Debt has a cost. Equity has a cost. Partners have a cost. Those costs are not always measured only in interest rates or percentages. Taking an investor may mean giving someone influence over how the company operates. Bringing in a partner means sharing the value you eventually create. An earn-out may make an acquisition price look larger, but some of that money depends on hitting future targets after control of the company has changed. Glenn's experience has made him particularly cautious about large earn-outs and long post-acquisition commitments. Choose Partners for More Than Proximity Glenn also offered a warning about business partnerships through something he jokingly calls "vice president in the room syndrome." A few friends start talking about creating a company. Someone becomes CEO. Someone else becomes VP of Technology. Another person gets sales. Someone else happens to be there, so they get a title too. The company has barely started, but ownership and leadership positions have already been distributed based on who was in the room rather than what the business actually needs. That can become extremely expensive later. Glenn has successfully worked with partners, so his point is not that partnerships cannot work. It is that ownership decisions made casually at the beginning become very difficult to undo once the company has real value. Experience Is Often Learning What Not to Do One thing I appreciated about Glenn's story is that the lessons do not come from pretending every decision was correct. Some worked. Some didn't. His first company taught him how dangerous an acquisition can become when you fail to investigate the buyer. His second taught him how quickly expansion outside your core strengths can consume a profitable business. Selling to private equity taught him about earn-outs and what happens when you are no longer the person controlling a company you built. Those lessons eventually influenced how he approached buying and running his current business. For developers building a career beyond the code, that may be the most useful takeaway. Entrepreneurship is not simply about having a good idea or building a product. It requires understanding money, people, partnerships, risk, operations, and sometimes knowing when to stop doing something that is not working. The technical problem may actually be the easy part. 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. Additional Resources Business Agreements – Lessons Learned Learning From Your First Business Strategies for a Successful Business Launch Building Better Developers Podcast Videos – With Bonus Content

Building a career beyond the code does not necessarily mean leaving technology behind. Sometimes it means learning how to take technical knowledge and apply it differently. That might involve sales, leadership, consulting, or eventually building a company of your own. In this episode of Develpreneur, we talk with Glenn Poulos, an entrepreneur who started his career as an electronic technician before moving into technical sales. That transition eventually led him to start, grow, and sell multiple technology distribution companies. More recently, Glenn took a different approach: instead of starting another company from scratch, he bought an existing business. His experience provides an interesting lesson for developers and technical professionals considering entrepreneurship. The biggest opportunity may not always be building something new. Sometimes it is finding something that already works and figuring out how to make it better. About Glenn Poulos Glenn Poulos has spent more than four decades working in technical sales, entrepreneurship, and business leadership. After beginning his career in electronics, he entered technical sales in 1985 and founded his first technology distribution company in 1991. He later co-founded Gap Wireless, which grew into a major Canadian distributor serving the mobile broadband and wireless industries before being acquired in 2022. Today, Glenn is President of ProgUSA, a U.S.-based company serving power utilities and service organizations with electrical test and measurement equipment, technical support, service, and calibration. He is also the author of Never Sit in the Lobby, which shares practical lessons from his career in sales and business. Connect with Glenn on LinkedIn or learn more about his work through his website. From Technical Skills to Sales and Entrepreneurship Glenn began his career working with electronics, including repairing equipment used at Canadian weather stations. He soon discovered that the role was not what he wanted long-term, and his boss suggested that he consider sales. That advice changed the direction of his career. Glenn moved into technical sales in 1985, selling test and measurement equipment used by engineers. Because he understood the technology, he could speak the customer's language while learning the business side of the industry. He eventually realized something important: sales could dramatically expand his earning potential without requiring him to abandon his technical background. A few years later, he saw another opportunity. Instead of simply selling products for someone else's company, he could build the company employing the salespeople. In 1991, Glenn left his job and launched his first business focused on technology for the growing mobile wireless market. He would spend the next several decades building businesses around a similar model: find useful technology, understand the market, and connect those products with customers who need them. For developers, there is an important lesson here. Your technical skills can be the foundation of your career without defining its boundaries. Starting a Business Versus Buying One After starting companies from scratch more than once, Glenn eventually decided he would take a different approach. He bought an existing business. The experience showed him how much infrastructure entrepreneurs have to recreate every time they start from zero. A new company needs banking relationships, insurance, employees, vendors, customers, processes, credit, and a reputation. An established company may already have many of those pieces. That does not mean buying a company eliminates the work. Glenn changed much of the business he acquired, including its branding, systems, vendors, staffing, and processes. He also had to manage something founders do not encounter in quite the same way: an existing culture and employees dealing with significant change. Still, he started with an engine that was already running. Glenn believes there is an overlooked opportunity in smaller established businesses whose owners are ready to retire but do not have someone prepared to take over. In some cases, a new entrepreneur may be able to structure a transition in which the existing business helps finance the owner's eventual exit. Instead of spending years creating everything from scratch, the entrepreneur can focus on improving what already exists. AI Changes What a Small Business Can Do The other major change Glenn has experienced is AI. When he acquired his current company in 2024, AI was already becoming useful. In only a few years, however, it has changed how he operates the business. Glenn described using AI across financial reporting, accounts receivable, marketing, planning, sales training, and internal tools. Rather than hiring full-time employees for every specialized role, he can combine fractional experts with AI-supported processes. The important distinction is that AI is not running the company. People still make decisions, review information, manage relationships, and provide judgment. AI increases what those people can accomplish. Glenn gave a simple example with trade shows. Coordinating a trade show means tracking booth reservations, travel, hotels, equipment, marketing materials, deadlines, and dozens of other details. Instead of buying another software package, Glenn had AI help him build a tool specifically around his company's process. He has created enough internal tools that he eventually needed another tool simply to keep track of them. That is both funny and revealing. AI removes many of the old barriers to creating software, automating processes, and increasing productivity. The new challenge is deciding which problems are worth solving and making sure we finish what we start. The Opportunity Beyond the Technical Work One thing that stood out in our conversation with Glenn is that none of these transitions required abandoning technology. His technical background remained useful throughout his career. What changed was how he applied it. He learned sales. He learned how businesses operate. He learned how to build companies, manage people, work with vendors, and eventually evaluate an existing company as an acquisition. Now he is adding AI to that toolkit. That is exactly what building a career beyond the code can look like. The technical skills get you started, but the opportunities become much larger when you combine them with communication, business knowledge, sales, leadership, and the ability to recognize a problem worth solving. You do not necessarily need to build the next startup from nothing. There may already be a good business, product, or process waiting for someone with the right technical experience to see what it could become. 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. Additional Resources Building Trust in the AI Era | Amit Zandberg Can AI Help You Trust Online Course Reviews? | Amit Zandberg The Entrepreneurial Mindset: Moving From Side Hustle to Company Building Better Developers Podcast Videos – With Bonus Content

Developer work-life balance is often treated as a productivity problem. We look for better schedules, better tools, fewer meetings, or another technique for getting more done. However, our second conversation with Gaylen A. Wilson raises a different question: what happens when the problem is not how much work you have, but your inability to stop working the problem? Developers spend their careers learning how to stay with difficult problems. We debug issues that make no sense, work through production failures, deal with changing requirements, and keep digging until we find an answer. That persistence can make us successful. It can also make it difficult to recognize when we have crossed from productive problem-solving into stress, frustration, and burnout. The challenge becomes even greater when we carry that state away from the computer. Work may have ended, but mentally, we are still debugging. Learning to recognize that transition is an important part of developer work-life balance. About Gaylen A. Wilson Gaylen A. Wilson is an author, relationship coach, technology veteran, entrepreneur, farmer, former stockbroker, and heart-transplant recipient whose career has required him to reinvent himself repeatedly. Together with his wife, Heather, Gaylen developed the Monument Method, an approach they use to help couples interrupt destructive conflict patterns and strengthen their connection. Learn more about Gaylen A. Wilson through his website http://www.monumentmethodinstitute.com/. Developer Work-Life Balance Starts with Recognizing Your State Michael brought the conversation back to developers by pointing out something familiar to many people in technology. We can become so accustomed to constantly working the problem that we stop recognizing what it is doing to us. There is always another release, bug, customer issue, deadline, or technology to learn. We keep pushing because that is what has worked throughout our careers. Eventually, though, we can reach a point where we are no longer solving the problem effectively. We are simply reacting to it. Gaylen connected that experience to what he describes as fight-or-flight thinking. He had experienced an extreme version during his health problems. As a self-described Type A personality, one of the hardest things for him was accepting that he still wanted to keep going while his body was telling him that he could not. He credited his relationship with his wife, Heather, as an important source of support during that period. You do not need to reach that extreme before recognizing the same pattern in your career. Sometimes the warning sign is much simpler. You close the laptop, but you are still thinking about the defect. You sit down for dinner and mentally replay a conversation from work. You are supposed to be relaxing, but you feel guilty because you are not doing something productive. The workday ended. Your brain never got the message. The Car That Would Not Start Gaylen shared a story that provides a surprisingly good example of what this looks like. He had spent two months working on one of his cars and finally got it running. After driving it around the block, he and Heather prepared to leave and visit friends. He pushed the button to start the car, and nothing happened. For someone who likes solving problems, that was frustrating enough. Gaylen also felt that he was disappointing Heather because they were supposed to leave. He grabbed a multimeter, found the battery was low, and started looking for jumper cables. He could not find them. They were actually nearby, underneath a blanket, but Gaylen had become so frustrated that he could not slow down enough to move the blanket and see them. By his description, he had entered full fight-or-flight mode. He found another old set of jumper cables, discovered they were badly corroded, and became even more frustrated. Developers have our own versions of that blanket. You have probably stared at a defect for an hour only to discover the problem was obvious once you stepped away. Maybe you rewrote code that did not need rewriting. Maybe you blamed a dependency, the network, the database, or someone else's code before discovering a simple configuration problem. The longer we fight the problem, the narrower our thinking can become. At some point, persistence stops being an advantage. Developer Work-Life Balance Requires an Interrupt The most interesting part of Gaylen's story came next. Heather was sitting in the car and did not realize how frustrated he had become. Gaylen finally walked over to her and said, "I need a monument." That phrase comes from the relationship framework Gaylen and Heather developed, which they call the Monument Method. They use "monument" as an agreed-upon signal to interrupt an escalating conflict or emotional reaction and reconnect before continuing. Gaylen said that when Heather turned toward him, his anger quickly disappeared. He then gave her permission to use the same technique whenever she saw him beginning to spiral in the future. Whether or not you use Gaylen's specific method, there is a useful concept here for developers: we need an interrupt. In programming, an infinite loop does not usually fix itself because we let it run longer. Sometimes something external has to break the cycle. Our work habits can operate the same way. Build an Interrupt into Your System Developers love systems, so it can help to think about disconnecting from work as something we deliberately design rather than something we hope happens automatically. Your interrupt does not have to be Gaylen's "monument." It can be something simple that signals the transition from work mode to the rest of your life. Take a walk after shutting down your computer. Write down the next step before leaving a difficult problem. Create a short end-of-day routine that closes out unfinished work. Exercise before transitioning into your evening. Set a fixed point when you stop checking Slack, Teams, or email. Talk with someone rather than continuing to replay the problem internally. Step away from a frustrating problem before making another major change. The specific ritual matters less than recognizing why you need it. If you regularly leave work in a frustrated state, simply closing the laptop does not necessarily reset that state. You may physically leave the work while mentally carrying it into everything you do afterward. That affects more than your evening. It can affect how you communicate with the people around you and how prepared you are to return to work the next day. You Cannot Debug Everything by Working Harder Michael asked Gaylen an important follow-up question: what if you do not have someone there to help you reset? Gaylen described an experience while Heather was away visiting family. He had become frustrated while working with ChatGPT and realized that Heather would normally recognize when he was becoming agitated. Without her there, he experimented with mentally recreating the calming experience they had practiced together. He said that simply closing his eyes and imagining the familiar interaction helped him calm down. Gaylen attributed that response to repeatedly practicing their method until it had become a familiar signal for him to reset. The larger lesson is not that developers need to reproduce Gaylen's exact technique. It is that we can become better at recognizing when our current state is no longer helping us solve the problem. When you have been staring at the same code for three hours, are you still debugging effectively? When you are angry at a tool because it is not behaving the way you expect, are you still evaluating the problem objectively? When you are rewriting something for the third time late at night, are you improving it, or are you just unwilling to stop? Developers spend enormous amounts of time learning how to diagnose systems. We should learn to diagnose ourselves, too. Find Your North Star Rob connected Gaylen's Monument Method to something we regularly discuss in software projects and businesses: having a "why." Projects need a reason for existing. Without that reason, teams can spend enormous amounts of energy building things that do not actually move them toward their goal. A clear purpose becomes a North Star. When the project begins drifting, the team can return to the original question: what are we actually trying to accomplish? Developers can apply that idea to our careers. Why are you working so hard? Why are you pursuing the promotion? Why are you building the business? Why are you learning another technology? Why are you putting in the extra hours? There may be excellent answers to all of those questions. The danger comes when the work becomes its own answer. Developer Work-Life Balance Requires Boundaries There is a strange contradiction in successful technology careers. We work hard because we want to build a better life, but the habits that help us succeed can gradually consume the life we were trying to build. Gaylen argued that professional success, money, and recognition lose much of their meaning if they come at the expense of the important relationships around us. Rob connected that back to the larger theme of Career Beyond the Code: career success needs a reason behind it. Simply pursuing more work, more money, or more achievement does not provide a natural stopping point. That is why developer work-life balance cannot be solved entirely with productivity hacks. Sometimes you need to recognize that enough is enough. The defect can wait until tomorrow. The email does not need an answer tonight. You do not have to understand every new AI tool this weekend. The side project does not have to become another full-time job. The people around you should not always receive whatever energy remains after work takes the best of you. Those are not failures of ambition. They are boundaries that can make a long career possible. Quality Includes the Life Around the Product At EnvisionQA, we talk about finding problems before customers do. That mindset usually applies to software quality, requirements, integrations, processes, and the technology supporting a business. However, quality is also about sustainability. A development process that only succeeds because someone works eighty hours is not a healthy process. A release that depends on heroics every time has a system problem. A developer who cannot disconnect from work indefinitely will eventually pay for that somewhere. Building better developers should mean more than producing developers who can write better code. It should mean developing people who can solve difficult problems without allowing every difficult problem to consume them. That is part of building a career beyond the code. Developer Work-Life Balance Means Knowing When to Stop One of Gaylen's final reflections brought both parts of our conversation together. Looking back over a life filled with career changes, financial setbacks, addiction, serious illness, and a heart transplant, he asked himself why those experiences had not left him bitter. His answer was gratitude. Gaylen said he realized that he had generally been more grateful for what he still had than bitter about what he had lost. Today, he practices that gratitude more intentionally. For developers, perhaps there is another lesson in that perspective. We are trained to see what is broken. It is literally part of the job. We find the missing requirement, failed test, security vulnerability, performance bottleneck, integration problem, or defect that everyone else missed. That skill makes us valuable, but we cannot spend our entire lives looking only for the next thing that needs fixing. Sometimes building a career beyond the code means recognizing what is already working, protecting the things that matter, and knowing when to walk away from the keyboard. The problem will still be there tomorrow. You will probably solve it better after the reset. About Gaylen A. Wilson Gaylen A. Wilson is an author, relationship coach, technology veteran, entrepreneur, former farmer and stockbroker, and heart-transplant recipient. His professional life has included multiple reinventions, from agriculture and finance to PeopleSoft consulting, computer repair, nationwide technical field work, writing, and relationship coaching. Together with his wife, Heather, Gaylen developed the Monument Method, a relationship framework centered on interrupting destructive conflict patterns and protecting the connection between partners. Their work grew from their own relationship, Gaylen's health journey, his involvement in large online communities discussing intimacy and relationship challenges, and their subsequent relationship-coaching education. Gaylen described his broader philosophy during our conversation as intentionally protecting what matters most rather than allowing the pressures of work and the outside world to damage it. You can learn more about Gaylen, his books, and his work through his PodMatch profile and the Monument Method Institute. 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. Additional Resources Constructive Communication in Software Development That Drives Results Facilitative Leadership: Why Modern Teams Need Guides Instead of Heroes Software Communication Gaps: The Hidden Foundation Problem Slowing Your Team Building Better Developers Podcast Videos – With Bonus Content