Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AI didn't erase the junior engineer's value, it increased it it

franciscotrindade.me

Post reply on HN
Print view View original

111–120 of 151 posts

Re: AI didn't erase the junior engineer's value, it increased it it

#111

Post by fzeroracer »

throwatdem12311 wrote: post #33
literallyroy wrote: post #21

Earlier quoted context omitted.

Making changes to someone else’s PR (other than extremely trivial ones) feels like they don’t have much ownership. People often have a reason for doing things the way they did and skipping over them seems like a mistake.

We do architecture reviews now. Code reviews are going away because agents handle it. When I ask an agent to do a code change for a PR, it’s because it’s not something I think the other engineer really should waste their time on. It’s on the same level as nitpicking what lines the braces go on before we had auto-formatters and lint checkers in CI. Other staff engineers I rarely even see their code. I trust them to be…

> We do architecture reviews now. Code reviews are going away because agents handle it.

So you already failed the first part of doing your goddamn job as an engineer which is reviewing and owning code. Code review is a vital part of that, because code ownership is a responsibility shared by your entire team. We used to say that cowboy coders were a disaster for your team and now you're saying everyone on your team is effectively a cowboy coder.

If it turns out claude or whatever LLM you're using pulled in a bad package and now your companies data has been exfiltrated are you going to be the one willing to be fired for your blunder?

Re: AI didn't erase the junior engineer's value, it increased it it

#112

Post by pluralmonad »

throwatdem12311 wrote: post #33
literallyroy wrote: post #21

Earlier quoted context omitted.

Making changes to someone else’s PR (other than extremely trivial ones) feels like they don’t have much ownership. People often have a reason for doing things the way they did and skipping over them seems like a mistake.

We do architecture reviews now. Code reviews are going away because agents handle it. When I ask an agent to do a code change for a PR, it’s because it’s not something I think the other engineer really should waste their time on. It’s on the same level as nitpicking what lines the braces go on before we had auto-formatters and lint checkers in CI. Other staff engineers I rarely even see their code. I trust them to be…

Then does the original author own the changes you made to their PR, e2e? Do you get their signoff on them if that's the case?

Re: AI didn't erase the junior engineer's value, it increased it it

#113

Post by jtrn »

Kim_Bruning wrote: post #105
glouwbug wrote: post #86

Earlier quoted context omitted.

This analogy only works if you’re ready to commit _only prompts_ and have those prompts do a clean “compile” of your production runtime everytime you pull. Are you ready to do that?

