We might all be AI engineers now • Hacker News Board

Re: We might all be AI engineers now

#321

Post by samiv » Sat, Mar 07, 2026, 3:41 AM UTC

johnfn wrote: post #309

samiv wrote: post #305

Earlier quoted context omitted.

AI will naturally draw people who are lazy and not interested in learning. It's like flipping through a math book and nodding to yourself when you look at the answers and thinking you're learning. But really you aren't because the real learning requires actually doing it and solving and struggling through the problems yourself.

This is just completely inaccurate. There is more to learn now than ever before, and I find myself spending more and more time teaching myself things that I never before would have been able to find time to understand.

This is just completely inaccurate. There's the same amout of information available as before. It's not like LLMs provide you with information that isn't available anywhere else.

But I agree that it can serve as a tool for a person who it's interested in learning but I bet you that for every such person there's 10x as many who are happy to outsource all their thinking to the machine.

We already have reports from basically every school in the world struggling with this exact problem. Students are just copy pasting LLMs and not really learning.

Re: We might all be AI engineers now

#322

Post by bryanrasmussen » Sat, Mar 07, 2026, 3:43 AM UTC

_zagj wrote: post #303

bryanrasmussen wrote: post #291

Earlier quoted context omitted.

>I'm using Claude every day, and it definitely makes me faster but.. I see a lot of posts about this, and I see a lot studies, also on HN, that show that this isn't the case. Now of the course the "this isn't the case" stuff is statistically, thus there can be individual developers whom are faster, but there can also be that an individual developer sometimes is faster and sometimes not but the times that they are fas…

