Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Going full AI engineer, not touching code anymore

max.gp

Post reply on HN
Print view View original

41–50 of 125 posts

Re: Going full AI engineer, not touching code anymore

#41

Post by dboreham »

aselimov3 wrote: post #8

I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…

I'm not sure about this. I think it's much the same as when you work in an organization comprising humans, and many of them are not so right about everything. Perhaps this will be familiar :)

I've noticed that Claude with the current model can act most of the time like a trusted senior engineer sounding board for me. However on occasions we disagree. Recently we had a stand up argument about a proposed solution to a potential security risk in a system. I realized Claude had taken on a kind of "corporate culture" thinking on the problem (which was to do with use of a vault/broker to hold user credential data) that would be appropriate in some contexts, but wasn't in ours. The experience was totally like arguing with someone on the corporate Slack, but in the end I control what gets deployed so I won. But I'd say 90% of the time I get as much value out of Claude on these discussions as I would if I knew one competent person for each of the subjects we discuss, and had called that person for advice. Of course even though my network is...vast...I just don't know a competent person in every single field.

Re: Going full AI engineer, not touching code anymore

#42

Post by lenerdenator »

We're basically doing the same thing where I'm at.

I do see the long-term goal as being the elimination of most engineering positions. If you can have an architect - or, even better, some solution manager talking directly to the customer - just prompt a solution into existing and monitor most of it, you can really reduce the headcount.

Re: Going full AI engineer, not touching code anymore

#43

Post by yehosef »

mariopt wrote: post #33

I’m forcing myself to write code. This idea of reviewing an architecture that you never coded is just a fantasy. At some point in time, me and a lot of people, thought that using Redux was a great idea until we had to manage verbosity and middlewares. Now we had to deal with the consequences of our decisions and we learned. I also think this article is just a rage bait

can an architect review a system he didn't design or build?

Re: Going full AI engineer, not touching code anymore

#44

Post by sebastianconcpt »

CharlieDigital wrote: post #19
aselimov3 wrote: post #8

I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…

> Slowly your brain just gets trained to mid thinking like an LLM Regression to the mean. I am doing a lot of the code reviews on my team and I can see that LLMs have a hard time with OOP (or are perhaps specifically guided to avoid) and writes a lot of `private static` utility functions. A lot of duplicated small utilities that can end up becoming a maintenance nightmare should the behavior need to be normalized/fix…

Predictable yeah. We're far better to find the right overarching narrative of the architecture and the necessary intermediate layers of abstractions. LLMs will invent verbal structs that sound okay but not have the elegance of a senior OOP. Although once the good foundation is there, agents can be great at extending and maintaining features on it.

Re: Going full AI engineer, not touching code anymore

#45

Post by dijksterhuis »

jrflo wrote: post #15
hootz wrote: post #3

But the question is, will this atrophy our ability to write and understand code? Is reviewing enough? Won't we inevitably get lazy and stop reading enough code? Reading always was a worse way to learn than doing. When we stop doing, we will have to triple our reading (if that's even enough), but will we do that or just trust the agents more and more?

I wonder if people thought something similar when moving from writing low level machine code by hand to high-level languages. No one looks at the actual machine instructions anymore! Will our ability to understand low level instructions atrophy?

reality is more nuanced. some people still need to inspect machine code by hand. people who primarily write SaaS django boilerplate don’t. the arguments were made back then, im sure.

but, according to the worst offending and persistent ai-hyper comments on this site, this is apparently a paradigm shift unlike anything that’s done before. according t them we don’t even need to understand high level languages, let alone machine code. which is frankly ridiculous.

i’m an “AI luddite”. but i accept there are useful use cases. that’s not where all the wasted money is going though.

Re: Going full AI engineer, not touching code anymore

#46

Post by spwa4 »

CharlieDigital wrote: post #19
aselimov3 wrote: post #8

I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…

