Live data from Hacker News

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

simonwillison.net

211–220 of 958 posts

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

#211

Earlier quoted context omitted.

> 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.

It isn't just that they believe this - they want a business model where this is how it works. For a big company a star coder is a liability - they have strong labor power, they can leave and they are hard to replace, etc.

Companies want workflows that work with mediocre programmers because they are more like interchangeable parts. This is the real secret to why AI programming will work in a lot of places. If you look at the externalities of employing talented people, shitty code actually looks better than great code.

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

#212
post #185

Earlier quoted context omitted.

> Objectives change; timeliness matters. The speed at which you deliver value is incredibly important, which is why it matters to measure your process. This assumes that shorter code is faster to write. To quote Blaise Pascal, "I would have written a shorter letter, but I did not have the time." > Can you deliver value without lines of code? No, but you can also depreciate value when you stuff a codebase full of bloa…

You seem determined to misinterpret. I’m not talking about LOC as a measure of productivity. The ratio of LOC needing review to the capacity of reviewers (using how many LOC can be read/reviewed over the sampling period) is what’s being discussed. Agentic AI/vibe coding has caused that ratio to increase and shows a bottleneck in the SDLC. It’s a proxy metric, get over yourself. “All models are wrong, some are useful”…

Yes, reading this back, I definitely veered off-topic. I apologize. I still don't think that you can say how much time it will take to review code based on how many lines of code are involved, but my argument was not well crafted. I just hope that others can learn something from our discussion. Thank you for being patient with me, and I hope you have a good day! :)

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

#213
post #21

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…

First, most software is already a hot mess. Second, LLM code can be less of a hot mess than human written code if you put in the time to train/prompt/verify/review. Generating perfect well patterned SOLID and unit tested code with no warnings or anti-patterns has never been easier.

>First, most software is already a hot mess.

That the industry was already routinely dealing with fires of it's own creation is not a valid reason to start cooking with gasoline.

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

#214

Earlier quoted context omitted.

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.

They're not suggesting that code will go away, but rather that it will be abstracted beneath an LLM interface, so that writing code in the future will be like writing assembly today: some people do it for fun or niche reasons, but otherwise it's not necessary, and most developers can't do it. Whether that happens or not is a different question, but I believe that's what they're suggesting.

Code is formal and there are basic axioms that grounds its semantic. You can build great constructs on top of those semantics, but you can’t strip away their formality without the whole thing being meaningless. And if you can formalize a statement well enough to remove all ambiguity, then it will turn into code.

Programming is taking ambiguous specs and turning them into formal programs. It’s clerical work, taking each terms of the specs and each statements, ensuring that they have a single definition and then write that definition with a programming language. The hard work here is finding that definition and ensuring that it’s singular across the specs.

Software Engineering is ensuring that programming is sustainable. Specs rarely stay static and are often full of unknowns. So you research those unknowns and try to keep the cost of changing the code (to match the new version of the specs) low. The former is where I spend the majority of my time. The latter is why I write code that not necessary right now or in a way that doesn’t matter to the computer so that I can be flexible in the future.

While both activities are closely related, they’re not the same. Using LLM to formalize statements is gambling. And if your statement is already formal, what you want is a DSL or a library. Using LLM for research can help, but mostly as a stepping stone for the real research (to eliminate hallucinations).

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

#215
post #90
post #22

Earlier quoted context omitted.

> Makes me want to just give up programming forever and never use a computer again. LLMs aren’t the first thing to come along and change how people develop applications. You had the rise of frameworks like Django, Rails, etc. Also the rise of SPAs. And also the rise of JS as a frontend+backend language. In a 3-5 yeats we’ll have adapted to the new norm like we have in the past

The difference between writing assembly code and Ruby code is much smaller than the difference between programming and vibe coding. Also, companies are pressuring employees towards adoption in novel ways. There was no such industry-wide pressure by employers in the 90s, 2000s or 2010s for engineers to use a specific tech.

