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

Vibe Coding and the Future of Software Engineering

alexp.pl

Post reply on HN
Print view View original

41–50 of 103 posts

Re: Vibe Coding and the Future of Software Engineering

#41

Post by voidhorse »

mohsen1 wrote: post #33

It's interesting to see a lot of senior folks are against this arguing that if you're working on a larger software project this falls apart. Two things can be argued against this: 1. Context sizes are going to grow. Gemini with 2M tokens is already doing amazing feats 2. We all agree that we should break bigger problems into smaller ones. So if you can isolate the problem into something that fits in a LLM context, no…

You don't understand software engineering. The goal isn't to produce a bunch of code. The goals are actually:

1. Build a computable model of some facet of reality to an achieve certain goals. 2. Realize a system that manifests the model, satisfying a set of other constraints, such as resource constraints and performance. 3. Ensure a community of system owners comprehend the key decisions made in the system and model design, and the degree to which certain constraints can be relaxed or increased and how the system can evolve such that it behavior remains predictable over time.

Basically none of that, in my view, is supported by LLM driven "vibe" coding. Sure your hobby project might be ok to treat like an art project, but, oh, I don't know, how about software for train communications, or aircraft guidance systems? Do you want to vibe code your way then? Do you want a community of engineers who only dimly understand the invariants satisfied in individual components and across the system as whole?

LLM fanatics are totally ignorant of the actual process of software development. Maybe one day we'll find a way to use them in a way that produces software that is predictable, well-specified, and safe, but we are not there yet.

Re: Vibe Coding and the Future of Software Engineering

#42

Post by chis »

mohsen1 wrote: post #33

It's interesting to see a lot of senior folks are against this arguing that if you're working on a larger software project this falls apart. Two things can be argued against this: 1. Context sizes are going to grow. Gemini with 2M tokens is already doing amazing feats 2. We all agree that we should break bigger problems into smaller ones. So if you can isolate the problem into something that fits in a LLM context, no…

I honestly think it comes down to preferred work style in some cases. Once a codebase gets decently complex, it’s true that you have to supervise the AI extremely closely to get a good result. But at least for me I tend to enjoy doing that more than writing it myself. I’m a fast typer of prose, I like to plan my coding ahead of time anyways, so whether the AI does it or me is kinda immaterial

Re: Vibe Coding and the Future of Software Engineering

#43

Post by mncharity »

Tweaking that list of capabilities yields integrated pervasive user observation, user interviewing, UX refinement discussions and prototyping and validation.

Friday AI report: A user was observed seeming to struggle a bit with X; we had a pain point discussion; they suggested some documentation and UI changes; they were confused, but further discussion turned up plausible improvements; we iterated on drafts and prototypes; I did an expanding alpha with interviews, and beta with sampled surveys, and integrated some feedback; evaluation was above threshold with no blockers; I've pushed the change to prod, and fed the nice users cookies.

Re: Vibe Coding and the Future of Software Engineering

#45

Post by batshit_beaver »

sergiotapia wrote: post #21
PartiallyTyped wrote: post #3

Earlier quoted context omitted.

Are you willing to elaborate about how they can accelerate you?

One example: I had to send a report to a slack webhook, showing how many oban jobs were completed in the last 24 hours for specific uses cases based on oban job params. That's: sql query, slack webhook api docs reading, ecto query for oban jobs with complex para filtering, oban job to run cron, cron syntax. easily like a 2 hour job? it took me 5 minutes with AI. then we decided to send the slack alert at 7am EST inst…

> i believe syntax memorization is dead.

Hold up, if you don't know a language's syntax, how can you verify that the answer returned by LLM is correct (at a glance, because a) nobody writes exhaustive tests, LLMs included, and b) you wouldn't be able to read the tests to confirm their validity either)?

I struggle to think of a case where explaining a task to an LLM in a natural language is somehow faster than writing it yourself, specifically in the case where you know a programming language and related libs to accomplish the task, implying non-zero ROI on learning these things.

Re: Vibe Coding and the Future of Software Engineering

#46

Post by goosejuice »

jstummbillig wrote: post #27
goosejuice wrote: post #12

Earlier quoted context omitted.

antirez's series looks awesome. My two cents w/ composer: Don't rely on the LLM for design. Start by defining some tests via comments or whatever your tools allow. The tab completion models can be helpful here. Start the interfaces / function defs and constrain them as much as possible. Let the LLM fill in the rest using TDD. The compiler / test loop along with the constraints can get you pretty far. You'll always ne…

If you are optimizing for less tool calls, I think you are rapidly and increasingly optimizing for the wrong thing here.

