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