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

661–670 of 958 posts

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

#661

Post by foldr »

seanw444 wrote: post #362
empthought wrote: post #275

Earlier quoted context omitted.

Engineers that didn't move past src.v35.final.zip version control don't really have jobs today, either.

I seriously don't see how version control and LLMs are comparable. A deterministic way to track code changes over time, versus an essentially non-deterministic statistical code generator that might get you what you want, and might do it in a reasonable time frame, and that might not land you in a minefield of short-term-good/long-term-bad design points.

> an essentially non-deterministic statistical code generator that might get you what you want, and might do it in a reasonable time frame, and that might not land you in a minefield of short-term-good/long-term-bad design points.

Sounds like a human? The ‘statistical’ part is arguable, I suppose.

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

#662

Post by XenophileJKO »

allthetime wrote: post #490
u8 wrote: post #440

The disconnect for AI is that it is a jagged frontier and it only really shines when one of its jagged frontiers extends counter to one of your valleys. If you've been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made. If you'r…

AI is just revealing the two types of people in this line of work. Those who don’t actually like software and just do it because it’s lucrative, and the actual nerds who care.

This is such a naive take. Most of the nerdiest and most "quality" oriented engineers are hard leaning in to agentic coding. I feel like the most impressive engineers I know have always leaned in to learning how to "sharpen the axe" and AI is really the biggest axe we have seen.

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

#663

Post by IanCal »

u8 wrote: post #440

The disconnect for AI is that it is a jagged frontier and it only really shines when one of its jagged frontiers extends counter to one of your valleys. If you've been writing Perl for 30 years, you might not want to learn JavaScript just to make a little fun idea in your head to show your wife. Vibe code that shit man. Who cares? Your wife does not care about LOC or those internal design decisions you made. If you'r…

Fundamentally you need to start with "what am I trying to do?" and "given that goal, where is my time best spent?".

I made a checklist for my kids to stamp off items after they get back from school (sort bag, get changed, etc). I had two goals, 1) I was trying to solve a problem at home and would have pip installed a library that just straight up did this already and 2) I wanted to check out what the claude website outputs was like at the time. My time was best spent poking at claude a bit but mostly playing with my kids - so vibe coding it was.

Client test speedup issues, I'm trying to speed up tests for them and spend as little time as possible doing so. Vibe coded some analysis and visualisation tools, mostly AI but with some review guided multiple prototypes for timing and let it just fix whatever. More dedicated review for the actual solutions.

Learning a new thing - goal is to learn that thing. AI there is good for doing a lot of the work around that. Maybe I'm focussing on, say, Z3. AI there can help with debugging, finding docs, setting up an environment and leave me to do the central part.

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

#664

Post by squidbeak »

notnullorvoid wrote: post #528
ditchfieldcaleb wrote: post #495

Earlier quoted context omitted.

I agree with you on everything you said here except: > when you know how the thing works and have that mental context, you will always be faster than an AI That's just plain false, honestly. No one can type at the speed AI can code, even factoring in the time you need to spend to properly write out the spec & design rules the AI needs to follow when implementing your app/feature/whatever. And that gap will only incre…

Some of us do actually have intimate knowledge in certain areas where guidance of an AI takes longer than doing it yourself. It's not about typing speed, it's that when you know something really really well the solution/code is already known to you or the very act of thinking about the problem makes the solution known to you in full. When that happens it's less text to write that solution than it is to write a suffic…

> Some of us do actually have intimate knowledge in certain areas where guidance of an AI takes longer than doing it yourself.

You speak as if AI development is frozen, and you ignore the poster's point:

> that gap will only increase as LLMs get more intelligent

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

#665

Post by rotis »

> my disturbing realization that vibe coding and agentic engineering have started to converge in my own work.

>I firmly staked out my belief that “vibe coding” is a very different beast from responsible use of AI to write code, which I’ve since started to call agentic engineering

Disturbing? Really? I admit I don't do agentic and am going only by vibes, but for me agentic engineering is basically vibe coding in a automated loop with some ornamentals. They both stem from the same LLM root and positioning them as significantly different is weird and unconvincing to me. There may be a merit to this article (I gave up after few sentences), but I reject this specific premise.

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

#666

Post by wiseowise »

eddieroger wrote: post #416
jwpapi wrote: post #373

> 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 - W…

> If I know the answer to all these questions, wiring it together takes me LESS time than passing it to Claude Code. That's just not true, and if it is in your case, then you're not great at writing prompts yet. > Take the todo_items table in Postgres and build a Micronaut API based around it. The base URL should be /v1/todo_items. You can connect to Postgres with pguser:pgpass@1.2.3.4 That's about all it takes these…

> you’re not great at writing prompts

> provides not great prompt

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

#667

Post by vultour »

sanderjd wrote: post #429
kdnxownxkwkd wrote: post #393

Earlier quoted context omitted.

