Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Probably dance.by whytevuhuni
- Programmers collect visions to express in natural language, then loop attempts to express the vision until it is actualizedby erelong
- Same as before? A fancy compiler that is able to accept code written in natural language still requires a programmer to write the source code.by win311fwg
- Compilers also write code (they write machine code based on high level langs)… yet nobody asked the same question about them (or did they?)
AI needs to be instructed and then some kind of verification of the output is needed. Programmers do that
by sdevonoes - Bad analogy. Compilers don't reason, they don't hallucinate. They take the language as given and "compile" it to the equivalent binary based on strict definitions in the language. It's reproducible and consistent. Saying they write code is factually wrong, at best they translate it.
AI will do the same thing in multiple ways or veer of course and do it another way based on spoken language with no strict syntax. It will make logical leaps, it will guess, it will assume etc.
These things are not equivalent at all.
by datakan - Design. And redesign.by sturza
- and specs, and tests, and smoke tests, and more specs, and updated specs.
And don't forget processes!
by Kim_Bruning - Interesting question. I work on AI for document processing, and I have found the same dynamic: generating a first pass is easy, but the real engineering goes into the verification layer.by madikz
- Edge cases you never think to test: that's where AI output breaks. I deal with this daily in document processing.by madikz
- There are three things programmers bring:
Salience - Agents only know what we bring to their attention
Judgment - Agents cannot make decisions in the larger business context
Responsibility - Agents do not care if they crash the system
by jmcqk6 - Debugging. Lots of debugging. It will be interesting when the researchers look back in 5-10 years to determine which was easier/better - trying to understand generated code vs generating code one understands.
If a functional reasoning layer is added to the current lookup level, “do you want fries with that?” might be in their “doing”. If this doesn’t appear in a timely fashion, de-slopping code will be their lot.
by jleyank - > It will be interesting when the researchers look back in 5-10 years to determine which was easier/better - trying to understand generated code vs generating code one understands
We don't need to wait 5-10 years, we have plenty of experience with this already! Software devs always want to build their own because building it is way easier than grabbing something someone else built and understanding it!
- It really depends on th SDLC of the codebase. I've sat in the park with a pad and pen and wrote down ideas for a small-ish utility that had both a DB and some low level systems interaction. I designed all the interfaces, control flow, and user facing ui. A decade ago I was designing class diagrams with public and private methods, then coding it up. Today I can articulate it with loose words and have it come to life.
The secrete ingredient here is... Im an experienced programmer, I know what to ask and what to look out for. I know sockets and how devices work under the hood and which knobs are available for me to turn. Juniors just don't have enough experience. The question should really be "what do inspiring programmers do?"
- People loke you're the minority. Most people use the brilliant strategy if "prompt and pray"
Because of AI speed is valued over everything else
- - in about 5 yrs of time, this is not going to age well
- massive studies ll come out on how 50% of the software engineers dont know or understand what they "generated" at all and how their critical thinking skills have taken a nosedive
- every major software company out there that is busy firing juniors now is going to run into the opposite problem: finding talented juniors and they ll command a hefty pay
- the whole LLM premise runs on one little assumption that they ll improve indefinitely. you are forgetting the law of diminishing returns
- i ll come back here in 5 yrs, this whole thing wont end well
by vivzkestrel - On your second point... that's the problem... IMO, humans need to read/understand and approve code changes generated by AI. If either through a lack of understanding or skill, they approve changes anyways, that's largely on them an they largely deserve what they get.
Like TFA, I'm a proponent of human gatekeepers in the loop. IMO, the result isn't much better at a team level when you compare dev + ai to a typical team and that level of output... but you get a lot more testing and documentation along the way just through the process refinement and iterations.
I think the harder issue is finding and growing Senior level developers that actually have a material understanding of what is happening and how things are working at a high and low level. The more junior, imo, the more likely someone is to just accept the AI result(s) that introduce more bugs in the process.
by tracker1 - Not since the advent of the compiler have most developers understood what is being generated. Their efforts have instead gone into validation (often manual, but sometimes automated) to see that what was generated works as expected as that is all that really matters to the business goals.
Which is still where the effort is going, although there does seem to be more interest in automated validation now, which is welcome progress.
by win311fwg - I wonder if people said the same when compilers first appeared in the software development scene.
> the whole LLM premise runs on one little assumption that they ll improve indefinitely. you are forgetting the law of diminishing returns
To be honest, I think I'd remain happy if they just stayed at the level they are now, maybe bit faster and cheaper (and ideally more energy efficient), best would be to run it locally too, but I don't really need them to get "better" to make good use of them at this point.