DEV Community: Bradley Matera

AI Didn't Replace Junior Developers. It Replaced Safe Places To Be One.

Bradley Matera — Sat, 13 Jun 2026 05:59:58 +0000

Every few weeks, another article lands in my inbox with a headline like "AI is Eliminating Junior Developer Roles" or "Why Entry-Level Engineers Can't Find Jobs Anymore." The narrative is consistent: AI tools are so good now that companies don't need to hire inexperienced developers. They can just have their senior engineers prompt a model and get production-ready code in minutes.

I've sent over 300 job applications in the past two years. I've earned my AWS Certified Solutions Architect Associate and AI Practitioner certifications. I completed an AWS Cloud Support Associate internship. I've built projects, contributed to open source, and use AI tools daily. I'm 33 years old, a combat medic veteran from the 82nd Airborne Division, with a degree in Web Development from Full Sail University. And I'm still struggling to find a junior developer position.

I don't know if entering software development was harder before. I wasn't there. What I do know is what it looks like trying to enter right now, and something about this narrative that AI is simply replacing junior developers never sat right with me.

I'm not anti-AI. I use GitHub Copilot, Claude, and ChatGPT every single day. These tools have made me more productive and helped me learn faster than I ever could have otherwise. But looking at job postings and talking with other developers, it feels like AI has fundamentally changed what companies expect from entry-level hires, and I'm not sure where that leaves people like me who are still trying to break into the industry.

The problem isn't that AI is replacing junior developers. The problem is that AI replaced much of the low-risk work companies historically used to train junior developers. From where I sit trying to break into the industry, this shift has created a Catch-22: you need experience to get a job, but the traditional pathways to gain that experience are disappearing.

How Juniors (Used to) Learn Their Craft

When I read about how junior developers learned their craft in the past, it sounds almost like a different industry. From what I can gather, entry-level developers used to spend significant time on tasks that now seem almost quaint in our AI-accelerated world:

They'd spend hours fixing typos in documentation. They'd update README files when APIs changed. They'd write simple CRUD (Create, Read, Update, Delete) pages for internal tools that nobody outside the company would ever see. They'd handle straightforward bug fixes—things like correcting a misspelled variable name that was causing a form to fail validation.

These tasks weren't glamorous, but they served a crucial purpose. They provided a safe environment for learning. When you made a mistake updating that documentation, the worst that happened was someone got confused about an API parameter. When you introduced a bug in that internal tool, it might inconvenience a few colleagues but wouldn't bring down customer-facing systems.

Coming from the military, construction, and security work, this approach makes perfect sense to me. In the Army, you don't drop a new private into combat on day one. You start them with basic training, then gradually increase responsibility as they prove themselves. In construction, apprentices spend months learning to use tools correctly before they're trusted with more complex tasks.

But looking at today's job market, it feels like the software industry has skipped this apprenticeship phase. I've seen job postings for "junior" positions that require:

2-3 years of experience with specific frameworks
Familiarity with cloud platforms and DevOps practices
Ability to work independently with minimal supervision
Experience with complex system design

This creates a Catch-22 that I experience every day: you can't get experience without a job, but you can't get a job without experience. AI hasn't eliminated the need for human developers—it's just shifted the baseline expectations upward.

I've built several projects, contributed to open source repositories, and earned AWS certifications. I use AI tools constantly in my learning process. But when I look at what companies are asking for in entry-level positions, I can't help but wonder where the modern equivalent of apprenticeship comes from.

The learning that used to happen gradually and naturally on the job now seems to be expected to happen before you're even hired. This isn't just my perception—talking with other career changers, the story is remarkably consistent. We're all trying to break into an industry that seems to have eliminated many of its traditional entry points.

Why Companies (Used to) Hire Juniors

Looking at job postings and talking with developers who entered the industry a few years ago, it seems like companies used to think differently about hiring juniors. From where I sit trying to break in, their reasoning makes sense:

Companies invested in junior developers because they needed talent pipelines. Tech moves fast, and organizations that couldn't cultivate their own talent often found themselves unable to scale or adapt. Senior engineers don't grow on trees—you have to grow them from seedlings.

There was also the matter of institutional knowledge. The person who understood why a particular workaround existed in a legacy codebase wasn't going to be a recent computer science graduate. It was going to be someone who'd been with the company for years, who'd learned the hard lessons that never made it into documentation.

Succession planning mattered too. When your lead architect decided to start their own company or move to finance, you needed someone ready to step into their role. That transition was smoother when the company had invested years in developing that person's skills.

Finally, there was simply the economics of supply and demand. Companies that waited for "perfect" candidates often found themselves with unfilled positions and missed opportunities. Better to hire someone promising and train them than to lose a business advantage because you couldn't find exactly the right person.

But from my perspective, this model seems to be changing. I've sent applications to hundreds of companies, and the feedback I consistently receive is that I'm "overqualified" for junior positions despite having limited professional experience. When I ask for clarification, the response often comes down to needing someone who can be immediately productive.

This puzzles me because I use AI tools constantly and can produce code much faster than I could without them. But it seems like companies now expect entry-level hires to be immediately productive, skipping the gradual learning curve that used to be normal. The investment in junior developers that made sense from a long-term business perspective appears to be viewed as a luxury that many companies can no longer afford.

What Changed Everything

Looking at the job market from my perspective as someone trying to break in, the shift didn't happen overnight, and AI wasn't the only factor. The post-pandemic economic corrections created a new reality for many companies. Higher interest rates made expansion more expensive. Layoffs became a regular occurrence, even at profitable tech companies. Suddenly, the long-term investment in junior developers looked like a luxury few could afford.

But AI productivity gains accelerated this trend in a specific way. When I talk with senior developers who use AI tools like Claude and Copilot, they tell me they can generate a basic CRUD application in minutes. From where I sit, this raises an obvious question: why spend weeks training someone to build the same thing manually when AI can do it faster?

When AI can produce accurate documentation based on code changes, why pay a junior to maintain README files? The pressure to do more with fewer people became intense. Companies that had survived the pandemic by cutting costs weren't eager to add headcount, even entry-level positions. If AI could handle the work juniors once did, the math seemed simple: fewer people, same output.

This created a feedback loop that I experience every day. As fewer junior positions open, competition for those roles intensifies. Companies can afford to be more selective, demanding more experience and skills from entry-level candidates. This makes it harder for true beginners like me to break in, which I can only assume reduces the pool of people who might eventually become senior developers.

I've been tracking job postings for the past two years, and the change is undeniable. Positions that used to require "0-2 years of experience" now routinely ask for "2-3 years of experience with specific frameworks." Requirements that used to be nice-to-haves—like cloud certifications, DevOps experience, and full-stack capabilities—are now table stakes for entry-level roles.

The economic pressures that drove these changes were real and significant. The tech sector lost hundreds of thousands of jobs in 2022 and 2023, with major companies each laying off tens of thousands of employees. In this environment, any position that could be questioned became a target for elimination or restructuring.

From my vantage point, the pandemic also accelerated trends that were already underway. Remote work became the norm, which changed how companies thought about hiring. If you could hire anyone anywhere, why limit yourself to local candidates who might need training? Why not hire someone with more experience, even if it cost a bit more?

Venture capital funding, which had been flowing freely into startups, dried up significantly. Startups that had been hiring aggressively suddenly needed to prove their business models and reduce burn rates. Junior positions, which often had the highest training costs and longest ramp-up times, were among the first to be eliminated.

The combination of these factors created what feels like a perfect storm for entry-level developers like me. Companies that survived the immediate crisis looked around and realized they could operate with fewer people. AI tools made this reduction possible without sacrificing output. The result seems to be a fundamental shift in how the industry approaches talent development.

It's worth noting that this isn't entirely irrational from a business perspective. Companies that can extract more productivity from their existing staff do have a competitive advantage. Those that can reduce their reliance on expensive senior engineers by using AI assistance can operate more efficiently.

But from where I sit trying to break into the industry, the long-term consequences of this rational short-term decision are concerning. When we eliminate the pathways for people to gain experience, we're not just affecting individual careers—we're affecting the entire industry's ability to grow and adapt.

The Work AI Actually Replaced

It's important to be specific about what AI automated away, because from my perspective trying to enter the field, this represents the loss of crucial learning opportunities:

Boilerplate code generation became trivial with AI assistance. Need a basic React component with state management? AI can generate that in seconds. When I first started learning React, building these components from scratch taught me fundamental concepts about state management, component lifecycle, and data flow. Now that same learning experience can be generated instantly, but I wonder if newcomers are missing out on understanding why certain patterns exist.

Simple bug fixes—those misspelled variables, off-by-one errors, incorrect import statements—became almost instant with AI-powered debugging. As someone still learning to debug effectively, I can see how valuable it would have been to spend time tracking down these issues manually. Each bug taught me something about how the system worked, how errors propagated, and how to think systematically about problems.

Repetitive implementation work disappeared too. Need to add a new field to a form? Connect an API endpoint to a frontend component? Implement standard authentication flows? These tasks that once provided valuable learning experiences are now routine AI-assisted work. But these weren't just busywork—they were how junior developers learned the nuts and bolts of how applications fit together.

Documentation generation improved dramatically. Instead of manually writing and updating documentation, AI can generate accurate docs from code comments and examples. This reduced the need for juniors to maintain documentation as a learning exercise. But writing documentation taught developers how to explain complex technical concepts clearly—a skill that's crucial for collaboration.

Simple CRUD development became almost effortless. The kind of basic data entry applications that once provided entry-level developers with experience in full-stack development, database design, and user interface principles could now be generated largely by AI. These projects were how many developers learned to think about data flow, user experience, and system architecture.

From where I sit, this represents a fundamental shift in how people learn software development. The safe, low-stakes tasks that provided essential hands-on experience are increasingly being automated away, leaving fewer opportunities for newcomers to gain practical experience in a controlled environment.

The New Expectations Problem

Here's where things get complicated from my perspective. As AI took over the routine work that once served as junior developer training, companies' expectations didn't adjust accordingly. Instead of recognizing that entry-level candidates would need more support and training, many organizations seem to have concluded that AI has simply made junior developers more productive.

The result is what I think of as the "instant senior" phenomenon. Job postings for "junior" positions now routinely require:

2-3 years of experience with specific frameworks
Familiarity with cloud platforms and DevOps practices
Ability to work independently with minimal supervision
Experience with complex system design

This creates a Catch-22 that I face every day. You can't get experience without a job, but you can't get a job without experience. AI hasn't eliminated the need for human developers—it's just shifted the baseline expectations upward.

I've seen job postings for "junior" React developers that required more specific technical knowledge than many "senior" positions demanded just a few years ago. This isn't because the work became inherently more complex. It's because companies now expect entry-level hires to be immediately productive, skipping the gradual learning curve that used to be normal.

As someone who uses AI tools constantly in my learning process, I can see both sides of this issue. AI does make me more productive and helps me learn faster. But it also means that companies can reasonably expect more from entry-level candidates. The problem is that this creates a gap between what AI can help you produce and what you actually understand deeply.

I can generate a full-stack application with AI assistance, but do I truly understand how all the pieces fit together? Do I know how to debug issues when they arise? Can I make architectural decisions when requirements change? These are the kinds of skills that used to be developed gradually through hands-on experience with real systems, not through AI-assisted code generation.

The Career Changer Perspective

My path to software development wasn't typical, and I think that gives me a unique perspective on what's happening in the industry. I spent years in the Army as a combat medic with the 82nd Airborne Division, including a deployment to Afghanistan. Before that, I worked in construction, private security, warehouse jobs, and case management. I earned a B.S. in Web Development from Full Sail University while working full-time, completing the degree in 2021 after years of balancing work and study.

In the military, construction, and security work, apprenticeship models are still common and respected. You start with basic tasks under close supervision, gradually taking on more responsibility as you prove yourself. You learn by doing, making mistakes in low-stakes environments, and gradually building up to more complex responsibilities.

When I transitioned to tech, I expected something similar. I figured I'd start with simple tasks, learn the ropes, and work my way up. Instead, I found an industry that seems to have eliminated many of the entry points that existed for previous generations.

This isn't unique to career changers like me. Even traditional computer science graduates are finding fewer opportunities to learn their craft in real-world environments. The gap between academic knowledge and practical skills has always existed, but it's widened as companies have become less willing to invest in training.

In construction, you don't expect a new electrician to wire a building on day one. They spend months learning to use tools correctly, understanding electrical codes, and working under supervision before they're trusted with complex installations. In the military, junior enlisted personnel spend months in basic training and job-specific schools before taking on significant responsibilities. But in software, the expectation seems to be that you should be able to contribute meaningfully from your first day, regardless of your background.

This disconnect is particularly challenging for career changers like me who are coming from fields with different learning models. I'm used to the idea that expertise takes time to develop and that mistakes are part of the learning process. But the current job market seems to expect immediate productivity without the gradual learning curve that would make that possible.

Learning from Other Industries

Having worked in multiple fields before entering tech, I've observed how different industries approach training and skill development. In the Army, we had a structured progression system where competence was demonstrated through practical application, not just theoretical knowledge. You didn't become a squad leader by passing a test—you became one by successfully leading a team in training exercises and real-world missions.

In construction, apprenticeship programs are formalized and regulated. An apprentice electrician works under a journeyman for years, gradually taking on more complex tasks as they prove their competence. They start with basic wiring and simple installations, progressing to complex commercial systems only after demonstrating mastery of fundamentals.

In security work, new officers go through extensive training that includes both classroom instruction and supervised field work. They're never left alone with critical responsibilities until they've proven they can handle them safely and effectively.

These industries recognize that expertise requires time, practice, and mentorship. They've developed systems that protect both the novice learner and the organization they're serving. The software industry seems to be moving away from this approach, and I'm not sure that's sustainable.

The Military Comparison

My military experience gives me a particular perspective on this issue. In the Army, we understood that investing in junior personnel was essential for mission success. A platoon sergeant who took time to develop junior soldiers was seen as valuable, not inefficient. The long-term benefits of having capable subordinates outweighed the short-term costs of training them.

We also had systems in place to ensure continuity of knowledge. When experienced soldiers rotated out, they didn't take all their institutional knowledge with them. We documented procedures, mentored newcomers, and created redundancy in critical skills.

In contrast, the software industry seems to be moving toward a model where knowledge is concentrated in fewer individuals. When experienced developers leave, they often take significant institutional knowledge with them, leaving gaps that are difficult to fill.

The Construction Parallel

In construction, there's a clear progression from apprentice to journeyman to master. Each level has specific requirements and expectations. An apprentice knows they're learning and expects to make mistakes under supervision. A journeyman can work independently but still consults with masters on complex problems. A master has the experience to make judgment calls and train others.

This progression makes sense because construction is inherently risky. A mistake in structural engineering can kill people. The industry has developed systems that minimize risk while maximizing learning opportunities.

Software development also has life-or-death stakes in some applications—medical devices, aviation systems, financial infrastructure. But the industry's approach to training doesn't always reflect this reality. Instead of creating safe learning environments, we seem to be pushing more responsibility onto less experienced developers while simultaneously reducing the support systems that would help them succeed.

Why This Matters Long Term

The implications extend far beyond individual career trajectories like mine. If fewer people can enter the field, where do future senior engineers come from? Who will design the next generation of systems? Who will lead teams and make architectural decisions?

The software industry has always been built on a pipeline model. Universities and coding bootcamps produce graduates. Companies hire and train them. Some become excellent engineers. Some become leaders. Some start their own companies. The cycle continues.

But what happens when that pipeline narrows? When the work that once provided essential training disappears? When the expectations for entry-level positions become so high that fewer people can meet them?

From where I sit trying to break into the industry, we're already seeing some effects. Salaries for experienced developers continue to rise, even as entry-level opportunities shrink. The gap between junior and senior compensation has widened. Companies are investing more in tools and processes to extract maximum productivity from their existing staff rather than growing their teams.

This creates a brittle system. When experienced developers leave—as they inevitably do—there may be fewer qualified people to replace them. The institutional knowledge that once accumulated over years of gradual learning might be concentrated in fewer and fewer individuals.

As someone who's been through multiple career transitions, this pattern looks familiar. I've seen what happens when industries become too focused on short-term efficiency and lose sight of long-term sustainability. The question is whether the software industry will recognize this pattern before it becomes a crisis.

The Experience Gap

One of the most concerning trends I've observed is the growing experience gap in the industry. When I talk to senior developers at conferences or in online communities, many express frustration with the lack of mid-level engineers. They're hiring either very junior developers who need extensive training or very senior developers who command high salaries.

This gap didn't appear overnight. It's the result of several years of reduced investment in junior developer training, combined with increased demands on those who do make it through the initial hurdles. The developers who would have spent the last few years developing into mid-level roles are missing, creating a gap between entry-level and senior positions.

I've experienced this gap firsthand in job interviews. I'm often told I'm "too experienced" for junior positions but "not experienced enough" for mid-level roles. This isn't just my perception—it's feedback I've received from dozens of interviews and conversations with hiring managers.

The Innovation Problem

There's another long-term concern that keeps me up at night: the potential impact on innovation. Historically, some of the most innovative solutions in software development have come from junior developers who didn't know what was "supposed to be impossible." They approached problems with fresh perspectives, unencumbered by assumptions about how things were "supposed to work."

When we eliminate the pathways for people to gain experience, we're not just affecting individual careers—we're potentially limiting the industry's ability to innovate. The next breakthrough in software development might come from someone who's just entering the field, but if we make it impossible for newcomers to gain the experience they need, we might miss that breakthrough entirely.

I've seen this principle in action in my previous careers. Some of the best security solutions I've encountered came from new officers who questioned established procedures. Some of the most efficient construction techniques I've learned came from apprentices who suggested improvements to traditional methods.

The software industry has benefited from this kind of fresh thinking throughout its history. From the early days of personal computing to the rise of the web to the mobile revolution, many breakthroughs came from people who were relatively new to the field. If we make it harder for newcomers to gain experience, we might be limiting our own future potential.

The Diversity Concern

This shift also has implications for diversity in the industry. Career changers like me, people from non-traditional backgrounds, and those who didn't follow the conventional path through computer science education are already underrepresented in tech. When we eliminate many of the traditional entry points, we're likely to reduce diversity even further.

I've noticed this in my own job search. Many of the positions I've applied for seem to assume a particular career trajectory: computer science degree, internship at a tech company, progression through increasingly senior roles. This path excludes many talented people who might contribute significantly to the industry but didn't start their careers in tech.

The lack of diverse perspectives in software development has real consequences. Products are built by people with similar backgrounds, leading to blind spots and missed opportunities. When we make it harder for people from different backgrounds to enter the field, we're not just limiting their opportunities—we're limiting the industry's potential.

Addressing Counterarguments

It's important to acknowledge that this analysis isn't universally accepted, and I've encountered compelling counterarguments in my discussions with other developers and hiring managers.

Some argue that AI creates new opportunities rather than just eliminating old ones. Perhaps we're seeing a shift toward more creative, strategic, and complex work. Instead of spending time on routine implementation, developers can focus on architecture, user experience, and business logic.

There's truth to this. AI tools do enable developers to tackle more interesting problems earlier in their careers. A junior developer today might work on machine learning integrations or complex data pipelines that would have been senior-only work just a few years ago. I've seen this in my own learning—AI has helped me explore advanced topics that would have been out of reach without assistance.

Others point out that juniors have more tools than ever before. Documentation is better, learning resources are abundant, and AI assistance can help bridge knowledge gaps quickly. Why shouldn't companies expect more from entry-level candidates when they have so many resources available?

This is also valid. The barrier to acquiring technical knowledge has never been lower. A motivated beginner can learn more in their first year than previous generations could learn in several years of formal education. I've certainly benefited from this—my AWS certifications and project work were made possible by the wealth of resources available today.

Finally, some argue that previous generations faced different barriers. The dot-com bust, the 2008 financial crisis, and other economic disruptions all affected entry-level opportunities. What makes the current situation unique?

The difference, from where I sit, may be in the nature of the change. Previous disruptions were cyclical—bad times followed by recovery periods where traditional hiring practices returned. The AI-driven shift might be structural, fundamentally altering how the industry develops talent. This isn't just a temporary market correction—it's a fundamental change in what companies expect from new hires and how they're willing to invest in their development.

I've also noticed something else in my conversations with developers who entered the industry before the AI boom. They often talk about learning on the job in ways that seem increasingly rare. The safe, low-stakes tasks that provided essential hands-on experience are disappearing, and I'm not sure what's replacing them as effective learning mechanisms.

The "Just Learn Faster" Argument

One argument I hear frequently is that the solution is simply to learn faster. With all the resources available today, the thinking goes, there's no excuse for not being able to acquire the skills needed for a junior position in a matter of months rather than years.

This argument misses a crucial point about how expertise actually develops. Yes, I can use AI tools to generate code for a web application in hours rather than weeks. But understanding why that code works, how to debug it when it fails, and how to modify it for different requirements still takes time and experience.

I've experienced this firsthand. I can generate a React component with AI assistance, but when it doesn't behave as expected, I still need to understand the underlying principles to debug it effectively. I can create a database schema with AI help, but designing for performance, scalability, and security requires experience that can't be shortcut.

The "just learn faster" argument also assumes that all learning happens in isolation. In reality, much of what makes someone effective as a developer comes from working with others, understanding organizational dynamics, and developing soft skills that are difficult to acquire through self-study.

The "Everyone Started Somewhere" Perspective

Another counterargument I encounter is that everyone started somewhere, and previous generations of developers faced similar challenges. This is true to some extent, but there are important differences in the current landscape.

When I talk to senior developers who entered the field 10-15 years ago, they describe a different environment. Yes, they faced challenges, but there were more entry-level positions available, and companies were more willing to invest in training. The path from beginner to experienced developer was more clearly defined and supported.

