Hacker News Reader

Comment by eterm | Hacker News Reader

I've learned that rather than juggle too much, I just accept that I'm still more productive than ever before, even if I'm "idle", it's important to take time to have a break and to recharge, refresh and reflect.

So I limit myself to at most 2 or 3 things at once, and if all of those are in long running sessions, well so be it, I know I'll be deep back in it soon.

But it's tempting to start "just one more session", especially something like getting it to better profile and improve performance. That feels super productive, but is often just to stop me feeling "idle".

View on HN

I think the multitasking problem will become a thing of the past when (or “if”) the models get much faster. I would absolutely love to just work on one thing at a time with a super fast model.

In the earlier days when they were slower and their code was worse so you had to review it, I’d watch the model code and just noodle away on guitar while it did its thing, interrupting it from time to time. Now they’re too fast for that to work, but still too slow for it not to be worth it to start a new task. It’s an awkward in-between stage.

If Anthropic made fast mode four or five times faster rather than just twice as fast, I’d probably shell out for it sometimes just to be able to single-task productively.

If call centres are anything to go by, it will be penalized to work on a single thing at once. The longer your workplace can resist measurements related to agents, the more sane the workplace will remain IMO, otherwise, it will turn into what happened to call centres around the 2000s. Measure everything down to the second, and introduce expectations that you will need to spend time justifying if you miss them.

The bottleneck is not only the model latency, Although it would help.

When you compile an ios app, or wait for some query result, search slack or wait for Github CI to finish, it all introduces significant wait between agent turns.

Models getting faster would help but would not eliminate the problem.

I main Deepseek Flash and the biggest bottleneck often isn't the model itself, its external stuff like compilation, testing things, making requests, running linters

Or running the 798 tests Opus wrote for your todo app.

"Claude, please remove 300 low value tests"

Agreed -- I only do 2 active things at a time, and maybe something third that is long-running in the background (like training a model or classifying thousands of files, where I just need to check in occasionally to make sure it hasn't veered off-track).

It's rare that with my 2 active things, they're both busy, since one usually finishes while I'm drafting my reply to the other.

When it occasionally happens that both are busy for the next 5 min, I just get to enjoy the break and stretch my legs and walk to the kitchen or something.

My cycle with agents has become: spend several days doing detailed planning architecture documents. Codify all new plans into Jira cards as isolated features. Mass fanout on the cards whenever possible with up to 32 agents running at a time, basically becomes a question frenzy for a couple crunch days. Stop and do testing and reviews for a week or two, I can generate up to 20 PRs per crunch day fairly reliably. Rinse and repeat. I feel lucky the type of software I'm producing is amenable to this process, some types aren't.

What are you working on?

Very large codebase modernization/conversion to newer libraries for interop and compliance reasons. Fan out only works if you have enough to do without the agents stepping on each others work. It is amazing when you can do it. Conversions make it even easier because you have a baseline metric of tested functionality to meet. We did pull off mass fanout on an ambitious greenfield internal tool that went very well. It feels like my entire job now is figuring out how to parallelize as much work as possible for the agents.

Not too dissimilar from my approach at work these days, sans the "up to 32 agents" bit.

I try to work on planning docs, scrutinize them a fair bit to look for edge cases or anything that stands out as a problem, whatever.

Then break down the work further into meaningful chunks and hand those out to agents. Mostly one agent at a time but with the directive to use subagents as needed for implementation/review/whatever other perspective I want.

I feel like I'm exercising my brain similarly to how I had in the past. Before LLMs we'd whiteboard things similarly and figure out if a design made sense and like you said, chunk it into Jira tickets. it's really just the implementor (?) that's changed.

After a week, my throughput is limited by compute to run tests/checks. Worse if I'm compiling Rust.

What’s the point of opening a PR in such a setup? Why not simply merge to trunk, and spin review agents?

I like this approach. I do exactly the same: do less with more focus. I do feel more productive. Otherwise there are too many sessions open and I get distracted and lost.

Jesus.

I only ever run one. You need to just write thoughts on a piece of paper while the agent runs. Do some design work or something.

The thing is, you’re not going to remember any of it so you’ll be useless to companies, and they can just hire someone else to have their own AI figure out what work your spaghetti agents did.

Slow down, for your own good!

Yeah and also being okay with throwing away that other stuff if it doesn't work out.

I feel you

Reply on news.ycombinator.com