I came to "vibe coding" with an open mind, but I'm slowly edging in the same direction.

It is hands down good for code which is laborious or tedious to write, but once done, obviously correct or incorrect (with low effort inspection). Tests help but only if the code comes out nicely structured.

I made plenty of tools like this, a replacement REPL for MS-SQL, a caching tool in Python, a matplotlib helper. Things that I know 90% how to write anyway but don't have the time, but once in front of me, obviously correct or incorrect. NP code I suppose.

But business critical stuff is rarely like this, for me anyway. It is complex, has to deal with various subtle edge cases, be written defensively (so it fails predictably and gracefully), well structured etc. and try as I might, I can't get Claude to write stuff that's up to scratch in this department.

I'll give it instructions on how to write some specific function, it will write this code but not use it, and use something else instead. It will pepper the code with rookie mistakes like writing the same logic N times in different places instead of factoring it out. It will miss key parts of the spec and insist it did it, or tell me "Yea you are right! Let me rewrite it" and not actually fix the issue.

I also have a sense that it got a lot dumber over time. My expectations may have changed of course too, but still. I suspect even within a model, there is some variability of how much compute is used (eg how deep the beam search is) and supply/demand means this knob is continuously tuned down.

I still try to use Claude for tasks like this, but increasingly find my hit rate so low that the whole "don't write any code yet, let's build a spec" exercise is a waste of time.

I still find Claude good as a rubber duck or to discuss design or errors - a better Stack Exchange.

But you can't split your software spec into a set of SE questions then paste the code from top answers.

▲

tomtomtom777 6 hours ago | parent | next [-]

I agree, and like to add,

> It is hands down good for code which is laborious or tedious to write, but once done, obviously correct or incorrect (with low effort inspection).

The problem here is, that it fills in gaps that shouldn't be there in the first place. Good code isn't laborious. Good code is small. We learn to avoid unnecessary abstractions. We learn to minimize "plumbing" such that the resulting code contains little more than clear and readable instructions of what you intend for the computer to do.

The perfect code is just as clear as the design document in describing the intentions, only using a computer language.

If someone is gaining super speeds by providing AI clear design documents compared to coding themselves, maybe they aren't coding the way they should.

▲

Verdex 5 hours ago | parent | next [-]

The quote that I heard (I think on HN) was, "If we had AIs to write XML for us then we never would have invented json."

My biggest LLM success resulted in something operationally correct but was something that I would never want to try to modify. The LLM also had an increasingly difficult time adding features.

Meanwhile my biggest 'manual' successes have resulted in something that was operationally correct, quick to modify, and refuses to compile if you mess anything up.

▲

abrahms 3 hours ago | parent | next [-]

This doesn't sound correct. We have computers write binary for us. We still make protocols which are optimizations for binary representation.. not because it's a pain to write.. but because there's some second order effect that we care about (storage / transfer costs, etc).

▲

zephen 5 hours ago | parent | prev [-]

And a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more, and talking about how much better it was than things like JSON.

The only thing I think I learned from some of those exchanges was that xslt adherents are approximately as vocal as lisp adherents.

▲

ern_ave 2 hours ago | parent [-]

> a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more

I still use it from time to time for config files that a developer has to write. I find it easier to read that JSON, and it supports comments. Also, the distinction between attributes and children is often really nice to have. You can shoehorn that into JSON of course, but native XML does it better.

Obviously, I would never use it for data interchange (e.g. SOAP) anymore.

	▲	zephen 22 minutes ago \| parent [-]
		> Obviously, I would never use it for data interchange (e.g. SOAP) anymore. Well, those comments were arguing about how it is the absolute best for data interchange. > I still use it from time to time for config files that a developer has to write. Even back when XML was still relatively hot, I recalled thinking that it solved a problem that a lot of developers didn't have. Because if, for example, you're writing Python or Javascript or Perl, it is dead easy to have Python or Javascript or Perl also be your configuration file language. I don't know what language you use, but 20 years ago, I viewed XML as a Java developer's band-aid.

▲

rich_sasha 5 hours ago | parent | prev [-]

Dunno. GUI / TUI code? "Here's a function that serialises object X to CSV, make a (de)serialiser to SQLite with tests". "And now to MS-SQL" pretty please".

I don't how much scope realistically there is for writing these kinds of code nicely.

▲

nonethewiser 6 hours ago | parent | prev [-]

The hardest part of coding has never been coding. It's been translating new business requirements into a specific implementation plan that works. Understanding what needs to be done, how things are currently working, and how to go from A to B.

You can't dispense with yourself in those scenarios. You have to read, think, investigate, break things down into smaller problems. But I employ LLM's to help with that all the time.

Granted, that's not vibe coding at all. So I guess we are pretty much in agreement up to this point. Except I still think LLMs speed up this process significantly, and the models and tools are only going to get better.

Also, there are a lot of developers that are just handed the implementation plan.