Live data from Hacker News

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

franciscotrindade.me

121–130 of 151 posts

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

#121
post #81
post #78

Earlier quoted context omitted.

Do you feel that layers of abstraction in project management and layers of abstraction in the technology being managed are the same thing?

Obviously not. Abstraction levels in projects management would go from something like: lower, “what should we name individual tasks items” to higher “what personalities are best suited for incident response handling”, or agile vs waterfall. While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?” Edit insertion for clarification: The compiler, framework usage, AI…

> While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?”

Those sound dangerously close to project management decisions. What about tech layers closer to coding?

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

#122
post #113

Earlier quoted context omitted.

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?

Yes, I agree with this fully.

But what’s interesting now is that the degree of determinism is increasing, as the community as a whole keeps refining the individual parts. The importance of spec becomes more obvious when the feedback loop speeds up, from spec to running software. That already made a huge difference in how many think about spec. There are multiple GitHub projects that are "spec only," where the goal is to spec it out in such a way that the software one wants is the inevitable result, if you just input the spec into a AI/harnes.

And the AI gets better, and the harnesses get better. So at some point we probably live in a reality where we can say: "If you spec out the software you want in this specific way, and add in these guidelines in AGENTS.md, and use X AI with Y harness, you almost certainly get identical software out the other end".

And yes "almost" is faaaaar from "always identical output". But the fact that we are even in the game of increasing determinism, in the Spec->AI->Software flow, is just mind-blowingly cool to me.

That is a detour from my main point, though, that on one specific level of analysis (can we move up one level of abstraction and lose some detail understanding, but gain more in productivity), AI, compiler, software frameworks, are all examples of the answer being: Yes.

And I do agree that we need to mitigate the damage that people with less experience can do because they don't know what pitfalls to avoid. But I would rather we focus on fixing that by improving the AI and harness, than the people that just keep saying that "AI is bad". In the same way I would rather make a tractor safer to use, not just complain that it's dangerous because someone drove it into the lake. Because the goal is not to make the perfect deterministic output from a compiler. that's just a step towards the real goal, which should, in my mind, be to help other people solve problems and do useful stuff. In the same way that the goal of the tractor is not to just plow the field, but to plow the field as fast and efficiently as possible so we can feed ourselves.

Wall of text because this topic has been bothering me for a while now, and Im using this thread to sort out my own thinking on it.

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

#123

Earlier quoted context omitted.

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.

You need to take a step back from the "it's always better than you" because you're making objectively false statements based on delusion.

> You just don't know how to harness it with the right context maybe.

Him placing this at the end of all his statements is just screaming, it takes an engineer to get a nicely engineered product. admitting defeat in his own statements over and over, kinda funny.

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

#124
post #81
post #78

Earlier quoted context omitted.

Do you feel that layers of abstraction in project management and layers of abstraction in the technology being managed are the same thing?

Obviously not. Abstraction levels in projects management would go from something like: lower, “what should we name individual tasks items” to higher “what personalities are best suited for incident response handling”, or agile vs waterfall. While technology layers would go from “who has the best transistors tech” to “should we use windows or macOS?” Edit insertion for clarification: The compiler, framework usage, AI…

[dead]

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

#125
post #36

It largely depends on the person. We have several junior engineers who cannot solve a problem without AI. When AI can’t solve it, they just keep trying and failing. And I mean weeks to months late. Then rinse and repeat on the next task. It used to be that they would have been forced to seek help from a senior engineer. Combine the teaching with a real struggle is what makes them better. As it is now, they aren’t bei…

I work at a workplace where the seniors use AI, and I am chastised for asking questions. I end up using the AI as a learning tool instead.

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

#126
post #122

Earlier quoted context omitted.

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

Yes, I agree with this fully. But what’s interesting now is that the degree of determinism is increasing, as the community as a whole keeps refining the individual parts. The importance of spec becomes more obvious when the feedback loop speeds up, from spec to running software. That already made a huge difference in how many think about spec. There are multiple GitHub projects that are "spec only," where the goal is…

> you almost certainly get identical software out the other end

I think you'd get a set of convergent solutions, where the actual implementations might be very different.

This also explains why you might want to keep more artifacts than just the design. There might be different performance overall, or interesting properties/side effects on axes that were not defined in the spec.

Possibly -at the limit- a theoretically 'perfect' spec would be 100% deterministic (eg. by defining the final object code down to the bit) but that wouldn't be a useful operation I don't think?

The other approach to getting bit-perfect output would be to aim for deterministic model runs. But this has numerous issues including making the model less "creative" or "smart" and anyway might not be the thing you actually want (to wit: a working artifact) .

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

#127
post #113

Earlier quoted context omitted.

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?

[deleted]

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

#128

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…

> Code reviews are going away because agents handle it.

So you're producing slop that is going to blow up in your faces. That's your organization's right, but not everyone is interested in giving up on producing a quality product like you guys are.

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

#129
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.

We're way too far down this current UIUX disaster to pretend "sane defaults" is a nice-to-have.

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

#130

Earlier quoted context omitted.

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

In Canada engineering is a regulated term and if you aren’t licensed you can get in serious trouble calling yourself one.

source: I am licensed.

Post reply on HN