The current situation is different because the nature of entry-level work itself has changed. It's not just that there are fewer positions—it's that the positions that do exist require more experience and skills than before. This creates a fundamentally different challenge for newcomers.

The "Bootcamp Graduates Are Fine" Observation

Some argue that coding bootcamp graduates are still finding jobs, so the problem isn't as severe as I'm suggesting. While it's true that some bootcamp graduates are successful, my observations suggest the picture is more complex.

Many of the bootcamp graduates I know who have found jobs had significant advantages: previous technical experience, strong networks, or the ability to dedicate full time to job searching. For career changers like me who are also supporting families, the path is much more challenging.

Additionally, the jobs that bootcamp graduates are finding often come with their own challenges. Some are in roles that are being automated, others require extensive unpaid overtime to meet unrealistic expectations, and many don't provide the mentorship and growth opportunities that would help develop long-term careers.

Finding a Path Forward

So where does this leave someone like me who's trying to break into the industry? If I'm right that AI primarily eliminated the safe learning environments that once existed for junior developers, what can be done about it?

First, we need to recognize that the traditional apprenticeship model hasn't disappeared—it's just moved. Instead of learning on the job at established companies, many new developers are building skills through open source contributions, personal projects, and community involvement.

This isn't necessarily worse than the old model, but it is different. It requires more self-direction and may not provide the same breadth of experience. A developer who builds impressive projects in isolation might struggle with the collaborative, process-heavy environment of many companies. I've experienced this myself—my projects demonstrate technical ability, but they don't show how I'd work within an existing team or navigate complex organizational dynamics.

Second, companies need to reconsider their hiring practices. If AI has eliminated much of the routine work that once provided training, perhaps they need to be more intentional about creating learning opportunities. This might mean dedicated mentorship programs, rotational assignments, or explicit investment in junior developer growth.

I've been fortunate to find some companies that still recognize the value of investing in junior talent. My AWS Cloud Support Associate internship was structured around this principle, and it made a huge difference in my development. But these programs seem to be becoming rarer, which concerns me for the future of the industry.

Third, the industry needs to acknowledge that the skills required for effective AI collaboration are different from those required for traditional development. Prompt engineering, result verification, and understanding AI limitations are now essential skills. Companies that recognize and train for these skills may find they can be more effective with smaller teams.

From my perspective, this creates an opportunity. While many experienced developers are still learning how to work effectively with AI, newcomers like me are growing up with these tools. The question is whether companies will recognize this as a strength rather than a weakness.

Conclusion

The narrative that AI is eliminating junior developer roles misses an important nuance, at least from where I sit trying to break into the industry. AI didn't eliminate the need for human developers. It eliminated many of the safe, low-stakes opportunities that helped people learn to become effective developers.

This creates real challenges for career changers like me and newcomers to the field. It also creates long-term risks for the industry as a whole. If fewer people can enter the profession, the pipeline of future senior engineers, architects, and technical leaders will eventually shrink.

The solution isn't to resist AI or pretend it hasn't changed the landscape. As someone who uses AI tools constantly, I can attest to their value in learning and development. But we need to recognize how AI has changed things and adapt accordingly. This means creating new pathways for learning and growth, adjusting expectations to match reality, and investing in the human skills that AI can't replace.

The industry still needs new developers. The challenge is figuring out how people gain experience when many of the traditional entry-level tasks are increasingly automated. Those who solve this challenge—whether individuals, companies, or communities—will likely find themselves with significant advantages in the evolving tech landscape.

As I continue applying for positions and building my skills, I'm trying to focus on what makes me valuable beyond what AI can produce. I bring problem-solving skills honed in high-stress environments, the ability to learn quickly and adapt, and a perspective shaped by multiple career transitions. I use AI tools effectively, but I also understand their limitations.

AI didn't replace junior developers. It replaced safe places to be one. The question now is how we create new safe places in an AI-assisted world—places where people like me can learn, grow, and eventually contribute meaningfully to the industry's future.

I don't know if entering software development was harder before. I wasn't there. But I do know that the path forward requires creativity, adaptability, and a willingness to forge new pathways where traditional ones have disappeared. For people like me trying to break into the industry, that's both a challenge and an opportunity.

The Reality of AI-Enhanced Productivity

As someone who uses AI tools daily in my learning and development process, I can attest to their incredible productivity benefits. But I've also observed how these tools are changing expectations in ways that may not be sustainable.

The Productivity Paradox

When I first started learning to code, building a simple web application might take me days or even weeks. I'd spend hours debugging simple syntax errors, researching API documentation, and figuring out how to connect different components. It was frustrating, but it was also how I learned.

Now, with AI assistance, I can build the same application in hours. GitHub Copilot suggests code as I type. Claude helps me debug complex issues. ChatGPT explains concepts I don't understand. These tools have made me significantly more productive than I would have been without them.

But this creates a paradox. Companies can see what AI-assisted developers can produce, so they adjust their expectations accordingly. They assume that entry-level candidates should be able to produce at the same rate, even though they haven't had years to learn how to use these tools effectively.

This is where my perspective as someone still learning differs from that of experienced developers. I use AI tools, but I'm still learning when and how to trust their output. I'm still developing the judgment to know when AI suggestions are appropriate and when they're misleading. I'm still building the foundational knowledge that would allow me to use these tools effectively even when they fail.

The Verification Challenge

One of the most important skills I've had to develop is verification. AI tools can generate code quickly, but that code isn't always correct. I've spent countless hours debugging AI-generated code that looked right but contained subtle errors.

This is where the experience gap becomes apparent. Experienced developers have spent years building intuition about what code should look like, how systems should behave, and what kinds of errors to expect. They can quickly spot when AI output is wrong because it violates principles they've learned through experience.

As a newcomer, I'm still building that intuition. I can verify that code runs without errors, but I might miss subtle issues with security, performance, or maintainability. This is why I believe the traditional apprenticeship model was valuable—it gave junior developers time to build that intuition gradually, with guidance from more experienced colleagues.

The Prompt Engineering Skill

Another skill I've had to develop is prompt engineering. Getting good output from AI tools requires understanding how to frame questions, provide context, and iterate on results. This isn't something that's typically taught in computer science programs or coding bootcamps.

I've learned prompt engineering through trial and error, experimentation, and observation of how more experienced developers work with these tools. But this learning process would have been much easier with mentorship and guidance from experienced colleagues.

The problem is that companies now expect entry-level developers to have these skills without providing the learning opportunities that would help them develop them. It's like expecting someone to become a master electrician without ever working under a journeyman.

Alternative Pathways and Their Limitations

While traditional entry-level positions have become scarcer, several alternative pathways have emerged. However, each comes with its own limitations and challenges.

Open Source Contributions

Many developers suggest contributing to open source projects as a way to gain experience and build a portfolio. I've tried this approach, and while it has value, it's not a complete solution to the apprenticeship problem.

Open source contributions can demonstrate technical ability and collaboration skills, but they don't replicate the full experience of working in a professional development environment. There's no product manager to clarify requirements, no deadlines that affect business outcomes, and no complex organizational dynamics to navigate.

Additionally, contributing to popular open source projects is extremely competitive. Many projects receive hundreds of contributions for each accepted pull request. For someone still learning, getting meaningful contributions accepted can be incredibly challenging.

I've had some success with smaller projects, but these often lack the complexity and scale of real-world applications. The skills I've developed through open source work are valuable, but they don't fully prepare me for the challenges of professional software development.

Personal Projects and Portfolio Building

Building personal projects is another commonly suggested approach. I've built several projects, including a task management application, a weather dashboard, and a simple e-commerce site. These projects have helped me develop technical skills and demonstrate my abilities to potential employers.

However, personal projects have limitations as learning tools. They don't involve working with legacy code, navigating complex requirements, or dealing with the constraints of existing systems. They also don't provide experience with code review processes, deployment pipelines, or collaboration with team members.

Most importantly, personal projects don't replicate the pressure of real business requirements. When a project is just for learning, it's easy to take shortcuts or abandon it when things get difficult. In a professional environment, these challenges must be faced and overcome.

Coding Bootcamps and Online Courses

I've considered enrolling in additional coding bootcamps or online courses, but my experience suggests these have limitations as pathways to employment. Many bootcamps make promises about job placement that don't match reality. The job market they describe often doesn't exist for graduates.

Online courses can provide valuable knowledge, but they don't replace hands-on experience with real systems and real problems. They also don't provide the mentorship and guidance that comes from working with experienced developers.

The time and financial investment required for additional education is also significant, especially for someone like me who is already supporting a family while trying to transition careers.

Freelancing and Contract Work

Some suggest starting with freelancing or contract work as a way to gain experience. While this approach can work, it comes with significant risks and challenges for newcomers.

Freelancing requires not just technical skills but also business skills: finding clients, negotiating contracts, managing finances, and handling legal issues. For someone still learning technical skills, adding these business challenges can be overwhelming.

Contract work often involves working on existing projects with tight deadlines and high expectations. Without the safety net of mentorship and gradual learning, mistakes can be costly both financially and reputationally.

Additionally, the freelance and contract market is highly competitive, with many experienced developers also seeking these opportunities. As a newcomer, competing on price alone often leads to a race to the bottom that doesn't provide sustainable income or meaningful learning opportunities.

What Companies Can Do Differently

While individuals like me face significant challenges, companies also have opportunities to adapt their approaches to talent development in ways that benefit both the organization and new developers.

Creating Structured Learning Environments

Companies that invest in structured learning environments for junior developers often see significant returns. These programs don't have to replicate the traditional apprenticeship model exactly, but they should provide the same core benefits: safe spaces to make mistakes, gradual increases in responsibility, and mentorship from experienced colleagues.

Some companies have started creating "resident" programs where new developers spend their first year rotating through different teams and projects, gaining broad exposure to the organization's systems and processes. Others have established formal mentorship programs that pair junior developers with senior mentors for regular check-ins and guidance.

These programs require investment, but they also create more capable, loyal employees. Developers who feel supported in their learning are more likely to stay with a company long-term and become valuable contributors.

Redefining Entry-Level Roles

Companies could also reconsider what entry-level roles should look like in an AI-assisted world. Instead of expecting junior developers to be immediately productive on complex projects, they could create roles focused on learning and growth.

These roles might involve working closely with AI tools to understand their capabilities and limitations, documenting best practices for AI collaboration, or developing internal training materials. They could provide value to the organization while also giving new developers the time and support they need to develop expertise.

Building Better Feedback Loops

One of the challenges I've observed is that many junior developers work in environments with poor feedback loops. They might spend weeks on a project only to have it rejected in code review with minimal explanation. This is frustrating and doesn't provide the learning opportunities that make feedback valuable.

Companies that invest in better feedback processes—regular one-on-one meetings, detailed code reviews, and clear expectations—tend to develop more capable junior developers. These processes take time and effort, but they're more effective than simply throwing new developers into complex projects and hoping for the best.

Recognizing Different Types of Experience

Finally, companies could benefit from recognizing that experience comes in many forms. My background as a combat medic, construction worker, and security officer has given me skills that are valuable in software development: problem-solving under pressure, attention to detail, and the ability to work effectively in teams.

Too often, job postings focus exclusively on traditional software development experience, missing out on candidates who might bring valuable perspectives and skills from other fields. Companies that broaden their definition of relevant experience may find they have access to a larger, more diverse pool of talented candidates.

The Path Forward for Individuals

For people like me who are trying to break into the industry, there are still strategies that can improve our chances of success, even in this challenging environment.

Building a Learning Mindset

One of the most important shifts I've made is embracing a learning mindset rather than focusing solely on immediate job placement. Instead of viewing every rejection as a failure, I try to extract lessons that will help me grow as a developer.

This means seeking feedback whenever possible, even when it's not offered. It means viewing every project—whether personal, open source, or professional—as an opportunity to learn something new. It means staying curious about technologies and approaches that might not be immediately relevant to my job search.

Developing a Broad Skill Set

I've also focused on developing a broad skill set rather than deep expertise in a single area. While specialization has its benefits, having a diverse set of skills makes me more adaptable to different roles and companies.

This includes not just technical skills—programming languages, frameworks, tools—but also soft skills like communication, project management, and problem-solving. It also means understanding the business context in which software is developed, not just the technical implementation.

Creating Value Wherever Possible

Another strategy I've adopted is looking for ways to create value wherever I can, even when those opportunities don't immediately lead to employment. This might mean contributing to open source projects, writing technical blog posts, or helping other developers in online communities.

These activities help me build skills, establish a reputation in the community, and sometimes lead to job opportunities. More importantly, they help me develop the mindset of someone who creates value rather than just someone who wants a job.

Building Genuine Relationships

Networking is often cited as important for career development, but I've found that building genuine relationships is more valuable than collecting contacts. This means engaging with other developers because I'm genuinely interested in their work and perspectives, not just because I hope they'll give me a job.

These relationships have led to mentorship opportunities, collaboration on projects, and insights into different companies and roles. They've also made the journey more enjoyable and less isolating.

Maintaining Long-Term Perspective

Finally, I've tried to maintain a long-term perspective on my career development. Breaking into the software industry is challenging, but it's not impossible. Success often requires persistence, patience, and the ability to learn from setbacks.

I've had to remind myself that the goal isn't just to get any job, but to build a sustainable, fulfilling career. This might mean being selective about opportunities, even when they're scarce. It might mean investing time in learning and growth rather than rushing into the first available position.

The path forward isn't easy, but it's not impossible either. For people like me who are committed to the journey, there are still opportunities to build meaningful careers in software development, even in this changing landscape.

The AI Review Trap: Why Verification Matters More Than Prompting

Bradley Matera — Sat, 13 Jun 2026 05:37:40 +0000

Most AI development content focuses on prompting.

Browse any AI coding discussion and the questions are consistent:

Which model should I use?
What prompt gets the best output?
How do I make agents more autonomous?
Should I use Claude or GPT-4?
How do I improve my prompt engineering?

These questions assume the bottleneck is generation quality.

That assumption is wrong.

The real bottleneck is verification.

AI systems are exceptionally good at producing answers that appear correct. They format code cleanly. They write confident explanations. They sound authoritative. They produce documentation-quality output.

But confidence is not correctness.

The trap works like this:

You ask an AI system a question.
The system returns a confident, well-formatted answer.
You assume confidence means correctness.
You build on top of that answer.
The mistake compounds.

This is the AI Review Trap.

The most dangerous part is not the initial mistake. AI will make mistakes. The dangerous part is building layers of work on top of an unverified assumption.

For junior developers, self-taught developers, and career changers using AI as a learning tool, this trap is especially costly. When you do not yet have the pattern recognition to spot mistakes quickly, every unverified answer becomes a potential production issue, a confusing debugging session, or hours of wasted work.

This guide argues that the most important skill in AI-assisted development is not prompting.

It is verification.

The Confidence Problem

AI does not know when it is wrong.

This is not a flaw in any specific model. This is how these systems work. They predict tokens. They do not verify truth. They do not check documentation. They do not run code. They produce output that matches patterns in their training data.

When an AI system generates code, it does so with the same confident tone regardless of whether the code is correct.

Consider these examples:

Non-Existent APIs

An AI generates a method call that sounds reasonable:

user = stripe.customers.get_by_email("user@example.com")

The method does not exist. The actual Stripe API requires listing customers with an email filter. But the AI's answer looks correct. The syntax is valid. The method name is plausible. A junior developer might spend twenty minutes debugging before realizing the API call itself is wrong.

Deprecated Methods

AI training data often includes older framework versions. The generated code might use a method that worked in React 16 but was removed in React 18. The code looks fine. The explanation is confident. The compiler might even accept parts of it. But the runtime behavior is broken.

Wrong Package Names

AI suggests installing stripe-node instead of stripe. Or aws-sdk-v3 instead of @aws-sdk/client-s3. The package name looks reasonable. The installation fails or installs the wrong library.

Incorrect Framework Patterns

AI generates a Next.js API route using an outdated pattern that worked in Next.js 12 but breaks in Next.js 14. Or it produces a Vue 2 component structure when the project uses Vue 3. The code is syntactically valid but architecturally wrong.

Invalid Configuration

AI recommends an IAM policy that grants permissions using a deprecated action name. Or it suggests a Docker Compose configuration that uses syntax from an older specification version. The file looks correct but fails at runtime.

Security Issues

AI generates code that works but exposes secrets in environment variables accessible to the client. Or it creates an API endpoint without authentication. Or it builds a form without input validation. The functionality works. The security posture is broken.

Outdated Documentation References

AI cites a configuration option that was removed in the latest version of the tool. Or it references a CLI flag that no longer exists. The explanation sounds authoritative but the actual command fails.

Broken Business Logic

AI generates code that passes type checks and compiles successfully but implements the wrong business rule. A discount calculation rounds the wrong way. A date comparison uses the wrong timezone. A filter excludes valid records.

The problem is not that these mistakes exist. Humans make similar mistakes.

The problem is that AI presents every answer with the same polished confidence.

Correct code and incorrect code look identical until you verify them.

Generation vs Verification

AI accelerates generation.

Generation includes:

Writing code
Writing explanations
Writing documentation
Proposing solutions
Suggesting architectures
Producing boilerplate
Drafting tests
Creating configurations

Generation is cheap. AI can produce thousands of lines of code in seconds.

Verification is what creates value.

Verification includes:

Running code
Testing code
Reading logs
Checking outputs
Reviewing assumptions
Comparing against documentation
Testing edge cases
Validating security
Confirming business logic
Checking error states
Testing user flows

Verification is expensive. It requires time, attention, and understanding.

Most developers using AI optimize for generation speed. They want faster output. Better prompts. More autonomous agents.

The developers who succeed with AI optimize for verification speed. They want faster feedback loops. Better testing. More reliable validation.

Here is the distinction:

Generation	Verification
AI writes 100 lines of code	You run the code
AI explains an API	You read the official docs
AI suggests a configuration	You test the configuration
AI proposes a solution	You validate the solution works
AI generates a component	You test the component in the browser
AI creates a migration	You review the migration in a staging environment
AI writes a test	You verify the test actually fails when it should

Generation is the starting point.

Verification is the work.

Why Senior Developers Catch More AI Mistakes

Experience often looks like intelligence.

A senior developer reviews AI-generated code and immediately spots problems:

"This will break in production because the timeout is too short."
"This configuration will cause memory issues under load."
"This migration will lock the table."
"This API call will fail when the user is not authenticated."

This is not magic. It is pattern recognition.

Senior developers have seen these failures before:

Authentication systems that failed during deployment.
Database migrations that caused downtime.
Configuration mistakes that broke monitoring.
API integrations that worked in development but failed in production.
Security issues that were caught in code review or, worse, discovered in production.

Because they have debugged these problems, they instinctively verify assumptions AI makes.

When AI suggests a configuration, they check the documentation.

When AI generates a query, they think about performance.

When AI writes an API route, they consider authentication.

When AI proposes a deployment step, they think about rollback.

Junior developers can build this skill intentionally.

The method is simple: verify everything until verification becomes instinct.

Over time, you will start recognizing patterns. You will see AI suggest something and think, "I have debugged this exact mistake before."

That instinct is not a replacement for verification. It is a signal that tells you where to verify first.

Real-World AI Failure Scenarios

These are not hypothetical. These are patterns that happen repeatedly in AI-assisted development.

API Hallucination

The Setup:

You ask AI how to retrieve a user from Stripe by email.

AI responds:

const user = await stripe.customers.getByEmail('user@example.com');

The Problem:

The getByEmail method does not exist in the Stripe API.

The actual pattern is:

const customers = await stripe.customers.list({
  email: 'user@example.com',
  limit: 1
});
const user = customers.data[0];

Why This Is Dangerous:

The hallucinated method looks correct. It follows JavaScript conventions. It matches the mental model of "get a customer by email." A developer might copy it, assume it works, and only discover the problem when the code runs.

The Verification Step:

Check the Stripe API documentation before using the method.

Cloud Configuration Error

The Setup:

You ask AI how to configure an S3 bucket for static site hosting.

AI generates a bucket policy that looks reasonable. The policy grants public read access. The syntax is valid. The explanation is confident.

The Problem:

The policy grants more access than necessary. It allows listing all objects in the bucket, not just reading specific objects. This is a security risk.

Why This Is Dangerous:

The configuration works. The site loads. But the bucket is now exposing more information than intended. A security audit or a penetration test would flag this.

The Verification Step:

Review the AWS documentation for least-privilege access patterns. Test the policy with the AWS Policy Simulator.

Security Oversight

The Setup:

You ask AI to build a simple authentication API.

AI generates code that stores passwords and returns user objects.

The Problem:

The code stores passwords in plaintext. The API returns password hashes to the client. There is no rate limiting on the login endpoint.

Why This Is Dangerous:

The code works. Users can log in. But the security posture is broken. Passwords are compromised if the database is accessed. Password hashes are exposed to clients. The endpoint is vulnerable to brute-force attacks.

The Verification Step:

Review authentication best practices. Use a library like bcrypt for password hashing. Do not return sensitive fields to the client. Add rate limiting.

Frontend Success, User Failure

The Setup:

You ask AI to build a form component.

AI generates a React form with controlled inputs. The code compiles. The tests pass.

The Problem:

The form does not validate input before submission. The error messages do not display correctly. The form does not show a loading state during submission. The form is not keyboard-accessible.

Why This Is Dangerous:

The component technically works. But the user experience is broken. Users submit invalid data. Users do not see errors. Users do not know if their submission is processing. Users who rely on keyboard navigation cannot use the form.

The Verification Step:

Test the form in the browser. Try invalid inputs. Submit the form. Navigate with the keyboard. Check accessibility with browser dev tools.

The Verification Workflow

Verification should be a repeatable process.

This is a practical workflow you can use immediately:

1. Read Everything