> I see a lot of posts about this, and I see a lot studies, also on HN, that show that this isn't the case. Most of these studies were done one or more years ago, and predate the deployment and adoption of RLHF-based systems like Claude. Add to that, the AI of today is likely as bad as it's ever going to be (i.e., it's only going to get better). Though I do think the 10x claims are probably unfounded.

I mean obviously things will always be a little bit behind that one reads about, so this is one of the claims I see sometimes about these studies is they are out of date, and if working with the new models they would find that wasn't the case. but then that is one of the continuing claims one also sees about LLMS, that the newest model fixes whatever issue one is complaining about. And then the claim gets reiterated.

The thing is when I use an AI I sort of feel these gains, but not any greatness, it's like wow it would have taken me days to write all this reasonable albeit sort of mediocre code. I mean that is definitely a productivity gain. Because a lot of times you need to write just mediocre code. But there are parts where I would not have written it like that. So if I go through fixing all these parts, how much of a gain did I actually get?

As most posters on HN I am a conceited jerk, so I can claim that I have worked with lots of mediocre programmers (while ignoring the points where I was mediocre by thinking oh that didn't count I followed the documentation and how it was suggested to use the API and that was a stupid thing to do) and I certainly didn't fix everything that they did, because there just wasn't enough hours in the day.

And they did build stuff that worked, much of the time, so now I got an automated version of that. sweet. But how do I quantify the productivity? Since there are claims put forth with statistical backing that the productivity is illusory.

This is just one of those things that tend to affect me badly, I think X is happening, study shows X does not happen. Am I drinking too much Kool-Aid here or is X really happening!!? How to prove it!!? It is the kind of theoretical, logical problem seemingly designed to drive me out of my gourd.

Re: We might all be AI engineers now

#323

Post by prescriptivist » Sat, Mar 07, 2026, 3:46 AM UTC

bryanrasmussen wrote: post #291

overgard wrote: post #276

Earlier quoted context omitted.

I'm using Claude every day, and it definitely makes me faster but.. I'm also able to give it a lot of very specific instructions and correct a lot of mistakes quickly because I look at the code and understand what it's doing; and I'm also asking it to write code in domains I understand. So I don't think these skills are obsolete at all. If anything, keeping them sharp is the only differentiator we have. "Agentic Engi…

>I'm using Claude every day, and it definitely makes me faster but.. I see a lot of posts about this, and I see a lot studies, also on HN, that show that this isn't the case. Now of the course the "this isn't the case" stuff is statistically, thus there can be individual developers whom are faster, but there can also be that an individual developer sometimes is faster and sometimes not but the times that they are fas…

I'm a principal engineer, been working on the same set of codebases for almost 10 years. I handle the 20% or so of my time that constitutes inbound faster than ever and I know because that inbound volume has clearly increased and yet I have, for the first time ever, begun chipping away at the "nice to have" backlog. My biggest time sink now is interviewing and code reviews -- the latter being directly proportional to the velocity increase across the teams I work with. Actually that's my biggest concern -- we are approaching a breaking point for code review volume.

Sorry I don't have DX stats or token usage stats I can share, but based on the directives from on high, those stats are highly correlated (in the positive).

[edit] And SEV rates are not meaningfully higher.

Re: We might all be AI engineers now

#324

Post by katalenia » Sat, Mar 07, 2026, 4:01 AM UTC

holyra wrote: post #38

what about the environmental impact of AI, especially agentic AI? I keep reading praise for AI on the orange site, but its environmental impact is rarely discussed. It seems that everyone has already adopted this technology, which is destroying our world a little more.

[dead]

Re: We might all be AI engineers now

#325

Post by [deleted] » Sat, Mar 07, 2026, 4:13 AM UTC

lll-o-lll wrote: post #317

prescriptivist wrote: post #193

Earlier quoted context omitted.

I don't think that people who don't want to use these tools or clean old ways are incurious. But I think these developers should face the fact that those skills and those ways they are reticent to give up are more or less obviated at this point. Not in the future, but now. It's just that the adoption of these tools isn't evenly distributed yet. I think there's a place for thoughtful dialogue around what this means fo…

> I think these developers should face the fact that those skills and those ways they are reticent to give up are more or less obviated at this point. Yes. We are this generations highly skilled artisans, facing our own industrial revolution. Just as the skilled textile workers and weavers of early 19’th century Britain were correct when they argued this new automated product was vastly inferior, it matters not at al…

[deleted]

Re: We might all be AI engineers now

#326

Post by Covenant0028 » Sat, Mar 07, 2026, 4:26 AM UTC

zdragnar wrote: post #138

squidbeak wrote: post #100

Earlier quoted context omitted.

A market has to exist for this expanded range and for the expanded ranges of every other bakery. Otherwise the bakery's just wasting flour. Where is this expanded demand coming from?

Two loaves of bread off the same line are perfect substitutes for each other, and compete to be sold. Lines of code within the same code base aren't competing to be sold. They either complement each other by adding new features, making the actual product sold more valuable, or one replaces another to make a feature more desirable- look better, work faster, etc. The market grows if you add new features- your bread now…

Adding new features doesn't necessarily grow the market. Your bread with nuts and berries competes with the regular bread for the customer's money. Other things also compete for the same money, such as medical, daycare, schooling etc. So increasing features won't necessarily grow the market because the market. Even in an optimistic scenario, those features only have a probability of increasing revenue, it's not certain.

OTOH, if you fire those workers, it is a certainty that your bakery gets more cash. You can then use that cash to reward your shareholders (a category that conveniently includes you) via buybacks or dividends.

Re: We might all be AI engineers now

#327

Post by Jensson » Sat, Mar 07, 2026, 6:45 AM UTC

ericd wrote: post #169

pydry wrote: post #40

Earlier quoted context omitted.

>I just can’t compete in speed and thoroughness I certainly know engineers for which this is true but unfortunately they were never particularly thorough or fast to begin with. I believe you can tell which way the wind is blowing by looking at open source. Other than being flooded with PRs high profile projects have not seen a notable difference - certainly no accelerated enhancements. there has definitely been an ex…

Maybe the bottleneck for most high profile open source is PR review and not coding?

The most thorough review is done when you write the code, it takes much more effort to be as thorough when you read it as when you write it.

So if what you say is true then agentic coding will be net negative for same quality.

Re: We might all be AI engineers now

#328

Post by maltelau » Sat, Mar 07, 2026, 7:14 AM UTC

therealdrag0 wrote: post #266

hansmayer wrote: post #45

Earlier quoted context omitted.

> Consider this oversimplified example: You own a bakery. You have 10 people making 1,000 loaves of bread per month. Now, you have new semi-automatic ovens that allow you to make the same amount of bread with only 5 people. That is actually the case with a lot of bakeries these days. But the one major difference being,the baker can rely with almost 100% reliability that the form, shape and ingredients used will be ex…

Eh accuracy and reliability is a different topic hashed out many times on HN. This thread is about productivity. I’m a staff engineer and I don’t know a single person not using AI. My senior engineers are estimating 40% gains in productivity.

And every time the issue is side-stepped by chatbot proponents.

Accuracy and reliability are necessary to know real productivity. If you have produced code that doesn't work right, you haven't "produced" anything (except in the economic sense of managing to get someone to pay for it).

For example, if you produce 5x more code at 5% reliability, the net result is a -75% change in productivity (ignoring the overhead costs of detecting said reliability).

Re: We might all be AI engineers now

#329

Post by KronisLV » Sat, Mar 07, 2026, 7:45 AM UTC

peteforde wrote: post #310

bryanrasmussen wrote: post #291

Earlier quoted context omitted.

>I'm using Claude every day, and it definitely makes me faster but.. I see a lot of posts about this, and I see a lot studies, also on HN, that show that this isn't the case. Now of the course the "this isn't the case" stuff is statistically, thus there can be individual developers whom are faster, but there can also be that an individual developer sometimes is faster and sometimes not but the times that they are fas…

It's incredibly frustrating arguing these same points, over and over, every time that this comes up. You're asking people who are experienced developers absolutely chewing through checklists and peeking at HN while compiling/procrastinating/eating a sandwich/waiting for a prompt to finish to not just explain but quantify what is plainly obvious to those people, every day. You want us to bring paper receipts, like we…

> It's incredibly frustrating arguing these same points, over and over, every time that this comes up. You're asking people who are experienced developers absolutely chewing through checklists and peeking at HN while compiling/procrastinating/eating a sandwich/waiting for a prompt to finish to not just explain but quantify what is plainly obvious to those people, every day. You want us to bring paper receipts, like we have some incentive to lie to you.

This puts what I have been feeling in the recent months into words pretty concisely!

To me, it really is a force multiplier: https://news.ycombinator.com/item?id=47271883

Of course, I still have to pay attention to what AI is doing, and figure out ways how to automate more code checks, but the gradual trend in my own life is more AI, not less: https://blog.kronis.dev/blog/i-blew-through-24-million-token... (though letting it run unconstrained/unsupervised is a mess, I generally like to make Claude Code create a plan and iterate on it with Opus 4.6, then fire off a review, since getting the Max subscription I don't really need Cerebras or other providers, though I still appreciate them)

At the same time I've seen people get really bad results with AI, often on smaller models, or just expecting to give it vague instructions and get good results, with no automated linters or prebuild checks in place, or just copying snippets with no further context in some random chat session.

Who knows, maybe there's a learning curve and a certain mindset that you need to have to get a benefit from the technology, to where like 80% of developers will see marginal gains or even detriment, which will show up in most of the current studies. A bit like how for a while architecturally microservices and serverless were all the rage and most people did an absolutely shit job at implementing them, before (hopefully) enough collective wisdom was gained of HOW to use the technology and when.

Re: We might all be AI engineers now

#330

Post by salawat » Sat, Mar 07, 2026, 7:56 AM UTC

tern wrote: post #284

salawat wrote: post #68

Earlier quoted context omitted.

You think you know what taste is. Have you been cranking on real systems all these years, or have you been on the sidelines armchairing the theoretics? I'm not trying to come across as rude, but it may be unavoidable to some degree when indirect criticism becomes involved. A laboring engineer has precious little choice in the type of systems available on which to work on. Fundamentally, it's all going to be some vari…

You seem to be saying two things. For me, the answer is: I've been somewhere in the middle—working on real projects, sure. I've been employed as a software developer in the past, and I've worked with startups and corporations. I've also worked in academia. Have I spent years, personally grinding directly in the belly of the beast? No. I managed a small dev team in small startup once. Yeah, it's not the same thing. I…

I envy you to be honest. My muse doesn't bring me visions of sublime beauty. No melodies, landscapes, scenes or plays in the mind's eye. Just blueprints, system diagrams, feedback loops, crystalized reasoning, probable futures, things going wrong, breaking. Never in a way that seems to be communicable to galvanize more than a couple people who probably already know what I'm seeing deep down in their hearts. But... I'm trying. I flubbed the middle. The point was, no one at the bottom can unseat the people at the top or their optimization function from inside the system, playing by it's rules. Unless we all align on something to force a change; the system's stable & will remain so. There's just one outcome, and it ain't pretty for most of us. I can't even bring myself to throw my weight in as much as I used to, because I just can't not see the patterns everywhere I look now. Didn't mean to be rude. Just. Tired. So, so, very tired. The kind sleep won't fix. Whatever your art form... May you get good inspiration, and may the work to realize lighten your soul in the doing, and everyone's around you. Mine... Certainly doesn't.