Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Personal AI Factory

john-rush.com

Post reply on HN
Print view View original

81–90 of 167 posts

Re: Building a Personal AI Factory

#81

Post by zxexz »

ffsm8 wrote: post #67
zackify wrote: post #41

Earlier quoted context omitted.

If it helps anyone else. I downgraded from Claude max to pro for $20 and the usage limits are really good. I think they’re trying to compete with Gemini cli and now I’m glad I’m paying less

you will run through the pro rate limiting within But yeah, if you're babysitting a single agent, only applying after reading what it wants to do ... You'll be fine for 3-4 hours before the token limit refreshed after the 5th

I've heard that if you have several relatively active separate sessions open, the limit is a little less restrictive. Especially if you do a /clear and continue your session on a different project. Honestly, a lot of Claude Code seems vibecoded if you look at the client side, too. Can't tell if I'm surprised that the backend has an element of that, too. Hey, dogfood tastes good - I respect them for that.

Re: Building a Personal AI Factory

#82

Post by stpedgwdgfhgdd »

9cb14c1ec0 wrote: post #31
photon_garden wrote: post #9

It’s hard to evaluate setups like this without knowing how the resulting code is being used. Standalone vibe coded apps for personal use? Pretty easy to believe. Writing high quality code in a complex production system? Much harder to believe.

Exactly. I use claude code as a major speedup in coding, but I stay in the loop on every code change to make sure it is creating an optimal system. The few times that I've just let it run have resulted in bugs that customers had to deal with.

I noticed that i hardly look anymore at the generated Go code… I do give a lot of attention to the tests. I let CC write some failing tests, implement. Let it run against some real scenarios. Find bugs, let it write more tests, fix. And iterate.

Writing this I realise, i should more clearly separate the functional tests from the implementation oriented unit tests.

Re: Building a Personal AI Factory

#83

Post by danielbln »

6510 wrote: post #76
cube00 wrote: post #40

Earlier quoted context omitted.

The end goal is to remove the developer from this equation. Business owner asks for a new CRUD app and there it is in production. Of course it's full of full of bugs, slow as syrup, saves to a public unauthed database but that's none of my business *gulps scalding hot tea*

You have users fill out bug reports then throw some buckets of money at it. You could even add a magic button for when things don't work that reruns the same prompt and possibly get better results. A slot machine animation while waiting would be cool.

It's like a salt mine in here. Go ahead and hand weave your copper cable code while the world moves on and accelerates. Will there be slop along the way? Oh hell yes.

The Model T car was notorious for blowing out tires left and right, to the point that a carriage might have been less hassle at times. Yet here we are.

Re: Building a Personal AI Factory

#84

Post by dgunay »

I am experimenting with a similar workflow and thought I'd share my experience.

I might be a little too hung up on the details compared to a lot of these agent cluster testimonials I've read, but unlike the author I'll be open and say that the codebase I work on is several hundred thousand lines of Go and currently does serve a high 5 to low 6 figure number of real, B2C users. Performance requirements are forgiving but correctness and reliability are very important. Finance.

Currently I use a very basic setup of scripts that clone a repo, configure an agent, and then run it against a prompt in a tmux session. I rely mainly on codex-cli since I am only given an OpenAI key to work with. The codex instances ping me in my system notifications when it's my turn, and I can easily quake-mode my terminal into view and then attach to the session (with a bit of help from fzf). I haven't gotten into MCP yet but it's on my radar.

I can sort of see the vision. For those small but distracting tasks, they are very helpful and I (mostly) passively produce a lot more small PRs to clean up papercuts around our codebase now. The "cattle not pets" mentality remains relevant - I just fire off a quick prompt when I feel the urge to get sidetracked on something minor.

I haven't gotten as much out of them for more involved tasks. Maybe I haven't really got enough of a context flywheel going yet, but I do typically have to intervene most of the time. Even on a working change, I always read the generated code first and make any edits for taste before submitting it for code review since I still view the output as my complete responsibility.

I still mostly micromanage the change control process too (branching, making commits, and pushing). I've dabbled in tools that can automate this but haven't gotten around to it.

I 100% resonate with the "fix the inputs, not the outputs" mindset as well. It's incredibly powerful without AI and our industry has been slowly but surely adopting it in more places (static typing, devops, IAC, etc). With nondeterministic processes like LLMs though it feels a lot harder to achieve, more like practice and not science.

Re: Building a Personal AI Factory

#85

Post by nilirl »

"Fix inputs" => The assumption is there exists some perfect input that will give you exactly what you want.

It probably works well for small inputs and tasks well-represented in the training data (like writing code for well-represented domains).

But how does this work for old code, large codebases, and emergencies?

- Do you still "learn" the system like you used to before?

- How do you think of refactoring if you don't get a feel for the experience of working through the code base?

Overall: I like it. I think this adds speed for code that doesn't need to be reinvented. But new domains, new tools, new ways to model things, the parts that are fun to a developer, are still our monsters to slay.

Re: Building a Personal AI Factory

#86

Post by com2kid »

simonw wrote: post #28

My hunch is that this article is going to be almost completely impenetrable to people who haven't yet had the "aha" moment with Claude Code. That's the moment when you let "claude --dangerously-skip-permissions" go to work on a difficult problem and watch it crunch away by itself for a couple of minutes running a bewildering array of tools until the problem is fixed. I had it compile, run and debug a Mandelbrot fract…

> That's the moment when you let "claude --dangerously-skip-permissions" go to work on a difficult problem and watch it crunch away by itself for a couple of minutes running a bewildering array of tools until the problem is fixed.

Eh, I just watched Claude spend an hour trying to incorrectly fix code. Eventually I realized what was happening, stepped in and asked it to write a bunch of unit tests first, get the code working against those unit tests, and then get back to me.

Claude Code is amazing, but I still have to step in and give it basic architectural guidance again and again.

Re: Building a Personal AI Factory

#87

Post by barrenko »

dgunay wrote: post #84

I am experimenting with a similar workflow and thought I'd share my experience. I might be a little too hung up on the details compared to a lot of these agent cluster testimonials I've read, but unlike the author I'll be open and say that the codebase I work on is several hundred thousand lines of Go and currently does serve a high 5 to low 6 figure number of real, B2C users. Performance requirements are forgiving b…

There's been a lot of talk recently (with "recently" being measured in days for the agents field) about context management, but I'm having the hardest time managing my own context when using these methods.

Re: Building a Personal AI Factory

#89

Post by barrenko »

simonw wrote: post #28

My hunch is that this article is going to be almost completely impenetrable to people who haven't yet had the "aha" moment with Claude Code. That's the moment when you let "claude --dangerously-skip-permissions" go to work on a difficult problem and watch it crunch away by itself for a couple of minutes running a bewildering array of tools until the problem is fixed. I had it compile, run and debug a Mandelbrot fract…

https://youtu.be/bUBF5V6oDKw I'd like to add this video from the AI Engineer conf, which may also be impenetrable, by the folks from Dagger (person behind Docker)

Re: Building a Personal AI Factory

#90

Post by _1tem »

nilirl wrote: post #85

"Fix inputs" => The assumption is there exists some perfect input that will give you exactly what you want. It probably works well for small inputs and tasks well-represented in the training data (like writing code for well-represented domains). But how does this work for old code, large codebases, and emergencies? - Do you still "learn" the system like you used to before? - How do you think of refactoring if you don…

> But how does this work for old code, large codebases, and emergencies?

Have you actually tried Claude Code? It works pretty well on my old code, medium size SaaS codebase. I’ve had it build entire features end to end in (backend, front end, data migrations, tests) in one or two prompts.

Post reply on HN