It turns out that this almost works. You'd probably want to commit explicit design documents btw, not every last prompt. FWIW, when people try this out in practice, they tend to commit the design docs alongside the generated tests and the generated code. Mutating the docs then leads to mutations in the code. Several friends and I have workflows that look a bit like this, but I know for sure mine isn't 100% strict(yet…

Thank you for the first sensible response that actually engages with the point I made. And your answer is better than mine, and less angry.... :P

The question from glouwbug was just taken for granted to be "no, and therefore the analogy fails." And if I understand your answer, it's basically: "no, but we're visibly closer every quarter, and here's what the intermediate state looks like, and we might even get there"

The interesting thing in all of this to me is what must happen for the same spec to be deterministically certain to generate the same software. Could you delete the code, regenerate from docs alone, and trust the result? And obviously.... not yet. In practice, workflows drift, sometimes you patch the code directly because it's faster, and now code and docs have not been properly updated.

But the entire flow and concept of: [Spec] -> [AI/Harness] -> [Finished software], and how we increasing determinism in that flow, is just immensely interesting to me.

Re: AI didn't erase the junior engineer's value, it increased it it

#115

Post by glouwbug »

jtrn wrote: post #113
Kim_Bruning wrote: post #105

Earlier quoted context omitted.

It turns out that this almost works. You'd probably want to commit explicit design documents btw, not every last prompt. FWIW, when people try this out in practice, they tend to commit the design docs alongside the generated tests and the generated code. Mutating the docs then leads to mutations in the code. Several friends and I have workflows that look a bit like this, but I know for sure mine isn't 100% strict(yet…

Thank you for the first sensible response that actually engages with the point I made. And your answer is better than mine, and less angry.... :P The question from glouwbug was just taken for granted to be "no, and therefore the analogy fails." And if I understand your answer, it's basically: "no, but we're visibly closer every quarter, and here's what the intermediate state looks like, and we might even get there" T…

Right, but hasn't generating the perfect spec always been the _exact_ problem of software development, regardless of language / LLM interface?

Re: AI didn't erase the junior engineer's value, it increased it it

#116

Post by bluefirebrand »

hawaiianbrah wrote: post #108
yifanl wrote: post #89

Earlier quoted context omitted.

You can't, as that removes the main value add of the AI.

I really disagree with that stance. It would be trivial to have it ask you questions about what it produced to ensure you understand. I’ve literally already done that several times.

From what I can tell, the value add for AI seems to be this behavior you're describing

But the value add being marketed is something entirely different, which is where the disconnect is coming in

Re: AI didn't erase the junior engineer's value, it increased it it

#117

Post by bluefirebrand »

pragmatic wrote: post #100
ModernMech wrote: post #56

Earlier quoted context omitted.

Ownership of the delivered code. This takes authorship out of the equation -- doesn't matter who wrote it, only matters who owns it and can be blamed for it. Not having written it doesn't absolve blame when something goes bad.

Ownership of something you have little control over is a great way to burn yourself out. If you constantly have to push back against the eager puppy jr dev who’s 1000% sure their vibe slop is prod ready and has proudly told the admiring crowd of stake holders it’s ready to go, wtf kind of life is that? Now the senior/lead is the bad guy and is in the no win scenario. Yuck.

> If you constantly have to push back against the eager puppy jr dev who’s 1000% sure their vibe slop is prod ready and has proudly told the admiring crowd of stake holders it’s ready to go, wtf kind of life is that? Now the senior/lead is the bad guy and is in the no win scenario

Oh.

You just described my last couple of jobs

I guess that partly explains why I've been miserable and exhausted all the time

Re: AI didn't erase the junior engineer's value, it increased it it

#118

Post by bluefirebrand »

throwatdem12311 wrote: post #43
_joel wrote: post #24

Earlier quoted context omitted.

"Software Engineer" is a thing.

Do you think software engineers just write code or something?

I would bet good money that the vast majority of people who have some variety of "software engineer" as their job title mostly just write code, yes

The concept of software engineer is so watered down at this point it often barely resembles engineering at all

Re: AI didn't erase the junior engineer's value, it increased it it

#119

Post by eudamoniac »

unified101 wrote: post #72
throwatdem12311 wrote: post #66

Earlier quoted context omitted.

Claude writes technical word salad that people hate reading. It’s writing docs nobody looks at and nobody cares about. Technical writing is a skill just like any other form of writing and if you’re bad at it that’s on you. People despise AI slop novels and they also despise AI slop technical documents.

And even with that fable would be more capable than you. You just don't know how to harness it with the right context maybe.

I can't imagine what level of monkeys you've been working with when you can't even imagine a human writing better docs than Claude. Disturbing, frankly.

Re: AI didn't erase the junior engineer's value, it increased it it

#120

Post by dns_snek »

hawaiianbrah wrote: post #108
yifanl wrote: post #89

Earlier quoted context omitted.

You can't, as that removes the main value add of the AI.

I really disagree with that stance. It would be trivial to have it ask you questions about what it produced to ensure you understand. I’ve literally already done that several times.

"Understanding" someone else's solution is not comparable to solving it on your own, even if you can answer some questions about it. It builds extremely fragile surface-level understanding.

That struggle and repeated failure before finally connecting the dots on your own is how you build intuition and deep understanding.

Post reply on HN