Before running AI-generated code, read it.

Look for:

Method names you do not recognize
Configuration values that seem unusual
Comments that contradict the code
Hardcoded values that should be configurable
Missing error handling

2. Verify Documentation

If AI references an API, package, framework method, or configuration option, check the official documentation.

Do not assume the AI is current.

Compare:

Method signatures
Parameter names
Return types
Deprecation notices
Version compatibility

3. Run Tests

If the codebase has tests, run them.

If AI generated new code, write tests for it.

If AI claims code is correct, verify that tests actually fail when they should.

4. Check Logs

Run the code and read the logs.

Look for:

Warnings
Deprecation notices
Error messages
Unexpected output

Logs are more honest than explanations.

5. Validate Outputs

Check that the code produces the expected result.

Do not just check that it runs without errors. Check that the output is correct.

Test:

Happy path
Edge cases
Error cases
Null values
Empty inputs

6. Review Assumptions

AI makes assumptions.

Common assumptions:

The database is always available
The API always responds in under one second
The user is always authenticated
The input is always valid
The network is always reliable

List the assumptions. Verify each one.

7. Browser Test User-Facing Changes

If the change affects a UI, open it in a browser.

Test:

Navigation
Forms
Buttons
Error states
Loading states
Mobile viewport
Keyboard navigation
Screen reader compatibility

8. Ship Only After Verification

Do not deploy code you have not verified.

The deployment pipeline should include:

Automated tests
Code review
Staging environment validation
Smoke tests in production

Documentation Is The Source Of Truth

Official documentation outranks AI.

Always.

When AI suggests an API method, check the docs.

When AI recommends a configuration, check the docs.

When AI explains framework behavior, check the docs.

AI training data has a cutoff date. Frameworks change. APIs evolve. Best practices shift.

A method that worked in version 2.0 might not exist in version 3.0.

A configuration option that was standard in 2023 might be deprecated in 2024.

AI does not know this. The training data is static.

Here is the verification pattern:

AI suggests a solution.
You identify the specific method, package, or configuration involved.
You search the official documentation for that method, package, or configuration.
You compare the AI's version with the documented version.
You use the documented version.

This takes time.

It is worth it.

One hour spent verifying documentation prevents days spent debugging production issues caused by outdated code.

Logs Are More Honest Than AI

AI generates explanations.

Logs report facts.

When something breaks, trust the logs more than the explanation.

This is a lesson from cloud operations, support workflows, and troubleshooting production systems.

Logs tell you:

What actually happened
When it happened
What error code was returned
What parameters were passed
What the system state was at the time

AI tells you:

What might have happened
What could cause similar issues
What the error message might mean
What debugging steps might help

Logs are evidence. Explanations are guesses.

Example: Debugging an API Failure

The Scenario:

An API call fails in production. You ask AI to explain the error message.

AI responds with a confident explanation. It suggests three possible causes. It recommends debugging steps. The explanation is detailed and well-formatted.

The Better Approach:

Read the logs.

Look for:

The exact error message
The HTTP status code
The request payload
The response payload
The timestamp
The request ID

Once you have the facts, you can verify AI's explanation against the actual evidence.

Often, the logs reveal the problem immediately. The API key was wrong. The request was malformed. The rate limit was exceeded. The timeout was too short.

These are facts. They do not require interpretation.

Example: Monitoring Dashboard

If your application has monitoring (CloudWatch, Datadog, New Relic, etc.), check the metrics before accepting AI's explanation.

Metrics tell you:

Latency
Error rate
Request count
Resource usage
Dependency health

If AI suggests a performance issue is caused by a database query, check the database metrics first. If the query time is 10ms, the database is not the bottleneck.

This is not anti-AI. This is pro-verification.

AI is extremely useful for generating hypotheses. It can suggest possible causes, debugging steps, and solutions.

But logs and metrics confirm which hypothesis is correct.

Browser Verification

Successful compilation does not mean a successful application.

This is especially true for frontend work.

The TypeScript compiler might accept your code. The tests might pass. The build might succeed.

But the user experience might be broken.

Browser verification is non-negotiable for frontend changes.

What To Check

Navigation:

Do all links work?
Do navigation menus open and close correctly?
Does the back button work as expected?
Do route changes update the URL?

Forms:

Do inputs accept the expected data types?
Do validations trigger at the right time?
Do error messages display correctly?
Does the form submit successfully?
Does the form show a loading state during submission?
Does the form handle submission errors?

Mobile Responsiveness:

Does the layout work on small screens?
Are buttons large enough to tap?
Is text readable without zooming?
Do modals and dropdowns work on mobile?

Error States:

What happens if an API call fails?
Does the UI show a meaningful error message?
Can the user retry the action?
Is the error reported to monitoring?

Loading States:

Does the UI show a loading indicator during async operations?
Are loading states visually clear?
Does the UI remain interactive during loading?

Accessibility Basics:

Can you navigate the UI with only a keyboard?
Do form inputs have labels?
Do images have alt text?
Is color contrast sufficient?
Do error messages work with screen readers?

The Browser Console

Open the browser dev tools. Check the console.

Look for:

JavaScript errors
Warning messages
Failed network requests
Deprecation notices

These are facts. They tell you what is actually broken.

Verification Checklist

Use this checklist before deploying AI-generated code.

Basic Validation:

[ ] I read the entire AI-generated code
[ ] I understand what the code does
[ ] I ran the code locally
[ ] The code runs without errors
[ ] The code produces the expected output

Documentation Verification:

[ ] I checked the official documentation for APIs used
[ ] I verified method names are correct
[ ] I verified package names are correct
[ ] I verified configuration options are correct
[ ] I checked for deprecation notices

Testing:

[ ] I wrote tests for the new code
[ ] I ran existing tests
[ ] All tests pass
[ ] I tested edge cases
[ ] I tested error cases

Logs and Monitoring:

[ ] I checked the logs after running the code
[ ] I looked for warnings or deprecation notices
[ ] I verified no unexpected errors appear in logs
[ ] I confirmed monitoring dashboards show expected behavior

Security Review:

[ ] I reviewed the code for hardcoded secrets
[ ] I verified authentication is required where needed
[ ] I confirmed user input is validated
[ ] I checked for overly permissive configurations

Frontend Verification (if applicable):

[ ] I tested the UI in a browser
[ ] I tested on mobile viewport
[ ] I tested form validation
[ ] I tested error states
[ ] I tested loading states
[ ] I tested keyboard navigation
[ ] I checked the browser console for errors

Deployment Readiness:

[ ] I reviewed the code in a pull request
[ ] I tested the code in a staging environment
[ ] I verified rollback procedures exist
[ ] I confirmed monitoring is in place

This checklist should feel repetitive.

That is the point.

Verification is repetitive.

The Cost Of False Confidence

Verification feels slower.

Reading documentation takes time. Writing tests takes time. Checking logs takes time. Testing in the browser takes time.

It is tempting to skip these steps.

AI gave you code. The code looks correct. Ship it.

This is the trap.

Skipping verification does not save time. It defers the cost.

The real cost is paid later:

Debugging:

The code breaks in production. You spend hours debugging. You trace the issue back to an incorrect API method AI suggested. You could have caught this with five minutes of documentation review.

Rework:

The feature works but does not meet requirements. The business logic is wrong. You rewrite the entire feature. You could have caught this with user acceptance testing before deployment.

Production Issues:

The application breaks for users. Support tickets increase. Engineers are pulled into incident response. Customers are impacted. You could have caught this with browser testing before release.

Lost Trust:

Your team starts questioning AI-generated code. Code review becomes adversarial. Deployments slow down. You could have avoided this by demonstrating that verification catches issues before they reach production.

Security Incidents:

A security researcher reports that your API exposes user data without authentication. You scramble to patch the issue. The vulnerability existed for weeks. You could have caught this with a basic security review.

Verification is an investment.

The return is fewer incidents, faster debugging, and higher confidence in deployments.

Final Thoughts

AI is one of the most useful tools available to developers today.

It accelerates generation. It explains complex concepts. It suggests solutions. It helps you learn new frameworks, languages, and tools.

This guide is not anti-AI.

This guide is pro-verification.

The skill that separates productive AI-assisted development from expensive mistakes is not prompting.

It is verification.

Prompting gets you answers.

Verification proves the answers are correct.

Confidence is not correctness.

A well-formatted, confidently written answer is still wrong if it references a deprecated API, uses an outdated pattern, or contains a security flaw.

The most valuable skill in AI-assisted development is not writing better prompts.

It is learning how to prove that the answer is correct.

Verify the documentation. Run the code. Read the logs. Test the UI. Check the assumptions. Write the tests.

Do the work.

AI will help you move faster, but only if you verify what it produces.

Verification Workflow Summary:

Read everything
Verify documentation
Run tests
Check logs
Validate outputs
Review assumptions
Browser test user-facing changes
Ship only after verification

The developers who succeed with AI are not the ones with the best prompts.

They are the ones who verify everything.

What 364 Applications, 187 Rejections, and Two Years Actually Looks Like

Bradley Matera — Sat, 06 Jun 2026 03:46:43 +0000

The advice for breaking into tech is consistent.

Get a degree or take a bootcamp. Build projects. Earn certifications. Get an internship. Make a portfolio. Use GitHub. Network. Apply broadly. Try support roles, not just developer positions. Write tailored resumes. Write cover letters. Follow up. Keep learning.

I followed that checklist.

Full Sail Web Development degree with a 3.8 GPA. AWS Cloud Support Associate internship. AWS Solutions Architect Associate and AWS AI Practitioner certifications. Portfolio site with public GitHub projects and a technical blog. LinkedIn network of about 206 connections, mostly developers, engineers, and recruiters. Tailored resumes and cover letters. Applications across software development, cloud engineering, DevOps, infrastructure, QA, technical support, Oracle/ERP analyst work, AI automation, and local IT fallback roles. Direct outreach to local employers. Recruiter contacts. Freelance attempts.

What mattered to me at the time was this: I had the degree. I had the AWS internship. I had the certs. I had the portfolio, GitHub, technical blog, LinkedIn network, tailored resumes, cover letters, direct outreach, recruiter contacts, freelance attempts, and applications across multiple lanes.

The outcome was not stable employment.

This is not a post about companies being unfair or the tech industry being impossible to enter. What I want to talk about is the gap between the advice given to career changers and the reality of the current entry-level market—at least the one I encountered from mid-2024 through mid-2026.

I kept thinking maybe the next resume version would be the one. Maybe the next project would make the difference. Maybe support roles would be more realistic. Maybe local companies would be different. After enough cycles of that, I started tracking it because I needed to know if I was imagining the pattern.

The Standard Advice I Kept Hearing

"Have you tried applying to more jobs?"

"Are you networking?"

"Maybe your resume needs work."

"Did you build projects?"

"Have you considered support roles instead of just developer positions?"

"Try local companies, not just remote roles."

"Get certifications."

"Do an internship if you can."

None of this advice was wrong. It just assumed that following it would eventually work if I kept adjusting and applying.

What I Actually Did

I am not claiming I did everything perfectly. I am claiming I did the work.

Graduated from Full Sail University's Web Development program in October 2025 with a 3.8 GPA. Completed an AWS Cloud Support Associate internship. Earned AWS Solutions Architect Associate and AWS AI Practitioner certifications. Built a portfolio site, maintained public GitHub repositories, and kept a technical blog. Networked through LinkedIn, stayed connected with my AWS internship cohort, and participated in a regular Friday night tech discussion group with Full Sail peers that often ran around six hours talking through projects, job searching, and software engineering.

Eventually, I started tracking it. Not because I wanted a spreadsheet for its own sake, but because I needed to know whether I was imagining the pattern. My Gmail searches show 364 application confirmations, 320 sent job-search emails, and 187 rejections over roughly two years. LinkedIn shows 87 tracked applications. Epic Systems alone shows 16 applications from July 2024 through June 2026. I applied across software development, cloud engineering, DevOps, infrastructure, QA, technical support, Oracle and ERP analyst work, AI automation, data roles, and local IT fallback positions. I reached out directly to local employers, contacted recruiters and staffing agencies, and attempted freelance work and paid writing collaborations.

I had followed the checklist as honestly as I knew how. The outcome was not stable employment.

I Was Building While Applying

"Build projects" is one of the main pieces of advice given to juniors. I did build projects, and I tried to document them in the way people say hiring teams want: problem, solution, role, stack, repo, live demo, and lessons learned.

My portfolio was not a one-page resume site. It became a working public hub for my job search and technical proof. The portfolio itself became one of the projects. It had a frontend, backend functionality, GitHub-backed iteration, deployment workflow, role pages, project case studies, a blog, contributions, and store/Stripe-related work. I kept thinking maybe this would be the proof that made the difference—that the site itself showed I could build, deploy, maintain, and iterate on a public web presence while applying.

The blog acted as field notes and project retrospectives—35 articles covering web development, career, DevOps, AWS, AI, Docker, APIs, testing, and debugging. The Projects page organized entries by problem, solution, role, tech stack, and proof. Car-Match showed full-stack work with React, Express, MongoDB, and JWT. The Interactive Pokédex demonstrated Next.js static generation with PokéAPI integration. Convo-AI was a local voice assistant built with Python, FastAPI, Whisper, and Ollama. CheeseMath showed testing patterns with Jest. CIRIS AI contributions showed open-source documentation and Docker Compose work. EthicsFrontEndDemo was a secrets-management tutorial.

The Roles page was intentionally transparent. I labeled the pages as aspirational student case studies and said directly that I had not been paid in those roles yet, that I used AI and tutor support, and that I still needed mentorship in areas like algorithms and large-scale operations. The Contributions page documented unpaid student-level work: README updates, contributor forms, volunteer runbooks, and Tech Talk Club involvement at Full Sail.

What mattered was this: I was not only applying. I was building, documenting, learning publicly, and trying to make the work verifiable.

What I Noticed in the Tracker

Once I stopped looking at each rejection as a separate event, the pattern became harder to ignore.

At first, I thought each rejection was just one rejection. After enough of them, I started looking at the pattern instead of the individual emails.

The tracker does not just show volume. It shows a pattern: applying, getting rejected, retargeting, following up, trying local options, and widening the search.

The rejections included phrasing like "not moving forward," "other candidates," or "position filled." Allstate rejected me for an entry-level full-stack role. DailyPay declined a junior web developer application. FORM moved forward with other candidates for a software support analyst position. I was not locked into one job title—I was trying developer roles, junior roles, and support-adjacent roles.

It was not only job boards either. Slitherine, Rockford IT, Shady Oak Dental, DoIT Illinois, and TreeTop Staffing show direct outreach beyond portals. They also show I tried developer roles, local IT, state IT, staffing channels, and non-tech fallback work. "Apply directly" and "try local companies" were part of the standard advice, and I was doing it.

The tracker spanned software engineering, cloud, DevOps, support, QA, AI, data, and customer success roles across multiple platforms. What frustrated me was not one rejection. It was that "just apply more" does not explain what happened. I was already applying, adjusting, following up, and widening the search.

Epic Systems: A Case Study

Epic is the strongest single-company example because it shows repeated, targeted effort over time. My Epic portal shows 16 applications submitted between July 2024 and June 2026 across infrastructure, systems administration, software development, technical support, UX design, and Windows engineering. Four separate applications went to Infrastructure Engineer roles. Five went to Technical Solutions Engineer. Two targeted Junior Systems Administrator positions. Two aimed at Software Developer roles. The rest spread across Infrastructure as Code Engineer, User Experience Designer, and Windows Engineer.

All Verona, Wisconsin. All onsite or hybrid. My Epic profile showed multiple uploaded resume versions tailored to cloud, infrastructure, software, and technical support paths. This was not one application and one rejection. This was sustained retargeting with one employer who was actively hiring in my region.

This is not me saying Epic did anything wrong. I am using Epic as the clearest example because their portal made the pattern visible.

The Career Lanes I Tried

People always say "don't just apply to one type of job." I did not. I tried seven lanes: software development, cloud and infrastructure, support engineering, QA and testing, analyst and ERP work, AI and data roles, and local fallback positions. Each lane had actual applications or tailored materials behind it.

Backend roles at WTS Paradigm. Full-stack roles at Yahara Software. Developer tooling at Netflix. Cloud engineering using my AWS internship experience with applications to Epic Infrastructure Engineer and Canonical Cloud Support Engineer. Support roles because the advice said support is a good entry point. QA roles at Collins Aerospace. Oracle and ERP analyst positions as a potential entry point. AI roles because I had experience with local AI hosting and LLM workflows. Local employers where I emphasized onsite availability.

Networking and Direct Outreach

People always say "network more" and "don't just rely on job boards." I was doing both. My LinkedIn network included approximately 206 connections, mostly developers, engineers, recruiters, and tech workers. I stayed in contact with people from my AWS internship cohort. Since around August 2024, I participated in a regular Friday night tech discussion group with Full Sail peers that often lasted around six hours talking through projects, job searching, and software engineering topics.

Those nights were not formal networking events. They were usually a few of us talking for hours about projects, job searching, software engineering, tools, and whatever we were stuck on that week.

Beyond that, I reached out directly to local employers. I emailed Rockford IT for entry-level IT work, followed up with Shady Oak Dental for a non-tech fallback role, contacted DoIT Illinois after a virtual job fair, sent materials to Slitherine for junior developer opportunities, and reached out to TreeTop Staffing. I attempted freelance work on Upwork and explored paid technical writing collaborations. Looking back, I was not just applying cold through portals. I was networking, reaching out directly, and trying multiple income paths.

What I Think This Does and Does Not Prove

This is not a benchmark. This is one person's experience over roughly two years of active job searching while completing a degree, internship, certifications, and projects. I cannot claim this represents everyone's experience, that the job market was uniquely hostile to me, that I did everything perfectly, or that every rejected application was flawless.

What I can claim is this: I followed the advice as best as I could, tracked what happened, and the result made me question whether the path was ever as reliable as people made it sound. The tracker shows repeated applications, rejections, retargeting, role-specific materials, public proof of work, education, certifications, networking, and continued effort after rejection.

Around that point, I started wondering: was the self-directed education and portfolio path enough for the entry-level market I was actually applying into? Maybe I am wrong, but after two years of sustained effort, I do not think lack of effort explains what happened.

What I Would Tell Someone Starting This Path Now

I would not tell someone to give up. I would tell them to be more careful than I was at the beginning.

Verify the local job market for entry-level roles before starting. Identify realistic entry points beyond "junior developer." Plan for the possibility that a hundred applications may not be enough. Consider whether you can sustain this effort financially for one to three years. Build relationships with people already employed in the roles you want. Ask whether formal programs with employer pipelines are available. Test your materials and approach with people who have hired successfully. Prepare for the psychological cost of sustained rejection.

The portfolio matters. The projects matter. The certifications matter. The education matters. The networking matters. They were not sufficient by themselves.

My Takeaway

This post documents my job search from mid-2024 through mid-2026. Evidence includes Gmail application confirmations, rejection emails, sent outreach messages, LinkedIn application tracker screenshots, ZipRecruiter application history, Epic Systems portal screenshots, Google Drive cover letter documents, uploaded resume versions, and project repositories. Numbers are based on search queries and visible records. I am not claiming these numbers are perfect. I am claiming they are real.

I proved I could learn. I proved I could build. I proved I could document. I proved I could troubleshoot. I did not prove I could turn that into stable employment.

That is the actual result.

I did not start tracking this because I wanted to prove everyone wrong. I started tracking it because I was starting to wonder if I was the problem, and I needed something more real than feelings to look at. After two years of applications, projects, certifications, an internship, networking, direct outreach, and retargeting, I do not think the honest answer is "just try harder." I did try harder.

Maybe the better question is whether career changers and juniors need more than the standard checklist. Maybe they need employer pipelines, realistic labor-market guidance, mentorship, and a clearer route to companies that actually hire from self-directed portfolios.

I am not completely comfortable saying the path was the whole problem, but after looking at the tracker, I do not think "try harder" explains it either.

The Developer Pay Paradox: Are Junior Devs, Staff Engineers and Most Developers Over- or Under-paid?

Bradley Matera — Sun, 10 May 2026 00:11:39 +0000

The software salary debate usually turns into two groups yelling past each other. One side sees a junior developer making $90k or $100k and says tech is overpaid, while the other side sees a staff engineer keeping a giant system alive and says developers are underpaid compared to the money they help companies make. Both sides can be right depending on what kind of developer they are talking about, but the conversation usually falls apart because people use one job title to describe a bunch of completely different jobs.

A junior dev building admin screens, a mid-level dev fixing production bugs, a staff engineer designing systems across teams, and an AI engineer working near model infrastructure are all technically “developers,” but they are not living in the same labor market. Some of that work is closer to skilled trade work with a keyboard, some of it is business automation work, some of it is infrastructure work, and some of it is high-scale technical decision-making where one bad call can cost a company a lot of money.

I also do not like when developers act like software is the only hard work that exists. I have been a roofer, I was a medic in the Army, I worked private security, and I have done warehouse-style work loading roofing materials onto job sites, so it is hard for me to listen to someone act like fixing a React bug is automatically harder than climbing a roof, treating people under pressure, standing a post all night, or throwing heavy material around in bad weather for less than $20 an hour.

At the same time, I do not like fake arguments that pretend software work is easy just because it is not physically brutal. A job can be easier on the body and still be valuable to a company, because the company is not paying based on how much your back hurts. The company is paying based on leverage, replacement cost, scalability, risk, and how close the work sits to money.

That is the uncomfortable part. A junior developer can do work that looks simple, like fixing a form or wiring an API call, and still get paid more than someone doing harder physical work. That does not mean the junior developer is tougher or more useful to society. It means software sits inside a business model where one small piece of work can be reused, deployed, copied, and sold again and again.

