Live data from Hacker News

We might all be AI engineers now

yasint.dev

151–160 of 384 posts

Re: We might all be AI engineers now

#151

"You can learn anything now. I mean anything." This was true before before LLMs. What's changed is how much work it is to get an "answer". If the LLM hands you that answer, you've foregone learning that you might otherwise have gotten by (painfully) working out the answer yourself. There is a trade-off: getting an answer now versus learning for the future. I recently used an LLM to translate a Linux program to Window…

It always comes down to economics and then the person and their attitude towards themselves. Some things are worth learning deeply, in other cases the easy / fast solution is what the situation calls for. I've thought recently that some kinds of 'learning' with AI are not really that different from using Cliffs Notes back in the day. Sometimes getting the Cliffs Notes summary was the way to get a paper done OR a way…

I’ve always like the essential/accidental complexity split. It can be hard to find, but for a problem solving perspective, it may defines what’s fun and what’s a chore.

I’ve been reading the OpenBSD lately and it’s quite nice how they’ve split the general OS concepts from the machine dependent needs. And the general way they’ve separated interfaces and implementation.

I believe that once you’ve solve the essential problem, the rest becomes way easier as you got a direction. But doing accidental problem solving without having done the essential one is pure misery.

Re: We might all be AI engineers now

#152
post #89

Earlier quoted context omitted.

