Live data from Hacker News

Becoming an AI-Native Engineer

rfitz.io

21–30 of 30 posts

Re: Becoming an AI-Native Engineer

#21
post #3

The more I use LLMs to code, the farther I stray from the joy of coding. I won't regurgitate the common sentiment of it being like pair programming with an oddly spiky profile junior engineer savant. I find my emotions being activated too often in having to recontextualize or reign in or re-orient or repeat. If I wrote code that doesn't work, that is on me. If I have to read code that doesn't work, I didn't write it,…

I definitely hear you on this. I, like most people my age came into coding when it was mostly high level (Javascript, python, etc), yet I watch YouTube videos about things like NES programming using 6502 assembly. Part of me yearns for a time I didn't get to experience where we were closer to the hardware. Screaming at an LLM for giving me outdated methods to a library I'm trying to implement isn't in my ideal workday.

So far, the AI revolution has only given me more work. People have come at me with applications that are 80% done (really more like 50%) that they "vibe coded" and need an actual programmer to finish. These apps would most likely just be a spark in someone's imagination pre-AI.

In a way, this is a positive. I can't say it's been more fun though.

Re: Becoming an AI-Native Engineer

#22

Earlier quoted context omitted.

> The more I use LLMs to code, the farther I stray from the joy of coding. I agree. The way I put it is that it feels like programming has been turned into the job of an editor, when it used to be an author. Of course, editing was always a huge part of programming, probably the biggest part, but I always kinda felt like reviewing and editing was more the "brussel sprouts" part of the job and authoring the "ice cream"…

You can call it editor or you can call it director/architect. Instead of tapping out characters you spend more time making interesting and more high level decisions.

It turns out that the process of "tapping out characters" is (a) never any kind of bottleneck for meaningful product velocity in any kind of meaningful system; and (b) actually important for engineers to do in order to understand the system that they're expected to maintain.

If (a) isn't true for you, then you're operating in a pathological environment, context, organization, etc. which isn't representative of any kind of broader industry experience.

And (b) is usually clear to anyone who's, for example, taken a university course, and compared the efficacy of manual note-taking vs. (say) automatic transcriptions from lectures. The process of parsing the lecture through your brain and into notes that you write yourself, turns out to be essential to information retention and conceptual understanding.

Re: Becoming an AI-Native Engineer

#23
post #2

it’s really hard to be consistently “excited” about this space when half of the AI companies are proudly proclaiming their commitment to try and automate your job (doubtful but the mantra is suffocating) and the other half are just about increasing your productivity (you get more done at the same pay). i guess some boilerplate is truly automated which is a mild qol improvement

Yeah, this is why I don't give them any money. I use their models locally. I use ChatGPT without an account.

I don't remember the WSIWYG editor companies bragging about eliminating jobs by making web development more accessible.

I don't remember No-Code platforms bragging about eliminating jobs by making it easier to build your own website for your business.

I don't remember Arduino bragging about eliminating jobs by making embedded programming more accessible.

I'm not worried too much about my "job" being eliminated, I just have a really hard time giving people money who want me to end up underneath an Oakland overpass in a tent.

Re: Becoming an AI-Native Engineer

#24
post #9

Earlier quoted context omitted.

I've been struggling with the same thing. It's the same reason I didn't really want to go on the management path because it loses the authoring part. But now it seems to be forced on us. That being said, there are lots of brussel sprouts in authoring sometimes - the boilerplate and wrote stuff we've done a billion times. You can make Claude eat those brussel sprouts which is nice. also, very nice analogy, but don't b…

Tangential fun fact! Good tasting brussel sprouts are a very recent invention. They used to be a lot more bitter, but a new cultivar was engineered in the 90's that all but completely eliminated the bitter notes. Over the next 30 years, pretty much everybody has switched over, so now brussel sprouts are just drastically better than they were when they got the reputation for being gross.

Also, it's brussels sprouts. The name comes from the city of Brussels, BE.

Re: Becoming an AI-Native Engineer

#25
post #20

Earlier quoted context omitted.

I totally disagree with this, and that's because (like this blog post says) the output can't be trusted - you still need to review every line of generated code. The recent post I linked in another comment about the Cloudflare OAuth implementation had a catastrophic bug that would have been "game over" if the engineer wasn't such an expert in the field. So it's like an architect but only if you need to triple check ev…

What was the bug, didnt read the CF article

https://news.ycombinator.com/item?id=44167006

Re: Becoming an AI-Native Engineer

#26
post #22

Earlier quoted context omitted.

