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

Vibe coding and agentic engineering are getting closer than I'd like

simonwillison.net

Post reply on HN
Print view View original

141–150 of 958 posts

Re: Vibe coding and agentic engineering are getting closer than I'd like

#141

Post by k__ »

murukesh_s wrote: post #75
QuantumNomad_ wrote: post #7

People in the future are going to wonder what the hell we were thinking, when 30 years down the line everything is a hot mess of billions of lines of code generated by LLMs that no human has read almost any of it and is no longer possible for anyone to maintain neither with nor without LLMs. And the LLM generated garbage will have drowned out all of the good quality code that ever existed and no one will be able to f…

Hello from assembly programmers to present day javascript folks. Joke aside, I sometimes think how VS Code is written in such layers and layers of code - ~200mb of minified code - Java based IDEs were worser with almost 1GB of code (libs/dependencies). And VS Code did beat native editors (Sublime) of its time to dominate now - may be because of the business model (open & free vs freemium). But it does the job quite w…

To be fair, MS send a world class engineer to make JavaScript usable for codebases at that scale.

Re: Vibe coding and agentic engineering are getting closer than I'd like

#142

Post by BowBun »

galkk wrote: post #139

Given rapidly decelerating quality of, at least, claude code output, the agentic coding use may decrease. It is insane how bad the results of background agents are now: constant hallucinations, nonsensical outputs.

The heavy users of Claude at my job disagree (me included), our work gets shipped and the quality has increased by all metrics. Are you talking about enterprise or consumer Claude subscriptions? I think they're serving drastic different quality depending on how much $ you fork up.

Re: Vibe coding and agentic engineering are getting closer than I'd like

#143

Post by exographicskip »

drmajormccheese wrote: post #65

There are techniques for improving our confidence in our software: unit testing, integration testing, fuzz testing, property-based testing, static analysis, model checking, theorem proving, formal methods, etc. The LLM is not only a tool for generating lines of code. It can also generate lines of testing. The goal is that the tests are easier to audit by the humans than the code.

I've found that one of the areas I enjoyed least is now what I spend a lot of time on now: testing!

Property-based testing in particular has uncovered a number of invariants in every code base I've introduced it to.

tbf depending on the agent/model a lot of the tests end up being thrown out so it's possible I _should_ handwrite more tests, but having better prompts and detailed plans seems to mitigate that somewhat

Re: Vibe coding and agentic engineering are getting closer than I'd like

#144

Post by techblueberry »

xienze wrote: post #26

> And that feels about right to me. I can plumb my house if I watch enough YouTube videos on plumbing. I would rather hire a plumber. I don't buy this argument at all. I think if we could pay $20/month to a service that would send over a junior plumber/carpenter/electrician with an encyclopedic knowledge of the craft, did the right thing the majority of the time, and we could observe and direct them, we'd all sign up…

> I think if we could pay $20/month to a service that would send over a junior plumber/carpenter/electrician with an encyclopedic knowledge of the craft, did the right thing the majority of the time, and we could observe and direct them, we'd all sign up for that in a heartbeat.

I don’t think this comparison quite works (or maybe I think it works and is wrong) and I think it has something to do with creativity or the initial ideation.

I would do this, but I’m a jack of all trades. I built my own diner booth in my kitchen recently. But my wife, who loves the diner booth, just doesn’t really want to get over the hump of figuring out what she might want. I think most people want to offload the mental load of figuring out where to start.

Most people aren’t just bored by coding, they’re bored or overwhelmed by the idea of thinking about software in the first place. Same with plumbing or construction, most people aren’t hiring someone to direct, they’re hiring a director.

Even I have this about some things, sometimes I choose to outsource the full stack of something to give me more space to do creativity elsewhere.

Re: Vibe coding and agentic engineering are getting closer than I'd like

#145

Post by jcalx »

ativzzz wrote: post #10
QuantumNomad_ wrote: post #7

People in the future are going to wonder what the hell we were thinking, when 30 years down the line everything is a hot mess of billions of lines of code generated by LLMs that no human has read almost any of it and is no longer possible for anyone to maintain neither with nor without LLMs. And the LLM generated garbage will have drowned out all of the good quality code that ever existed and no one will be able to f…

By then, the fix will be easy. Fire up the latest LLM, point it at your codebase and tell it "rewrite this from scratch. do it well. fix the architecture mistakes"

There is definitely going to be some Wirth's law-like [0] effect about the asymmetry of software complexity outpacing LLMs' abilities to untangle said software. Claude 9.2 Optimus Prime might be able to wrangle 1M LoC, but somehow YC 2035 will have some Series A startup with 1B+ LoC in prod — we'll always have software companies teetering on the very edge of unmaintainability.

[0] https://en.wikipedia.org/wiki/Wirth%27s_law

Re: Vibe coding and agentic engineering are getting closer than I'd like

#146

Post by Daishiman »

kashyapc wrote: post #82
devin wrote: post #39

> If you can go from producing 200 lines of code a day to 2,000 lines of code a day, what else breaks? The entire software development lifecycle was, it turns out, designed around the idea that it takes a day to produce a few hundred lines of code. And now it doesn’t. It is so embarrassing that LOC is being used as a metric for engineering output.

[flagged]

LOC is very much an effective metric for general productivity for the median feature. You can't code golf most lines of code out of existence.

We're also assuming LOC vibe coded by competent engineers who should be able to tell when something is overengineered.

Re: Vibe coding and agentic engineering are getting closer than I'd like

#148

Post by skydhash »

michelb wrote: post #104
QuantumNomad_ wrote: post #7

People in the future are going to wonder what the hell we were thinking, when 30 years down the line everything is a hot mess of billions of lines of code generated by LLMs that no human has read almost any of it and is no longer possible for anyone to maintain neither with nor without LLMs. And the LLM generated garbage will have drowned out all of the good quality code that ever existed and no one will be able to f…

If 30 years down the line I still have to look at code, maintain code, or even worry in the slightest about code, something went deeply wrong.

Code will never go away. Code was there before computer hardware and it will always be there. Code is (almost?) all of computation theory so unless we throw computers away, we shall always use code.

Re: Vibe coding and agentic engineering are getting closer than I'd like

#150

Post by ryandrake »

embedding-shape wrote: post #119
datsci_est_2015 wrote: post #71

Earlier quoted context omitted.

Bad engineers continue being bad, good engineers continue being good. I personally don’t know any colleagues who were good engineers just because they wrote code faster. The best engineers I know were ones who drew on experience and careful consideration and shared critical insights with their team that steered the direction of the system positively. > Claude, engineer a system for me, but do it good. Thanks!

> I personally don’t know any colleagues who were good engineers just because they wrote code faster Same, if anything, the opposite seems to be true, the ones that I'd call "good engineers" were slower, less panicked when production was down and could reason their way (slowly) through pretty much anything thrown at them. Opposite experience, I've sit next to developers who are trying their fastest to restore product…

> Same, if anything, the opposite seems to be true, the ones that I'd call "good engineers" were slower

Unfortunately, a lot of workplaces are ignoring this, believing their engineers are assembly line workers, and the ones who complete 10 widgets per minute are simply better than the ones who complete 5 widgets per minute.

Post reply on HN