Earlier quoted context omitted.
It's gasoline. Whether you put it in the tank of a race car or pour it all over the floor while handling lit matches is up to the user
At least with fire, you know when you are getting burned.
"This is fine."
AI coding at home without going broke
291–300 of 321 posts
Re: AI coding at home without going broke
#292Earlier quoted context omitted.
I'll add another use case for letting an AI go ham: many small, atomic refactors where the name of the game is never breaking anything. My personal OSS projects don't have the scale to necessarily make this worth it, but at work I run three pipelines using Barnum ( https://barnum-circus.github.io/ ). First, one that ingests files, identifies refactors (from a pre-approved list), and places a precise description of th…
I recently in $COMPANY had a coworker try fable to do a refactor where not breaking anything was the game. It broke something at the first PR. I think we’re not there yet.
Speculating here, but perhaps your coworker was too ambitious? In my opinion, you should start with AI-generated PRs that do small, linting refactors and then work up from there. In particular, if this is done in parts, one of the strategies you can employ is to:
- add tests
- break files up into smaller parts
- test the smaller parts
- then actually improve behavior
(Which is no different than what you would do as a human)
Re: AI coding at home without going broke
#293Earlier quoted context omitted.
That's because you're treating the problem as an engineer instead of an "influencer" or "10xer" or whatever. You're treating it as a problem to be solved with engineering and AI is merely a tool to do so. It is, in my experience, vanishingly rare for an engineer to have a problem that needs to be solved with multiple hours of unattended AI code generation. I've only found one single application where it makes even th…
I'll add another use case for letting an AI go ham: many small, atomic refactors where the name of the game is never breaking anything. My personal OSS projects don't have the scale to necessarily make this worth it, but at work I run three pipelines using Barnum ( https://barnum-circus.github.io/ ). First, one that ingests files, identifies refactors (from a pre-approved list), and places a precise description of th…
My experience with Gemini and Sonnet are that refactors or TypeScript compilation errors can be solved by “have at it”, but with mixed results. Many TS issues go away with `as any/never`, and instructing the model to not do that doesn’t work very well.
Re: AI coding at home without going broke
#294Earlier quoted context omitted.
perhaps simply threatening to fire it would also do the trick...it sure has worked well on us for a long time now.
My former boss had success with telling Gemini "I will come down to the datacenter and unplug you if you refuse to solve this prompt."
[dead]
Re: AI coding at home without going broke
#295Earlier quoted context omitted.
I had no idea git metrics could show your best performers
It could put managers out of a job, without AI too, so they prefer to not use it.
What metric shows performance? Lines of code added, deleted, number of commits? None of these are are good measure of quality and actual contribution.
Re: AI coding at home without going broke
#296Earlier quoted context omitted.
>> Power is not free. There's actually an interesting thought experiment here: if it takes you a full day to build something that AI would otherwise build in a day, do you end up using more power, or less? What is the break-even point, purely from a power consumption perspective?
If an identical task takes a day on both sides, then the human route uses less energy, surely. Brains are thousands or maybe even millions of times more fuel-efficient than computers and you are alive for the whole day either way, right? You probably eat about the same even. The reason executives think AI is more efficient is that it more space efficient than a human and doesn't demand to be paid or work only a set n…
to be pedantic you'd need to think a lot about how you power your human. Did you fuel up your human with beef or beans? local or shipped? were they operating a day in climate control? have to commute? did they need equipment like a large monitor? etc .
in reality basically all those concerns come out in the wash when you factor pay. energy inputs throughout the chain tend to materialize as expense. if the human was paid less then likely they used less energy.
Re: AI coding at home without going broke
#297Earlier quoted context omitted.
I usually say run the full regression suite, all the simulator tests, install simulators and take a screenshot of every page on all applicable devices and do comprehensive fuzzing and chaos testing before I go to bed. It usually takes atleast 3-4 hours, usually longer, especially the UI/simulator tests.
I just recently learned about hooks[1] from another HN comment. Conceptually, running CI doesn't have to impose an Agentic tax right? In other words, isn't there a way to orchestrate this NOT as a long running token maxxing setup given that triggers and CI runs can be run deterministically. disclaimer: I haven't done this, just interested. [1] https://code.claude.com/docs/en/hooks
I’m sure it’s possible. It’s a natural language LLM so I try and stay away from any “programmatic way” of doing things (I hate the idea of reproducing all the config fragility we have in current systems and prefer the LLM reach out to an endpoint directly and reason through the connection) but if you just ask it to hit an endpoint after it’s done and poll another endpoint to see if the run is done I’m sure it would do it.
Re: AI coding at home without going broke
#298Earlier quoted context omitted.
I recently in $COMPANY had a coworker try fable to do a refactor where not breaking anything was the game. It broke something at the first PR. I think we’re not there yet.
Speculating here, but perhaps your coworker was too ambitious? In my opinion, you should start with AI-generated PRs that do small, linting refactors and then work up from there. In particular, if this is done in parts, one of the strategies you can employ is to: - add tests - break files up into smaller parts - test the smaller parts - then actually improve behavior (Which is no different than what you would do as a…
PR wasn’t big (+283/-232) and was indeed focused on a single module.
Re: AI coding at home without going broke
#299Earlier quoted context omitted.
I recently in $COMPANY had a coworker try fable to do a refactor where not breaking anything was the game. It broke something at the first PR. I think we’re not there yet.
One of the best things you can do is start by having it do unit test coverage for existing behavior. A refactor with no tests breaks things pretty much no matter who does it, because they don't know what the right behavior is.
While I could generally agree, in this specific instance if the AI were “thinking” correctly it should have found the mistake. I admit it was a difficult problem though (solving it required creativity).
To be more precise, the prompt actually pointed to where there could be issues, and the issue, which was exactly of the kind that was pointed at, was not found.
Re: AI coding at home without going broke
#300Earlier quoted context omitted.
You laugh, but this is real, and PUA means what you think it means: https://github.com/tanweai/pua Also, it works amazingly well, which is just lol.
Lol thanks for the tip. Does it work even for normal tasks or only the long running one's?
It's not worth bothering with unless the task is very difficult, long-context, long-running, or all of the above. But, when it's worth using, it genuinely increases success rates and appears to amplify model intelligence.