You can call it editor or you can call it director/architect. Instead of tapping out characters you spend more time making interesting and more high level decisions.

It turns out that the process of "tapping out characters" is (a) never any kind of bottleneck for meaningful product velocity in any kind of meaningful system; and (b) actually important for engineers to do in order to understand the system that they're expected to maintain. If (a) isn't true for you, then you're operating in a pathological environment, context, organization, etc. which isn't representative of any ki…

There's a big difference in criticality of different kinds of software. If the code you're writing will be 'the thing that runs the actual business logic in production' of course you should understand and own the code. And that code is very meaningful in the way you describe.

But so much of the software we need to solve various problems is not mission critical. Like tooling. Or any low stakes software that can be easily replaced. Or some script that makes your life a little bit easier. Or maybe even a small gui app that helps you compose some specific configuration for that other software. Tools where the output is easy to verify and can stand on its own and can't be used by an attacker to exploit your systems.

If you put a lot of effort into tooling that you can throw away the moment better tooling appears you can make the mission critical software leaner.

> actually important for engineers to do in order to understand the system

It is one tool for it and an important one. But it is not the end all tool for understanding or trusting code. If that were the case you'd have to rewrite all code you ever had to maintain. You rely on a stacks of software all the time that you do not write.

AI indeed makes mistakes but so does humans so we have to validate the code we use with multiple such tools.

Re: Becoming an AI-Native Engineer

#27
post #3

The more I use LLMs to code, the farther I stray from the joy of coding. I won't regurgitate the common sentiment of it being like pair programming with an oddly spiky profile junior engineer savant. I find my emotions being activated too often in having to recontextualize or reign in or re-orient or repeat. If I wrote code that doesn't work, that is on me. If I have to read code that doesn't work, I didn't write it,…

Yes, it seems to decrease the fun/satisfying parts of software development and increase the unpleasant parts.

Re: Becoming an AI-Native Engineer

#28
post #22

Earlier quoted context omitted.

It turns out that the process of "tapping out characters" is (a) never any kind of bottleneck for meaningful product velocity in any kind of meaningful system; and (b) actually important for engineers to do in order to understand the system that they're expected to maintain. If (a) isn't true for you, then you're operating in a pathological environment, context, organization, etc. which isn't representative of any ki…

There's a big difference in criticality of different kinds of software. If the code you're writing will be 'the thing that runs the actual business logic in production' of course you should understand and own the code. And that code is very meaningful in the way you describe. But so much of the software we need to solve various problems is not mission critical. Like tooling. Or any low stakes software that can be eas…

In any kind of minimally-effective engineering team, engineers will only ever be working with and maintaining code that's "mission critical" in the sense you're describing here, there won't be any meaningful amount of "non-mission-critical" code worth considering or optimizing.

This is in some sense a didactic assertion: if it's not the case, then your engineering team isn't providing any value beyond what a bash script, gluing-together JIRA tickets and GitHub PRs via the LLM-du-Jour, could do autonomously.

Re: Becoming an AI-Native Engineer

#29
post #28

Earlier quoted context omitted.

There's a big difference in criticality of different kinds of software. If the code you're writing will be 'the thing that runs the actual business logic in production' of course you should understand and own the code. And that code is very meaningful in the way you describe. But so much of the software we need to solve various problems is not mission critical. Like tooling. Or any low stakes software that can be eas…

In any kind of minimally-effective engineering team, engineers will only ever be working with and maintaining code that's "mission critical" in the sense you're describing here, there won't be any meaningful amount of "non-mission-critical" code worth considering or optimizing. This is in some sense a didactic assertion: if it's not the case, then your engineering team isn't providing any value beyond what a bash scr…

I have never worked in an engineering organisation that lives up to that level of efficiency that you seem to describe. Once you scratch the surface there's always a mountain of things that would help people get more efficient that never gets prioritized.

Re: Becoming an AI-Native Engineer

#30
post #28

Earlier quoted context omitted.

In any kind of minimally-effective engineering team, engineers will only ever be working with and maintaining code that's "mission critical" in the sense you're describing here, there won't be any meaningful amount of "non-mission-critical" code worth considering or optimizing. This is in some sense a didactic assertion: if it's not the case, then your engineering team isn't providing any value beyond what a bash scr…

I have never worked in an engineering organisation that lives up to that level of efficiency that you seem to describe. Once you scratch the surface there's always a mountain of things that would help people get more efficient that never gets prioritized.

And I've never worked in an engineering org that _didn't_ live up to the level of efficiency that I'm describing. I guess, seek better employment?
Post reply on HN