Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
That human-first approach is probably more important than ever in this conversation. The tools and languages are interesting, but we shouldn't lose sight of the people behind the work. I'll take a look at the rebellion too! 😄
Compressed tedium” is a great way to say it. We learn the most from the boring tasks and the bugs that take hours to fix. If AI does all of that for us, we miss the part that teaches us. I like the idea of doing one task a week without AI. It’s simple and anyone can try it.
Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
I think the tricky part is that those boring tasks don't feel like learning while you're doing them. You only realise later how much you picked up from fixing something that seemed insignificant at the time. That's why I wouldn't want AI to take all of that away, especially from someone just starting out.
Totally agree! When I started learning to code there was no AI to help me, and I still remember the mistakes I made and the bugs I spent hours trying to fix. Those lessons stuck with me because I had to figure them out myself. When AI fixes everything for you, you get the answer but you don’t really remember how you got there. The struggle is what makes it stick with you forever. Great post :)
The year-seven point is the one that should worry planning meetings. Cutting junior seats saves money this quarter, and the cost shows up years later as a shortage of people who can review generated code with any real judgment. Since every firm faces the same math, nobody budgets for it.
One reply suggested making junior roles about verification from day one, and I think that is the practical version of a plan. Writing acceptance cases, reproducing the messy edge cases, and explaining a change to a teammate without the original prompt are exactly the skills that turn into review judgment later.
At Ascendra Ventures we see the same thing in fixed-scope work. Typing got cheap, but deciding what done means and proving it did not, and that part still needs people who learned it somewhere.
Of the options in your table, which one do you think a small team could actually start with next month?
Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
I'd start with one real task per sprint where a junior owns the work, then walks a senior through the decisions they made. No elaborate policy needed. Just making that time non-negotiable would be a good start. The hard part isn't introducing the practice, it's making sure it doesn't disappear the moment deadlines get tight.
In financial pipelines and SEC filing extractors, modern models easily generate clean, passing code. They frequently miss subtle semantic distinctions, like treating accrual tax adjustments as cash tax payments, or mixing discrete quarterly numbers with cumulative year-to-date figures.
A reviewer who never spent nights tracing discrepancies across restated 10-Q tables will struggle to catch those slips in a diff. They see formatted functions, passing mocks, and green test runs. Senior judgment requires having burned hours debugging weird edge cases to recognize when generated code is subtly wrong. Without building that diagnostic muscle early, teams lose the ability to review long before 2033.
Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
This is exactly the part that worries me. Passing tests and clean code can make a change look perfectly fine, but understanding what the code is actually doing takes a different kind of experience. And you're right, that judgment usually comes from dealing with the messy cases, not just reviewing the happy path. That's a lot harder to replace than writing the code itself.
Your incentives table describes a classic general-training externality. When a firm pays senior engineers to mentor juniors, it builds portable judgment that another employer can hire away in year three, while cutting junior seats drops this quarter's payroll cost immediately. Because every firm faces the same math, nobody prices the 2033 senior review bottleneck into today's headcount budget.
That dynamic is also why voluntary rules like protected mentoring hours tend to slip under margin pressure. For a policy like your team-ai-policy.yml to hold across firms, junior seats have to pay back inside the first year as structured verification work, or employers have to pair training with retention structures that keep trained mid-levels from walking out the door.
Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
I hadn't thought about the retention side of this as much, but that's a fair point. Even if a company invests in training juniors, there's no guarantee it'll benefit them a few years down the line. I also like your point about making junior roles useful through verification work from the start. That feels like a much more practical way to approach this than simply asking companies to spend more time mentoring.
The napkin math hits hard because it's the exact timescale nobody in a planning meeting is incentivized to care about. "Save money this quarter, discover in year seven that all your mid-levels are gone" is not a line that survives a budget review.
Your point about seniors doing mostly review is the part I keep circling back to. Reviewing generated code well requires precisely the judgment you build by writing a lot of bad code first — so we're quietly optimizing away the training set for the skill we're about to need most. That's not a paradox anyone has to intend; it just falls out of everyone acting rationally.
On your closing question: if my team stopped hiring juniors tomorrow, in 2033 the seniors would be whoever came in through an adjacent door — data, ops, QA, support — because those paths still involve real debugging with real consequences. It's a worse pipeline, but not zero. Which is maybe the quiet hope buried in all this: the ladder doesn't have to stay the only way up, we just haven't built the others on purpose yet.
Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
I hadn't really thought about people coming into engineering through those other paths, but it makes sense. QA and support especially can teach you things you don't always pick up when you're just writing code. Maybe the bigger issue is that we're so focused on the traditional junior-to-senior path that we're not putting enough thought into what other paths could look like.
Exactly — and the frustrating part is those paths already work, we just don't formalize them. Support engineers who debug customer issues all day build better diagnostic instincts than most juniors. We just don't call it engineering training, so nobody designs it that way.
Doing one task a week with the agent off and then diffing against the agent's version is a practical way to keep reps, because the diff shows both what you would not have thought of and what the agent got wrong. The PR template line about someone on the team being able to explain the change is the part I'd adopt first, since it costs nothing. How would you handle a change that only the person who prompted it can explain?
Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
I'd struggle to approve that PR, honestly. If the person who prompted the AI is the only one who can explain the change, that's a sign something is missing. I'd ask them to walk another teammate through the logic without relying on the original prompt. If they can't, I'd rather have them revisit the code than merge something nobody else on the team fully understands.
I research AI tools, APIs & agents — comparing specs, pricing and real user reports — then publish honest rankings so you don't waste money. Research-first, never sponsored fluff.
The 'learn to code' parallel is the sharpest bit in here — true, free, and not a plan for anyone except you. The year-seven line is the one I'd steal for planning meetings though. Genuine question: in your model, who actually owns the plan? The firm has no incentive, the industry has no mechanism — is it just nobody's job by design?
Founder @thebitforge.dev • Software & AI Product Agency • 181K+ readers & 7K+ followers • We turn ideas into digital products people 💙 to use | visit us also on insta @thebitforge.dev
I think that's the uncomfortable part: it mostly is nobody's job right now. Firms are focused on their immediate needs, and there's no real incentive to think seven years ahead. I don't think there's one owner who can fix it, but teams can at least stop treating junior development as something that will somehow take care of itself.
Great piece. AI made code cheap, but deciding what to build, for whom, and how good it has to be is still the scarce part. Please have a look at MyJackfruit (warning: self-promotion). We built it so you and our Kai-Zen agents do the systems engineering first: map the stakeholders, quantify what they value, and set numeric targets for security, scalability and performance before any code.
"If the plan is nobody's job, why would it ever get made?" is the line that stuck with me. In India the junior ladder was the main way in for a lot of us: join somewhere, do the boring tickets, learn on the job. If agents eat those first-year tasks, the ladder doesn't get shorter, it loses its bottom rungs. I don't have the plan either, but I'd bet it starts with teams deliberately keeping some easy work for people to learn on, even when an agent could do it faster.
"Compressed tedium” is the phrase I’ll steal. The part I think gets overlooked is your incentives table: it’s rare to see someone lay out that every actor is behaving rationally and that’s exactly why the gap persists. The other thing that deserves more attention is the PR template line about explaining every changed line without reopening the agent chat. It’s cheap, it’s testable, and it exposes the difference between a team that owns a change and a team that just deployed one.
What I can’t get past is that the plan still has no accountable owner. A YAML file and a template are good habits, but if a generated change causes an incident, “the team owns it” only works if someone can point to the human who reviewed the logic and the rollback path. Otherwise the post correctly diagnoses the gap and then hands the fix to people who already have no time.
I’d be glad to compare notes on this, and happy to connect with others who are trying to make the junior pipeline concrete rather than just debated.
If you want a realistic next step, run it as a one-sprint experiment: every AI-assisted PR gets a named human owner, a short explanation of the logic, and a rollback note; then measure review time and escaped defects against the previous sprint. Small enough to actually finish, and it gives you data instead of a policy file nobody reads.
We're a place where coders share, stay up-to-date and grow their careers.
Reflect to a title: Mostly I build software for human first mentality Terminal is your Friend |> ; Hexaw the programming language, plus above these I created a game which is courious about Singularity.
Do not miss my invite to join a rebellion request!
That human-first approach is probably more important than ever in this conversation. The tools and languages are interesting, but we shouldn't lose sight of the people behind the work. I'll take a look at the rebellion too! 😄
Compressed tedium” is a great way to say it. We learn the most from the boring tasks and the bugs that take hours to fix. If AI does all of that for us, we miss the part that teaches us. I like the idea of doing one task a week without AI. It’s simple and anyone can try it.
I think the tricky part is that those boring tasks don't feel like learning while you're doing them. You only realise later how much you picked up from fixing something that seemed insignificant at the time. That's why I wouldn't want AI to take all of that away, especially from someone just starting out.
Totally agree! When I started learning to code there was no AI to help me, and I still remember the mistakes I made and the bugs I spent hours trying to fix. Those lessons stuck with me because I had to figure them out myself. When AI fixes everything for you, you get the answer but you don’t really remember how you got there. The struggle is what makes it stick with you forever. Great post :)
The year-seven point is the one that should worry planning meetings. Cutting junior seats saves money this quarter, and the cost shows up years later as a shortage of people who can review generated code with any real judgment. Since every firm faces the same math, nobody budgets for it.
One reply suggested making junior roles about verification from day one, and I think that is the practical version of a plan. Writing acceptance cases, reproducing the messy edge cases, and explaining a change to a teammate without the original prompt are exactly the skills that turn into review judgment later.
At Ascendra Ventures we see the same thing in fixed-scope work. Typing got cheap, but deciding what done means and proving it did not, and that part still needs people who learned it somewhere.
Of the options in your table, which one do you think a small team could actually start with next month?
I'd start with one real task per sprint where a junior owns the work, then walks a senior through the decisions they made. No elaborate policy needed. Just making that time non-negotiable would be a good start. The hard part isn't introducing the practice, it's making sure it doesn't disappear the moment deadlines get tight.
Skipping entry-level engineers directly undermines code review.
In financial pipelines and SEC filing extractors, modern models easily generate clean, passing code. They frequently miss subtle semantic distinctions, like treating accrual tax adjustments as cash tax payments, or mixing discrete quarterly numbers with cumulative year-to-date figures.
A reviewer who never spent nights tracing discrepancies across restated 10-Q tables will struggle to catch those slips in a diff. They see formatted functions, passing mocks, and green test runs. Senior judgment requires having burned hours debugging weird edge cases to recognize when generated code is subtly wrong. Without building that diagnostic muscle early, teams lose the ability to review long before 2033.
This is exactly the part that worries me. Passing tests and clean code can make a change look perfectly fine, but understanding what the code is actually doing takes a different kind of experience. And you're right, that judgment usually comes from dealing with the messy cases, not just reviewing the happy path. That's a lot harder to replace than writing the code itself.
Your incentives table describes a classic general-training externality. When a firm pays senior engineers to mentor juniors, it builds portable judgment that another employer can hire away in year three, while cutting junior seats drops this quarter's payroll cost immediately. Because every firm faces the same math, nobody prices the 2033 senior review bottleneck into today's headcount budget.
That dynamic is also why voluntary rules like protected mentoring hours tend to slip under margin pressure. For a policy like your team-ai-policy.yml to hold across firms, junior seats have to pay back inside the first year as structured verification work, or employers have to pair training with retention structures that keep trained mid-levels from walking out the door.
I hadn't thought about the retention side of this as much, but that's a fair point. Even if a company invests in training juniors, there's no guarantee it'll benefit them a few years down the line. I also like your point about making junior roles useful through verification work from the start. That feels like a much more practical way to approach this than simply asking companies to spend more time mentoring.
The napkin math hits hard because it's the exact timescale nobody in a planning meeting is incentivized to care about. "Save money this quarter, discover in year seven that all your mid-levels are gone" is not a line that survives a budget review.
Your point about seniors doing mostly review is the part I keep circling back to. Reviewing generated code well requires precisely the judgment you build by writing a lot of bad code first — so we're quietly optimizing away the training set for the skill we're about to need most. That's not a paradox anyone has to intend; it just falls out of everyone acting rationally.
On your closing question: if my team stopped hiring juniors tomorrow, in 2033 the seniors would be whoever came in through an adjacent door — data, ops, QA, support — because those paths still involve real debugging with real consequences. It's a worse pipeline, but not zero. Which is maybe the quiet hope buried in all this: the ladder doesn't have to stay the only way up, we just haven't built the others on purpose yet.
I hadn't really thought about people coming into engineering through those other paths, but it makes sense. QA and support especially can teach you things you don't always pick up when you're just writing code. Maybe the bigger issue is that we're so focused on the traditional junior-to-senior path that we're not putting enough thought into what other paths could look like.
Exactly — and the frustrating part is those paths already work, we just don't formalize them. Support engineers who debug customer issues all day build better diagnostic instincts than most juniors. We just don't call it engineering training, so nobody designs it that way.
Doing one task a week with the agent off and then diffing against the agent's version is a practical way to keep reps, because the diff shows both what you would not have thought of and what the agent got wrong. The PR template line about someone on the team being able to explain the change is the part I'd adopt first, since it costs nothing. How would you handle a change that only the person who prompted it can explain?
I'd struggle to approve that PR, honestly. If the person who prompted the AI is the only one who can explain the change, that's a sign something is missing. I'd ask them to walk another teammate through the logic without relying on the original prompt. If they can't, I'd rather have them revisit the code than merge something nobody else on the team fully understands.
The 'learn to code' parallel is the sharpest bit in here — true, free, and not a plan for anyone except you. The year-seven line is the one I'd steal for planning meetings though. Genuine question: in your model, who actually owns the plan? The firm has no incentive, the industry has no mechanism — is it just nobody's job by design?
I think that's the uncomfortable part: it mostly is nobody's job right now. Firms are focused on their immediate needs, and there's no real incentive to think seven years ahead. I don't think there's one owner who can fix it, but teams can at least stop treating junior development as something that will somehow take care of itself.
Great piece. AI made code cheap, but deciding what to build, for whom, and how good it has to be is still the scarce part. Please have a look at MyJackfruit (warning: self-promotion). We built it so you and our Kai-Zen agents do the systems engineering first: map the stakeholders, quantify what they value, and set numeric targets for security, scalability and performance before any code.
"If the plan is nobody's job, why would it ever get made?" is the line that stuck with me. In India the junior ladder was the main way in for a lot of us: join somewhere, do the boring tickets, learn on the job. If agents eat those first-year tasks, the ladder doesn't get shorter, it loses its bottom rungs. I don't have the plan either, but I'd bet it starts with teams deliberately keeping some easy work for people to learn on, even when an agent could do it faster.
"Compressed tedium” is the phrase I’ll steal. The part I think gets overlooked is your incentives table: it’s rare to see someone lay out that every actor is behaving rationally and that’s exactly why the gap persists. The other thing that deserves more attention is the PR template line about explaining every changed line without reopening the agent chat. It’s cheap, it’s testable, and it exposes the difference between a team that owns a change and a team that just deployed one.
What I can’t get past is that the plan still has no accountable owner. A YAML file and a template are good habits, but if a generated change causes an incident, “the team owns it” only works if someone can point to the human who reviewed the logic and the rollback path. Otherwise the post correctly diagnoses the gap and then hands the fix to people who already have no time.
I’d be glad to compare notes on this, and happy to connect with others who are trying to make the junior pipeline concrete rather than just debated.
If you want a realistic next step, run it as a one-sprint experiment: every AI-assisted PR gets a named human owner, a short explanation of the logic, and a rollback note; then measure review time and escaped defects against the previous sprint. Small enough to actually finish, and it gives you data instead of a policy file nobody reads.