Earlier quoted context omitted.
Route A is good for rapid, disposable prototyping. If you ever have a stray thought, “I wonder how this would work if the whole paradigm were turned sideways”, you now have a chance to preview a “working” version of your idea. If you like it, discard the code and reimplement it correctly. In this way, I think it can be a good adjunct to sketches and other lofi prototyping techniques. Just don’t outsource the creative…
Have you seen many of the replies in this thread and others? They’re not doing that. They’re putting it into production code. Their company’s thought leaders are trying to say that review itself is a waste of time, etc. That’s not “disposable prototyping” that’s whole versions of the codebase written with barely a human in sight.
It’s so hard to finish an idea that is not yours and is just suggested by AI
181–190 of 200 posts
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#182Earlier quoted context omitted.
The problem, in my experience is: 1. It writes SO MUCH code, in minutes, that theres no way I as a human can review it. 2. I am not very motivated to read/review this code anyway: it was cheaply written, by some _thing_ that is not going to improve from my feedback. 3. If you DO review it conscientiously , it becomes a never ending thing: you keep finding issue upon issue. 4. If you report the issues for fixes, the f…
Route A seems genuinely horrifying to me - maybe not for small and/or helper scripts; but for anything substantial. For anything that bites you or someone else hard when things go bad. I don’t want a vibe-coded, mass-produced diabetes tracking app, or banking tool, or tax management software. I don’t want a vibe-coded power grid analysis software. I don’t care if a person’s little, local scripting thing is vibe-coded…
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#183Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#184Earlier quoted context omitted.
The problem, in my experience is: 1. It writes SO MUCH code, in minutes, that theres no way I as a human can review it. 2. I am not very motivated to read/review this code anyway: it was cheaply written, by some _thing_ that is not going to improve from my feedback. 3. If you DO review it conscientiously , it becomes a never ending thing: you keep finding issue upon issue. 4. If you report the issues for fixes, the f…
You should be the one building the gates then, but those gates should be mechanical and deterministic so the AI doesn’t wprk around them. Lint rules, type errors, commit lint, anything that tells the AI to stop instead of allowing workarounds.
These are basic: they work for human coders and are typically quick to setup. But gates at this level are far from enough for agentic coding. You need an extensive test suite/e2e suite/benchmark suite. Typically much larger than the code base itself: This is what enables those "i ported bun to rust in a weekend" headlines. Where ever such extensive 'gates', high quality ones, already exist, the agent can do a good job of making things work, cause it can automatically iterate.
But: every hole, every gap in coverage, will be eventually found by the coding agent and 'exploited'. So you need full, extensive coverage.
This suite itself is a LOT of work, much more than what it would be if you only had to worry about human coders. So if YOU are writing the gates yourself, you are going to fall between A and B: you still have a convoluted, unreliable, impossible-to-reason-about prod app, AND it still took you eons to build it cause you spent that time writing the gates. This is no win at all, on either front.
Where gates, extensive ones, help in route A is they can significantly reduce the churn/spinning, fix-x-break-y, to just the parts that are gaps in coverage (which the agent will keep finding at a ridiculous rate). And your work would be to have it ALSO keep filing in those gaps with more tests/etc.
One of the reasons go coding with agents works better than other langs is cause I even include AST based enforcements in my governance suite. Its still route A, but with somewhat more confidence, somewhat less frustration.
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#185Earlier quoted context omitted.
Exactly. That would mean going back to square one, and I also personally don't review the code anymore but I am more focused on asking the model to demonstrate the value it created through benchmarks, workload-generators, and e2e tests. Mostly it proves as a valid approach, barring the bugs the model can introduce to value-demonstrating benchmarks which can of course skew the evidence on hypotheses, and thus code tra…
Are you working on complex systems that serve many users in production? Do you actually save time?
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#186Earlier quoted context omitted.
When the combustion engine was invented, and we got the means by which we could accelerate our trip by 10x, and at the same time scale it to multiple people, we didn't tell the humans to keep pushing the vehicles by their hands, didn't we?
As a developer you are more akin to a car mechanic, who’s still expected to know how the engine works even a century after it was invented, rather than a driver, who is just the user in this parallel.
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#187Earlier quoted context omitted.
>If you take responsibility for the architecture and instruct it to do things properly it will do them properly. The problem here is that after a while it is impossible to detect when such potential abstractions is overlooked in the generated code. Because it has become hard to reason about the existing code. Not all work is green field.
I have wondered about this. Can’t you ask the AI to find the patterns than need abstracting?
You choose your level of effort and involvement. The LLM can write whatever you tell it to write. If you send a drawing of an app and say "make this" then you'll get whatever it comes up with. If you tell it how to make it then it will make it the way you tell it to.
If your AI code is trash that's because you're trash at directing it.
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#188Earlier quoted context omitted.
> So, I admit that I'm finally getting into this "let Claude help you write code" stuff, and I'm enjoying it a bit for the stuff I, honestly, just don't want to write; but ... I still read it. I still review it. I still look at the code like I'm peer-reviewing it and go, "Uh ... I don't like this area at all. That's going to be really hard to debug at 3am" and so on. I used to. I've stopped in recent months, only bec…
Exactly. That would mean going back to square one, and I also personally don't review the code anymore but I am more focused on asking the model to demonstrate the value it created through benchmarks, workload-generators, and e2e tests. Mostly it proves as a valid approach, barring the bugs the model can introduce to value-demonstrating benchmarks which can of course skew the evidence on hypotheses, and thus code tra…
LLMs are fantastic at faking those
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#189Earlier quoted context omitted.
You should be the one building the gates then, but those gates should be mechanical and deterministic so the AI doesn’t wprk around them. Lint rules, type errors, commit lint, anything that tells the AI to stop instead of allowing workarounds.
> Lint rules, type errors, commit lint, anything These are basic: they work for human coders and are typically quick to setup. But gates at this level are far from enough for agentic coding. You need an extensive test suite/e2e suite/benchmark suite. Typically much larger than the code base itself: This is what enables those "i ported bun to rust in a weekend" headlines. Where ever such extensive 'gates', high qualit…
100k lines of app code? 300-500k lines of test, sort of thing.
Re: It’s so hard to finish an idea that is not yours and is just suggested by AI
#190Earlier quoted context omitted.
As a developer you are more akin to a car mechanic, who’s still expected to know how the engine works even a century after it was invented, rather than a driver, who is just the user in this parallel.
Mechanics I've been to generally have no idea about how things actually in the car work - from what I could understand, area is full of recurring problems, and this exactly benefits mechanics to solve them through trial and error approach rather than understanding much how underlying things work. Pretty much close to what I would say SWE will turn into, there's no other choice IMO in foreseeable future.