DEV Community: Bradley Matera

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.

Review the Logic, Not Whether the Junior Used AI

Bradley Matera — Wed, 29 Apr 2026 22:36:56 +0000

Code review has a new lazy question:

"Did AI write this?"

Sometimes that question matters.

If private code was pasted into an unapproved tool, it matters.

If generated code was shipped without understanding, it matters.

If the team has a compliance policy, it matters.

But as a review standard, that question is weak.

The better question is:

"Is this code correct, tested, maintainable, and owned by the person submitting it?"

That standard catches bad AI code. It also catches bad human code.

Coding Computer Science GIF by Quixy - Find & Share on GIPHY

Discover & share this Coding Computer Science GIF by Quixy with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

AI panic can hide ordinary review failures

Take a SQL example.

A report needs to include analytics events even when the segment reference is missing, because missing references are part of the data-quality signal.

The wrong query looks clean:

SELECT a.id, a.user_id, a.segment_id
FROM analytics_events a
JOIN segments s ON a.segment_id = s.id
WHERE a.deleted_at IS NULL;

The problem is the JOIN. It drops rows without matching segment records.

If missing segment references are supposed to remain visible, the query needs a LEFT JOIN and an explicit signal:

SELECT
  a.id,
  a.user_id,
  a.segment_id,
  s.id IS NULL AS missing_segment
FROM analytics_events a
LEFT JOIN segments s ON a.segment_id = s.id
WHERE a.deleted_at IS NULL;

That bug has nothing to do with whether AI was used.

A human can make it. AI can make it. A rushed senior can make it. A junior can make it.

The review should catch it either way.

Code review is supposed to teach and protect

Research on code review does not describe it as a rubber stamp.

The 2013 paper Expectations, Outcomes, and Challenges of Modern Code Review found that while defect finding remains a major motivation, code review also supports knowledge transfer, team awareness, and alternative solution discovery.

Google's 2018 paper Modern Code Review: A Case Study at Google describes review as serving readability, education, maintainability, and correctness goals.

Sources: ICSE 2013 modern code review paper and Google Modern Code Review case study.

That matters for juniors. If review only says:

"This looks AI-generated."

It is not teaching anything useful.

If review says:

"This join drops orphaned events. Add a fixture that proves missing segments stay visible."

That teaches.

Ask review questions that expose behavior

Here is the shift teams need:

Weak review question	Strong review question
Did AI write this?	Can the author explain the logic?
Is this generated?	What behavior does this guarantee?
Does it look clean?	What data does it drop?
Did the junior follow policy?	Did the reviewer verify the assumption?
Is this allowed?	What risk does this introduce?
Can we reject it?	What test would make it safe?

The tool-origin question is not useless. It is just not enough.

AI disclosure should be boring

Teams need policies that make disclosure normal.

Example:

AI assistance:
- used AI to understand the existing SQL join behavior
- used AI to brainstorm edge cases
- final query was manually reviewed and tested

Validation:
- added fixture for missing segment reference
- verified deleted events are excluded
- verified active orphaned events remain visible

That is a reviewable note.

It gives the reviewer a path:

inspect the behavior
inspect the test
ask what was rejected
verify the edge case

Compare that with the usual vague policy:

"Use AI responsibly."

That is not a policy. That is a future argument.

Tests are where the tool debate gets real

For the SQL example, a useful test fixture includes:

event with valid segment
event with missing segment
deleted event
expected output that preserves the missing-segment row

Example:

it('preserves active analytics events with missing segment references', async () => {
  await seedAnalyticsEvent({ id: 1, segmentId: 'known-segment', deletedAt: null });
  await seedAnalyticsEvent({ id: 2, segmentId: 'missing-segment', deletedAt: null });
  await seedAnalyticsEvent({ id: 3, segmentId: 'deleted-segment', deletedAt: new Date() });

  const rows = await reportRepository.getCampaignSegmentRows();

  expect(rows).toEqual([
    expect.objectContaining({ id: 1, missing_segment: false }),
    expect.objectContaining({ id: 2, missing_segment: true }),
  ]);
});

That test does not care who wrote the query. It cares whether the business rule survives.

That is the right level of discipline.

Developers already know AI is unreliable

The common narrative is that juniors trust AI too much.