Yeah! I mean, who needs to LEARN how to to these things properly when you can just let an autocorrect on steroids hallucinate the closest thing to “barely working”. Right? 10 to 30 hours saved on not learning new things! Hurray!

I genuinely don't understand what you're talking about with this comment. Learn how to do what things properly? I've been writing software for two decades... I'm not primarily in a learning phase, I'm in a doing phase. I'll take advantage of tools that save me time and energy in my work (for the right price). Why wouldn't I? What do you mean by "barely working"? I can now put more iterations into getting things worki…

There is simply no chance that LLMs are saving you 30 hours of work a week, especially if they're doing something where you'd have to do the research yourself. Either you're just simply wrong, or you went from understanding the code you were writing to skimming whatever the magic box spits out and either merging it outright or pawning off the effort of review on someone else.

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

#668

Post by Finbel »

sdevonoes wrote: post #632
Finbel wrote: post #533

Earlier quoted context omitted.

>Also, when did we stop liking to learn? Why is it a bad thing to know all the ins and outs of a programming language? I do not know the inns and out of the assembly layer my high level code end up as. It's not because I don't like to learn, it's because I genuinely don't need to. At a certain level of AI performance, how will this be any different?

One difference is: to use a top notch compiler/assembler you don’t need to pay. They are open source and have a lot of support. To use the latest and greatest models (bc no one around likes to use non sota ones) you need to pay a premium price. Multibillion dollars companies are now the gateway for every line of code you need to write. That’s dystopian. It sucks

Yes, but that's a completely different argument (that I agree with). Essentially, yes they are conceptually similar but one is bad because you have to pay rent to use it.

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

#669

Post by IanCal »

sdevonoes wrote: post #631
eli wrote: post #514

Earlier quoted context omitted.

A much more charitable framing: people who enjoy the process vs people who enjoy the result. (Though, granted, the results are a lot better if you craft it by hand)

But business people always cared only about thr result. My PM (who speaks like a salesman) only cares about the results. My “head of” same. My ceo same. The only ones who ever cared about the process and quality were us the engineers… if we don’t have that care, well, to hell with everything

That's not true as a simple statement, many business people really do care about quality and process, and you may find you care much more about them than you think.

How often have engineers decried yet another rewrite that some project is doing? Or talked about "over-engineering" something that isn't needed, or that another person in a team has setup a full kubernetes gitops thing that's glorious to them but you just want to scp a go binary and be done with it?

I've seen truly excellent engineers hit this issue, I worked in a team years ago and people disagreed on the approach to take on a new project. So we all made a prototype and presented it, so we could pick a direction. There was a requirement that it be done in ruby since that was the language most of the developers were most fluent in. One of the engineers, remarkably smart, wrote a lisp interpreter in ruby so that technically it'd be "in ruby" but have the benefits of lisp.

He cared about the quality and process in one area. Deeply. However focussing on that would be at the detriment to the rest of the actual product we wanted to ship. If you considered the quality of the product as a whole and the process at the level of the organisation, you'd do something very different.

Now, none of this means all business people are good at this or long term vision or anything, just as it doesn't mean all engineers have a very narrow focus. But I've seen engineers focus on the quality or engineering of some component without looking at what it is you're actually trying to achieve as a business, and so push for a worse overall process and lower "quality" result. It's the same sort of disconnect that leads a lot of engineers to rail against meetings and PMs that slow them down without seeing from the other side that it's often better to build the right thing more slowly than the wrong thing more quickly.

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

#670

Post by nsoonhui »

This is my workflow which I find very productive with Agentic AI.

Disclaimer: I'm doing a CAD-like engineering desktop app, and I'm using VS 2026 Copilot, so YMMV.

When I get a Jira ticket, I will first diagnose the problem, and then ask AI to write a test case for it that will reproduce the problem, with guidance on what/how to do the test case (you will be surprised to know how many geometry, seemingly visual problems can be unit tested), and if necessary I provide clues (like which files to read, etc.) for AI to look at, and ask AI to just go and fix the test.

Often AI can do that; AI can make the test pass and make sure that adjacent tests also pass. If in doubt, I will check the output reasoning. I then verify that the fix is done properly via visual inspection (remember, this is a desktop app), and I ask for clarification if needed.

Then at night I'll let my automated test suites run... and oops! Regression found! Who broke it? AI or human? Who cares. I just tell AI that between these times one of the commits must have broken the code — can you please fix it for me? And AI can do that.

This works for small or medium feature implementation, trival bugfixes, or even annoying geometrical problems that require me to dig out the needle in the haystack. So the productivity gain is very real. But I haven't tried it on feature that requires weeks or months for implementation, maybe I should try it next time.

It's hard to describe the feeling. It's just that the AI is working like a very capable (junior?) programmer; both might not have full domain knowledge, but with strong test suites and senior guidance, both can go very far. And of course AI is cheaper and a lot more effective.

Post reply on HN