I agree. I'm not suggesting to optimize for that. We want the best acceptable outcome in the least amount of time.

More toolcalls per interaction is typically a product of planning ahead, which in my experience produces better outcome. Each toolcall is a verification of the last step. Without those guardrails I find I waste a tremendous amount of time.

Re: Vibe Coding and the Future of Software Engineering

#47

Post by martin-t »

voidhorse wrote: post #35

Honestly, the fact that this is even a concept assessed with any seriousness shows me how much bullshit the label "engineering" is when applied to software. You want to have an LLM help you crap out a script, sure, but you mean to tell me you'd seriously consider using an LLM for a production systems that affects real people that deals with real people's real data and call yourself a software "engineer"? Engineering…

I never had respect for programmers who call themselves software engineers without doing any actual engineering. This hype cycle and its buzzwords like "prompt engineers" just takes it to an extreme.

Re: Vibe Coding and the Future of Software Engineering

#48

Post by thwarted »

AlwaysRock wrote: post #24
brundolf wrote: post #8

Earlier quoted context omitted.

Agreed. I've had a lot of success using ChatGPT for nontrivial bash one-liners. They're small in scope and there must be a huge amount of training data for them, I use them rarely enough that I don't remember details off the top of my head, and they're intrinsically throwaway code

I was doing some file management last weekend and wanted a little script to remove any numbers at the start of a file name and any region values at the end. I also wanted to ensure any duplicate files were moved into a separate folder so i could remove them. I could have written that code. I'm sure there is a program that can do exactly that for me that I could have downloaded. But one prompt, a few tests to make sur…

There's probably a program in /usr/bin on your machine that does that.

Re: Vibe Coding and the Future of Software Engineering

#49

Post by d_burfoot »

risyachka wrote: post #14

>> Seems like programmers are terrified Idk why terrified, vibe coding is nice but everyone who developed something bigger than a toy knows that code is 5% of the task and never was a bottleneck. Its not like faang employees write code all day long, or even half day. Ah and you need to make sure it doesn’t nuke your db or send weird email to your users because someone prompt-engineered it badly.

> why terrified

I'm terrified some colleague is going to vibe-code a product and use it to get promoted, then move to another team and dump the project on me to maintain.

Re: Vibe Coding and the Future of Software Engineering

#50

Post by mncharity »

> There are additional difficulties brought about by the economics of large scale production. Programmers have become "proletarianized". The elite expert programmer who crafted a system and stayed with it for many years, finely tuning it and adding new bells and whistles with ease, has by and large been superseeded by an entire generation of college graduates who were introduced to computing in their courses, and who are hired and fired by programming shops in accord with the winds of the market place.

> A radical approach to the complexity problem has been to suggest that the easiest way out is simply to make the machine do everything; i.e. automatic programming. [...] this approach does seem seductive, it is our estimate that it will not in the short run produce results of much value to the designer of [...] large scale programs

> the belief that man-machine interaction can be a symbiotic relationship in which the overall productivity is greater than the sum of the parts.

> how a knowledgeable computer could help an already competent programmer. It has been our experience that we can produce better and cleaner code faster when working with a partner who shares our understanding of the intentions and goal structure of our program. We, therefore, believe that the appropriate metaphor for our work is that of creating a program with the capabilities of a junior colleague working on a joint project. The program should know the problem domain, implementation techniques, and the programming language being used fairly well. It need not know everything in advance; it can always ask its senior partner for advice or further information. Furthermore, this program might well be capable of paying more attention to details, of writing trivial parts of the code, of checking that certain constraints are satisfied, and even (in some cases) of cleaning up a large system after it has been put together.

> First Scenario: Initial Design > I'd like to build a hash table `O.K. youll need an insert, a lookup, an array, a hasher, and optionally a delete routine.` The P.A. knows the main parts of a hashing system.

> parallels [...] between understanding a program [...and...] natural language. In both cases, a key component in the understanding system is the background knowledge base, which establishes a context for understanding the semantics of the particular utterance in question. The huge problem in natural language understanding research is that if you try to advance beyond conversations in toy domains like the blocks world, this background knowledge quickly amounts to having a common-sense model of the whole world of human existence. Unfortunately, building such a representation of the world is exactly the central unsolved research project of the entire A.I. community.

> The transition from tab equipment systems to the modern day computer utility, exemplified by MULTICS, has taken little more than two decades.

Understanding LISP Programs: Towards a Programmer's Apprentice (1974) https://dspace.mit.edu/handle/1721.1/41117

Post reply on HN