The Real Question
Why I’m Comparing These Jobs At All
The Pay Numbers That Start The Argument
Salary Comparison Graphic
Why A Junior Dev Can Make More Than People Doing Harder Work
Roofing Compared To Software Development
Army Medic Work Compared To Software Development
Private Security Compared To Software Development
Warehouse And Manual Labor Compared To Software Development
Teaching Compared To Software Development
Do Most Developers Even Do DSA?
Is Web Development Skilled Trade Work With A Keyboard?
Are Junior Developers Overpaid?
Are Mid-Level Developers Fairly Paid?
Are Staff Engineers Overpaid?
Where AI Changes The Pay Conversation
The Three Different Developer Economies
The Honest Answer
Sources

The Real Question

The real question is not “are developers overpaid?” because that question is too broad to be useful. A better question is, “overpaid compared to what, for what type of work, at what company, and under what business model?” Without those details, the argument turns into people comparing a junior web developer at a small company to a staff engineer at Google like those are the same thing.

If we compare developers to the national median worker, developers are paid a lot. If we compare developers to roofers, EMTs, paramedics, security guards, warehouse workers, construction laborers, or teachers, software pay can look insane, especially when the software job is remote and the other job is physically dangerous, emotionally heavy, or socially necessary.

If we compare developers to the money their work can generate, the answer changes. A developer working on a SaaS product, payment system, cloud platform, AI tool, ad system, internal dashboard, or automation flow can touch systems that scale to thousands, millions, or even billions of interactions. That kind of scale is why the salary conversation gets weird fast.

That is the part people miss when they only compare effort. The labor market does not pay only based on pain, danger, stress, intelligence, or how noble the job is. It mostly pays based on leverage, scarcity, replacement cost, company margins, and how close the work is to revenue.

This is why the argument feels morally wrong but economically explainable. A medic can do more socially important work than a junior web developer and still make less, because medical labor is often trapped inside public budgets, insurance structures, military pay tables, local contracts, or staffing models. Software work, especially inside product companies, can sit closer to high-margin revenue.

That does not mean the market is fair. It means the market is not built around fairness. It is built around money, risk, supply, demand, and who has the power to negotiate.

Why I’m Comparing These Jobs At All

I am not comparing software to roofing, Army medic work, private security, warehouse-style labor, and case management because I think they are all the same job. I am comparing them because I have lived enough of those worlds to know that “hard work” and “high pay” are not the same thing, and pretending they are is one of the reasons the developer pay debate gets so fake.

My own work history did not start in tech. I served as a Healthcare Specialist in the Army from 2011 to 2014, including training environments and combat-zone medical support, where the work involved triage, emergency response, medical readiness, supplies, physical exams, medication administration, and staying calm when things were unpredictable. After that, I worked roofing and roofing supply roles from 2017 to 2020, including general contracting, tear-off, shingle work, site prep, cleanup, and roof loading heavy materials onto job sites in bad weather and under tight schedules. I also worked private security, and later worked in case management with Veterans Court, Drug Court, and Mental Health Court, where documentation, communication, crisis intervention, and keeping people on track mattered every day.

I also worked at Mason County Kitten Rescue from 2020 to 2022, which was not high-paying tech work, but it taught organization, intake, care routines, training volunteers, watching for signs of distress, and doing important daily work that does not become more profitable just because it matters. Then I started moving seriously into software, contributing as a Junior Frontend Developer with CIRIS Ethical AI in 2024 by running the project locally, improving onboarding and setup documentation, adding small code changes, improving token-verification logging, fixing lint issues, improving error messages, and opening GitHub Issues to keep larger ideas tracked. In 2025, I completed an on-site AWS Cloud Support Engineer internship in Seattle, where the work included guided support rotations in training environments with no customer data, guided Juniper and Junos troubleshooting labs in Jupyter Notebooks, and a capstone serverless metadata extraction workflow using Lambda, DynamoDB, S3, and an accessible frontend deployed on AWS Amplify.

The reason that timeline matters is because none of the earlier physical or service-heavy jobs paid me over $20 an hour at the time, but they still demanded discipline, pressure management, communication, safety, documentation, and the ability to keep moving when things were not comfortable. Then tech came along and suddenly the pay ceiling was completely different, not because the work became morally superior, but because the business model changed. Software is not automatically harder than those jobs, but it can be attached to systems where the output scales in a way those jobs usually cannot.

The Pay Numbers That Start The Argument

The U.S. Bureau of Labor Statistics listed the median annual wage for software developers at $133,080 in May 2024. The same BLS page says the lowest 10 percent earned less than $79,850, while the highest 10 percent earned more than $211,450.

That number is already high compared to normal American wages. BLS listed the median annual wage for all workers at $49,500 in May 2024, which means the median software developer made about 2.7 times the median worker.

The comparison gets uncomfortable when software is placed next to jobs that are clearly hard, risky, or socially important. BLS listed roofers at $50,970, EMTs at $41,340, paramedics at $58,410, security guards at $38,370, construction laborers and helpers at $46,050, hand laborers and material movers at $37,680, and high school teachers at $64,580.

Those numbers explain why people outside tech get annoyed when developers complain about pay. A junior developer can make more than a roofer, medic, security guard, teacher, construction laborer, or warehouse worker before that junior developer is even fully useful to the team.

Levels.fyi shows even larger numbers because it tracks total compensation, not just base salary. In May 2026, Levels.fyi listed U.S. software engineer median total compensation around $191,000, with the 25th percentile around $135,000, the 75th percentile around $276,100, and the 90th percentile around $380,000.

BuiltIn shows a lower junior number than Levels.fyi, which makes sense because BuiltIn pulls from a broader mix of companies. BuiltIn lists U.S. junior software engineer average base salary around $89,847, average additional cash compensation around $10,590, and average total compensation around $100,437.

Role Or Group	Recent Pay Data	Why It Matters
All U.S. workers	$49,500 median wage	This is the broad baseline for the whole labor market.
Roofers	$50,970 median wage	This is skilled, physical, dangerous work, but the pay is close to the national median.
EMTs	$41,340 median wage	This is life-safety work, but the labor market pays it far below software.
Paramedics	$58,410 median wage	This pays more than EMT work, but still far below the median developer.
Security guards	$38,370 median wage	This is common risk-bearing work, but it pays far below software.
Construction laborers and helpers	$46,050 median wage	This is hard physical work that often pays less than many junior tech jobs.
Hand laborers and material movers	$37,680 median wage	This covers a lot of warehouse-style physical labor and shows how low that work often pays.
High school teachers	$64,580 median wage	This requires education, responsibility, and social value, but it is still below junior software pay in many cases.
Software developers	$133,080 median wage	This is where the comparison starts looking unfair to people outside tech.
U.S. software engineers on Levels.fyi	$191,000 median total comp	This includes bonus and equity, so it shows the higher end of tech more clearly.
Junior software engineers on BuiltIn	$100,437 average total comp	This is one reason people ask whether junior developers are overpaid.

The table is not saying developers have easy lives or that every developer is rich. It is showing why the discussion gets tense, because the pay gap is real and the explanation is not as simple as “developers are smarter” or “developers work harder.”

The market is not judging pay by soreness, danger, or public good. It is judging pay by how much money the company has, how scalable the output is, how hard the role is to fill, and how expensive it is when the work is done badly.

Salary Comparison Graphic

A salary comparison using recent BLS wage data, BuiltIn junior software engineer compensation, and Levels.fyi software engineer total compensation. The point is not that software is always harder. The point is that software sits closer to scalable business leverage, which changes how companies pay for the work.

Why A Junior Dev Can Make More Than People Doing Harder Work

This is the question people are really asking. Why is a junior developer who barely knows the codebase getting paid more than somebody climbing roofs, treating casualties, standing security posts, moving freight, or managing a classroom?

The answer is not that junior devs are tougher than roofers, medics, teachers, or security guards. A junior dev sitting at a desk with a laptop is not taking the same physical beating as a roofer, and they are not carrying the same kind of immediate life-and-death pressure as a medic.

The answer is also not that every junior developer is doing genius-level computer science all day. Most junior developers are not writing compilers, designing databases, or inventing new algorithms. Most are fixing bugs, building components, writing API calls, updating forms, handling validation, reading existing code, asking questions, and trying not to break the build.

The reason junior developers can still get paid more is leverage. A junior dev working on the right product can ship a small feature that thousands of customers touch, while a roofer can only roof the house, building, or section physically in front of them.

That does not make the roofer less skilled, and it does not make the medic less important. It means software output can be copied, deployed, reused, sold, and scaled in a way physical labor usually cannot.

A roofer finishes a roof and that roof exists in one place. A developer finishes a login flow, billing screen, internal automation, or API endpoint, and that work might run all day for every user the company has.

A medic treats the patient in front of them, and that work matters in a direct human way. A developer builds a system that might remove manual steps for a whole department, process thousands of payments, or prevent support tickets before they exist.

A security guard protects a site, handles access, watches patterns, and responds to incidents in one location. A developer who builds access controls, audit logs, or monitoring systems might affect every user and every employee at the company.

That is why software salaries feel disconnected from effort. The pay is not really for typing code. The pay is for building and maintaining systems that can scale past one person’s physical output.

Roofing Compared To Software Development

Roofing is one of the easiest jobs for people to underestimate because the final product looks simple. A roof keeps water out, but anyone who has actually done the work knows that a roof is only simple when you ignore everything that makes it fail.

When I think about roofing, there are about 10 things you have to actually learn before you are useful and safe. You need to understand tear-off, decking, underlayment, flashing, shingles, fasteners, ventilation, valleys, measurements, and job-site safety.

Tear-off is not just ripping old material off the roof. It is removing layers without destroying the deck, managing debris, watching for rot, keeping the site clean enough to work, and not creating a bigger problem before the new material even goes on.

Decking matters because the roof is only as good as what it is attached to. In software, this is like discovering the data model, old architecture, or legacy service is rotten underneath the feature request.

Underlayment, ice barrier, and water protection are the hidden layers most homeowners never think about. In software, those are like validation, auth checks, error handling, logging, and safe defaults, because nobody praises them when they work but everybody notices when they fail.

Flashing is where a lot of bad roofs lose. In software, the equivalent is integrations, permission boundaries, third-party APIs, weird browser behavior, and all the places where one clean system meets another messy system.

Shingles look easy from the ground, but alignment, overlap, nailing pattern, starter strips, and sequence all matter. In software, that is the repeatable pattern work, because a component, endpoint, or service should fit the system instead of being random every time.

Fasteners matter because using the wrong nail, wrong placement, or wrong pressure creates future failure. In code, that is like using the wrong dependency, weak typing, fragile state management, a bad query, or a shortcut that only works until the system changes.

Ventilation is one of those things that makes a roof fail slowly. In software, performance, caching, queues, background jobs, and infrastructure limits are the same kind of hidden system health work.

Valleys, edges, vents, chimneys, and walls are where the easy middle stops being easy. In software, the happy path is usually simple, but the edge cases, weird inputs, expired sessions, duplicate requests, broken permissions, and production-only bugs are where the real work shows up.

Measurement and material planning matter because waste costs money and bad estimates kill jobs. In software, bad estimates create missed deadlines, half-built features, rushed testing, and pressure that usually lands on the people doing the work.

Safety matters because roofing can hurt or kill you fast. Software usually will not do that to your body, but it can hurt customers, leak data, break billing, stop operations, or create business damage if the system is important enough.

Roofing Work	Software Equivalent	Why The Comparison Makes Sense
Tear off the old roof without damaging the deck	Refactor old code without breaking production	Both jobs start by removing bad or outdated layers carefully.
Inspect problem areas before quoting the job	Read requirements, logs, errors, and existing code before coding	Both jobs punish people who start swinging before understanding the problem.
Measure the roof and calculate material	Scope the feature, data model, and implementation work	Both jobs need estimating, waste control, and planning before execution.
Replace rotten plywood or damaged joists	Fix bad architecture, bad data, or broken dependencies	Both jobs reveal hidden problems once the surface layer comes off.
Install underlayment and water protection	Add validation, auth, error handling, and security checks	Both jobs need invisible protection that the customer may never notice until it fails.
Flash chimneys, walls, valleys, and vents	Handle edge cases around integrations, permissions, and weird states	Both jobs usually fail at the edges, not in the big flat middle.
Lay shingles with proper overlap and alignment	Build UI and API flows with consistent patterns	Both jobs need repeatable patterns, not random improvisation every few feet.
Cut materials around vents, walls, and valleys	Adapt code around browser quirks, API limits, and product exceptions	Both jobs require custom fitting while still following a system.
Install ventilation correctly	Design performance, caching, and operational flow	Both jobs can look fine at first and fail later if system flow is wrong.
Work safely on ladders, slopes, heat, wind, and job sites	Work safely around production data, secrets, deployments, and user impact	Both jobs have risk, but the kind of risk is different.

This is why I do not buy the argument that software work is always intellectually superior to trade work. A lot of software development is applied craft, pattern recognition, troubleshooting, repetition, and learning how to avoid known failures.

The difference is that software companies can sell the same work again and again. A roofing company cannot install the same roof on 100,000 houses with one deployment.

Army Medic Work Compared To Software Development

Medic work is another comparison that makes software pay feel strange. As a medic, especially in the Army, the job is not just knowing medical facts. It is applying training under stress, around chain of command, with imperfect information, limited time, and real consequences.

The Army describes the 68W Combat Medic Specialist role as assessing injuries, stabilizing patients, making critical medical decisions under extreme conditions, training other soldiers in first aid, and providing emergency medical treatment. That is a lot of responsibility for a role that often does not pay anywhere near what a developer makes.

Civilian pay shows the gap clearly too. BLS lists EMTs at a median annual wage of $41,340 and paramedics at $58,410, which means a junior software developer can easily make more than someone doing emergency medicine work.

This is not because the junior developer has more immediate responsibility than a medic. A junior dev might break a page or slow down a sprint, while a medic can be involved in decisions where minutes matter.

The software comparison is not about physical danger or emotional pressure. It is about decision-making inside a system, because medics and developers both work with incomplete information and need to decide what matters first.

A medic has to assess the patient, control bleeding, protect the airway, manage shock, communicate with the team, prepare evacuation, document care, and keep working under pressure. A developer has to assess the bug, isolate the failure, protect production, communicate with the team, prepare a fix, document the change, and keep working under pressure.

Those are not equal jobs. The human stakes are not the same. But the pattern is similar because both involve triage, prioritization, systems thinking, and knowing when the wrong action is worse than taking a moment to understand the problem.

Medic Work	Software Equivalent	Why The Comparison Makes Sense
Triage multiple problems under pressure	Prioritize incidents, bugs, and outages	Both jobs require deciding what matters first.
Stop bleeding before treating smaller injuries	Fix the production-breaking issue before cosmetic bugs	Both jobs need damage control before polish.
Maintain airway, breathing, and circulation	Protect uptime, data flow, and core system health	Both jobs depend on keeping the main system alive.
Work with limited information	Debug with incomplete logs or unclear reports	Both jobs rarely start with perfect information.
Communicate with chain of command or evacuation teams	Communicate with managers, product, support, and engineers	Both jobs fail when communication fails.
Track treatment and patient status	Document incident notes, fixes, and follow-up work	Both jobs need records so the next person is not blind.
Train others in basic first aid	Mentor juniors and write operational docs	Both jobs scale knowledge through training.
Stay calm when people panic	Stay calm during production issues	Both jobs punish panic and reward process.

This is why I do not like when developers exaggerate how hard coding is compared to everything else. Medic work can be more stressful, more direct, more personal, and more consequential in the moment.

The reason software pays more is not because society values medics correctly. Software pays more because companies can turn working software into repeatable revenue, while emergency medical work is often limited by public budgets, contracts, insurance systems, military pay structures, and staffing models that do not reward the worker based on the actual human value of the work.

Private Security Compared To Software Development

Private security is another job people underestimate because they picture someone just standing around. Sometimes that is what it looks like from the outside, but the actual job is staying alert when nothing is happening, noticing when something changes, handling people without escalating the situation, and being the first person blamed when something goes wrong.

BLS lists security guards at a median annual wage of $38,370 in May 2024. That is about $18.45/hour, and it is still far below what many junior developers make.

When I worked private security, the job was not technically complex the same way software is complex, but it required discipline, awareness, patience, and judgment. You had to watch access points, control entry, write incident reports, handle tense people, stay awake, stay professional, and understand when to call for help.

Software has a security version of that same thinking. A lot of development work is boring monitoring, access control, logging, reviewing permissions, checking systems, and making sure the wrong person does not get into the wrong place.

The pay difference is not because the private security worker has no value. The pay difference is because private security is often treated as a cost center, while software is often treated as a product engine or revenue multiplier.

Private Security Work	Software Equivalent	Why The Comparison Makes Sense
Control access to a site	Build authentication and authorization	Both jobs decide who gets in and what they can touch.
Watch cameras, doors, lots, and patterns	Monitor logs, dashboards, errors, and metrics	Both jobs require noticing abnormal behavior.
Write incident reports	Write bug reports, incident notes, and postmortems	Both jobs need clear records after something happens.
De-escalate tense people	Handle support escalations and production pressure calmly	Both jobs need communication under stress.
Follow post orders	Follow runbooks, deployment process, and security policy	Both jobs depend on process because memory is not enough.
Patrol and inspect areas	Review systems, endpoints, configs, and permissions	Both jobs look for problems before they become incidents.
Respond when something changes	Respond to alerts, outages, and suspicious activity	Both jobs can be quiet for hours and then serious fast.

The unfair part is that security workers are paid like replaceable labor even though bad security can cost a company a lot. Software developers are paid better because their work is closer to scalable revenue and because companies believe replacing a developer is harder than replacing a guard.

That does not mean the market is morally correct. It means the market rewards leverage more than responsibility.

Warehouse And Manual Labor Compared To Software Development

Warehouse work is another comparison that matters because a lot of people in tech have never had to do repetitive physical work for a paycheck. BLS lists hand laborers and material movers at a median annual wage of $37,680, which shows how low that work often pays compared to software.

Warehouse work can look simple if you only describe it as “moving boxes.” Software can also look simple if you only describe it as “typing code,” which is why bad descriptions are useless.

Warehouse work requires speed, accuracy, memory, scanning, staging, loading, safety, endurance, and not making mistakes that slow down everyone behind you. A bad pick, bad label, bad count, bad pallet, or bad load can create real downstream problems.

Software has the same kind of flow problem, just in a different form. A bad data migration, wrong config, bad deploy, missed environment variable, or broken API contract can hold up the whole team or create customer issues.

Warehouse Work	Software Equivalent	Why The Comparison Makes Sense
Pick the right item	Pull the right data or dependency	Both jobs fail when the wrong thing moves through the system.
Label and scan correctly	Name, type, and log data correctly	Both jobs need traceability.
Stage items in the right place	Prepare code, branches, builds, and environments correctly	Both jobs depend on sequence and organization.
Load without damaging product	Deploy without damaging production	Both jobs involve moving work safely from one state to another.
Keep pace without losing accuracy	Ship quickly without breaking quality	Both jobs punish sloppy speed.
Follow safety and workflow rules	Follow code review, testing, and deployment rules	Both jobs use process to reduce mistakes.

The difference is not that software is always harder. The difference is that software work can automate the warehouse workflow itself, reduce headcount, improve routing, change inventory systems, or improve company-wide efficiency.

That is why a developer who has never done warehouse work might make more than the warehouse worker. It is not because the developer is automatically tougher, it is because the developer may be building the system that changes how 500 warehouse workers operate.

Teaching Compared To Software Development

Teaching is one of the clearest examples of how pay does not equal social value. BLS lists high school teachers at a median annual wage of $64,580, which is above the national median but still far below software developer pay and below many junior tech offers.

A good teacher has to understand the subject, manage a room, communicate clearly, adjust to different students, track progress, deal with parents and administrators, follow standards, grade work, and keep showing up even when the system is not built to make the job easy.

That sounds a lot like developer mentorship in some ways. A senior developer who cannot explain anything clearly is less useful than a senior developer who can teach patterns, review code well, write docs, and help juniors become productive.

The difference is that teaching usually sits inside public budgets, district funding, local taxes, political fights, and credential systems. Software sits inside companies that can sell products repeatedly and use technical work to increase margins.

Teaching Work	Software Equivalent	Why The Comparison Makes Sense
Break down hard concepts	Explain systems, code, and architecture	Both jobs require turning complexity into something another person can use.
Manage different skill levels	Mentor juniors and collaborate across teams	Both jobs involve uneven experience levels.
Grade and give feedback	Review code and give actionable comments	Both jobs need feedback that improves the person, not just the output.
Follow curriculum and standards	Follow product requirements, security standards, and engineering process	Both jobs work inside constraints.
Track progress over time	Track technical debt, sprint work, and developer growth	Both jobs require long-term attention.
Handle classroom pressure	Handle meetings, incidents, and team pressure	Both jobs require communication when things get messy.

This is why the “developers are paid because they are smarter” argument falls apart. Teachers need skill, judgment, patience, communication, and subject knowledge, but their labor does not scale the same way software does.

A teacher teaches the students in front of them. A developer builds a feature once and the company can put it in front of every customer.

Do Most Developers Even Do DSA?

Most developers do not spend their normal workday implementing red-black trees, writing graph algorithms from scratch, or solving LeetCode-style dynamic programming problems. Most business software work is much more ordinary than the interview process makes it look.

That does not mean data structures and algorithms are useless. It means there is a difference between the theory that helps you think and the daily work most developers are paid to do.

Most web developers spend more time reading existing code, changing components, writing endpoints, shaping data, handling errors, fixing tests, wiring third-party services, working with databases, and pushing changes through a deployment process. That work still uses data structures, but usually in the form of arrays, objects, maps, JSON, query results, collections, queues, and state.