Seems strange, for decades we allowed developers to use what made them comfortable, you like notepad? go ahead and use it. Don't want an LSP? that's fine disable it. So long as their productivity was on par with the rest of the team there was no issue. Suddenly, everyone needs to use this new tool (which we haven't proven to actually be effective) and if you don't you don't belong in the industry.

> So long as their productivity was on par with the rest of the team there was no issue. Emphasis added. And anyway, for most software dev in most shops it wasn't true; most development takes place in whatever IDE the group/organization standardized on for the task, to make sure everyone gets proper tooling and to make collaboration and information sharing easier. Think of all the Java enterprise software developed b…

> It's only with the emergence of whiny, persnickety Unix devs who refused to leave the comforting embrace of their editor of choice that shops in the internet/dotcom/startup tradition embraced a "use whatever tools you want" philosophy. They had uncharacteristically enormous leverage over the tech stack being deployed in such businesses and could force employers to make that concession. And anyway, what some of them could do with vi blew the boss's mind.

They had enormous leverage because they were more productive then the drones who use whatever tools they are handed and lack the curiosity to use anything else. These breathless reports of increased productivity are constant, but why is there no evidence of that productivity increase otherwise? Why hasn't there been a surge of side-project video games on Steam? Why is github down so often despite Microsoft's commitment to AI?

The AI tools make it easier to do things that were already easy, but the minute your code gets interesting these tools are an absolute mess.

Re: We might all be AI engineers now

#153

"You can learn anything now. I mean anything." This was true before before LLMs. What's changed is how much work it is to get an "answer". If the LLM hands you that answer, you've foregone learning that you might otherwise have gotten by (painfully) working out the answer yourself. There is a trade-off: getting an answer now versus learning for the future. I recently used an LLM to translate a Linux program to Window…

That's not what the author means. Multiple times a day, I have conversations with LLMs about specific code or general technologies. It is very similar to having the same conversation with a colleague. Yes, the LLM may be wrong. Which is why I'm constantly looking at the code myself to see if the explanation makes sense, or finding external docs to see if the concepts check out. Importantly, the LLM is not writing cod…

Yeah, it's a great way for me to reduce activation energy to get started on a specific topic. Certainly doesn't get me all the way home, but cracks it open enough to get started.

Re: We might all be AI engineers now

#154

"You can learn anything now. I mean anything." This was true before before LLMs. What's changed is how much work it is to get an "answer". If the LLM hands you that answer, you've foregone learning that you might otherwise have gotten by (painfully) working out the answer yourself. There is a trade-off: getting an answer now versus learning for the future. I recently used an LLM to translate a Linux program to Window…

That's not what the author means. Multiple times a day, I have conversations with LLMs about specific code or general technologies. It is very similar to having the same conversation with a colleague. Yes, the LLM may be wrong. Which is why I'm constantly looking at the code myself to see if the explanation makes sense, or finding external docs to see if the concepts check out. Importantly, the LLM is not writing cod…

I kinda wonder to what extent grad students’ experience grading projects and homework will end up being a differentiating skill. 75% kidding.

Re: We might all be AI engineers now

#155

Earlier quoted context omitted.

I wrote it myself. But the irony isn't lost on me. "Who did what" is kind of the whole point of the article. Appreciate the feedback.

FWIW I reported your post to the mods because it reads completely AI generated to me. My judgement was that it might have been slightly edited but is largely verbatim LLM output. Some tells that you might wanna look at in your writing, if you truly did write it yourself without Any LLM input are these contrarian/pivoting statements. Your post is full of these and it is imo the most classic LLM writing tell atm. These…

The LLMs are training "us" now.

First we develop the machines, then we contort the entire social and psychic order to serve their rhythms and facilitate their operation.

Re: We might all be AI engineers now

#156
post #98

I vibe coded a Kubernetes cluster in 2 days for a distributed compilation setup. I've never touched half this stuff before. Now I have a proof of concept that'll change my whole organization. That would've taken me 3 months a year ago, just to learn the syntax and evaluate competing options. Now I can get sccache working in a day, find it doesn't scale well, and replace it with recc + buildbarn. And ask the AI questi…

> I vibe coded a Kubernetes cluster in 2 days for a distributed compilation setup. I've never touched half this stuff before. Now I have a proof of concept that'll change my whole organization.

Dunning-Kruger as a service. Thank God software engineers are not in charge of building bridges.

Looking forward to your post-mortem.

Re: We might all be AI engineers now

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

Environment impact is overstated. If you've ever looked at the numbers vs your daily carbon impact, you'd realize this.

Re: We might all be AI engineers now

#158
post #34
post #3

Not a day goes by that a fellow engineer doesn't text me a screenshot of something stupid an AI did in their codebase. But no one ever mentions the hundreds of times it quietly wrote code that is better than most engineers can write. The catch about the "guided" piece is that it requires an already-good engineer. I work with engineers around the world and the skill level varies a lot - AI has not been able to bridge…

I am solidly in this "curious" camp. I've read HN for the past 15(?) years. I dropped out of CS and got an art agree instead. My career is elsewhere, but along the way, understanding systems was a hobby. I always kind of wanted to stop everything else and learn "real engineering," but I didn't. Instead, I just read hundreds (thousands?) of arcane articles about enterprise software architecture, programming language d…

But that knowledge was never hidden or out of reach. Why not read books, manuals, or take online classes? There is free access to all these things, the only cost is time and energy.

Everyone has tons of ideas. But every good engineer (and scientist) also knows that most of our ideas fall apart when either thinking deeper or trying to implement it (same thing, just mental or not). Those nuances and details don't go away. They don't matter any less. They only become less visible. But those things falling apart is also incredibly valuable. What doesn't break is the new foundation to begin again.

The bottleneck has never been a shortage of ideas nor the hands to implement them. The bottleneck has always been complexity. As the world advances do does the complexity needed to improve it.

Re: We might all be AI engineers now

#159
post #42

Earlier quoted context omitted.

Even speaking from a pure statistical perspective, it is quite literally impossible for "AI" that outputs world's-most-average-answer to be better than "most engineers". In fact, it's pretty easy to conclude what percentage of engineers it's better than: all it does is it consumes as much data as possible and returns the statistically most probable answer, therefore it's gonna be better than roughly 50% of engineers.…

This is kind of like saying a kid can never become a better programmer than the average of his teachers. IMHO, the reasons not to use AI are social, not logical.

The AI doesn't know what good or bad code is. It doesn't know what surpassing someone means. It's been trained to generate text similar to its training data, and that's what it does.

If you feed it only good code, we'd expect a better result, but currently we're feeding it average code. The cost to evaluate code quality for the huge data set is too high.

Re: We might all be AI engineers now

#160

Earlier quoted context omitted.

One issue is that developers have been trained for the past few decades to look for solutions to problems online by just dumping a few relevant keywords into Google. But to get the most out of AI you should really be prompting as if you were writing a formal letter to the British throne explaining the background of your request. Basic English writing skills, and the ability to formulate your thoughts in a clear manne…

> the ability to formulate your thoughts in a clear manner, have become essential skills for engineering The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible. Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 7. And Some people found error messages they couldn't ignore m…

Oh, we're quoting Dijkstra? I'll add one :)

  by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. ... I claim that a programmer has only done a decent job when his program is flawless and not when his program is functioning properly only most of the time. But I have had plenty of opportunity to observe that this suggestion is repulsive to many professional programmers: they object to it violently! Apparently, many programmers derive the major part of their intellectual satisfaction and professional excitement from not quite understanding what they are doing. In this streamlined age, one of our most under-nourished psychological needs is the craving for Black Magic, and apparently the automatic computer can satisfy this need for the professional software engineers, who are secretly enthralled by the gigantic risks they take in their daring irresponsibility. 

  Concern for Correctness as a Guiding Principle for Program Composition. (EWD 288)
Things don't seem to have changed, maybe only that we've embraced that black box more than ever. That we've only doubled down on "it works, therefore it's correct" or "it works, that's all that matters". Yet I'll argue that it only works if it's correct. Correct in the way they Dijkstra means, not in sense that it functions (passes tests).

50 years later and we're having the same discussions

Post reply on HN