Live data from Hacker News

We might all be AI engineers now

yasint.dev

231–240 of 384 posts

Re: We might all be AI engineers now

#231
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…

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…

You are correct. You absolutely must fill the token space with unanbiguous requirements, or Claude will just get "creative". You don't want the AI to do creative things in the same way you don't want an intern to do the same.

That said, I have found that I can get a lot of economy from speaking in terms of jargon, computer science formalisms, well-documented patterns, and providing code snippets to guide the LLM. It's trained on all of that, and it greatly streamlines code generation and refactoring.

Amusingly, all of this turns the task of coding into (mostly) writing a robust requirements doc. And really, don't we all deserve one of those?

Re: We might all be AI engineers now

#232
post #128

I'm glad I am no longer in tech because I just don't want to do this. This is not a dig at AI. If I take this article at face value, AI makes people more productive, assuming they have the taste and knowledge to steer their agents properly. And that's possibly a good thing even though it might have temporary negative side effects for the economy. >But the AI is writing the traversal logic, the hashing layers, the wat…

Might I ask how you make a living now?

Re: We might all be AI engineers now

#233

I don't agree with the headline of "we're all AI engineers now", but I do agree that AI is more of a multiplier than anything. If you know what you're doing, you go faster, if you don't, you're just making a mess at a record pace. I'm not sure how this sustains though; like, I can't help but think this technology is going to dull a lot of people's skills, and other people just aren't going to develop skills in the fi…

[dead]

Re: We might all be AI engineers now

#234

Right now I'm working two AI-jobs. I build agents for enterprises and I teach agent development at a university. So I'm probably too deep to see straight. But I think the future of programming is english. Agent frameworks are converging on a small set of core concepts: prompts, tools, RAG, agent-as-tool, agent handoff, and state/runcontext (an LLM-invisible KV store for sharing state across tools, sub-agents, and pro…

> The job becomes naming, describing, and instructing and then wiring those pieces together with something more akin to flow-chart programming.

That's precisely what peoples are bad at. If people don't grasp (even intuitively) the concept of finite state machine and the difference between states and logic, LLMs are more like a wishing well (vibes) than a code generator (tooling for engineering).

Then there's the matter of technical knowledge. Software is layers of abstraction and there's already abstraction beneath. Not knowing those will limit your problem solving capabilities.

Re: We might all be AI engineers now

#235

"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…

AI gave you the option of making it happen without learning anything.

It also gives you an avenue to accelerate your learning if that is your goal.

Re: We might all be AI engineers now

#236
So far the issue for me is that you can generate more crap by far than you can keep an eye on.

Once you have your 50k line program that does X are you really going to go in there and deeply review everything? I think you're going to end up taking more and more on trust until the point where you're hostage to the AI.

I think this is what happens to managers of course - becoming hostage to developers - but which is worse? I'm not sure.

Re: We might all be AI engineers now

#237

"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…

I'm conflicted about this. On one hand, I think LLMs make it easier to discover explanations that, at least superficially, superficially "click" for you. Sure, they were available before, but maybe in textbooks you needed to pay for (how quaint), or on websites that appeared on the fifth page of search results. Whatever are the externalities of that, in the short term, that part may be a net positive for learners. On…

> learning is doing;

I could not agree more.

Re: We might all be AI engineers now

#238

I am running local offline small models in the old fashioned REPL style, without any agentic features. One prompt at a time. Instead of asking for answers, I ask for specific files to read or specific command line tools with specific options. I pipe the results to a file and then load it into the CLI session. Then I turn these commands into my own scripts and documentation (in Makefile). I forbid the model wandering…

> I ask straight questions and look for straight answers. One line at a time, one file at a time.

I've also taken to using the Socratic Method when interrogating an LLM. No loaded questions, squeaky clean session/context, no language that is easy to misinterpret. This has worked well for me. The information I need is in there, I just need to coax it back out.

I did exactly this for an exercise a while back. I wanted to learn Rust while coding a project and AI was invaluable for accelerating my learning. I needed to know completely off-the-wall things that involved translating idioms and practices from other languages. I also needed to know more about Rust idoms to solve specific problems and coding patterns. So I carefully asked these things, one at a time, rather than have it write the solution for me. I saved weeks if not months on that activity, and I'm at least dangerous at Rust now (still learning).

Re: We might all be AI engineers now

#239
post #35

They will never admit it, but many are scared of losing their jobs. This threat, while not yet realized, is very real from a strictly economic perspective. AI or not, any tool that improves productivity can lead to workforce reduction. 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 sam…

[dead]

Re: We might all be AI engineers now

#240

Earlier quoted context omitted.

I've managed to go my whole career using regex and never fully grokking it, and now I finally feel free to never learn! I've also wanted to play with C and Raylib for a long time and now I'm confident in coding by hand and struggling with it, I just use LLMs as a backstop for when I get frustrated, like a TA during lab hours.

Same there is a few things I never learned and don't care to learn and ultimately it has no greater value to learn. Like do I really get anything out of learning another framework or how some particular library does something?

If you're going to deploy what you make with them to production without accidentally blowing your feet off, 100%, be they RegExp or useEffect(), if you can't even tell which way the gun is pointing how are you supposed to know which way the LLM has oriented it?

Picking useEffect() as my second example because it took down CloudFlare, and if you see one with a tell-tale LLM comment attached to it in a PR from your coworkers who are now _never_ going to learn how it works, you can almost be certain it's either unnecessary or buggy.

Post reply on HN