A roofer does not calculate structural engineering formulas all day either. That does not mean roofing has no skill. It means the job is mostly applied field knowledge, judgment, tool use, sequence, safety, and knowing what failure looks like before it happens.

A medic does not write a medical textbook during every patient interaction either. They apply training, assess the current situation, follow protocol, make decisions, communicate, and act before the situation gets worse.

A security guard is not doing legal theory all night either. They follow post orders, watch patterns, control access, de-escalate, document, and call the right people when something crosses the line.

Software is similar for most developers. The job is less “solve a puzzle from scratch” and more “change a living system without making it worse.”

The reason DSA still matters is that some jobs really do need it. Search, ranking, distributed systems, graphics, compilers, databases, high-frequency trading, AI infrastructure, embedded systems, and large-scale platform work can absolutely require deeper computer science.

The problem is that the hiring process often treats every web developer like they are applying to build a search engine. That creates a fake picture of the job, because plenty of developers make solid money doing CRUD, integrations, infrastructure, UI, testing, debugging, and maintenance.

This is part of why salary conversations get weird. A person outside tech hears that developers make six figures and assumes they must be doing advanced math all day. A person inside tech knows plenty of developers are mostly moving data from one place to another, validating it, displaying it, storing it, and making sure it does not break.

That work still matters, but it is not always the mythical version of software engineering people imagine. Most companies pay for working systems, not for how many algorithm problems someone can solve on a whiteboard.

Is Web Development Skilled Trade Work With A Keyboard?

A lot of normal software work is closer to skilled trade work than developers want to admit. Most business developers are not doing advanced algorithm research, because they are building, fixing, connecting, deploying, documenting, and maintaining systems.

That does not make the job fake or easy. Roofing is also “just putting materials on a roof” if someone wants to describe it badly, but anyone who has done it knows that a bad roof can look fine for a little while before the leak exposes every shortcut.

Software is the same way. Bad code can look fine in the demo, pass the happy path, and still fail when users hit weird inputs, network errors, bad permissions, slow queries, expired sessions, broken environment variables, or real production load.

This is where the trade comparison gets useful. A lot of web development is not elite math, but it is still skilled production work where experience matters because the edge cases are what punish you.

The same pattern shows up across roofing, medic work, security, warehouse work, teaching, and software. The public sees the visible output, but the worker knows the job is mostly about preventing the failure that nobody notices if you did it right.

In roofing, a customer might only see shingles. In software, a product manager might only see a button. The worker sees the layers under it, the ways it can fail, the shortcuts that were taken before, and the cleanup nobody budgeted time for.

That is why I think “easy job” is the wrong phrase. Some development work is physically easy, and some tickets are technically simple, but the job becomes valuable because the work lives inside a larger system with users, data, revenue, and future maintenance attached to it.

Are Junior Developers Overpaid?

Compared to roofers, EMTs, teachers, security guards, warehouse workers, construction laborers, and the national median worker, junior developers are usually overpaid in the plain social comparison sense. A junior developer making $90k to $120k while still learning the job is making more than many people who carry more physical risk, more public responsibility, or more immediate consequences.

Compared to the business model they work inside, juniors are not always overpaid. A junior who can ship small production improvements, automate annoying internal work, fix customer-facing bugs, improve documentation, and grow into a mid-level developer is not just being paid for today’s output.

The company is paying for the pipeline. Hiring a junior is partly a bet that the person will become useful enough to retain, promote, or use as a cheaper alternative to hiring only seniors.

This is also why junior hiring gets ugly when the market tightens. If companies stop wanting to invest in training, juniors suddenly look expensive because they need mentorship before they become reliably productive.

That is where the “easy job” complaint has some truth but not the whole truth. A lot of junior tickets are easy compared to roofing, medic work, or private security, but the junior is still learning how to work inside a system where small changes can create bigger problems.

So yes, juniors can be overpaid if the company expects them to be productive immediately and they are mostly being carried. But juniors can be underpaid if they are doing real production work, learning fast, getting little support, and still being treated like replaceable cheap labor.

The more honest answer is that junior pay is not about whether the current ticket is easy. It is about whether the company believes the person can become valuable before the cost of training them becomes a loss.

Are Mid-Level Developers Fairly Paid?

Mid-level developers are probably the closest thing to fairly paid in normal software work. They usually know enough to ship, debug, communicate, review code, understand production basics, and ask for help before they create a disaster.

They are not usually responsible for company-wide technical direction. They also are not usually helpless, which makes them valuable without making them as expensive as staff or principal engineers.

This level is where software starts looking most like skilled trade work. A solid mid-level developer knows the tools, knows the common failure points, knows how to estimate better than a junior, and knows when a “small change” is not actually small.

A solid roofer with a few years in the field is the same kind of person. They may not own the company or design the whole job, but they can look at a roof, understand the next steps, avoid obvious mistakes, and keep the job moving.

A solid medic is also that kind of person. They may not be the doctor, but they know how to assess the situation, act within scope, document, communicate, and keep the patient moving through the system.

A reliable security worker fits the same pattern too. They may not be writing policy, but they know the post, notice what is off, document what happened, and understand when a situation needs to move up the chain.

That is why mid-level dev compensation makes the most sense to me. They are expensive, but they are usually expensive in the same way any reliable skilled worker is expensive, with the added difference that software output can scale.

Are Staff Engineers Overpaid?

Staff engineers are where the conversation becomes almost impossible because the numbers get absurd. A Google L6 staff engineer around $580k, a Meta E6 staff engineer around $775k, and Netflix senior staff compensation near or above $1M sounds fake if you compare it to normal jobs.

But staff engineers at companies like that are not being paid to close Jira tickets. They are paid to reduce risk, set technical direction, unblock teams, review architecture, avoid expensive mistakes, and make decisions that affect systems with huge numbers of users.

That is why revenue per employee matters. NVIDIA reportedly generated around $4.4 million in revenue per employee, and Netflix was reported around $4.15 million per employee, which changes how a $700k engineer looks on a spreadsheet.

That does not mean every staff engineer deserves $700k. Some people have inflated titles, some companies hand out titles loosely, and some senior people become expensive bottlenecks instead of force multipliers.

But a real staff engineer at scale is not just a better coder. They are closer to a technical foreman, architect, incident preventer, reviewer, teacher, and risk manager combined.

That kind of work can be underpaid if it prevents huge losses. It can also be overpaid if the person mostly attends meetings, writes vague docs, and creates no real technical leverage.

The title alone does not answer the question. The value depends on the actual scope, the systems involved, and whether the person makes many other engineers and systems better.

This is the part that normal salary comparisons miss. A staff engineer at a small company and a staff engineer at a global platform can have the same title, but one might be improving internal tooling for 80 employees while the other is making architecture decisions that affect millions of users.

That is why staff pay looks fake from the outside. Sometimes it is inflated, sometimes it is justified, and sometimes it is still cheaper than the damage the wrong technical decision would cause.

Where AI Changes The Pay Conversation

AI makes this debate even harder because it lowers the floor and raises the ceiling at the same time. A junior with AI tools can ship more than a junior could a few years ago, but a weak junior can also create a bigger mess faster than before.

The boring tasks are becoming cheaper. Boilerplate, simple components, basic scripts, basic CRUD, documentation drafts, test scaffolds, and quick debugging help are all easier with tools like ChatGPT, Claude, Cursor, and Copilot.

That means companies may eventually pay less for people who only know how to produce basic code. The value is moving toward people who can understand the system, verify AI output, debug bad suggestions, protect production, think through risk, and connect technical work to business goals.

This is where staff engineers and strong mid-level developers may become even more valuable. If a company has ten juniors using AI and nobody experienced reviewing the architecture, the company did not get faster, it just created problems at higher speed.

AI does not remove the need for judgment. It makes judgment more important because the cost of producing code went down, but the cost of understanding whether that code is correct did not disappear.

This is also why junior dev pay is going to be a rough topic for a while. If a junior can use AI to ship useful work and they can explain what they are doing, their value goes up. If they use AI to produce code they cannot understand, their risk goes up.

The same thing happened in other work when tools improved. Better nail guns did not remove the need for someone who understands roofing. Better medical equipment did not remove the need for someone who can assess the patient. Better cameras did not remove the need for security judgment.

Better coding tools will not remove the need for developers who understand systems. They will probably remove some tolerance for people who only copy output and hope it works.

The Three Different Developer Economies

The software industry is not one labor market anymore. It is at least three different economies pretending to be one because all the job titles use the word developer or engineer.

The first economy is normal software work. These are the developers at small companies, local businesses, agencies, internal IT teams, healthcare companies, manufacturing companies, insurance companies, and non-tech companies where software supports the business instead of being the whole business.

The second economy is high-scale tech. These are developers at Big Tech, AI labs, high-frequency trading firms, cloud infrastructure companies, fintech platforms, and product companies where one technical decision can affect millions of users or billions of dollars in market value.

The third economy is underpaid software work. These are developers maintaining legacy systems, handling frontend, backend, support, infrastructure, deployments, and documentation while making $60k, $80k, or maybe $100k with little mentorship and no real path upward.

This is why the argument goes nowhere. Someone talking about a junior web developer at a small local company and someone talking about an L6 engineer at Google are not talking about the same job.

Both people can be telling the truth. They are just describing different worlds.

Developer Economy	Typical Work	Typical Pay Reality
Normal software work	CRUD, internal tools, websites, APIs, integrations, support, maintenance	Often $70k to $180k depending on region and company.
High-scale tech	Infrastructure, platforms, AI, distributed systems, revenue-critical products	Can reach $300k to $1M+ because the leverage is massive.
Underpaid software work	Legacy maintenance, too many hats, little support, low-budget companies	Can pay closer to $50k to $100k while still demanding broad responsibility.

This split explains why developers argue past each other. One person is talking about people making $500k and another person is talking about someone doing full-stack work for $70k at a non-tech company.

The title alone does not tell you enough. You need to know the company, the market, the revenue model, the level, the scope, the risk, and whether the person is actually creating leverage or just carrying a fancy title.

The Honest Answer

Developers are overpaid if the comparison is physical danger, social value, or visible effort. A junior developer working from home can make more than a roofer, medic, teacher, security guard, warehouse worker, or construction laborer, and I do not think developers should pretend that feels normal.

Developers are not always overpaid if the comparison is business leverage. A developer who ships a feature used by thousands of customers, prevents outages, improves performance, secures customer data, or automates expensive work can easily create more value than their salary.

Most normal developers are not doing elite computer science all day. They are doing applied software trade work, which means building, fixing, connecting, testing, deploying, documenting, and maintaining systems that break in weird ways.

That work is not magic. It is not always harder than roofing, medic work, construction, warehouse work, teaching, or security work, but it exists inside a business model where output can scale.

The cleanest answer is this: junior devs can be socially overpaid and economically reasonable at the same time, mid-level devs are often the most fairly paid group, and real staff engineers at scale can look wildly overpaid while still being underpaid compared to the money and risk they manage.

The thing I do not buy anymore is the idea that pay equals difficulty. Pay equals leverage, scarcity, company margins, negotiation power, and how close your work is to money.

That is why the junior dev making a React form can out-earn a roofer, medic, guard, teacher, or warehouse worker. It is not because the junior dev is tougher, and it is not because the other jobs are easy. It is because the software company can scale the result in a way most physical or public-service work cannot.

That does not make the market morally correct. It just explains why the numbers look broken.

Sources

BLS, Software Developers, Quality Assurance Analysts, and Testers

BLS, Roofers

BLS, EMTs and Paramedics

BLS, Security Guards and Gambling Surveillance Officers

BLS, High School Teachers

BLS, Construction Laborers and Helpers

BLS, Hand Laborers and Material Movers

BLS, Fatal Work Injury Rates, 2024

U.S. Army, 68W Combat Medic Specialist

Army COOL, 68W Combat Medic Specialist MOS Overview

DFAS, Military Pay Tables

Levels.fyi, Software Engineer Salary

BuiltIn, Junior Software Engineer Salary in US

ADP Research, The Rise and Fall of the Software Developer

Harvard Business School, Remote Work or More Pay

OnDeck, Revenue Per Employee Rankings

AI Policy Is Becoming the New Entry-Level Gatekeeping

Bradley Matera — Wed, 29 Apr 2026 22:37:55 +0000

AI policy is becoming a new entry-level gate.

Not because companies have mature rules. Because many do not.

They want juniors who are AI-literate, fast, current, and able to use modern tools.

They also distrust AI-assisted work, punish unclear disclosure, and often fail to explain which tools are allowed.

That contradiction creates the trap:

Use AI and risk looking dependent. Avoid AI and risk looking behind.

That is not a junior developer problem. It is a leadership problem.

Winning Artificial Intelligence GIF by Afiniti - Find & Share on GIPHY

Discover & share this Winning Artificial Intelligence GIF by Afiniti with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

The market already moved

AI is not a fringe developer tool anymore.

Stack Overflow's 2025 Developer Survey says 84% of respondents are using or planning to use AI tools in their development process. It also says 44% used AI-enabled tools to learn coding techniques or a new language. [Stack Overflow AI survey]

GitHub's Octoverse 2025 report says nearly 80% of new developers on GitHub used Copilot within their first week. [GitHub Octoverse 2025]

Microsoft's 2025 Work Trend Index describes AI agents and AI-assisted work as part of the emerging workplace model. [Microsoft Work Trend Index 2025]

OpenAI's 2025 enterprise AI report also frames coding workflows as one of the areas where frontier models are accelerating software development. [OpenAI enterprise AI report]

Sources: Stack Overflow 2025 Developer Survey, GitHub Octoverse 2025, and Handshake Class of 2026 AI economy research.

The message is obvious: AI is already in the workflow. The rules are lagging behind the tools.

The entry-level contradiction

Handshake's research on the Class of 2026 in the AI economy found that 70% of hiring leaders say AI will change entry-level role requirements. [Handshake]

Source: Handshake Class of 2026 AI economy research.

That means companies expect entry-level candidates to understand AI's role in work.

But many job descriptions still do not say:

whether AI tools are allowed
which tools are approved
whether generated code is allowed
whether AI use must be disclosed
whether candidates may use AI in take-home assignments
whether company code can be pasted into tools
whether AI is allowed for learning but not implementation

That ambiguity matters because juniors are the least powerful people in the hiring process.

Ambiguous rules usually punish the least powerful person first.

"Use AI, but not like that" is not a policy

A lot of companies have a vibe instead of a policy.

The vibe sounds like this:

We want people who use modern tools.
We value productivity.
We are exploring AI.
Do not submit AI slop.
Use common sense.
We can tell when something is generated.

That is not governance. That is a collection of future arguments.

A real policy answers operational questions:

Policy area	Clear answer needed
Approved tools	Which tools can employees use?
Data privacy	What code, logs, tickets, or customer data may be pasted?
Generated code	Is generated implementation allowed?
Learning use	Can AI explain code, docs, errors, and concepts?
Disclosure	When must AI assistance be mentioned in a PR?
Review	What extra review is required for risky code?
Interviews	Can candidates use AI during take-homes or live screens?
Enforcement	What happens when rules are unclear or violated?

Without that, companies are not evaluating judgment. They are evaluating whether candidates guessed the hidden rule.

Do not trust the output blindly

AI output should not be trusted blindly.

Stack Overflow's 2025 survey says more developers distrust AI output accuracy than trust it: 46% versus 33%. The most common frustration is that AI solutions are "almost right, but not quite." [Stack Overflow AI survey]

Source: Stack Overflow 2025 Developer Survey.

That warning matters. It does not justify lazy anti-AI rules.

It supports a verification standard:

Can the developer explain the code?
Did they test the risky behavior?
Did they compare output against docs?
Did they reject bad suggestions?
Did they disclose meaningful assistance?
Did they protect private data?

That is better than:

"No AI."

It is also better than:

"Use AI to move faster, but we will punish you if we dislike the result."

Hiring managers often do not know what they want

Many hiring managers are trying to hire for a role they have not defined.

They want:

AI-literate but not AI-dependent
junior but production-ready
independent but coachable
full-stack but cheap
fast but careful
transparent but not risky
modern but compliant with unstated policy

That is not a candidate profile. It is unresolved leadership tension.

The job description turns into a contradiction because the team has not decided what kind of developer it actually needs.

Evaluate AI use directly

Companies should stop pretending candidates are not using AI. Evaluate how they use it.

A good interview prompt could be:

Here is a small function with a bug.
You may use AI as you normally would.
When you submit the fix, include:
- what you asked
- what the tool got wrong
- what you verified
- what tests you added
- what you would want reviewed before production

That tests judgment, not theater. It also reflects how real work is increasingly done.

Bad AI use versus professional AI use

Lazy AI use	Professional AI use
Paste generated output	Own the final code
Trust confident answers	Verify against docs and tests
Hide tool use	Disclose when required
Ignore security and privacy	Use approved tools and data rules
Skip fundamentals	Use AI to strengthen fundamentals
Treat AI as authority	Treat AI as a fallible assistant

This is the distinction hiring should measure: not whether the candidate touched AI, but whether the candidate can use it without outsourcing judgment.

The learning-resource problem is real

AI is becoming the default learning layer partly because older learning paths are fragmented.

The modern junior is trying to stitch together:

official docs
old Stack Overflow answers
framework changelogs
YouTube tutorials
Discord threads
GitHub issues
blog posts
paid courses
outdated examples
internal docs if they are lucky

AI sits on top of that mess and gives a conversational way to ask:

What changed between versions?
Why does this error happen?
What should I search next?
Can you explain this code like I am new to the repo?
What test cases should I consider?

That is not a replacement for learning. It is a learning interface.

Companies that do not understand that will keep misreading AI use as laziness.

The research points back to training

The paper The Widening Gap found that generative AI can help novice programmers, but weaker learners may accept incorrect suggestions more easily. [The Widening Gap]

A 2025 systematic literature review on junior developers adopting LLMs found both positive and negative perceptions in most of the studies reviewed. [Junior developers and LLMs SLR]

That points back to training: AI literacy has to be taught, not assumed and not banned by reflex.

A policy that actually says something

A serious AI policy for junior developers could say:

Rule	Meaning
Approved tools only	Prevents data leakage and tool sprawl.
No private code in unapproved tools	Protects IP and customer data.
Disclosure for material assistance	Keeps review honest.
Tests required for generated logic	Verifies behavior.
Human review for risky domains	Auth, payments, permissions, infrastructure, data access.
AI allowed for learning	Explanation, docs, debugging, practice tasks.
Developer owns final output	No hiding behind the model.

That is not anti-AI. That is professional.

Bottom line

AI policy is now part of junior hiring. Companies can either define it clearly or keep using it as hidden gatekeeping.

The serious path is obvious:

allow learning
protect private data
require verification
inspect the work
teach the judgment
stop pretending AI is not part of the modern developer stack

Juniors do not need permission to be reckless. They need clear rules for being responsible.

If companies cannot provide those rules, they should stop calling the confusion a candidate-quality problem.

Interested in AI tooling, junior developers, and hiring? Explore #ai on DEV.

Senior Engineers Complaining About Juniors Are Missing the Point

Bradley Matera — Wed, 29 Apr 2026 22:34:40 +0000

Senior engineers love complaining about juniors.

They complain juniors do not understand fundamentals.

They complain juniors use AI too much.

They complain juniors ask basic questions.

They complain juniors cannot debug production systems.

Some of those complaints are true. They are also incomplete.

Because the same industry that complains about junior quality spent years weakening the systems that used to create it.

Teamwork GIF by Dubsado - Find & Share on GIPHY

Discover & share this Teamwork GIF by Dubsado with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Juniors are not supposed to arrive finished

A junior developer is not a discounted senior.

A junior is a developer with potential, fundamentals in progress, limited production context, and a real need for feedback.

That should not be controversial. Many companies still act like it is.

They hire a junior and expect:

independent delivery
production debugging
architectural judgment
stakeholder communication
cloud deployment
test strategy
security intuition
codebase navigation
product sense

Those are learned abilities, not personality traits.

If the company does not teach them, the company should not be shocked when the junior learns from AI, YouTube, old docs, Stack Overflow, Discord, Reddit, and trial-and-error.

The mentorship gap is not mysterious

Good junior development requires slack in the system. Somebody has to have time to teach.

Someone has to:

explain the codebase
review PRs with reasoning
answer questions without making the junior feel stupid
give scoped tasks
connect bugs to system concepts
show how production incidents are handled
explain trade-offs
model debugging
call out risk before it becomes blame

That takes time. Companies cut that time first.

Then they complain the pipeline is weak.

That is not a junior problem. It is a resource allocation problem.

Psychological safety is not office decor

The research on team learning has been clear for a long time.

Amy Edmondson's 1999 paper, Psychological Safety and Learning Behavior in Work Teams, studied 51 work teams and found psychological safety was associated with learning behavior.

Source: Psychological Safety and Learning Behavior in Work Teams.

That matters in engineering because juniors learn by taking small interpersonal risks:

"I do not understand this code."
"I think this bug is deeper than the UI."
"I used AI to understand the error, but I want to verify it."
"I do not know whether this is safe."
"Can you explain why this pattern is preferred?"

If asking those questions gets punished, juniors stop asking.

Then seniors say juniors are quiet, passive, or not curious.

That is the predictable result of a team that punishes learning out loud.

AI fills the space mentorship left open

Stack Overflow's 2025 Developer Survey says 44% of developers used AI-enabled tools to learn coding techniques or a new language. [Stack Overflow AI survey]

GitHub's Octoverse 2025 report says nearly 80% of new developers on GitHub used Copilot within their first week. [GitHub Octoverse 2025]

Sources: Stack Overflow 2025 Developer Survey and GitHub Octoverse 2025.

This is the part senior engineers need to take seriously: AI is not only being used to generate code.

