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

371–380 of 958 posts

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

#371

Post by dspillett »

sanderjd wrote: post #337
andai wrote: post #333

Earlier quoted context omitted.

An old comic I like: - I've taken a controversial new pill that accelerates my brain. -- So you're smart now? - I'm stupid faster! That being said, being stupid faster can work if validation is cheap (and exists in the first place). Turns out "eh close enough" for AGI is just stupidity in an "until done" loop. (Technically referred to as Ralphing.)

Yep, validation is key. The smartest thing I've heard on this, which has reoriented how I think about this is that the objective function of a piece of software is now more important to get right than the implementation.

> the objective function of a piece of software is now more important to get right than the implementation

That has always been the case. That is why weeks or even months of programming and other project busy work could replace a couple of days of time getting properly fleshed out requirements down.

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

#372

Post by seanw444 »

dyauspitr wrote: post #203
deadbabe wrote: post #84

Earlier quoted context omitted.

The amount of times an engineer says what the fuck while reading code still seems like a reliable metric for code quality assessment.

We won’t be doing that for much longer, enjoy it while you can.

Two more weeks!

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

#373

Post by jwpapi »

> I know full well that if you ask Claude Code to build a JSON API endpoint that runs a SQL query and outputs the results as JSON, it’s just going to do it right. It’s not going to mess that up. You have it add automated tests, you have it add documentation, you know it’s going to be good.

I feel like this is just not true. An JSON API endpoint also needs several decisions made.

- How should the endpoint be named

- What options do I offer

- How are the properties named

- How do I verify the response

- How do I handle errors

- What parts are common in the codebase and should be re-used.

- How will it potentially be changed in the future.

- How is the query running, is the query optimized.

…

If I know the answer to all these questions, wiring it together takes me LESS time than passing it to Claude Code.

If I don’t know the answer the fastest way to find the answer is to start writing the code.

Additionally, whilst writing it I usually realize additional edge cases, optimizations, better logging, observability and what else.

The author clearly stated the context for this quote is production code.

I don’t see any benefits in passing it to Claude Code. It’s not that I need 1000s of JSON API endpoints.

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

#374

Post by layoric »

etothet wrote: post #33

Vibe Coding (and LLMs) did not create undisciplined engineering organizations or engineers. They exposed and accelerated them. Plenty of engineers have loose (or no!) standards and practices over how they write coee. Similarly, plenty of engineering teams have weak and loose standards over how code gets pushed to production. This concept isn't new, it's just a lot easier for individuals and teams who have never reall…

This is very true, I've found these tools that I am highly encouraged to use very hit and miss, which they are by nature. After using Matt Pocock's skills, I've come around to the idea that LLM's main utility is to act as the ultimate rubber ducky. The `grill-me` feature is honestly the most useful, not for guiding the follow up writing of code, but to make me write down and explore the idea I have more quickly. It's guesses of questions to ask are generally pretty good. I don't believe there is any 'understanding', so I feel the rubber ducky analogy works quite well. This isn't anything you couldn't do before with some discipline, but at least I find it helpful to be more consistent.

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

#375

Post by truncate »

sanderjd wrote: post #336
truncate wrote: post #309

Earlier quoted context omitted.

>> Bad engineers continue being bad, good engineers continue being good. I don't know if good engineers can necessarily continue to be good. There is limit to how much careful consideration one can give if everything is on an accelerated timeline. Regardless good or not, there is limit on how much influence you have on setting those timelines. The whole playing field is changing.

Hmmm, I think I disagree with this. I estimate that I'm now spending about 10 to 30 hours less time a week in the mechanical parts of writing and refactoring code, researching how to plumb components together, and doing "figure out how to do unfamiliar thing" research. All of those hours are time that can now be spent doing "careful consideration" (or just being with my family or at the gym or reading a book, which i…

Maybe we do different things. Not that you are wrong about spending less time on things that you don't care about, but at the same time all that mechanical things helps you build a really good mental model of your product from high level design to individual classes. If I already have a good mental model of that I can direct AI to make really good changes fast, if I don't I will get things done ... but it does end up with less than ideal changes that compounds over time.

