Live data from Hacker News

Going full AI engineer, not touching code anymore

max.gp

61–70 of 125 posts

Re: Going full AI engineer, not touching code anymore

#61
post #52
post #15

Earlier quoted context omitted.

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?

It did atrophy, but more importantly understanding what's going on below the code you are writing, even if your project isn't assembly, also atrophied. When you're coding an Electron app with Javascript you're so far removed from any concept of the efficiency a modern CPU can achieve you stop caring about optimization. Speed and memory management don't matter and then you get... well, the modern web.

And the modern web being usable is basically thanks to the people who understand lower level optimization.

Re: Going full AI engineer, not touching code anymore

#62
post #24

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…

> If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written. This is my experience as well, and I've been using Claude Code a lot. Extremely impressive tools, but they're like fast food. They will solve your immediate problems quickly and cheaply, but you're going to have issues on the long term if that's all…

Have you tried drilling into the reasoning when this happens? This is why I usually leave it in "Plan Mode" and when it proposes a solution that seems unusual or unexpected, I point out why I think it is and ask it to justify it's position.

Sometimes I get the "you're right!" response, but often it will also explain why it made the decision it did, and it's rational enough that I accept the new approach.

It's still very much like a junior dev in this way - pretty good at 'just make it work', pretty good at monkey-see-monkey-do, and occasionally surprises you with something novel (to you).

Re: Going full AI engineer, not touching code anymore

#63

What's interesting to me is how many people have found out with the LLM boom that they don't want to be developers/engineers, they want to be managers, delegating all the work to another entity and checking in occasionally to see how the coding is coming along

I’ve found it interesting too.

It’s like I spent 20 years mastering painting in watercolour… nerding out on other painters, canvas options, even the backstory on some guy that makes a specific paint etc.

And I don’t regret any of that. but now I’m just loving creating my art 100x faster.

I thought I loved the craft (and I did) but more, I loved the product.

Re: Going full AI engineer, not touching code anymore

#64

Is anyone doing this who is not making CRUD web-apps or other very common types of programs for which there is masses of training data to copy from the net? I tend to do oddball stuff (eg. software for custom arcade machines, AR games) and any forays I've made into AI code have made it seem like a total waste of time for me. (ie. I will spend much longer trying to get AI do to a shitty job, compared to just doing it…

It is a minefield for structural bio/chem.

Re: Going full AI engineer, not touching code anymore

#65
The problem I have is that I find generic code reviews really, really boring. With agents I write less code but read more code that I didn't write myself, which makes the job more boring than it was.

I would rather let AI do the code reviews and focus on test coverage.

Re: Going full AI engineer, not touching code anymore

#66
post #24

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…

> If I do ask an LLM another question about something small it will offer solutions but doesn’t offer the solution I think makes sense in the architectures I’ve written. This is my experience as well, and I've been using Claude Code a lot. Extremely impressive tools, but they're like fast food. They will solve your immediate problems quickly and cheaply, but you're going to have issues on the long term if that's all…

Fast food might be the right approach if it's a business that prefers speed to maintainability, and they might move towards that with LLMs. I wish more developers would go with it instead of fight it. It's not like it's a personal failure you can't convince the business to slow down and prefer quality.

The quality of the craft can live on in open source and personal projects.

Re: Going full AI engineer, not touching code anymore

#67

Everybody knows you don't go full AI engineer.

You know any AI war heroes? You went full AI engineer, man. Never go full AI engineer. You don't buy that? Ask Roy Lee, 2025, "Cheat On Everything." Remember? Went full AI engineer, went home empty-handed.

Re: Going full AI engineer, not touching code anymore

#68

What's interesting to me is how many people have found out with the LLM boom that they don't want to be developers/engineers, they want to be managers, delegating all the work to another entity and checking in occasionally to see how the coding is coming along

I do not manage LLMs, I manage people. I always considered myself a builder, a creator. The end result is interesting and it's important for me the end result to be just as I envisioned it. Typing code isn't exciting. Thinking, planning, finding solutions and driving the LLM to implement the finished product is.

I'm happy for you that you enjoy being a manager. I'm just saying that a lot of people seem to have found they prefer managing another system writing the code for them asking it nicely to do things, rather than writing code myself. I'm in the camp of enjoying typing code, and I do not want to become a manager, either of LLMs or people

Re: Going full AI engineer, not touching code anymore

#69

What's interesting to me is how many people have found out with the LLM boom that they don't want to be developers/engineers, they want to be managers, delegating all the work to another entity and checking in occasionally to see how the coding is coming along

You seem to think you can only be an engineer if you are holding the shovel yourself.

Building software consists of many parts. I love each individually. I was always a bit dissatisfied about how they interact and how they block each other. I love puzzle solving, I love debugging, but I kinda hated building software because it depended on those elements and I'm not fond of context switching.

I can love building software now. And I didn't become a manager because people bs never interested me. LLM doesn't feel like a person. It feels way better.

Re: Going full AI engineer, not touching code anymore

#70

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…

> You go from formulating unique solutions to flagging things that look wrong and then just picking an alternative Not really. You write the specs, you write the architecture. You ask the model to implement your solution.

But the specs can’t be fully detailed or else they would just be code which is the point the article above makes. You can certainly limit where the LLMs have freedom by writing more detail but obviously that defeats the purpose of LLMs. What I mean more broadly though is more along the lines of baked in solutions. The LLM will generally prefer certain architectures/libraries/patterns. If you develop a spec alongside an LLM (which I think most people do) you will get pushed towards those. You kind of close yourself off to other ways of solving a problem.

You can stop this by detailing exactly what solution you want but I think continuous leaning on the LLM will lead you into a confined space.

Post reply on HN