Live data from Hacker News

It’s so hard to finish an idea that is not yours and is just suggested by AI

ssp.sh

181–190 of 200 posts

Re: It’s so hard to finish an idea that is not yours and is just suggested by AI

#181

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.

Yes; my point was not related to any of that.

Re: It’s so hard to finish an idea that is not yours and is just suggested by AI

#182
post #154

Earlier 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…

Route A is what concretely what is behind those "a select few are seeing 100x productivity increases" posts. agents bring enterprise-level engineering to the IC. your average enterprise PM has no idea how the code works either but knows who to call when it breaks or needs a new feature added. the industry split on agentic use lies in how much and to what degree you believe "but AI is different!" in this analogy

Re: It’s so hard to finish an idea that is not yours and is just suggested by AI

#183
post #136

Earlier quoted context omitted.

But then the LLMs sees the syntax and is likely able to mimic it.

Shouldn't the "human generated comment" part be a strong hint not to?

As if LLMs would ever not ignore explicit instructions if they stand in the way of a goal...

Re: It’s so hard to finish an idea that is not yours and is just suggested by AI

#184
post #154

Earlier 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.

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

#185
post #172

Earlier 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?

Yes, I can't say exactly what but the backbone of cloud computing and/or infra, think databases, distributed storage, filesystems, ...

Re: It’s so hard to finish an idea that is not yours and is just suggested by AI

#186
post #171

Earlier 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.

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.

Re: It’s so hard to finish an idea that is not yours and is just suggested by AI

#187
post #157

Earlier 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 can do that, with varying results. Or you can just do actual software engineering like we used to do, and tell it what patterns to abstract and how.

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

#188

Earlier 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…

>asking the model to demonstrate the value it created through benchmarks, workload-generators, and e2e tests.

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

#189
post #184

Earlier 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…

I mean, from my training long ago, a good test suite is usually / always a few multiples in size of the codebase.

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

#190
post #171

Earlier 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.

I think you underestimate the skill of more experienced mechanics. Tractor (as in 18 wheeler) and master mechanics tend to know what’s going on under the hood in detail.
Post reply on HN