It is being used because juniors need explanations and often cannot get them from people.

AI answers:

What is this error?
What does this SQL join do?
Why is this React state stale?
What is a race condition?
How do I write a test for this?
What should I ask in code review?
What edge cases might I be missing?

That does not make AI a mentor. It makes AI the thing juniors reach for when the actual mentor is unavailable.

The old learning culture had shortcuts too

It is dishonest to act like older developers learned only through deep first-principles study.

Previous generations used:

Stack Overflow answers
snippets from blogs
copied config files
starter templates
WordPress themes
Bootstrap examples
jQuery plugins
internal code copied from older services
tutorials that skipped production concerns

Some developers learned deeply through those shortcuts. Some cargo-culted them.

That same distinction matters with AI.

The question is not:

Did the junior use outside help?

The question is:

Did the junior build understanding?

Review the thinking, not just the diff

A senior who wants better juniors should stop reviewing only the final diff. Review the thinking.

Ask:

Review question	What it teaches
What problem is this solving?	Product framing.
What did you try first?	Debugging process.
What did AI suggest that you rejected?	Judgment.
What edge case worries you?	Risk awareness.
What test proves this behavior?	Verification.
What part of this system do you still not understand?	Learning path.

That is how review becomes mentorship.

Without that, review becomes a gate. Gates do not create seniors. Mentorship does.

AI dependence is a real risk

There is a real danger in AI-assisted learning.

The paper The Widening Gap found that generative AI can help novice programmers, but weaker students may struggle more to ignore incorrect or unhelpful suggestions. [The Widening Gap]

A 2025 systematic review on GenAI and code comprehension found that AI explanations can support comprehension, but can also be inaccurate or difficult for novices to evaluate. [Code comprehension SLR]

That means teams should not tell juniors:

"Just use AI."

They should teach:

how to verify generated output
how to compare against docs
how to write tests
how to reject confident wrong answers
how to disclose meaningful AI assistance
when to ask a human

That is modern mentorship. Not nostalgia. Not tool panic.

The management failure nobody wants to own

Many companies removed the apprenticeship layer and replaced it with vibes.

They have:

no onboarding map
no junior-safe backlog
no mentor capacity
no documentation budget
no pairing culture
no AI policy
no explicit progression rubric
no time for seniors to teach

Then they ask:

"Why are juniors not ready?"

Because nobody built readiness. That is the answer.

What a real junior pipeline looks like

A serious junior pipeline does not need to be fancy. It needs to be intentional.

Timeframe	What should happen
Week 1	Environment setup, product overview, first docs fix, mentor assigned.
Month 1	Small bug fixes, guided PRs, test-writing practice, codebase map.
Month 2	Slightly larger feature work with review checkpoints.
Month 3	Limited ownership of a small surface area.
Month 6	Participation in production support with shadowing.
Month 12	Clear evaluation for mid-level readiness.

That is not charity. That is workforce development.

Source: Author framework for staged junior onboarding.

Bottom line

Senior engineers are allowed to expect rigor. They are not allowed to pretend rigor appears without teaching.

If juniors use AI badly, correct the behavior.

If juniors use AI to learn, review the learning.

If juniors cannot explain their code, teach them how to explain it.

But stop acting like the new generation failed a system that the old generation forgot to maintain.

The next senior engineers will not appear by accident. Somebody has to build them.

Interested in mentorship, junior developers, and engineering culture? Explore #career on DEV.

Entry-Level Job Descriptions Are Becoming Broken Product Specs

Bradley Matera — Wed, 29 Apr 2026 22:33:15 +0000

A lot of "entry-level developer" job descriptions are not entry-level.

They are broken product specs.

They ask for one person to build frontend features, debug backend APIs, write SQL, manage cloud infrastructure, understand CI/CD, test everything, talk to stakeholders, support production, know security basics, and somehow still be "junior."

That is not an entry-level role.

That is a company trying to buy a small engineering team at junior pricing.

Animation Hiring GIF by Biteable - Find & Share on GIPHY

Discover & share this Animation Hiring GIF by Biteable with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

The market is saying two things at once

The long-term outlook for software developers is still strong.

The U.S. Bureau of Labor Statistics projects software developer employment to grow 15.8% from 2024 to 2034, adding 267,700 jobs. [BLS projections]

Source: BLS employment projections.

But the entry point is getting narrower.

Indeed Hiring Lab reported that from Q2 2022 to Q2 2025, the share of tech job postings asking for at least five years of experience rose from 37% to 42%. The report specifically notes that the environment became more challenging for entry-level and early-career tech job seekers. [Indeed Hiring Lab]

Source: Indeed Hiring Lab.

That creates a broken labor-market shape:

software work is projected to grow
companies still need engineers
job postings increasingly favor experienced candidates
juniors are told to "get experience" before anyone will give them experience

That is not just a candidate-quality problem. It is a pipeline design problem.

The imaginary junior candidate

Here is a common bad hiring pattern:

Requirement	Why it is a red flag for "junior"
3-5 years of production experience	That is not entry-level.
React, Node, Python, SQL, AWS, Docker, Kubernetes	That is a platform surface, not a junior scope.
Own features end to end	Ownership requires support and context.
Build and maintain CI/CD	That is DevOps/platform work.
Understand security best practices	Reasonable as learning goal, unrealistic as solo owner.
Work independently from day one	That means the company does not plan to mentor.
Excellent UI/UX instincts	That is a design skill, not automatically a dev skill.
Support production incidents	Fine with backup, reckless without it.

There is nothing wrong with wanting broad engineers.

There is something wrong with calling that role "entry-level" while refusing to say what the company will teach.

Source: Illustrative role-scope comparison based on the job-description pattern discussed in this article, not a market-wide statistic.

Skills-based hiring can still be lazy

NACE's Job Outlook 2026 data shows employer use of skills-based hiring is growing for entry-level roles. [NACE]

In theory, that is good. Skills-based hiring can reduce overreliance on degrees, school prestige, and GPA filters.

But in practice, it can become a new version of the same problem:

"Show us evidence you already performed the job we refuse to train you for."

A portfolio project is useful.

A take-home project can be useful.

A technical screen can be useful.

But none of those prove a junior can safely own ambiguous production work without mentorship.

They prove the candidate can complete an assessment under artificial constraints.

Companies confuse those things constantly.

AI is now another requirement

Handshake's research on the Class of 2026 in the AI economy found that 70% of hiring leaders say AI will change entry-level role requirements. [Handshake]

Source: Handshake Class of 2026 AI economy research.

That is probably true. It also raises the question companies keep dodging:

Are companies teaching AI-assisted engineering, or are they just adding AI to the list of things juniors are supposed to magically know?

The industry already expects juniors to understand:

Git
testing
APIs
databases
frontend frameworks
deployment basics
security basics
agile workflow
product communication

Now add:

prompt literacy
AI code review
tool privacy
generated-code risk
model limitations
agent workflows
AI policy compliance

That is a real skill stack. It needs training.

Older developers used shortcuts too

Older developers often criticize juniors for using AI as if previous generations learned from pure fundamentals alone.

That is not what happened.

Previous generations learned through:

Stack Overflow answers
blog snippets
jQuery plugins
Bootstrap templates
WordPress themes
forum posts
copied config files
outdated but useful tutorials
internal code copied from another service

The issue was never "did the developer use outside help?"

The issue was whether the developer understood the code before shipping it.

That is still the standard.

Smart AI use is not laziness

Stack Overflow's 2025 survey says 84% of respondents are using or planning to use AI tools, and 44% used AI-enabled tools to learn coding techniques or a new language. [Stack Overflow AI survey]

GitHub's Octoverse 2025 report says nearly 80% of new developers on GitHub used Copilot within their first week. [GitHub Octoverse 2025]

Sources: Stack Overflow 2025 Developer Survey and GitHub Octoverse 2025.

That is the world juniors are entering. Pretending otherwise is not discipline. It is denial.

Lazy AI use looks like this:

paste the output
do not read it
do not test it
do not understand failure cases
hide the tool use
ship confidence without comprehension

Smart AI-assisted learning looks like this:

ask for explanation
compare with official docs
generate test cases
inspect edge cases
rewrite in project style
document assumptions
ask a human for review where risk is high

The first one deserves criticism. The second one deserves coaching.

A real junior role has a smaller blast radius

If companies want juniors to succeed, the job description should identify the first 90 days.

Example of a bad junior scope:

Own the customer dashboard end-to-end across React, Node, PostgreSQL, AWS, CI/CD, analytics tracking, and production support.

Example of a better junior scope:

In the first 90 days, ship small product fixes in the React dashboard, write tests for touched behavior, pair on API changes, and learn the deployment process with a mentor before joining the support rotation.

That second version is still real work. It just does not pretend the junior is a full product team.

What the job post should actually say

Section	What it should say
Required skills	The minimum needed on day one.
Teachable skills	What the company expects to train.
First 30 days	Onboarding, repo setup, first small fixes.
First 90 days	Expected independent scope.
Mentorship	Who reviews work and how often.
AI policy	Approved tools, disclosure rules, privacy limits.
Support expectations	Whether production support is shadowed or owned.
Evaluation	How the junior will be judged.

That is not extra paperwork. It is basic hiring clarity.

Source: Author framework for staged junior onboarding.

The leadership mistake

Many leadership teams do not know whether they want:

an apprentice
a junior developer
a mid-level developer
a full-stack generalist
a platform engineer
a cheap senior
a product engineer
a support engineer who can code

So they write all of it into one job description, then complain about the candidate pool.

That is backwards. Bad requirements create bad hiring signals.

If the role is confused, the hiring process will be confused.

If the hiring process is confused, the team will reject good juniors for not being imaginary candidates.

AI does not magically fix the gap

AI does not fix this.

It can even make the gap worse.

The paper The Widening Gap found that generative AI can help novice programmers, but it can also widen differences between learners who can evaluate suggestions and learners who accept bad output too easily. [The Widening Gap]

A 2025 systematic literature review on junior developers and LLMs found that most studies report both positive and negative perceptions of LLM adoption. [Junior developers and LLMs SLR]

That means AI can help juniors climb. It can also hide weak understanding.

The difference is not moral character. The difference is training, review, and feedback.

Bottom line

Entry-level hiring is broken when the job description asks for a junior title, a mid-level skillset, a senior ownership model, and no mentorship plan.

Companies can keep blaming juniors.

Or they can write honest roles.

If a company wants junior talent, it has to define what the junior is expected to know, what the company will teach, and how AI-assisted learning will be reviewed.

Anything else is just a broken product spec disguised as hiring.

Interested in hiring, junior developers, and tech careers? Explore #hiring on DEV.

Companies Say There Are No Good Juniors. They Mean They Stopped Training Them"

Bradley Matera — Wed, 29 Apr 2026 22:23:55 +0000

Tech has a lazy line it keeps repeating:

"There are no good junior developers anymore."

It sounds like a talent diagnosis.

It is usually a management confession.

The industry spent years cutting apprenticeships, thinning mentorship, compressing onboarding, outsourcing training to bootcamps and universities, and turning entry-level job descriptions into mid-level wish lists.

Now the same companies look at juniors using AI to learn and act shocked.

That is not serious.

AI did not create the junior developer problem. It exposed it.

Team Teamwork GIF by ClickUp - Find & Share on GIPHY

Discover & share this Team Teamwork GIF by ClickUp with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

The pipeline is the problem

Software is not a dying field.

The U.S. Bureau of Labor Statistics projects employment for software developers to grow 15.8% from 2024 to 2034, adding 267,700 jobs. That is over five times faster than the all-occupation average in the same projection set. [BLS projections]

Source: BLS employment projections.

So no, the simple story is not "software is over."

The problem is the pipeline.

Companies still need software. They still need engineers. They still need future senior people.

But many of them do not want to pay the cost of producing those senior people.

They want developers who are:

cheap enough to call junior
experienced enough to ship like mid-levels
broad enough to cover full-stack work
mature enough to self-manage
fast enough to justify headcount
compliant enough not to challenge broken scope

That is not a junior role.

That is a budget fantasy.

The bar moved up

The hiring market has been tightening around experience.

Indeed Hiring Lab reported that between Q2 2022 and Q2 2025, the share of tech postings asking for at least five years of experience rose from 37% to 42%, while early-career candidates faced a harder environment after the tech posting decline. [Indeed Hiring Lab]

Source: Indeed Hiring Lab.

NACE's Job Outlook 2026 data shows employers are increasing skills-based hiring for entry-level roles. That sounds good until you remember that "skills-based" can mean "prove you already did the job somewhere else." [NACE skills-based hiring]

Handshake's research on the Class of 2026 in the AI economy found that 70% of hiring leaders say AI will change entry-level role requirements. [Handshake]

Source: Handshake Class of 2026 AI economy research.

That is the entry-level contradiction in plain English:

Company says	Company often means
"We want entry-level talent"	We want someone already productive.
"We hire for skills"	We want proof you have done production work.
"AI is changing the role"	We have not rewritten onboarding yet.
"There are no good juniors"	We stopped building junior pipelines.
"We need ownership"	We want low-management headcount.

That is not a junior failure. It is hiring design failure.

The old learning web is not enough anymore

Older developers sometimes talk as if they learned in a cleaner era.

They did not.

They copied Stack Overflow answers. They pasted snippets from blogs. They modified WordPress themes. They followed YouTube tutorials. They used Bootstrap examples. They dropped in jQuery plugins. They learned from forums, old repos, templates, docs, and trial by fire.

Some of that learning was deep.

Some of it was shallow.

That was always true.

The difference now is that the old web is weaker as the main learning layer.

Search results are noisier. Framework churn is faster. Tutorials age badly. Many of the most visible beginner resources for older tools are years old, while modern production expectations include testing, deployment, observability, security, accessibility, cloud platforms, CI/CD, API design, analytics, and AI tooling.

The industry raised the floor while weakening the ladder.

AI filled the hole

Stack Overflow's 2025 Developer Survey says 84% of respondents are using or planning to use AI tools, up from 76% the year before. It also says 44% used AI-enabled tools to learn coding techniques or a new language. [Stack Overflow AI survey] [Stack Overflow press release]

Source: Stack Overflow 2025 Developer Survey and Stack Overflow 2025 press release.

GitHub's Octoverse 2025 report says nearly 80% of new developers on GitHub used GitHub Copilot within their first week. [GitHub Octoverse 2025]

Sources: Stack Overflow 2025 Developer Survey and GitHub Octoverse 2025.

That is not a weird side habit anymore. That is part of the learning surface.

AI helps juniors:

explain unfamiliar code
generate practice tasks
translate documentation into plain English
compare implementation options
debug error messages
create test cases
rehearse interviews
review resumes
understand unfamiliar libraries

None of that means the junior understands automatically.

But it does mean AI is covering work teams used to handle through mentorship, pairing, code review, and onboarding.

The catch: AI is wrong a lot

The answer is not "AI good, juniors right, seniors bad."

That would be cheap.

AI output is often wrong.

Stack Overflow's 2025 survey says more developers distrust AI output accuracy than trust it: 46% distrust versus 33% trust. The biggest frustration is that answers are "almost right, but not quite," cited by 66% of respondents. [Stack Overflow AI survey]

Source: Stack Overflow 2025 Developer Survey.

That is why juniors need training, not shame.

The strongest junior AI workflow is not:

"Generate the code and ship it."

It is:

"Use AI to understand the problem, then verify the answer with docs, tests, code review, and actual system behavior."

Those are not the same workflow.

The research is not a slogan

The education research does not support a simple anti-AI panic.

It supports a more serious claim: AI helps some learners and hurts others depending on how they use it.

The 2024 paper The Widening Gap: The Benefits and Harms of Generative AI for Novice Programmers observed 21 novice programming lab sessions. The researchers found that GenAI could help students complete tasks, but weaker students were more vulnerable to accepting incorrect or unhelpful suggestions. [The Widening Gap]

A 2025 systematic review on junior developers adopting LLMs found both positive and negative perceptions across most of the literature it reviewed. [Junior developers and LLMs SLR]

A 2025 review on GenAI and code comprehension found that generated explanations can support learning, but can also be inaccurate, unclear, or hard for novices to evaluate. [Code comprehension SLR]

That is not an argument for banning AI. It is an argument for teaching AI literacy as part of engineering literacy.

This is leadership work

If a company hires juniors with no plan to teach them, it is not running a junior program. It is gambling.

A real junior program needs:

scoped work
named mentors
clear review standards
onboarding tasks tied to production concepts
time for questions
code review that teaches reasoning
documentation that is not tribal memory
a path from small fixes to system ownership
explicit AI usage rules

Most companies do not need a 12-month academy.

They do need to stop pretending a junior becomes production-ready by osmosis while seniors are booked 110% and managers ask for "ownership" on week two.

Ask better questions

Stop asking:

"Why are juniors worse now?"

Ask:

Better question	Why it matters
What do we expect a junior to know on day one?	Prevents hidden mid-level expectations.
What do we teach in the first 90 days?	Turns hiring into development.
Who reviews their work and how?	Creates accountability for mentorship.
Which tasks are junior-safe but still real?	Avoids fake work and impossible work.
What AI use is allowed?	Prevents inconsistent punishment.
How do we test understanding?	Separates learning from blind copying.

That is how companies get better juniors. Complaining on LinkedIn is not a training plan.

Bottom line

There are juniors. There are motivated graduates. There are self-taught developers doing the work.

Many of them use AI because the modern learning stack is fragmented, outdated, noisy, and incomplete without it.

The shortage is not curiosity. The shortage is serious training.

If companies want senior engineers in five years, they need to build juniors now.

If they refuse, they should stop blaming the generation that showed up after the ladder was already pulled up.

Interested in junior developer hiring, AI, and tech careers? Explore #career on DEV.

The Orphaned ID Bug from My First Job (And What It Taught Me About Being a Junior Dev)

Bradley Matera — Tue, 28 Apr 2026 05:20:55 +0000

About two weeks into my first web-dev job, I had a Trello card that said the LMS was sometimes leaving orphaned IDs behind when assigned trainings were finished or deleted.

The app was a corporate LMS for a global manufacturer that made machine protection, chip and coolant management systems, and facility safety products.

This was not a small internal team tool. It was the training system for the whole company, and they wanted every training assignment for anyone to go through this broken LMS.

The frontend was simple: jQuery dialogs, table rows, and AJAX calls.

The bug was not a dramatic React failure. It was a row-based edge case in a table view.

Sometimes the AJAX response would arrive and the data would be missing. Sometimes the table would render, but an empty row would appear where an assignment should have been.

That was enough for the card to hit the board and for me to start investigating.

Why the bug was more than a blank row

At first, it was easy to dismiss this as a rendering issue.

Maybe the list component was failing to fill the template. Maybe the CSS was swallowing the text. Maybe the client was accidentally rendering an empty object.

Then I opened the network tab.

The API was returning assignment objects. Some of them had training_id, some of them had completed_at, and some of them had fields set to null or undefined.

The client never filtered those out. It rendered every row it received.

That meant the bug was not just on the page. It was in the data the page was given.

What I was told

When I asked my senior for more context, the answer was basically, “Figure it out without AI.”

That line was a punch in the face, because this was the same team that had told me they liked that I understood AI. The same team that had hired me after I talked about how I used free tools to speed up small fixes and keep my commits focused.

I was not being asked to build a feature. I was being asked to debug a failure in a system I did not own.

I was not given:

the schema for assigned_trainings
the intended lifecycle of a completed assignment
whether deletes were supposed to cascade
whether completed_trainings was supposed to be a source of truth

I was only given the symptom and an expectation.

That is a very common junior-dev situation: the problem is clear, but the contract is not.

It got worse after I was fired.

The official reason was that I used AI too much. I had spent one month on the job, made forty small commits, and the only real problem I had found was one that was creating blank rows in the UI.

The contradiction stung. They paid for the work, accepted the fixes, and then told me they did not want my process. It left me angry, confused, and more than a little ashamed.

That was the context I brought to the bug: a team that liked the results but disliked the tool, a junior dev who felt stuck between expectations and execution.

Following the data trail like a junior detective

Once I stopped looking at the UI and started looking at the database, the problem became more concrete.

The symptoms were:

blank rows appeared after delete or completion
the user record still existed
the training record still existed in some form
the list view did not know which rows were stale

In plain English: the UI was still receiving references to assignments that had lost their parent record.

That usually means one of two things:

the database is missing a foreign key constraint, or
code that cleans up stale assignments is not running consistently.

I began checking the tables in the order the app was likely using them:

assigned_trainings
completed_trainings
users
trainings

I was looking for rows that should have been gone but were still visible.

The SQL I wrote to prove the orphan

I did not have a polished schema diagram. I had a terminal and a query editor.

The first query I used was a simple orphan finder.

SELECT a.id,
       a.user_id,
       a.training_id,
       a.assigned_at,
       c.id AS completed_id
FROM assigned_trainings a
LEFT JOIN completed_trainings c
  ON a.user_id = c.user_id
  AND a.training_id = c.training_id
WHERE c.id IS NULL;

That returned assignment rows that had no matching completion row.

Then I extended it to catch assignments that referenced missing training metadata.

SELECT a.id,
       a.user_id,
       a.training_id,
       t.title AS training_title
FROM assigned_trainings a
LEFT JOIN trainings t ON a.training_id = t.id
WHERE t.id IS NULL;

Those queries were not meant to be elegant. They were meant to answer one question:

Is there data in the system that should not still be shown?

The answer was yes.

Why the SQL mattered more than the frontend

This bug was not a broken component. It was stale data flowing through the app.

The frontend code was basically doing this:

fetch assignment rows
render each row
assume each row was valid

It was not validating status, it was not filtering by deleted_at, and it was not checking whether the associated training still existed.

That made the UI brittle.