> Slowly your brain just gets trained to mid thinking like an LLM Regression to the mean. I am doing a lot of the code reviews on my team and I can see that LLMs have a hard time with OOP (or are perhaps specifically guided to avoid) and writes a lot of `private static` utility functions. A lot of duplicated small utilities that can end up becoming a maintenance nightmare should the behavior need to be normalized/fix…

This sounds very much like a problem of the context, that should be solvable by having a file with instructions on how to do generic utilities somewhere in the code (e.g. AGENTS.md)

Re: Going full AI engineer, not touching code anymore

#47

Post by add-sub-mul-div »

Most of the AI submissions are from people who are here to self-promote their own content and have little to no other participation. It's like this stuff appeals to a different audience than made up this site 5 years ago. Everything and everyone feels so nonsubstantive now.

Re: Going full AI engineer, not touching code anymore

#48

Post by snek_case »

jrflo wrote: post #15
hootz wrote: post #3

But the question is, will this atrophy our ability to write and understand code? Is reviewing enough? Won't we inevitably get lazy and stop reading enough code? Reading always was a worse way to learn than doing. When we stop doing, we will have to triple our reading (if that's even enough), but will we do that or just trust the agents more and more?

I wonder if people thought something similar when moving from writing low level machine code by hand to high-level languages. No one looks at the actual machine instructions anymore! Will our ability to understand low level instructions atrophy?

The difference is that LLMs are not compilers. You can't trust the output to be correct. They routinely make bad design choices. If you're prototyping some kind of throwaway MVP, you're just sketching something, it's probably fine not to review it. If you're trying to build a piece of software that's going to survive for years, why are you doing this? The tech is clearly not yet fully mature.

Just yesterday, I was trying to use Claude Opus 4.7 to debug an issue in a program that I wrote, and its solution was to remove a feature, change the design to eliminate the problem without consulting me. I only found out that it had removed this feature through testing. Imagine not reviewing things like that. How can people argue for this with a straight face? We'll probably get there eventually, but there's no need to rush before the tech is ready. Doing that is just being clueless.

Re: Going full AI engineer, not touching code anymore

#49

Post by fnoef »

"The fun part was never lifting weight. The fun was in being buffed with a 6-pack and picking up women. The fun is in bullying those who are weaker than me. I never liked going to the gym and lifting weights. What I actually love is the result of the lifting, but I never wanted to do the hard work".

Not saying this is a 1:1 parallel, or that writing is what makes you a good coder, but I do wonder - if you remove the entire process of making something, what is left there? Sure, people keep arguing that architecting or "managing" AI agents is the actual moat, but is this really? If you do not participate in the craft itself, how would you get better?

I mean, I have amazing ideas for wooded furniture I'd like to build. I doubt that if you give me an LLM connected to a router that I would be able to build something by "architecture, review, push back, and argue". I simply lack the knowledge to make something out of wood. And the only way to get this knowledge is to go and make something and not "architect, review, push back, and argue".

Re: Going full AI engineer, not touching code anymore

#50

Post by aselimov3 »

kbuchanan wrote: post #16
aselimov3 wrote: post #8

I think the main issue with this approach is that your solution space eventually narrows. You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative LLM generated one. I’ve noticed this recently as all my side project work is being done by hand. If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think…

I agree this is a problem too, but I suspect mostly for novel(ish) software problems. For me, LLMs have expanded the solution space, because, while I used to be decent with SQL in Postgres, now I'm operating on a whole new level—the LLM's ability to make sense of Postgres' full suite of options, and the performance implications of the queries, is far beyond what I could have accomplished.

That’s a good point but I think this article above would push back on this point slightly. I certainly am able to do a lot more with LLMs because it can produce a passable solution in a lot of places but I’m not sure it expands my solution space really. I tend to separate what I’m able to build and what I’m able to solve. I can build a frontend with an LLM but I don’t think I’m able to solve frontend engineering problems.
Post reply on HN