Some do. But the broader developer population is not blindly confident either.

Stack Overflow's 2025 Developer Survey says more developers distrust AI output accuracy than trust it: 46% versus 33%. It also says the biggest frustration is AI answers that are "almost right, but not quite." [Stack Overflow AI survey]

Source: Stack Overflow 2025 Developer Survey.

That phrase should be printed above every code review tool:

almost right, but not quite

That is the danger zone. It applies to human code too.

Bad AI use versus smart AI use

Bad AI use:

generate code
paste it
cannot explain it
no tests
no docs
no edge cases
hide the tool use

Smart AI use:

ask AI to explain unfamiliar code
ask for edge cases
compare with docs
write or improve tests
reject wrong suggestions
disclose meaningful help
own the final change

Teams should punish the first pattern and teach the second.

The senior double standard

The uncomfortable part is that many seniors have a double standard.

They treat junior AI use as suspicious but treat senior intuition as trustworthy.

That is not engineering. Engineering is evidence.

A senior's hand-written code can still be wrong.

A junior's AI-assisted code can still be correct.

Neither gets a free pass.

The standard should be:

Standard	Applies to
Explain the code	Everyone
Test risky behavior	Everyone
Follow privacy policy	Everyone
Disclose required AI use	Everyone
Accept review	Everyone
Own production impact	Everyone

That is how teams avoid turning AI policy into status politics.

What hiring managers should ask

If companies want AI-aware juniors, they should evaluate AI-aware review skills.

Ask candidates:

How would you verify AI-generated code?
What makes an AI answer unsafe?
When would you refuse to use generated output?
How would you test this SQL query?
What would you disclose in a PR?

That is better than pretending AI does not exist. It is also better than rewarding candidates who hide their workflow.

Bottom line

Review the logic. Review the tests. Review the assumptions. Review the data that disappears.

Review the security boundary. Review the production risk.

Yes, review AI usage too.

But do not confuse tool suspicion with engineering rigor.

The goal is not to keep AI out of the conversation. The goal is to keep bad code out of production.

Interested in code review, AI, and engineering culture? Explore #code-review on DEV.

Stop Hiring One Junior to Be the Whole Engineering Department

Bradley Matera — Wed, 29 Apr 2026 22:35:56 +0000

One of the worst hiring patterns in tech is the "junior full-stack owner."

The title says junior.

The job says:

build the UI
write the API
design the database
deploy to cloud
manage CI/CD
write tests
handle analytics
debug production
talk to support
understand security
use AI responsibly
move fast

That is not a junior role. It is an underfunded engineering department wearing a junior title.

Work From Home Leaf GIF by CC0 Studios - Find & Share on GIPHY

Discover & share this Work From Home Leaf GIF by CC0 Studios with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Scope is the hidden hiring failure

The industry talks a lot about skill gaps. It talks less about scope gaps.

A junior can learn React. A junior can learn SQL. A junior can learn AWS basics. A junior can learn testing.

But a junior cannot safely be the primary owner for every layer of a production system without support.

That is not because juniors are weak. It is because production systems are multi-disciplinary.

Frontend work requires accessibility, state management, browser behavior, design constraints, and product judgment.

Backend work requires API design, data modeling, validation, concurrency, error handling, and performance awareness.

Infrastructure work requires networking, secrets, deployment, observability, rollback, permissions, and cost control.

Support work requires incident judgment, user empathy, logging, triage, and communication.

Those are different skill families. Calling all of them "full-stack" does not make the scope reasonable.

The market rewards impossible wish lists

Indeed Hiring Lab reported that tech postings have shifted toward higher experience requirements, with the share asking for at least five years of experience rising from 37% to 42% between Q2 2022 and Q2 2025. [Indeed Hiring Lab]

Source: Indeed Hiring Lab.

NACE reports growing use of skills-based hiring for entry-level roles. [NACE]

That combination can be useful if companies define the skills clearly.

It becomes harmful when the skill list turns into:

"Everything our team is missing."

Bad hiring logic looks like this:

Business need	Bad junior requirement
We need a frontend fix	Must know React, design systems, accessibility, analytics.
We need API work	Must know Node, Python, SQL, auth, caching.
We need deployment help	Must know AWS, Docker, Kubernetes, Terraform.
We need quality	Must know unit, integration, E2E, and load testing.
We need velocity	Must know AI tools and ship independently.
We need coverage	Must join support rotation immediately.

