[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

[DonHopkins]

Speak for yourself. That's the way I use it, so I get a lot more out of it and get a lot more done than a "vibe coder" who's lazy and doesn't want to put in any effort or learn anything new.

You simply can't learn nearly as fast with vi or Emacs or VSCode, and they can't explain unknown code and APIs and algorithms and bug fixes to you, suggest best practices, review code, write documentation for existing code, check and align code with updated documentation, or automatically update existing documentation and comments to reflect the actual code.

Right now I'm using Cursor to refactor and overhaul a huge complex multi-repo codebase of Python, TypeScript, Bash, SQL, JSON, YAML, Markdown, and ML models, from multiple repos with Google Cloud Build to a monorepo with GitHub actions, and it's no cake walk, a huge amount of work, I'm learning and applying a whole lot of new stuff, meticulously documenting every part of the system, making it rock solid, DRY, with extensive logging and error handling, and there's no way I would have been able to do 5% of this work in the same amount of time without using AI. You don't HAVE to be lazy, instead you can work as hard as you've ever worked without AI and get a hell of a lot more done while learning new things, if you so choose to. It's all up to you.

If you insist on going into it refusing to use it as a learning tool, and don't want to work hard, then you be you, and I'm going to have a huge advantage over you or any "vibe coder".

You asked "How do you verify that Claude did what you wanted?" and I told you. Just because you're too lazy and incurious to drink the water I led you to doesn't mean I or anyone else can't.

[disgruntledphd2]

Yup, this is gonna be like autopilots and aeroplanes all over again.

It's a shame that we'll invest so much money and compute into this, and continue to ignore all the ergonomics research that could help.

[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/