[davydm]

the only good part was the joke about "vibecoding" (shudder what a stupid term) being like a fart and attracting flies... ok investors

still, this "ai code tools will deprecate real programming" bullshit will one day be laughed at just like how most of us laugh at shitcoin maniacs

it just takes a lot of people way too long to learn

[skydhash]

Maybe there's a different universe out there, where the code you write is not expected to work, so you can poke the LLM for a whole day to see if it barfs something out.

I spend much of the day reading and thinking and only a small portion actually writing code, because when I'm typing, I usually have a hypothetical solution that is 99% correct and I'm just bringing it to life. Or I'm refactoring. You can interrupt me at any time and I could give you the complete recipe of what I'm doing.

Which is why I don't use LLMs, because it's actually twice the work for me. Typing out the specs, then verifying and editing the given result, while I could type the code in the first place. And they suck at prototyping. Sometimes I may want to leave something in the bare state where only one incantation works, because I'm not sure of the design yet, and have a TODO comment, but they go to generate a more complicated code. Which is a pain to refactor later.

[wrs]

I agree with the spirit of the argument, but I don’t think you’re taking into account the scale of “typing” we’re talking about now.

For example, yesterday I needed a parser for a mini-language. I wrote a grammar — actually not even the formal grammar, just some examples — and what I wanted the AST to look like. I said “write the tokenizer”, and it did. I told it to tweak a few things and write tests. It did. I told it to “write a recursive descent parser”, and it did. Add tests and do some tweaks, done.

The whole thing works and it took less than an hour.

So yeah, I had to know I needed a parser, but at that point I could pretty much hand off the details. (Which I still checked over, so I’m not even in full vibe mode, guess.)

[LPisGood]

This is a cool use case that probably saved you some time, but writing a recursive descent parser is something freshman CS students do for a lab assignment.

It isn’t exactly breaking new ground or doing anything you couldn’t find with a quick google search.

[wrs]

You want me to do a Google search for a parser for the language that I just invented?

If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it.

[kuschku]

> If you have a parser generator tool that can go from zero to parser based on a few examples rather than a grammar, I’d love to hear about it.

That's the part where the LLM would be useful. Turn the examples into a grammar, verify the grammar, and use a parser generator for the rest.

You know the code does what it should and you get there in minutes.

[wrs]

I'm pretty sure it could have done that equally easily, but this grammar is small enough that a parser generator is overkill. (I made that decision before I asked the LLM to write the parser.)

[davydm]

"add tests and do some tweaks"

there's the snake in the grass - you're asking the LLM to write tests after the code is generated, so naturally, it will write passing tests - including tests which enforce buggy behavior

if not now, then you're lucky; watch out for next time.

[skydhash]

Isn't that what tools like antlr [0], bison[1] do?

[0]: https://www.antlr.org/

[1]: https://www.gnu.org/software/bison/

[jdlshore]

They typically generate generic LALR parsers, not custom recursive descent parsers. I'm no expert, but my understanding is that custom recursive descent parsers have advantages in terms of readability and error message generation.

[danielbln]

I disagree, agentic coding is amazing for prototyping. It removes a ton of friction and inertia and allows me to try a bunch of ideas to see what works (from a delivery and/or UX perspective). Of course, you should have the systems thinking and experience in place to know what it is you're doing with it at any given point , but for demos and prototypes it has been an absolute boon.

Generally, you wouldn't type out the spec either, either you provide an existing spec to the model (in form of white board notes, meeting notes, etc.) or you iterate conversationally until you arrive at an initial implementation plan.

It's a different way of working for sure, and it has distinct draw backs and requires different mental modes depending if you're doing green field, demo/prototype, existing large app feature development etc. but it's been a massive productivity enhancement, especially when tackling multiple projects in quick succession.

[hombre_fatal]

A good example of this at the extreme is game design.

When you're making a game, it's really expensive to try out different ideas, like a few different implementations of a mechanic. It could be hours of work to make a change. You tend to have to do a lot of thinking to tweak a mechanic in a fundamental way just to see what it feels like, knowing that you're probably going to throw it away.

LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like. Rollback the change or continue tweaking.

Same with branching the UI to see what a different idea would feel like. Simple changes to explain could result in hours of refactoring UI code (chore work) just to see if you like the result. Or just ask the LLM to do it, see what it feels like, roll it back.

[bluefirebrand]

> LLMs are really good at this. Make a git branch, ask Claude Code to tweak the physics so that it does X, see what it feels like

How do you verify that Claude did what you wanted?

Maybe more importantly, how do you verify that Claude didn't make a change that you didn't want?

Trying to verify the code changes just by testing the running project seems incredibly careless

[DonHopkins]

You READ what it did and REVIEW every change and ASK it to explain and LEARN from it so you can do it yourself too: the OPPOSITE of "vibe coding", whose goal is to avoid learning and reading and reviewing and understanding at all costs, to live a careless effortless TLDR life of self imposed ignorance.

There's a responsible enlightened self enriching way to use AI tools, and there's "vibe coding".

[bluefirebrand]

> You READ what it did and REVIEW every change and ASK it to explain and LEARN from it so you can do it yourself too

I don't believe anyone will actually use AI this way long-term

Even if we start out this way, eventually people will trust it enough that they get complacent and mistakes will start to slip through

Besides which, this doesn't actually sound faster than just writing the code yourself

[skydhash]

Usually my own way of working is to use Balsamiq[0] to have a visual prototype to test out flows, Figma|Sketch for the UI specs, then to just code it. Kinda the same when drawing where you just doodle until you have a few workable ideas, iterate of these to judge colors and other things, and then commit to one for the final result.

[0]: https://balsamiq.com/

[null_name]

Yeah, call me a cynic or conservative or whatever - I'll believe it when I see it. I give very little weight to predictions about the future from AI shills, especially when they include some variant of "we're 90% there already" or "an exponential shift is imminent, if things keep improving at this rate, which they Will." Opinion discarded, create your thing and come back if/when it works.

Everything is shifting so fast right now that it hardly matters anyways. Whatever I spend time learning will be outdated in a few years (when things are predicted to get good). It does matter if you're trying to sell AI products, though. Then you gotta convince people they're missing out, their livelihood is at stake if they don't use your new thing now now now.