That is not skills-based hiring. That is panic-based hiring.

Production reliability is not a junior checkbox

Reliability work is a good example.

Companies often expect juniors to understand retry logic, circuit breakers, queues, dead-letter handling, monitoring, and incident response while never giving them a safe path to learn those concepts.

Microsoft's Azure Architecture Center describes the Circuit Breaker pattern as a way to handle faults that may take time to recover from when an application connects to a remote service or resource.

Google's SRE book chapter on cascading failures explains how failures can amplify across systems, especially when retry behavior and overload are handled badly.

Those are not beginner concepts. They are teachable concepts. There is a difference.

AI can name the pattern. It cannot own the blast radius.

AI is useful here.

A junior can ask:

"What pattern prevents one failing upstream service from taking down the whole ingestion pipeline?"

The answer might point toward:

circuit breaker
retry with backoff
bulkhead isolation
dead-letter queue
schema validation
graceful degradation

That is valuable. But knowing the name of a pattern is not the same as owning production risk.

The junior still needs help deciding:

when the circuit opens
when it closes
what gets dropped
what gets retried
how operators are alerted
what users see
what metrics prove it worked
how to remove or replace the mitigation

That is where mentorship matters. AI can shorten discovery. It cannot replace operational judgment.

"No hacks" is often fake discipline

Another leadership mistake is rejecting temporary mitigations because they sound messy.

Teams say:

"We do not do hacks."

Sometimes that is discipline. Sometimes it is an excuse to avoid making a hard risk trade-off.

There is a real difference between a sloppy patch and a responsible mitigation:

Sloppy patch	Responsible mitigation
Hidden behavior	Documented behavior
No owner	Named owner
No tests	Test for failure mode
No observability	Logs, metrics, alerting
No end date	Removal or replacement condition
Pretends to be final	Explicitly buys time

Juniors should learn that distinction. Companies should teach it.

Instead, many teams give juniors vague slogans:

no hacks
move fast
own your work
think like a senior
use AI but be careful

Those are slogans, not operating instructions.

A realistic junior production path

If companies want juniors to learn production work, they need staged exposure.

Stage	Good junior scope
Observe	Watch incident reviews and deployment rollbacks.
Pair	Debug logs with a senior during low-risk issues.
Implement	Add tests, alerts, or small guardrails with review.
Shadow	Join support rotation without being primary.
Own small surface	Maintain a limited component with backup.
Expand	Take larger production ownership after evidence.

Source: Author framework for staged junior onboarding.

That is how production judgment develops. Not by throwing a junior into a multi-layer system and calling it "ownership."

AI adds another layer of pressure

Stack Overflow's 2025 survey says AI use is widespread among developers, but trust is low. [Stack Overflow AI survey]

Handshake reports that 70% of hiring leaders say AI will change entry-level role requirements. [Handshake]

Source: Handshake Class of 2026 AI economy research.

That means juniors are now expected to know the tool and know when not to trust the tool. That is a sophisticated skill.

If companies add AI to already bloated junior roles without training, they are not modernizing. They are increasing risk.

Write the role like you mean it

Bad:

Junior Full-Stack Developer
Must own frontend, backend, AWS deployments, testing, analytics, and production support.
Experience with AI coding tools preferred.

Better:

Junior Product Engineer
First 90 days focus on frontend bug fixes, API integration tasks, test coverage, and guided deployments.
Production support begins as shadowing only.
AI tools are allowed for learning and drafting, with disclosure and review rules.

The second version is still ambitious. It is also honest.

Bottom line

Companies cannot complain that juniors are not production-ready while designing junior roles with production blast radius and no training path.

If the role spans frontend, backend, cloud, DevOps, testing, analytics, support, and AI tooling, the candidate is not the problem.

The scope is.

A junior can grow into broad ownership. They should not be used as a cheap replacement for a missing team.

Interested in production engineering, hiring, and junior developer growth? Explore #production 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.

AI Did Not Make Junior Developers Risky. Unreviewed Work Did.

Bradley Matera — Wed, 29 Apr 2026 22:31:42 +0000

The industry talks about junior developers using AI like the junior is the main risk.

That is too convenient.