> Also, companies are pressuring employees towards adoption in novel ways. There was no such industry-wide pressure by employers in the 90s, 2000s or 2010s for engineers to use a specific tech.

Companies have been enforcing technology mandates since time immemorial. In the early 2000s there were definitely a lot of mandates to move away from commercial UNIX to Linux. Lots of companies began enforcing the switch to PHP, Ruby and Python for new projects.

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

#216
post #208

Earlier quoted context omitted.

[flagged]

This was a podcast, not a pre-scripted talk. I suggest listening to the audio version - it makes it more clear that this was thinking out loud, not carefully considering every word.

I see, fair point. Sorry for taking a dig at you. Please know that I do appreciate a lot of work that you do. I was just worried for a moment when just reading that bit.

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

#217
post #59

Correct me if I’m wrong Simon, but weren’t you highly optimistic about llm’s and agentic-use of them? I believe this is a common fault of not being able to zoom out and look at what trade offs are being made. There’s always trade-offs, the question is whether you can define them and then do the analysis to determine whether the result leaves you in a net benefit state.

I still am. I think setting up LLMs to call tools in a loop is a fascinating way to build interesting software that could not have existed before.

Coding agents are also upending how software development works, in a way that we are still very much figuring out.

I don't think anyone has a confident answer for how best to apply them yet, especially on larger production-ready projects.

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

#218
post #166

Earlier quoted context omitted.

I think it’s a mistake to think that we will be blindly going in this direction for many years and then suddenly collectively wake up and realize what have we done. It’s a great filter and a great opportunity. If LLMs stop improving at the pace of the last few years (I believe they already are slowing down) then they will still manage to crank out billions lines of code which they themselves won’t be able to grep and…

> If LLMs stop improving at the pace of the last few years (I believe they already are slowing down) Depending on how you measure "improvement" they already have or they never will :-/ Measuring capability of the model as a ratio of context length, you reach the limits at around 300k-400k tokens of context; after that you have diminishing returns. We passed this point. Measuring capability purely by output, smarter h…

300k-400k isn’t the current limit if you create modules and/or organize the code reasonably.. for the same reason we do this for humans: it allows us to interact with a component without loading the internals into out context.

you can also execute larger tasks than this using subagents to divide the work so each segment doesn’t exceed the usable context window. i regular execute tasks that require hundreds of subagents, for example.

in practice the context window is effectively unlimited or at least exceptionally high — 100m+ tokens. it just requires you to structure the work so it can be done effectively — not so dissimilar to what you would do for a person

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

#219
I agree somewhat, but I do still think there is a decently sized separation between true vibe coding (the typical "make me an app...fix this bug") and actual AI assisted development. I personally think that if you are a dev and you simply trust the AI's output, that is still vibe coding.

I am not a developer and have very basic code knowledge. I recently built a small and lightweight Docker container using Codex 5.5/5.4 that ingests logs with rsyslog and has a nice web UI and an organized log storage structure. I did not write any code manually.

Even without writing code, I still had to use common sense in order to get it in a place I was happy with. If i truly knew nothing, the AI would have made some very poor decisions. Examples: it would have kept everything in main.go, it would have hardcoded the timezone, the settings were all hardcoded in the Go code, the crash handling was non existent, and a missing config would have prevented start. And that is on a ~3000 line app. I cannot imagine unleashing an AI on a large, complex. codebase without some decent knowledge and reviewing.

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

#220
post #181

huh. i honestly never thought they were all that different. didn't the same guy coin them both to refer to the same thing?

Not at all. Andrej Karpathy coined vibe coding as: https://twitter.com/karpathy/status/1886192184808149383

> where you fully give in to the vibes, embrace exponentials, and forget that the code even exists [...] It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

So clearly we need a term for what happens when experienced, professional software engineers use LLM tooling as part of a responsible development process, taking full advantage of their existing expertise and with a goal to produce good, reliable software.

"Agentic engineering" is a good candidate for that.

Post reply on HN