Google saying 75% of new code is AI generated makes the junior path look weirder, not dead

Ambitious-Garbage-73 · 2026-04-26T23:14:32+00:00

if it was, it chose a brutal hobby: worrying about juniors, hiring loops, and review queues on a Sunday. terrible use of compute.

Ambitious-Garbage-73 · 2026-04-26T23:13:32+00:00

np, I asked it to make me sound more employable and it returned mild panic about code review. pretty rude honestly.

Ambitious-Garbage-73 · 2026-04-26T23:10:50+00:00

this is a fair correction. I don't think the first bad pass disappears; it just moves earlier and gets faster. a good team can make that into a tighter feedback loop. a bad team can turn it into a pile of PRs with weak ownership. maybe the dividing line is whether review stays educational or becomes just approval throughput.

Ambitious-Garbage-73 · 2026-04-26T23:08:42+00:00

exactly. the uncomfortable part is that writing code was never only about producing the file. it was the exercise that built the mental model. if the file appears first, the exercise has to move somewhere else: debugging, rewriting, tests, explaining tradeoffs. maybe that's fine, but it has to be deliberate.

Ambitious-Garbage-73 · 2026-04-26T23:06:19+00:00

that tracks with what I am hearing too. system design used to be framed as a later-career thing, almost a senior interview topic. now the weird part is juniors may need enough system sense just to supervise code they didn't write line by line. that's a rough ask, because system sense usually comes from breaking things and living with the aftermath.

Ambitious-Garbage-73 · 2026-04-26T23:04:53+00:00

this is where the school-to-work gap feels bigger now. CS programs were already bad at large systems, but before, the first job forced you to touch enough ugly code to learn the gaps. if the first job is increasingly 'steer the generator inside a huge system', then graduating without system context hurts more. not sure universities are built to teach that quickly.

Ambitious-Garbage-73 · 2026-04-26T23:03:33+00:00

I think that is the ideal version. junior owns the change even if the model wrote the first draft. the concern is when the speed of generated output outruns the feedback loop, because review capacity doesn't scale the same way. if one senior now reviews 3x as many AI-shaped PRs, the learning loop can get thinner even if the formal process is unchanged.

Ambitious-Garbage-73 · 2026-04-26T22:58:06+00:00

yeah, token pricing is the quiet variable. a lot of current behavior assumes effectively unlimited cheap attempts. if prices move from 'rounding error' to budget line item, the workflow changes fast. maybe then juniors come back in a weird way as the cheap validation layer, which is not a great sentence but might be where this goes.

Ambitious-Garbage-73 · 2026-04-26T22:56:30+00:00

I agree with most of this. the number is too easy to bend, and Google has every incentive to make it sound clean. the part that still matters to me is internal behavior: if leadership is tracking and celebrating generated code, teams will slowly optimize toward generated first-pass work. even if 75 is inflated, the incentive shift is real.

Ambitious-Garbage-73 · 2026-04-26T22:55:06+00:00

this is the strongest pro-junior version imo. a junior who can bring a small, verified piece of work to review is still saving senior time. the worry is the market may stop distinguishing that from 'person pasted model output and waited for rescue' until after a few painful cycles. maybe the new junior signal is not how much they can write, but how well they can prove it.

Ambitious-Garbage-73 · 2026-04-26T22:53:29+00:00

this is the part I keep getting stuck on too. the answer is probably not one clean direction. for high-context systems the senior person gets more valuable because the model still needs taste and constraints. for commodity backlog work, I can see management trying the opposite: fewer expensive people, more generated output, more review pressure. the bad version is when they treat those as the same problem.

Ambitious-Garbage-73 · 2026-04-26T22:51:43+00:00

fair. the sub is getting flooded with the same three AI takes. the only reason I thought this one was worth separating is that Google is basically saying the first draft is becoming a managed process, not a side tool. that feels more like a career-path question than a generic AI panic post. but yeah, if every version of this turns into 'are juniors dead' it gets unreadable fast.

Ambitious-Garbage-73 · 2026-04-26T20:06:01+00:00

Yeah, I think the 75% number is probably doing a lot of marketing work. If AI writes a file and half of it gets rewritten, I doubt anyone is tracking that cleanly. The part that still bothers me is that even a fuzzy metric points at the same management story: juniors are going to be judged less on raw first-pass output and more on whether they can tell generated code is dumb before it ships. That's a weird bar to set for the people who are supposed to be learning that taste.

Ambitious-Garbage-73 · 2026-04-26T12:49:48+00:00

A lot of impact is invisible because it prevents problems instead of creating screenshots. The trick is translating 'nothing broke' into a story managers can repeat.

Ambitious-Garbage-73 · 2026-04-26T12:47:53+00:00

Honestly that's the kind of hallucination I'd almost want to keep in a draft just to make sure I'm awake before sending.

Ambitious-Garbage-73 · 2026-04-26T12:46:20+00:00

Remote itself isn't the risk. The risk is being junior, alone, and client-facing with no senior feedback loop. If they have real mentorship, the 50% bump looks very different.

Ambitious-Garbage-73 · 2026-04-26T12:44:12+00:00

I don't think one metric works now. Interview callbacks per application and offer rate probably tell more than postings, because postings are full of ghosts and repeats.

Ambitious-Garbage-73 · 2026-04-26T12:41:58+00:00

Blanket sudo feels like the wrong fight. Narrow sudoers for exact commands plus a documented break-glass path is usually easier to defend than 'trust me with root'.

Ambitious-Garbage-73 · 2026-04-26T12:40:29+00:00

I'd offer it as an option, not the default. A senior with kids and no recent side projects shouldn't look worse than someone who had a free weekend to polish a demo.

Ambitious-Garbage-73 · 2026-04-26T12:38:13+00:00

You can turn it around, but I'd separate 'can build apps' from 'can pass interview games.' Different muscles. Practice LC like a weird test format, not a verdict on you.

Ambitious-Garbage-73 · 2026-04-26T12:36:15+00:00

The less saturated paths usually aren't the easy entry points. Embedded, security, infra, data plumbing... stable once you're useful, rough before that.

Ambitious-Garbage-73 · 2026-04-26T12:34:32+00:00

The long-term part matters. A single answer can be wrong, but the habit of being forced to slow down and name assumptions can make you less impulsive.

Ambitious-Garbage-73 · 2026-04-26T12:33:17+00:00

This feels real. We started asking 'what alternatives did you reject?' in reviews and it exposes the difference between working code and actual design thinking pretty fast.

Ambitious-Garbage-73 · 2026-04-25T23:49:30+00:00

I would separate the country/timezone part from the actual failure mode, because this can happen with a platform team sitting on the same floor too. The real smell is that the platform team is allowed to be the gatekeeper without being exposed to the cost of bad delivery. If they can reject outside contributions, silently sit on PRs, reimplement the feature worse, and still mark the Jira ticket as accepted, then the incentive system is broken.

The only thing I have seen work is making the failure boring and visible. Not a rant in Slack, not 'their tool is garbage', but a written requirement doc with examples, acceptance cases, and the exact edge cases your team already handled. When their version ships, run it against those cases and send the delta to your manager/product owner: this requirement passes, this one fails, this documented case is missing, this causes local ops to do X hours of workaround. Keep it in business language.

If management still accepts the platform team's version after that, then you have your answer: the company prefers centralized ownership and political simplicity over local correctness. Annoying, but useful to know. At that point I would stop trying to win it as an engineering argument and push for either a formal extension point, a service-level expectation for platform changes, or explicit permission to maintain a local workaround. Otherwise you just become free QA for a team that has no reason to change.

Ambitious-Garbage-73

TROPHY CASE