A junior can absolutely ship bad AI-generated code.

So can a senior.

So can a staff engineer under deadline pressure.

So can a team with no tests, unclear ownership, and code review that nitpicks style while missing behavior.

The problem is not that juniors use tools.

The problem is companies letting risky work pass through weak systems, then blaming the lowest-status person when something breaks.

Computer Code GIF by HACKER.REHAB - Find & Share on GIPHY

Discover & share this Computer Code GIF by HACKER.REHAB with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

Security shows the double standard

Take a basic authentication example.

A service verifies a JWT signature but forgets to validate issuer or audience:

const payload = jwt.verify(token, publicKey);
if (!payload.sub) {
  throw new Error('Invalid token');
}

The missing checks are the boring part that matters:

if (payload.iss !== config.allowedIssuer) {
  throw new Error('Unauthorized token issuer');
}

if (payload.aud !== config.expectedAudience) {
  throw new Error('Unexpected token audience');
}

That is not an "AI problem." It is an engineering-control problem.

If a junior asks AI, "What claims should a JWT validation path check?" and then uses that answer to inspect the code, that can be a good learning move.

If anyone copies generated auth code into production without tests or review, that is reckless.

The difference is verification.

The risk is real

Security concerns around AI-generated code are real.

AI can suggest outdated libraries, miss authorization boundaries, invent safe-looking checks, or generate code that passes happy-path tests while failing under real attack scenarios.

But security risk existed long before AI.

OWASP's Top 10 lists Broken Access Control as the number one 2021 web application security risk category. It also lists Identification and Authentication Failures as a major category.

Sources: OWASP Broken Access Control and OWASP Identification and Authentication Failures.

Those are not "junior used ChatGPT" categories. They are systems failing to enforce trust boundaries.

NIST's Secure Software Development Framework, SP 800-218, emphasizes secure practices across the software lifecycle, including defined roles, testing, vulnerability review, and risk response.

Security is a lifecycle responsibility. It cannot be reduced to "did the junior use AI?"

The pattern that actually breaks teams

Here is the pattern that should worry companies:

Weak system	What happens
No clear security checklist	Review depends on memory and senior availability.
No threat modeling	Teams do not know which risks matter.
No auth regression tests	Small claim-check bugs survive.
No AI usage policy	Tool use becomes hidden or selectively punished.
No safe escalation path	Juniors stop raising uncomfortable concerns.
No ownership of deferred risk	"Later" becomes "never."

That is how security bugs survive. Not because a junior asked an AI assistant to explain JWTs.

AI can teach vocabulary, not judgment

One underrated use of AI is vocabulary.

Juniors often see a problem before they know how to name it.

They might notice:

this token accepts too much
this endpoint trusts a client field
this query exposes another tenant's data
this permission check happens only in the UI
this webhook handler is not idempotent

AI can help map those observations to terms:

issuer validation
audience validation
broken access control
authorization bypass
tenant isolation
idempotency
replay risk
least privilege

That does not make AI a security reviewer. It makes AI a learning layer.

The human process still has to verify the answer.

The data supports caution, not panic

Stack Overflow's 2025 Developer Survey says AI use is widespread, but trust is low. More developers distrust AI output accuracy than trust it: 46% versus 33%. [Stack Overflow AI survey]

Source: Stack Overflow 2025 Developer Survey.

That is the right posture for security-sensitive work:

useful, but not trusted blindly.

The research on novice programmers is also cautious. The Widening Gap found that GenAI can help novices complete tasks, but weaker learners may struggle to reject incorrect suggestions. [The Widening Gap]

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

That is not a ban argument. It is a governance argument.

Review should follow the risk

Teams need different review standards for different code.

Changing button copy is not the same as changing authentication logic.

A risk-based review model might look like this:

Code area	AI assistance allowed?	Review expectation
UI copy	Usually low risk	Normal review.
Styling	Usually low risk	Visual check.
Business logic	Allowed with validation	Tests for behavior and edge cases.
Database migrations	High caution	Human review, rollback plan, test data.
Auth and permissions	High caution	Security review, threat model, regression tests.
Payments	High caution	Lifecycle tests, idempotency, reconciliation.
Secrets and infrastructure	High caution	Approved tooling, least privilege, audit trail.