So I shifted the fix to the place where the contract belonged: the database.

The cleanup fix I shipped

I did not have enough confidence to rewrite the whole lifecycle.

What I had enough confidence to do was this:

Identify stale assignment rows with SQL
Delete them in a controlled cleanup operation
Confirm the UI stopped showing blank rows

The frontend trigger was tiny:

$.post('/cleanup-orphans', {}, function(response) {
  console.log('deleted orphans', response.deletedCount);
});

The backend controller looked like this in rough form:

app.post('/cleanup-orphans', async (req, res) => {
  const orphanIds = await db.query(`
    SELECT a.id
    FROM assigned_trainings a
    LEFT JOIN completed_trainings c
      ON a.user_id = c.user_id
      AND a.training_id = c.training_id
    WHERE c.id IS NULL
  `);

  const deleted = await db.query(
    'DELETE FROM assigned_trainings WHERE id = ANY($1)',
    [orphanIds.rows.map(row => row.id)]
  );

  res.json({ deletedCount: deleted.rowCount });
});

I also added a small log statement so I could see the number of deleted rows in the server output.

This was not a permanent fix.

It was a controlled cleanup that removed the broken rows and let the UI go back to behaving.

What this taught me about junior work

There are two kinds of fixes in a codebase like that:

quick patches that make the symptoms disappear
deeper fixes that make the system enforce the invariant

A junior developer is often asked to deliver the first one while learning the second.

This bug mattered because it exposed a gap in the system’s contract.

The frontend expected valid assignment rows. The database did not guarantee them.

Until that was fixed, the app was fragile.

It also mattered because I was not just fixing a bug for a product. I was fixing a bug while trying to prove that I belonged in that role.

After the firing, the problem became more than technical. It became personal.

I was unemployed again. I had a recruiter apologizing on the phone. I had a wife and kids depending on me. I felt worthless for a day, then angry, then confused.

That is what made the lack of guidance especially painful. I was being measured on results, but I was not given the information that would have led to a better result.

What I wish someone had said

If my senior had said any of the following, the work would have been clearer:

“This looks like a data integrity problem, not a UI bug.”
“We need to know whether assignment rows should be deleted, archived, or left as history.”
“Check if the assigned_trainings table has a foreign key on user_id.”
“Find out whether completed_trainings is the source of truth.”

Instead I got, “Figure it out.”

That is a useful outcome sometimes, but it is not a substitute for explaining the problem domain.

What I learned

Blank rows are usually a data problem, not a render problem.
The UI can only show what it receives.
A query is a debugger.
SQL is a powerful way to prove whether the data actually exists.
CRUD is not enough without constraints.
Adding a row is easy. Making sure it is still valid later is the hard part.
Ask for the contract.
If you are told to fix something, ask what the data model is supposed to guarantee.
Patches are not the same as system fixes.
A cleanup endpoint can make the app behave, but the real fix is enforcing the invariant at the source.

If I did the bug again today

I would still start with the same questions:

What exactly should a completed assignment look like?
Which table is the source of truth for assignment status?
Should deletes remove the row, or should the row stay marked as completed?

I would also look for missing constraints and missing cleanup paths.

In a better design, the database can help.

For example:

ALTER TABLE assigned_trainings
ADD CONSTRAINT fk_user
FOREIGN KEY (user_id)
REFERENCES users(user_id)
ON DELETE CASCADE;

That would cause the database to delete assignments automatically when the user is deleted.

But even that is not always the right answer.

If the business needs a record of completed training for audits, a history row is the right fix, not a cascade delete.

That is why the first job of a debugging session is always: ask what the data should mean.

Final takeaways

This story is not about one query or one jQuery call.

It is about the way junior developer work often happens:

you are handed a symptom
you are expected to turn it into a fix
you may not be told what the system is supposed to enforce

I fixed this bug with SQL, with a cleanup endpoint, and with enough caution to avoid deleting something live.

It was not the perfect design.

It was the right fix for the moment.

The bigger lesson was not the query itself. It was how much the work depended on context.

If I had been told whether this was supposed to be a one-time cleanup or a permanent contract, the answer could have looked very different.

The code I wrote was useful. The team knowledge I did not get was the thing that would have made it better.

If you are a junior dev, learn to ask for the data contract.

If you are a senior dev, help the junior dev understand whether the fix is temporary or permanent.

If you are a team, document your schema and your data assumptions before the blank rows appear.

That is what separates a band-aid from a reliable system.

This story is not just about a blank row in an LMS. It is about how much more fragile a junior engineer feels when the rules keep changing.

A team can survive one fired junior dev if the work is real and the feedback is honest. It becomes a different problem when the team refuses to say what the contract is.

Want other junior dev stories? Explore #junior-dev on DEV.

Testing Bifrost CLI and Code Mode: What Worked, What Broke, and What I Verified

Bradley Matera — Mon, 27 Apr 2026 04:40:01 +0000

Bifrost Quick Start

Bifrost Features

‹ ›

I spend a lot of time wiring AI coding tools together: VS Code, Copilot, Claude Code, Codex-style flows, local agents, and MCP servers.

The problem is not the model anymore. It is the plumbing.

Every new provider needs a key. Every MCP server adds another tool catalog. Every tool adds schema, API shapes, and prompt context.

That is where Bifrost caught my attention.

Bifrost is an open-source gateway from Maxim AI. It is not meant to replace models or agents. It is meant to sit between them and make the whole system easier to inspect and control.

This test had a simple goal: start the gateway, route real model traffic through it, attach a filesystem MCP server, enable Code Mode, and see whether a coding agent could actually work through that stack.

I also wanted practical answers:

Which key did this agent use?
Which model did it call?
Which tools could it reach?
What did the run cost?
Where could I inspect the logs?

That is the thread through this post. It is not a marketing summary. It is a field test of the local gateway, the CLI, provider routing, MCP setup, Code Mode, and a real coding-agent launch.

Repository:

maximhq / bifrost

Fastest enterprise AI gateway (50x faster than LiteLLM) with adaptive load balancer, cluster mode, guardrails, 1000+ models support & <100 µs overhead at 5k RPS.

Bifrost AI Gateway

The fastest way to build AI applications that never go down

Bifrost is a high-performance AI gateway that unifies access to 23+ providers (OpenAI, Anthropic, AWS Bedrock, Google Vertex, and more) through a single OpenAI-compatible API. Deploy in seconds with zero configuration and get automatic failover, load balancing, semantic caching, and enterprise-grade features.

Quick Start

Go from zero to production-ready AI gateway in under a minute.

Step 1: Start Bifrost Gateway

# Install and run locally
npx -y @maximhq/bifrost

# Or use Docker
docker run -p 8080:8080 maximhq/bifrost

Step 2: Configure via Web UI

# Open the built-in web interface
open http://localhost:8080

Step 3: Make your first API call

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "Hello, Bifrost!"}]
  }'

That's it! Your AI gateway is running with a web interface for visual configuration…

View on GitHub

Official setup docs:

Open the official Bifrost gateway setup guide.

What I was actually testing

MCP is useful because it gives AI agents a standard way to call tools. Those tools can be filesystem access, search, databases, internal APIs, browser automation, or anything else exposed through an MCP server.

That sounds good until your tool list gets large.

Classic MCP can put a big tool catalog into the model's context. With a few servers that is okay. With many servers, the model spends tokens just reading what tools exist.

That is the problem I want to avoid.

I do not want my coding agent spending context on every possible tool every time. I want it to discover what it needs and keep the prompt smaller.

Bifrost's Code Mode is designed for that issue.

So the question was not "does Bifrost look useful?" The question was:

Can I install it, wire it into a real project, and see the tool-control layer work end to end?

Why the Bifrost CLI matters

The gateway routes providers. The CLI is what makes the setup usable for coding agents.

I wanted to avoid hand-editing agent config every time I switched models or providers.

The workflow I tested was:

launch the gateway
run bifrost-cli
pick a harness
pick a model
launch the agent

The CLI stores state under ~/.bifrost/, including gateway URL, selected model, and harness.

That matters because it keeps the gateway and agent shared in one place instead of every agent maintaining a separate, brittle config.

Supported harnesses in the docs included:

Claude Code
Codex CLI
Gemini CLI
Opencode

Installation and integration

I tested both ways to run the gateway.

Local NPX

npx -y @maximhq/bifrost

Docker

docker run -p 8080:8080 -v $(pwd)/data:/app/data maximhq/bifrost

That gives you a dashboard at:

http://localhost:8080

I always start there. If the dashboard does not respond, nothing else matters.

First smoke test

curl http://localhost:8080

Once the gateway was up, the next step was provider setup, MCP setup, and CLI testing.

First model request

A basic OpenAI-compatible request looks like this:

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      { "role": "user", "content": "Hello, Bifrost!" }
    ]
  }'

I did not use RunKit here because RunKit cannot reach localhost:8080.

Add an MCP client and enable Code Mode

The Bifrost path is:

Dashboard → MCP Gateway → add client → choose STDIO, HTTP, or SSE → configure command or URL → choose tool permissions

For this test, I used a STDIO filesystem MCP server scoped to the donotpush draft folder.

That scope matters. A gateway should not become an excuse to give every agent access to the whole machine.

Once the MCP client exists, Code Mode can be enabled for that client. When Code Mode is on, the model does not get the full tool catalog directly. It gets four meta-tools first, then inspects and executes only what it needs.

Where Code Mode fits in

This was the part I cared about most.

Classic MCP can work fine. It can also force the model to carry a lot of extra tool metadata.

Code Mode is meant to change that.

Bifrost exposes these four meta-tools:

listToolFiles
readToolFile
getToolDocs
executeToolCode

That means the model can ask:

what tool files are available?
what is in this stub?
what are the docs for this tool?
execute this code against the tool binding

The idea is to give the model an index instead of a giant binder.

Why Code Mode exists

The problem is context bloat. In a small MCP setup, every tool definition may be fine. In a larger setup, it becomes waste.

Bifrost's docs use an example with five MCP servers and around 100 tools. In the classic flow, the model carries that catalog across multiple turns. In Code Mode, it carries only four meta-tools and then loads the specific stubs it needs.

This is why Code Mode uses code instead of a long chain of individual tool calls. The model can orchestrate the workflow in a constrained Starlark interpreter, and intermediate results do not have to get pushed back through the model.

Performance and cost claims

Bifrost's docs claim that for about 100 tools across five MCP servers, Code Mode can cut the interaction shape from six LLM turns with a full catalog to three or four turns with about 50 tool-definition tokens.

Their published benchmark goes further: 55.7% lower estimated cost with 96 tools, 83.4% with 251 tools, and 92.2% with 508 tools.

Those are vendor claims. I am including them here because they explain why the feature is worth testing, not because my one-server filesystem test reproduced them.

When I would enable it

My rule of thumb after this pass:

keep classic MCP for one or two small servers
enable Code Mode when you have three or more MCP servers
enable it for heavier servers like filesystem, search, docs, databases, CRM, or internal APIs
use tool-level binding when one server has many tools or big schemas
keep the allowed tool list tight either way

How it works

Code Mode exposes MCP tools as virtual .pyi stub files. There are two binding levels:

server-level binding: one stub file per MCP server
tool-level binding: one stub file per tool

Server-level binding is simpler when a server has a small tool set. Tool-level binding is better when a server has many tools or large schemas.

The code runs in Starlark, a deterministic Python-like runtime. Bifrost's docs describe it as intentionally constrained: no imports, no file I/O, no network access, just allowed tool calls and basic Python-like logic. That constraint is what makes Code Mode interesting for agent workflows.

"Classic MCP vs Code Mode in plain English"
Classic MCP is like handing someone a giant binder full of every tool manual before every task.

Code Mode is more like giving them a small index first. They look up the exact tool they need, read only that tool's instructions, then run the task.

That matters when the number of tools grows.

Why that matters for coding agents

Coding agents already use a lot of context.

They read files, inspect diffs, look at errors, review stack traces, and sometimes pull in project history. If they also carry every connected MCP tool definition on every request, the context gets noisy fast.

That can hurt:

cost
latency
tool selection
reliability
debugging

For small setups, this may not matter. If you only have one or two MCP servers with a few tools, classic MCP can be fine.

But once you start connecting heavier tools, Code Mode makes more sense.

That is why I tested the flow directly instead of only repeating the docs.

What I tested

My test setup used the tools I actually work with:

VS Code
Bifrost gateway
Bifrost CLI
Codex CLI and OpenCode
one filesystem MCP server
a real local project

The test needed to answer one practical question: can the gateway sit between the agent, the provider, and the MCP server without turning the workflow into a black box?

The flow looked like this:

Start Bifrost gateway
↓
Open Bifrost dashboard
↓
Configure provider
↓
Start Bifrost CLI
↓
Launch coding agent through Bifrost
↓
Run a small repo task
↓
Compare classic MCP flow vs Code Mode flow

The task was intentionally small. I did not want a fake benchmark. I wanted enough proof to answer this:

Can I route a coding agent through Bifrost, expose MCP tools, turn on Code Mode, and see the control layer working?

Everything after this point is evidence for that question.

The small agent task

For the coding-agent check, I used a deliberately small prompt:

Do not edit files. Reply with exactly: opencode through bifrost ok

That prompt is boring on purpose. It does not prove the agent can solve every repo task. It proves the path: agent starts, uses the configured Bifrost provider, calls the model through the gateway, and returns a response.

Then I split the MCP behavior into two questions:

Classic MCP:
- Did the model see the direct filesystem tools?
- Did it produce a normal MCP tool call?
- Could I execute that tool call through Bifrost?

Code Mode:
- Could I enable Code Mode on the MCP client?
- Did the four meta-tools work?
- Could executeToolCode call the underlying filesystem server?

What I am not claiming

This is not a benchmark.

Bifrost publishes token-savings numbers for Code Mode. My test did not try to reproduce those claims.

I only used one filesystem MCP server. With one server, there is not enough tool sprawl to make a serious token-savings claim. The useful result is narrower:

gateway
provider route
local Ollama
Ollama cloud
MCP server
Code Mode meta-tools
coding agent

That is the difference between "I read the docs" and "I ran the workflow."

What I measured

I also have Ollama installed locally, with both local models and Ollama cloud variants available. That let me test:

local Ollama model routing
Ollama cloud model routing
Bifrost provider behavior
MCP tool discovery
Code Mode meta-tool behavior
one coding-agent launch through Bifrost

Here is the checklist from the hands-on pass:

Install/setup:
- [x] NPX start cleanly
- [x] Docker start cleanly
- [x] Dashboard available at localhost:8080
- [x] Provider setup persists
- [x] OpenAI config bootstrap tested
- [ ] OpenAI provider request blocked by missing OPENAI_API_KEY

CLI:
- [x] Bifrost CLI detects the gateway
- [x] Bifrost CLI asks for the expected config
- [x] Bifrost CLI shows Codex CLI as installed
- [x] Bifrost CLI lets me set the gateway URL and model
- [x] Config is stored in ~/.bifrost/config.json and ~/.bifrost/state.json
- [x] Bifrost CLI launches Codex CLI
- [x] Bifrost CLI prints the MCP server URL for Codex CLI
- [x] Codex CLI launch works
- [ ] Codex CLI request blocked because current Codex expects Responses API for this route

MCP:
- [x] Add at least one MCP server
- [x] Gateway can see the tools
- [x] Model can produce a classic MCP tool call
- [x] Classic MCP tool call works
- [x] Enable Code Mode
- [x] Code Mode exposes the four meta-tools
- [x] Run the same "list allowed directories" task with classic MCP and Code Mode
- [x] Route local Ollama models through Bifrost
- [x] Route Ollama cloud models through Bifrost

Agent workflow:
- [x] Complete a minimal coding-agent request through Bifrost with OpenCode
- [x] Keep the response understandable
- [x] Confirm tool-governed filesystem access through MCP
- [ ] OpenAI-vs-Ollama provider fallback blocked by missing OpenAI key
- [out of scope] Prove token savings with a large multi-server setup

Cost/context:
- [out of scope] Fewer tokens used in a realistic multi-server setup
- [x] Latency is acceptable for small local tests
- [x] Workflow is inspectable from one gateway dashboard

This is the evidence I care about more than a marketing number: what launched, what routed, what exposed tools, what returned output, and what failed.

The unresolved items were clear: OpenAI fallback needs a real key, Codex needs a Responses-compatible route, and a larger multi-server setup is required for any real token-savings claim.

Hands-on results

The first thing I verified was the gateway.

I started the local gateway and confirmed http://127.0.0.1:8080 was alive.

The dashboard loaded cleanly.

That dashboard is useful because it gives a second source of truth. It shows request volume, token usage, model usage, latency, cache state, and cost.

And the panels were meaningful for this test.

With that working, I moved to provider wiring.

The Bifrost CLI defaulted to Codex CLI. I chose openai-ollama2/gpt-oss:20b-cloud after confirming the custom provider could route Ollama cloud requests.

On disk, the CLI state was exactly where I expected:

~/.bifrost/config.json pointed at http://localhost:8080
~/.bifrost/state.json stored the selected harness and model
./bifrost-data/config.db had the usual config tables

I also checked the repo .env. It had project secrets, but not an OpenAI key for Bifrost.

So I did one more bootstrap test:

created bifrost-temp/config.json with providers.openai.keys[0].value = "env.OPENAI_API_KEY"
launched Bifrost on http://127.0.0.1:8081
the gateway started and wrote state to ./config.db
the provider row existed, but Bifrost reported "no valid keys found for provider: openai"

That was the exact failure mode: the key was missing from the shell.

Ollama routing worked

With OpenAI blocked by a missing secret, I tested the local provider I could fully verify: Ollama.

I started ollama serve on http://127.0.0.1:11434 and confirmed the API exposed models such as gemma3:1b, qwen3-coder:30b, tinyllama:latest, and mistral:latest.

I configured a custom Bifrost provider through /api/providers. The right pattern for Ollama was a key with an empty models list, which allows all models through.

The provider config looked like this:

{
  "provider": "openai-ollama2",
  "keys": [
    {
      "name": "openai-ollama2-key",
      "value": "dummy",
      "models": [],
      "weight": 1.0
    }
  ],
  "network_config": {
    "base_url": "http://127.0.0.1:11434",
    "default_request_timeout_in_seconds": 60
  },
  "custom_provider_config": {
    "base_provider_type": "openai",
    "allowed_requests": {
      "chat_completion": true,
      "chat_completion_stream": true
    }
  }
}

With that in place, Bifrost routed both local Ollama and Ollama cloud requests.

The request volume panel captured the setup process honestly: successful checks and tuning failures.

The token usage panel was not a benchmark, but it gave me a baseline.

The model usage panel confirmed the requests were hitting the models I expected.

Latency was uneven, which is no surprise for mixed local/cloud routing.

Cache was effectively unused in this small test.

I also verified the Docker path on http://127.0.0.1:8082 with:

docker run -p 8082:8080 -v $(pwd)/bifrost-temp:/app/data maximhq/bifrost

That instance also responded.

At that point the provider layer was proven enough to move on.

Classic MCP versus Code Mode

Next, I added a filesystem MCP server scoped to the donotpush folder.

curl -X POST http://127.0.0.1:8080/api/mcp/client \
  -H "Content-Type: application/json" \
  -d '{
    "name": "filesystem_blog",
    "connection_type": "stdio",
    "stdio_config": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/bradleymatera/Desktop/gatsby-starter-minimal-blog/donotpush"
      ],
      "envs": ["HOME", "PATH"]
    },
    "tools_to_execute": ["*"],
    "is_ping_available": false
  }'

Bifrost discovered 14 tools from that server.

In classic MCP mode, the model produced a direct tool call:

filesystem_blog-list_allowed_directories

I executed it through Bifrost:

curl -X POST http://127.0.0.1:8080/v1/mcp/tool/execute \
  -H "Content-Type: application/json" \
  -d '{
    "id": "call_pjlop9a3",
    "type": "function",
    "function": {
      "name": "filesystem_blog-list_allowed_directories",
      "arguments": "{}"
    }
  }'

Result:

Allowed directories:
/Users/bradleymatera/Desktop/gatsby-starter-minimal-blog/donotpush

That is the governance point in miniature: the server only saw one draft folder.

Then I flipped the same client into Code Mode.

curl -X PUT http://127.0.0.1:8080/api/mcp/client/f771c023-8a16-4b34-b03f-ffbfffd34e4b \
  -H "Content-Type: application/json" \
  -d '{
    "name": "filesystem_blog",
    "connection_type": "stdio",
    "stdio_config": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/bradleymatera/Desktop/gatsby-starter-minimal-blog/donotpush"
      ],
      "envs": ["HOME", "PATH"]
    },
    "tools_to_execute": ["*"],
    "is_ping_available": false,
    "is_code_mode_client": true
  }'

The four Code Mode meta-tools worked.

listToolFiles returned:

servers/
  filesystem_blog.pyi

readToolFile returned a compact stub with signatures like:

def read_text_file(path: str, head: float = None, tail: float = None) -> dict
def list_allowed_directories() -> dict
def list_directory(path: str) -> dict

getToolDocs returned docs for a specific function.

executeToolCode ran the filesystem server from inside the Code Mode layer:

Execution completed successfully.
Return value: "Allowed directories:\n/Users/bradleymatera/Desktop/gatsby-starter-minimal-blog/donotpush"

So the behavior matched the docs. The model saw a small tool-file surface first, then executed the specific tool binding it needed.

The task was the same in both modes:

List the allowed filesystem directory.

Classic MCP exposed the filesystem tools directly. Code Mode exposed a smaller meta-tool surface.

On this setup, I am not claiming savings. I am claiming behavior verification.

Coding agent results

The final step was the coding-agent launch.

Bifrost CLI launched Codex CLI and showed:

Harness       Codex CLI (codex-cli 0.125.0)
Model         openai-ollama2/gpt-oss:20b-cloud

It also printed:

MCP: Codex CLI has no native auto-attach yet. Use server URL: http://localhost:8080/mcp

So the launch path worked.

But the actual Codex request did not complete. Codex expects the Responses API, while my Ollama route was using chat completions.

Codex reported:

Error loading config.toml: `wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.

That is a real provider compatibility issue, not a gateway failure.

For the working agent test, I used OpenCode, which supports OpenAI-compatible chat completions.

The config was:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "bifrost/openai-ollama2/gpt-oss:20b-cloud",
  "provider": {
    "bifrost": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Bifrost",
      "options": {
        "baseURL": "http://127.0.0.1:8080/v1",
        "apiKey": "dummy"
      },
      "models": {
        "openai-ollama2/gpt-oss:20b-cloud": {
          "name": "Ollama cloud through Bifrost",
          "limit": {
            "context": 32768,
            "output": 4096
          }
        }
      }
    }
  }
}

Then I ran:

OPENCODE_CONFIG=/tmp/bifrost-opencode.json opencode run \
  --dir /Users/bradleymatera/Desktop/gatsby-starter-minimal-blog \
  --format json \
  --model bifrost/openai-ollama2/gpt-oss:20b-cloud \
  'Do not edit files. Reply with exactly: opencode through bifrost ok'

Result:

opencode through bifrost ok

Usage reported:

17154 total tokens
17100 input tokens
54 output tokens

That was the first real coding-agent request through Bifrost in this test.

Why governance matters here

This setup is not just about making a request succeed.

It is about making the request visible and controllable.

A gateway lets you answer:

which virtual key was used?
which provider routed the request?
which MCP server was available?
what did the dashboard record?

That matters more than one successful completion.

Bifrost also surfaces:

virtual keys
budget controls
provider routing
MCP tool governance
audit logs
cost tracking

This is not only enterprise language. Even for solo projects, it is useful to know what key is being used, what model is being called, and what tools the agent can reach.

If I am running multiple demos or experiments, I want separate keys, usage tracking, and some protection against accidental spending.

Bifrost as the control plane

Without Bifrost, the setup looks like this:

Agent → Provider
Agent → MCP server
Agent → another provider
Agent → another tool config
Agent → another local config file

With Bifrost:

Agent → Bifrost → Providers
              → MCP tools
              → routing
              → governance
              → logs
              → cost tracking

That second layout is easier to reason about.

It does not make agents perfect, but it does make the system easier to inspect.

Benefits and limitations

What was clear from this pass:

the gateway is easy to start with NPX or Docker
the dashboard makes traffic, latency, tokens, and errors visible
the CLI reduces per-agent setup work
the CLI can switch between supported agents without hand-editing every config
virtual keys, audit logs, and budget controls add governance
Code Mode turns the MCP surface into a smaller discovery-and-execute flow

What was also clear:

Code Mode is not a magic switch. It is worth validating in every environment.
Classic MCP can still be the better choice for very small setups.
Provider compatibility matters. One OpenAI-compatible route is not the same as another.

My local dashboard was on v1.4.24. The docs call out Code Mode from v1.4.0-prerelease1. That is a good reminder: verify the exact version where you run this.

The provider-specific limitation was real. OpenCode worked through Bifrost + Ollama. Codex CLI launched, but the request failed because the route needed Responses compatibility.

That is not a reason to discard the setup. It is a reason to test each agent/provider pair instead of assuming every OpenAI-compatible route behaves identically.

maximhq / bifrost

Fastest enterprise AI gateway (50x faster than LiteLLM) with adaptive load balancer, cluster mode, guardrails, 1000+ models support & <100 µs overhead at 5k RPS.

Bifrost AI Gateway

The fastest way to build AI applications that never go down

Quick Start

Go from zero to production-ready AI gateway in under a minute.

Step 1: Start Bifrost Gateway

# Install and run locally
npx -y @maximhq/bifrost

# Or use Docker
docker run -p 8080:8080 maximhq/bifrost

Step 2: Configure via Web UI

# Open the built-in web interface
open http://localhost:8080

Step 3: Make your first API call

curl -X POST http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [{"role": "user", "content": "Hello, Bifrost!"}]
  }'

That's it! Your AI gateway is running with a web interface for visual configuration…

View on GitHub

Bifrost CLI article:

Anthony Max

Mar 19

Bifrost CLI + Codex CLI: One Command to Set Up OpenAI's Coding Agent with Any Model

#ai #webdev #programming #opensource

111

3 min read

Bifrost MCP Gateway and Code Mode article:

Hadil Ben Abdallah

Jan 29

How Bifrost’s MCP Gateway and Code Mode Power Production-Grade LLM Gateways

#ai #llm #mcp #opensource

7 min read

Official Bifrost setup article on Medium:

medium.com

Final status

Here is the final state of the test:

[x] Install Bifrost locally with NPX
[x] Install Bifrost locally with Docker
[x] Open the dashboard and confirm the UI works
[x] Configure at least one provider (Ollama)
[ ] Configure OpenAI provider request blocked by missing secret
[x] Start Bifrost CLI
[x] Confirm Bifrost CLI asks for the right config
[x] Confirm Bifrost CLI config storage
[x] Launch Codex CLI through Bifrost CLI
[x] Record the Codex limitation with this route
[x] Launch one working coding agent through Bifrost with OpenCode
[x] Add at least one MCP server
[x] Verify the tool surface
[x] Verify classic MCP tool execution
[x] Enable Code Mode
[x] Verify the Code Mode meta-tools
[x] Run the same small MCP task with and without Code Mode
[x] Verify local Ollama routing through Bifrost
[x] Verify Ollama cloud routing through Bifrost
[ ] Check provider selection and fallback path blocked by missing OpenAI key
[x] Capture screenshots of the dashboard and terminal results
[x] Record exact errors, fixes, and commands
[out of scope] Replace vendor benchmark claims with my own benchmark for a one-server test

This is still not a benchmark. It is a tested setup walkthrough and an initial MCP + Code Mode proof. I do not want to turn a one-server smoke test into a fake performance claim.

Final thought

I am not testing Bifrost because I need another AI tool.

I am testing it because the wiring is getting messy.

Every agent wants a config file. Every provider wants a key. Every MCP server adds tools. Every tool adds context.

Bifrost does not solve all of that, but it does give you one place to inspect and control it.

In this setup, the core pieces worked:

the gateway installed cleanly
the dashboard gave me visibility
Ollama routed through it
MCP tools were governable
Code Mode exposed the expected meta-tools
OpenCode completed a request through the gateway

The limits are also clear:

OpenAI routing still needs a real OPENAI_API_KEY
Codex CLI launched, but the request path needs Responses compatibility
the Code Mode savings claim still needs a larger multi-server test

My takeaway is practical: Bifrost can be a useful control layer for local agent experiments, but the value depends on provider wiring, MCP scoping, and agent-specific testing.

Testing That I Actually Run: A Small Pyramid

Bradley Matera — Thu, 29 Jan 2026 19:38:41 +0000

The "Testing Guilt" Cycle

There is a cycle that every developer goes through. It starts with a vow: "This time, I will have 100% code coverage. I will write E2E tests for every button click. I will be a 'Responsible Engineer'."

Two months later, the CI pipeline takes 20 minutes to run. The E2E tests flake out randomly because a div moved 2 pixels. You start commenting out tests just to get a hotfix deployed. Eventually, you stop running npm test altogether.

I have abandoned more test suites than I care to admit.

The problem isn't the desire to test; it's the strategy. We often build an "Ice Cream Cone" of testing: massive, slow, expensive UI tests on top, with a tiny cone of unit tests at the bottom. This is unstable and exhausting.

In 2025, I flipped the script. I use a "Small Pyramid" strategy. It relies on a high volume of ultra-fast unit tests, a complete absence of complex E2E frameworks (for personal projects), and a rigorous, documented "Smoke Protocol."

This post is the blueprint for that stack.

Level 1: The Infrastructure (Why Vitest Won)

For the better part of a decade, Jest was the undisputed king of JavaScript testing. But as the ecosystem shifted toward ESM (ECMAScript Modules) and TypeScript, Jest started showing its age.

The Problem with Jest: Jest operates by overriding the Node.js require system. To make it work with modern TypeScript or Vite projects, you essentially have to configure a Babel pipeline just for your tests. It is slow, memory-hungry, and debugging "SyntaxError: Cannot use import statement outside a module" is a rite of passage I never want to repeat.
The Solution (Vitest): Vitest is a native Vite-powered test runner. It reads your existing vite.config.ts. It supports ESM out of the box. It uses Worker threads for true parallelism.

The Setup

We don't just install a library; we define a standard. The package.json is the contract.

Command:

npm install -D vitest @vitest/coverage-v8

Configuration (package.json):

{
  "scripts": {
    "test": "vitest run",
    "test:watch": "vitest",
    "test:coverage": "vitest run --coverage"
  }
}

The Config File (vitest.config.ts):
We create a dedicated config to ensure our testing environment isolates side effects.

import { defineConfig } from 'vitest/config';

export default defineConfig({
  test: {
    environment: 'node', // Use 'jsdom' if testing React components
    include: ['src/**/*.test.ts'],
    coverage: {
      provider: 'v8',
      reporter: ['text', 'json', 'html'],
    },
    // Fail the build if we accidentally leave a .only() in the code
    allowOnly: false, 
  },
});

Why this matters:
Using vitest run (single pass) vs vitest (watch mode) is a crucial distinction for CI/CD pipelines. If you put vitest in your GitHub Action, it will hang forever waiting for input.

Level 2: The Unit Test (The Bedrock)

The bottom of the pyramid must be wide and stable. These tests verify Pure Logic.

A "Pure Function" is a function that, given the same input, always returns the same output and produces no side effects (no API calls, no DOM updates). These are the easiest to test and the most critical to verify.

Real World Example: Data Transformation

Imagine an e-commerce app where we need to format a messy API response into a clean UI object.

The Logic (src/utils/formatter.ts):

interface UserAPIResponse {
  first_name: string | null;
  last_name: string | null;
  created_at: string; // ISO Date string
  role: 'admin' | 'user' | 'guest';
}

interface UserUI {
  fullName: string;
  memberSince: string;
  isAdmin: boolean;
}

export function formatUser(user: UserAPIResponse): UserUI {
  const first = user.first_name ?? 'Guest';
  const last = user.last_name ?? '';

  // Format Date (simple implementation for demo)
  const date = new Date(user.created_at);
  const year = date.getFullYear();

  return {
    fullName: `${first} ${last}`.trim(),
    memberSince: isNaN(year) ? 'Unknown' : year.toString(),
    isAdmin: user.role === 'admin',
  };
}

The Test Suite (src/utils/formatter.test.ts):

import { describe, it, expect } from 'vitest';
import { formatUser } from './formatter';

describe('formatUser utility', () => {
  it('combines names correctly', () => {
    const input = { 
      first_name: 'Jane', 
      last_name: 'Doe', 
      created_at: '2023-01-01', 
      role: 'user' 
    } as const;

    expect(formatUser(input).fullName).toBe('Jane Doe');
  });

  it('handles null names gracefully', () => {
    const input = { 
      first_name: null, 
      last_name: null, 
      created_at: '2023-01-01', 
      role: 'guest' 
    } as const;

    expect(formatUser(input).fullName).toBe('Guest');
  });

  it('identifies admin privileges', () => {
    const input = { 
        first_name: 'Admin', 
        last_name: 'User', 
        created_at: '2023-01-01', 
        role: 'admin' 
    } as const;

    expect(formatUser(input).isAdmin).toBe(true);
  });

  it('handles invalid dates', () => {
      const input = { 
          first_name: 'Test', 
          last_name: 'User', 
          created_at: 'invalid-date', 
          role: 'user' 
      } as const;

      expect(formatUser(input).memberSince).toBe('Unknown');
  });
});

The Lesson:
This suite runs in 4 milliseconds. It protects us against null pointer exceptions and ensures our UI never says "undefined undefined". This is the highest ROI (Return on Investment) coding you can do.

Level 3: The "Smoke Protocol" (The Human Element)

This is where I diverge from the "Best Practices" dogma.

Standard advice says "Automate Everything." But setting up Cypress or Playwright to click a "Login" button, handle Authentication tokens, deal with 2FA, and wait for animations to finish is a massive maintenance burden. For a solo developer or a small team, maintenance is the enemy.

Instead, I use a rigorous Manual Smoke Protocol.

This isn't just "clicking around." It is a standardized checklist committed to the repository that must be physically checked off before a release.

The Protocol File (docs/QA_SMOKE_CHECK.md):

# 🛑 Release Smoke Check Protocol
**Do not merge to main until all items are verified.**

## 1. Critical User Flows
- [ ] **Authentication:** Log out and Log back in using Google Auth.
- [ ] **Data Persistence:** Update the user profile name, refresh the page. Does the new name persist?
- [ ] **Payment Flow:** Go to /pricing, click "Buy", reach the Stripe Checkout hosted page. (Do not need to complete purchase).

## 2. Responsive Check
- [ ] **Mobile Menu:** Open on iPhone viewport (Chrome DevTools). Does the hamburger menu expand?
- [ ] **Grid Layout:** Resize window to 768px. Does the 3-column grid snap to 1-column?

## 3. The "Stupid" Check
- [ ] **Console Errors:** Open DevTools console. Are there any red text blocks on the homepage?
- [ ] **Links:** Click the "Contact Us" link in the footer. Does it 404?

Why this works:
It forces you to look at your application. Automated tests pass silently. Manual tests force you to feel the latency, see the layout shifts, and notice the janky animations that a script would ignore.

The "Gap" Analysis: What Are We Missing?

To be an honest engineer, you must admit what you are not testing. In this "Small Pyramid" stack, we have deliberate gaps:

Visual Regression: We are not using Percy or Chromatic to check pixel-perfect rendering.
Risk: I might accidentally change the button color from blue to slightly-less-blue.
Acceptance: I can live with this risk in exchange for development speed.
Integration Tests: We are not mocking the full API and testing the connection between the Frontend and Backend components.
Risk: The API contract might change (e.g., firstName becomes first_name) and the frontend will crash.
Mitigation: This is caught during the Manual Smoke Check.
Cross-Browser Testing: I am mostly testing on Chrome.
Risk: Safari might render flexbox differently.
Acceptance: 90% of my traffic is Chrome/Mobile Safari. The Smoke Check covers the Mobile Safari viewport.

Bonus: Automating the Bedrock (GitHub Actions)

We can't automate the Smoke Check easily, but we must automate the Unit Tests. If tests only run on your laptop, they don't exist.

Here is the exact workflow file I drop into every project.

File: `.github/workflows/test.yml`

name: Unit Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'

      - name: Install Dependencies
        run: npm ci

      - name: Run Vitest
        run: npm test

This ensures that no code can be merged into main unless the math functions and data formatters are working perfectly.

Final Verdict

Testing is not binary. It is not "Tested" vs "Untested." It is a spectrum of confidence.

By using Vitest for the logic that must be correct (math, data formatting) and a Smoke Protocol for the things that must look right (layout, navigation), you achieve 95% of the confidence with 10% of the maintenance cost of a full E2E suite.

That is a trade I will take every single time.

AWS vs. Azure vs. Google Cloud: The Ultimate Free Tier Battle & Survival Guide

Bradley Matera — Thu, 29 Jan 2026 18:40:57 +0000

Which cloud provider actually supports a developer’s growth for free, and which one is designing a billing trap?

In my previous post, I broke down the mechanics of the AWS Free Tier—specifically how to survive the first 12 months without incurring surprise debt. Since then, the conversation has shifted toward a broader comparison. It is not enough to just know how AWS works; as developers, we need to know if we are even betting on the right horse.

If you are building a portfolio, launching a startup prototype, or just trying to learn cloud without melting your credit card, you need a side-by-side technical and financial breakdown.

This is that breakdown.

We are going to pit AWS, Microsoft Azure, and Google Cloud Platform (GCP) against each other. We will analyze their compute limits, database constraints, hidden network costs, and the specific "gotchas" that each provider uses to monetize their free users.

The Philosophy of "Free"

Before looking at the numbers, you have to understand the business model, because it dictates the limitations you will face.

"The cloud is not a charity. The Free Tier is a customer acquisition funnel designed to integrate you into an ecosystem."

AWS wants you to build habits. Their 12-month model is designed to get you addicted to their specific proprietary tools (RDS, S3, IAM) so that when the year ends, the switching cost is too high to leave.
Azure wants enterprise adoption. They front-load credits ($200) to let you taste the "premium" power, hoping you'll convince your boss to migrate the company infrastructure later.
GCP plays the long game. They are the distant third in market share, so they offer the most generous "Always Free" tier to attract hobbyists and students, hoping that grassroots loyalty will grow their market share.

1. Compute: The Engine Room

The biggest cost for any project is the Virtual Machine (VM). Here is how they compare when you strip away the marketing fluff.

AWS: The Standard (EC2)

The Offer: 750 Hours/month of t2.micro or t3.micro.
The Specs: 2 vCPUs (burstable), 1 GiB Memory.
The Reality: This is enough to run one instance continuously (24/7) for a month. However, AWS uses a "CPU Credit" system. If your website gets a sudden spike in traffic, you burn credits. If you run out of credits, your CPU is throttled to baseline performance, making your site crawl.
The Trap: It is strictly 12 months. On day 366, you are billed standard on-demand rates.

Azure: The Burstable (B-Series)

The Offer: 750 Hours/month of B1s instances.
The Specs: 1 vCPU, 1 GiB Memory.
The Reality: Similar to AWS, this uses a credit banking system. The B1s is noticeably weaker than the AWS t3.micro for multi-threaded tasks because it only offers 1 vCPU compared to AWS's 2.
The Trap: The interface. Azure’s portal is complex. It is very easy to accidentally select a "Standard SSD" (paid) instead of a "Standard HDD" (free) during setup.

GCP: The Forever Server (Compute Engine)

The Offer: e2-micro instance.
The Specs: 2 vCPUs, 1 GiB Memory (0.25 vCPU sustained).
The Reality: This is the winner for longevity. As of this writing, this offer is part of the "Always Free" program, meaning it does not expire after 12 months.
The Trap: Location. This is only free in specific regions (usually us-west1, us-central1, us-east1). If you deploy in us-east4 by mistake, you pay full price immediately.

2. Databases: The Expensive Part

Stateless servers are cheap; stateful data is expensive. This is where the cloud providers try to squeeze you.

AWS (RDS)

AWS offers 750 hours of db.t2.micro or db.t3.micro (Single-AZ).

Pros: You get a real, managed relational database (MySQL, PostgreSQL, MariaDB).
Cons: It stops being free after 12 months. Migrating data out of AWS later can be tricky due to egress fees.

Azure (SQL Database)

Azure offers 250 GB of Azure SQL Database.

Pros: 250 GB is massive compared to the 20GB limit often seen elsewhere.
Cons: This is specifically "Azure SQL," which is Microsoft SQL Server. If your project is built on Postgres or MySQL, this free tier doesn't help you much. You have to adapt your stack to their technology.

GCP (Firestore)

GCP does not offer a generous free tier for Cloud SQL (their managed relational service). Instead, they push you toward Firestore (NoSQL).

Pros: Firestore is incredibly fast and easy for mobile apps.
Cons: It is NoSQL. If you are trying to learn traditional SQL table relationships, GCP forces you to pay roughly $10-$15/month for the smallest SQL instance.

3. The "Silent Killers" of Cloud Billing

Regardless of which provider you choose, the billing algorithms share the same ruthless logic regarding "optional" resources. These are the line items that do not appear on the main pricing page but appear on your invoice.

The Orphaned Volume

When you terminate a server, the cloud provider assumes you want to keep the data. They delete the compute resource but leave the hard drive (EBS/Disk) active.

The Cost: Roughly $0.10 per GB per month.
The Fix: You must manually locate the "Storage" or "Volumes" dashboard and delete these unattached disks. There is no auto-delete for these.

The Static IP Tax

A static IP (Elastic IP) is free only while it is being used.

The Logic: IPv4 addresses are a scarce global resource. The providers punish you for hoarding them.
The Cost: If you stop your server but keep the IP reserved, you are charged ~$0.005/hour. That is roughly $3.60/month for doing absolutely nothing.

Data Egress (The "Hotel California" Fee)

You can check out any time you like, but you can never leave—without paying.

Ingress (Data In): Always Free.
Egress (Data Out): Charged per GB after a small threshold.
The Risk: If you host a large media file and it gets hotlinked on a popular site, your egress fees will skyrocket instantly.

Final Verdict: Which One Should You Choose?

After deploying stacks on all three, here is my decision matrix for new projects:

Choose AWS If:

You are job hunting. AWS holds the largest market share. Having "Deployed MERN stack on EC2" on your resume is statistically more valuable than the others.
You need a standard SQL database. The RDS free tier is the most straightforward way to run MySQL/Postgres for a year.

Choose GCP If:

You are building a permanent personal tool. If you want a Discord bot or a script runner that stays online for 5 years for $0, the e2-micro is unmatched.
You are comfortable with Linux/Command Line. GCP’s interface is developer-focused but less "hand-holding" than Azure.

Choose Azure If:

You work in the .NET ecosystem. Visual Studio integration with Azure is seamless.
You need massive database storage. The 250GB SQL limit is generous if you are willing to use Microsoft SQL Server.

The Golden Rule

The only true way to stay free is vigilance. Set up "Billing Alerts" the moment you create your account. Set an alert for $0.01. The moment you get that email, you know you have crossed a line, and you can fix it before it becomes a $500 problem.

Stay curious, keep building, and check your billing dashboard every single morning.

— Bradley Matera

(bradleymatera.dev)