What you said: "figure out how to do unfamiliar thing" -- is correct, and will get things done, but overall quality, maintainability or understanding how individual pieces work...that's what you don't get. One can argue who care about all that as AI can take care of that or already can. I don't think its true today at-least.

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

#376

Post by Quekid5 »

jkaptur wrote: post #161
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. However, the best engineers I know are usually among the quickest to open an editor or debugger and use it fluently to try something out. It's precisely that speed that enables a process like "let's try X, hmm, how about Y, no... ok, Z is nice; ok team, here are the tradeoffs...". Then they remember their experience…

> However, the best engineers I know are usually among the quickest to open an editor or debugger and use it fluently to try something out.

That's not my experience... mostly it's about first interrogating the actual problem with the customer and conditions under which it occurs. Maybe we even have appropriate logging in our production application? We usually do, because you know, we usually need to debug things that have already happened.

(If it's new/unreleased code, sure fine, let's find a debugger.)

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

#377

Post by Amber-chen »

The distinction between 'vibe coding' and 'agentic engineering' is important. In my experience, the key difference is whether you're reviewing and understanding the code the agent produces. When I use coding agents for non-trivial tasks, I always review the diff before committing — that's the engineering part. The danger is when people skip that step and just trust the output.

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

#378

Post by datsci_est_2015 »

truncate wrote: post #309
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!

>> Bad engineers continue being bad, good engineers continue being good. I don't know if good engineers can necessarily continue to be good. There is limit to how much careful consideration one can give if everything is on an accelerated timeline. Regardless good or not, there is limit on how much influence you have on setting those timelines. The whole playing field is changing.

> if everything is on an accelerated timeline

Good engineers are also capable of managing expectations. They can effectively communicate with stakeholders what compromises must be made in order to meet accelerated timelines, just as they always have.

We’ve already had conversations with overeager product people what the ramifications are for introducing their vibe coded monstrosities:

  - Have you considered X?
  - Have you considered Y?
Their contributions are quickly shot down by other stakeholders as being too risky compared to the more measured contributions of proper engineers (still accelerated by AI, but not fully vibe-coded).

If that’s not the situation where you work, then unfortunately it’s time to start playing politics or find a new place to work that knows how to properly assess risk.

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

#379

Post by sodapopcan »

Amber-chen wrote: post #377

The distinction between 'vibe coding' and 'agentic engineering' is important. In my experience, the key difference is whether you're reviewing and understanding the code the agent produces. When I use coding agents for non-trivial tasks, I always review the diff before committing — that's the engineering part. The danger is when people skip that step and just trust the output.

That's exactly what TFA is about.

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

#380

Post by Quekid5 »

mleo wrote: post #332
bitexploder wrote: post #120

Earlier quoted context omitted.

Vibe coded apps with barely no tests, invariants, etc. No wonder it turns into spaghetti. You can always refactor code, force agents to write small modular pieces and files. Good engineering is good engineering whether an agent or human wrote the code. Take time to force agents to refactor, explore choices. Humans must at least understand and drive architecture at this point still. Agents can help and do recon amazin…

I can’t understand this. The first thing I do with new agent driven project is set up quality checks. Linters, test frameworks, static analysis, etc… Whatever I would expect a developer to do, I would expect an agent to do. All implementation has to go through build success and mixed agent reviews before moving on. I might not do this with initial research/throwaway prototype, but once I know what direction to go and…

Generated tests... I mean... listen to yourself.

I can generate a lot of tests amounting to assert(true). Yeah, LLM generated tests aren't quite that simplistic, but are you checking that all the tests actually make sense and test anything useful? If no, those tests are useless. If yes, I don't actually believe you.

It's the typical 10 line diff getting scrutinized to death, 1000 line diff: Instant LGTM.

Pay attention to YOUR OWN incentives.

Post reply on HN