This is stricter than yelling "no AI," and it is more useful.

Bad leadership makes people hide tool use

If leadership treats all AI use as suspicious, juniors will not stop using AI.

They will stop disclosing it.

That is worse than disclosure.

The company loses visibility into:

what tools are being used
what code may have been generated
what data may have been pasted
which developers need coaching
which patterns keep causing confusion

A useful AI policy should make disclosure normal, not humiliating.

Something like:

AI assistance:
- used for explanation, edge-case brainstorming, or draft code

Developer responsibility:
- author owns final code
- risky code requires tests and human review
- private code may only be used with approved tools

That gives reviewers something concrete.

Seniors have to review better too

Senior engineers cannot just complain that juniors do not know enough.

They have to decide whether they are reviewers, mentors, or gatekeepers.

A useful senior review asks:

What behavior does this code guarantee?
What cases are not covered?
What did the AI suggest that you rejected?
Which docs did you verify against?
What would break if this assumption is wrong?
How does the test prove the security boundary?

A weak senior review says:

"This looks AI-generated."

That is not enough.

Maybe it is generated. So what?

Is it correct? Is it tested? Is it safe? Is it maintainable? Does it respect the data boundary?

Those are the questions that matter.

Example: JWT validation checklist

For security-sensitive code, teams should teach checklists.

For JWT validation, a basic review checklist might include:

Check	Why it matters
Verify signature	Confirms token integrity.
Validate issuer	Rejects tokens from unexpected authorities.
Validate audience	Ensures token is meant for this service.
Validate expiration	Prevents stale token use.
Validate tenant mapping	Prevents cross-customer access.
Test failure cases	Confirms invalid tokens are rejected.
Log safely	Helps investigation without leaking secrets.

That checklist is useful no matter who wrote the first draft.

Bottom line

AI did not make junior developers risky.

Unreviewed work is risky. Ambiguous ownership is risky. Security-sensitive code without tests is risky. Leadership that punishes disclosure is risky.

If companies want safer software, they need review systems that inspect behavior, teach risk, and make AI use governable.

Blaming juniors is easier. It is also weaker engineering.

Interested in security, AI, and engineering review culture? Explore #security 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

Comments 5

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

Comments 16

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)

DEV Community: Bradley Matera

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

Table Of Contents

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

AI Policy Is Becoming the New Entry-Level Gatekeeping

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

The market already moved

The entry-level contradiction

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

Do not trust the output blindly

Hiring managers often do not know what they want

Evaluate AI use directly

Bad AI use versus professional AI use

The learning-resource problem is real

The research points back to training

A policy that actually says something

Bottom line

Review the Logic, Not Whether the Junior Used AI

Coding Computer Science GIF by Quixy - Find & Share on GIPHY

AI panic can hide ordinary review failures

Code review is supposed to teach and protect

Ask review questions that expose behavior

AI disclosure should be boring

Tests are where the tool debate gets real

Developers already know AI is unreliable

Bad AI use versus smart AI use

The senior double standard

What hiring managers should ask

Bottom line

Stop Hiring One Junior to Be the Whole Engineering Department

Work From Home Leaf GIF by CC0 Studios - Find & Share on GIPHY

Scope is the hidden hiring failure

The market rewards impossible wish lists

Production reliability is not a junior checkbox

AI can name the pattern. It cannot own the blast radius.

"No hacks" is often fake discipline

A realistic junior production path

AI adds another layer of pressure

Write the role like you mean it

Bottom line

Senior Engineers Complaining About Juniors Are Missing the Point

Teamwork GIF by Dubsado - Find & Share on GIPHY

Juniors are not supposed to arrive finished

The mentorship gap is not mysterious

Psychological safety is not office decor

AI fills the space mentorship left open

The old learning culture had shortcuts too

Review the thinking, not just the diff

AI dependence is a real risk

The management failure nobody wants to own

What a real junior pipeline looks like

Bottom line

Entry-Level Job Descriptions Are Becoming Broken Product Specs

Animation Hiring GIF by Biteable - Find & Share on GIPHY

The market is saying two things at once

The imaginary junior candidate

Skills-based hiring can still be lazy

AI is now another requirement

Older developers used shortcuts too

Smart AI use is not laziness

A real junior role has a smaller blast radius

What the job post should actually say