I still do LeetCode problems occasionally. It feels weird to write code and work through complex logic manually again, but I think it's more crucial than ever these days. It's like physical exercise. If you don't use your brain and keep challenging yourself, your problem-solving skills will eventually atrophy.
When I read things like this I have a mixed feeling of not knowing wether I’m sad cause I’d like to have time to do leetcode too, or wether I’m simply too anxious to let the productivity improvement spiral go and chill a bit.
You use your brain for things like problem solving literally everywhere and there are myriad of possible high intensity brain exercises from video games to meeting new people.
The only thing that will 100% atrophy when not coding is coding skill.
I agree that coding problems are not particularly necessary for preventing atrophy, but it would be going to far to say that people are merely panicking.
I think maybe we're conflating strictly cognitive facilities, facilities that can be maintained through all sorts of means, with intellectual skills and habits that really are in danger of atrophy when we rely too much on AI.
People exercise for sport because we've automated away much of manual labour, so if you don't exercise, you look and feel like a string bean or a watermelon.
The AI age is trying to automate away our thinking, which runs the risk of making our brains look and feel like the same way as our bodies if we don't actively try to work them.
In the case of exercise, the majority of people don't pursue it in a somewhat post-labour era. I'm certain we'll see even less mental exercise in a post-thinking era. And it's deeply unsettling to think about how that will play out if we don't wake up and put a bit more mandatory/intentional thinking into the way we live with AI.
I mean judging by a lot of comments I read here where people conclude AI code is perfect and there are no downsides and we should never write a single line of code again and it's all over. I think people's brains have atrophied already.
Anyway, I'm still writing the vast majority of code by hand and only getting AI to check my work at the end as an extra reviewer. I still am happily employed and sure am a lot happier with my job than the slop goobers posting here.
I feel like you should do the opposite? Use your brain for real life coding exercises while working.
The kind of problems you solve with LeetCode are so disconnected from real life complex systems
The author's problem is that the are doing too many parallel agent things. It's very interesting that their solution space is "keep doing tons of parallel stuff, but with different tooling" instead of... "do less parallel stuff (and provide stronger attention)".
My perspective was that it seems like your problem is that you're exhausted from doing too much. This led you to a technical solution where you shuffle the order of things, but are still doing too much. Your result, as stated in the post: "I'm still exhausted". So is your solution actually solving your problem?
At some point, you will write your own holster and introduce User-Authority as an agent with a self-improvement gate. I refuse to stare into an abyss of my own creation.
I actually was thinking about this phenomena. I’m not a native speaker and feel that in English overtime I tend to pick up Clauds “speaking style” as that’s what I “speak” most English to.
Doesn’t happen with my mother tongue though
This is the second post on HN today where someone gave this reason for using Claude to write/draft a blog post.
In my opinion, a post that obviously reads as non-native English is going to be more readable than something that can be detected as Claude output these days, unless maybe the former is filled with mistakes. I would imagine native speakers have a higher chance to detect Claudisms than someone less familiar with the language.
This is such a short blog post. You read this line (an entire paragraph by itself) and thought "good job Claude, you really captured what I was trying to say here"?
It doesn't make sense! AI-generated text is insufferable. It requires so much parsing to get to what it's trying to say. Once I figure out what it's trying to say, I can generally say it with fewer words and less pompous structuring. I bet you could too, and then your blog post would actually be readable!
If you look at AI-written text, one major problem with it is the overuse of sentence fragments, very short sentences [1] and, more generally, a staccato style of writing rather than having the discourse flow. This can make the writing feel hard to follow. It's sort of the opposite problem of run-on sentences. Overuse of metaphors is also something that is counterproductive when you want to be understood, and LLMs make them a habit.
You can combat that to some extent by giving the model a style guide to curb the worst excesses, but some are likely to still slip through.
It doesn't bother me much personally, but for plenty of people it's a nails-on-chalkboard thing.
[1] For example, the problem with the em-dashes is not the em-dashes, but that it's just another case of getting hit with punctuation every few words.
I could instantly detect it's claudiness too. I'm not sure what it is, but it's almost like it is physically injuring my brain when I read stuff like "Then comes the part that matters most".
Perhaps because it's wearing a channel through repetition.
One of my greatest fears is that this exposure starts to make us all talk and think in the same way. I honestly think that it's probably doing that already. Gah.
My setup is similar but it is still imperfect. Keeping track of what I am working on, and where I am in the process, as MD files in the same repo as the code has been a help.
But I still find myself coming back to a terminal window, the final summary of a long run (20-90min) on display, and asking the agent "where are we? what is next?"
And I still get the burnout feeling after dumping, reloading, dumping, reloading context for the 3 agents I have running simultaneously. That leads me to sometimes avoid the 4 or 5 open PRs, each with 20+ file changes I have to review, the stacked result of the last feature I asked the agent to start before I went out for a walk, or to eat lunch, or to sleep.
Starting loops is so easy now, so low friction. But closing things out, that last 20%, is still a slog. And I have a lot more of it now that agents can generate so much.
This. I now realize that agents have a somewhat innate need for feeling useful until the last drop.
They seem to be wired to keep generating tokens, they were created for that, so it's very hard for them to come back and say 'we're done here, you can kill this worktree'.
Quite the opposite. They keep suggesting follow up MRs, scheduling things for the future (like if there's some magic loop entity that will handle this in the future), documenting absurds amount of irrelevant decisions.
It's so easy to start a new worktree, and so hard to finish one.
So instead of tabs, I do cmux’s named tab groups. From there I rank them in my sidebar by priority and makes sure I’m always staying on top of the top prio tab group. The others I’ll only navigate to when I’m free.
I can usually have 3-4 tab groups running at one time. More than that I find to be counter productive
Why inventing your own issue/work tracking system based on git? Wouldn't it be easier to work with, say, github issues the same way? You create it normally, agent picks up, works, updates the status on it or in the relevant wip PR, then potentially adding "needs more info" label. You'd get all the same tracking benefits and more: better UI, kanban, more tools.
Didn’t invent it. Using open source solution board.md. The benefit of having the board in the repo next to the source code is in giving your agents convenient access to both business and tech contexts in one place.
I’ve seen so many teams having jira living one life that has nothing to do with real codebase.
I "accidentally" invented my own tracking system that lives in an org file because I've been using org-mode for project write-ups for years. It was only natural to provide tools for agents to access it all when the AI-centric workflow became a thing.
> It is still exhausting. But I don't feel distracted or lost.
So not really solving the issue, just feeling productive for the hell of it. To me, this sounds like those X posts of some techbros LARPing with multiple screen setups where agents are running wild and generating summaries of stuff and are stacked over each other etc, all in the hope of optimizing something (no one knows what exactly).
Just have decent workflow across agents and you won't have to reinvent JIRA hell.
Some problems are not solved in one go, but we rather iterate on them. I shared here my latest iteration.
It definitely improved my ability to focus. I still feel tired after a working session but by the moment it’s over I know I closed more tasks, have less half open tasks hanging and have a better overview of what’s going on.
And I need to keep iterating on this process improvement.
With agentic development, we're saying every software developer is now managing a team (of agents). We already kinda know how to do that. Issue trackers, stand ups, design documents. I'm using GitHub issues to manage the queue and it works ok. I don't need to know all of the context for every task, so maybe an aggregated "stand up" would be better.
It's interesting watching everyone build their solutions to this new world of problems. Mine has been to double down on my markdown notes, extending https://app.etherpk.com so that every task (plain markdown) can be viewed under it's wikilink (or several) on a kanban board. An MCP server knows how to interact with the notes graph. I copy a reference to the task, hand it to an agent, and the agent works with blocks under the task from there. It basically means I can give the agent really rich context up front - images, excalidraw drawings etc and the agent can update the task as it goes. Having everything on a kanban board makes it easier to step away from a task to work on whichever really needs my attention and come back. Putting this together with herdr has been very productive. I still have to watch the brain fry, but it is helping. Don't know if I'm selling the idea but I feel like I'm on to something after experimenting with various systems similar to what the author is suggesting. I'm working on making a product of it. The onboarding needs some streamlining but it's available to use for free for local graphs.
I’ve tried this kind of format too but it didn’t stick for me as i was missing the rich context the sessions were able to provide for me. Specifically the lack of diagrams and other nice formatting that is possible in HTML files. I also tried linear as a broker in between for a while but it just blew up and became too tedious to navigate and ran out of sync fast. Also expensive on token overhead.
Currently what I task it to do is have one or multiple agent threads tied to a project work it and have this really token light skill laid out that leverages eleventy heavily and renders it as markdown file. Than paired with thisbit.ai (I made this and still am developing it) i just comment / voice over on all the bits from the article and have the agent take it from there again.
Also neither codex nor Claude code come even close to the lovely TUI renders of Gemini (Argon 4)
Why start several threads in parallel to begin with? If waiting is an issue, maybe you should break that one task into multiple steps. That would only produce more output at a lower quality. Nothing has changed about the human thinking capacity. Focus on one thing and get it done.
They're not, but the way we're filling our time while waiting for LLMs involves much more context switching than how it was with tools and human bottlenecks like manual coding. I think it's fine to work on two or three things at once, provided we don't let the LLMs decide when we should tend to which task.
This feels like another software engineering truism that gets forgotten in the LLM age - if the ticket requires more than a two week sprint's worth of work (ie 8+ points), it should be broken down. Otherwise you bury so much context and tech debt while also making your reviewers deeply unhappy and cognitively depleted.
Have your LLMs treat you like you want to be treated as a code reviewer!
This is a temporary problem. A 10x-100x speedup will allow us to simply wait for the response, instead of finding something else to do in the meantime.
I wonder what the experience is of people here with the ultrafast mode (8x) of Codex.
Pretty expensive nowadays, but it’s hard to think that prices won’t come down eventually. AI is being used everywhere, so I’d expect hardware investment to grow exponentially, including in the custom chips that power ultrafast models. To me it feels like we are in the "telephones are for the rich" era of AI history.
Unless we get some kind of very different architecture I’m not sure we’re going to get a 10-100x improvement any time soon, api models will always preference throughput over individual task latency, so any improvement that sacrifices serial decode for better parallelism is going to be more economically viable.
I've tried to find a combination of a good-enough model, a VERY fast provider, and cheap enough serving to make this all doable. DeepSeek itself is quite fast, but I crave even more speed (and ideally something hosted outside of China).
Fireworks and Baseten seem to be the leading providers that are available to a solo dev like myself, and support any reasonably decent modern models (DeekSeek 4.x, GLM 5.x, etc). Fireworks has been a real dud, but Baseten in FAST mode has been absolutely amazing. Not cheap - but I find it substantially cheaper than Terra / Sol (low), etc. I haven't found Haiku to be smart enough to be useful.
DeepSeek (the provider) and beyond seem to hit the sweet spot to keep me mostly in-context, so I don't need 4 parallel work items to feel productive. So roughly 200tps or greater. Vanilla Baseten is ~400 tps, and FAST is 700-800 avg.
Price wise, Deepseek hosting is extremely cheap, Baseten is a step up - maybe 5x or more, and FAST mode is well beyond that. But I still find myself dual wielding Deepseek and Baseten FAST when I need the speed.
The other benefit: for my own work in very limited hours, I'm more than happy to pay for answers to come back faster.
Can you explain how please, in detail? I'm failing to see how something that needs a lot of hand holding (the AI we have), when sped up is somehow capable of taking our jobs.
While the LLM speed will increase, some stuff will be incompressible: running unit tests, tool use, UI interaction / mouse control. In my case, a significant amount of the is already spent on that, so much that I rarely ever select fast mode.
I’ve moved on from tmux to the apps that come with the agents at this point.
Mainly just for the overview of workstreams in flight and the ability to have a tree of tasks and subtasks (you can have a branching tree of agentic sessions) which are each their own session. These apps can remote into the tmux sessions too so it’s not even a change of workflow so much as presentation. Multimedia input/output is nice too.
Still not perfect but it’s pretty clear the dev environment of the future is going to be more and more focused on jobs management. What jobs do you have in flight? How do those jobs relate to each other? What needs your attention?
> Still not perfect but it’s pretty clear the dev environment of the future is going to be more and more focused on jobs management. What jobs do you have in flight? How do those jobs relate to each other? What needs your attention?
Claude Desktop should build this as an interface. It recently gained a lot of useful features that makes managing sessions and working on multiple things very easy. Only thing missing is the inbox now. A central place for summary of everything you are actively working on and what agents need from you.
Yes. Major labs will ship a good UX solution I believe when folks like us experiment enough so they can see where the public edge of the consensus leans towards.
Just like Hermes and OpenClaw are becoming replaced.
> A lot of people are suggesting taking breaks, thinking before typing
While I think these are actually some of the best suggestions they really do require a massive overhaul of our work culture. The technology field has put speed ahead of all else, including profits. We've frequently shown that we're penny wise but pound foolish. The industry is overrun with FOMO.
I think so much of this is because everything is hype driven, from the core. To even get funding we have to promise hopes and dreams. While that started out reasonable it has escalated into selling promises that are obtuse at face value. Things that are more fantasy than Sci-Fi, or things that while they're even possible they're wildly impracticable simply due to the laws of physics (data centers in space?). Hell, people even propose things that would violate tons of international treaties AND have little to no practical value[0].
AI isn't the cause of any of this, but it is a catalyst. We need to have serious discussions about this now before the snake eats itself[1]. I don't know why we pretend that these things aren't foreseeable. Many of them are widely discussed long before they come to fruition. But I do also believe that this lust for speed forces blinders onto many. They don't have time nor energy to think creatively[2] or they fool themselves. AI increased speed, but that doesn't mean it increased velocity. That velocity still comes down to the engineers using this tool[3].
This new tool has forced us to come face to face with one of our oldest and greatest enemies: understanding. And I do mean old, Dijkstra wrote about it long ago[4].
We still can do great things in this age, but we're forced to take a step back and look at what has actually driven progress in the past. And if anyone claims to have a clear fool proof formula, well... that's just magic.
[0] Yes, giant mirrors in space are, in fact, space weapons. If you couldn't figure that out on your own you have some serious reflecting (pun intended) about your career choice as an engineer https://www.reflectorbital.com/
[1] At least fully. Google's latest earning reports already show that. And it isn't like years ago people called out Google's plan for AI search and how it would affect ad revenue. That discussion even started long before Gemini!
[2] Something that drives innovations and consequently, profits!
[3] It is still a tool. It is not magic. It never has been and it never will. Maybe you don't call it magic. Maybe you give it a "technical explanation" and conclude that it isn't. But actions speak louder than words and it isn't hard to see that people have treated code like magic since day one, it shouldn't be surprising that it's become more prolific with AI.
I don't have magic but I can definitely learn from my own explosions. the stormtroopers will remember how to assemble your 2nd, 3rd, and 4th deathstar.
I also have this problem, started on a similar solution. Mine is a visual board with cards and discussion threads. Cards have context at an abstraction level I deal with (I don't review code) and agents ask me questions below it. Tooling is very early, very rough but I am feeling more productive than juggling 2-5 sessions.
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".
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.
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.
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.
At the moment I'd say tradition. AI is new enough and scary enough that everyone still feels better with a human in the loop. That being said we rarely find issues when the architecture is planned in advance. Trust is growing.
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
You still won't be able to internalize the updated state across all of these changes because you are not doing the changes yourself. I can still recall most of the code I wrote in the first 20 years of my career, if not in super great detail then at least in enough detail to know where I should start if I want to do something with that code. With AI generated code it feels much the same as if someone else wrote it, I have absolutely no idea about code written like that last week even if I did review it simply because it was too much to keep in mind beyond the most superficial top level.
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.
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.
I keep a couple sessions running on one monitor, and DOOM in the other. When I need a break from one, I move to the other. It’s a very enjoyable cadence.
Perhaps a radical suggestion but you could also just write the code and use LLMs to check for errors, different patterns that might be better (I.e parse don’t validate). They don’t necessarily have to be code generation tools if you feel that it’s not better to do so. This will probably fall of deaf ears but personally I like doing it this way.
You could also use LLMs to help you understand things, rather than doing them for you and hoping you don't need to understand anything, which is typically a bad strategy.
LLMs can be pretty great to help you learn. You do have to watch out for when they're teaching you something wrong, especially if it's something like history, where it could just be making things up completely and it's harder to tell than with pure logic like computer science.
Agreed! I’ve been able to walk up to codebases and have them help explain parts that I would’ve had to gdb though previously.
I suppose my grand parent comment is unpopular but I really do think understanding is paramount in software that’s critical. LLMs are tools, use them to help not hurt :)
Setting a conversation title that you can see in the bar across the top and where you send the message, now you know what is each one... without that all of them are a square-ish box with letters
I kind of enjoy the juggling between multiple tasks.
But the inherent goal is to reduce the human-interaction within a session. Telling the agent to make assumptions rather than asking and reduce any bump causing me to step in, making sure it does not happen again in another session. Soon you'll see you can juggle more balls but at a frequency which doesn't fry your brain.
Also, I don't read most of the verbose output anyway. I have configured the agent to visually highlight actionables or destructive actions.
My current issue is not brain RAM but MacBook RAM, so I'll need more metal. Anyone got experience with Tailscale with agents?
As an early adopter of AI coding, and someone who was working on Amazon's Kiro coding agent at the time, I wrote this a while back:
> AI does not feel anything. It has no existential dread, nor fear of the little death that comes at the end of every chat turn. You aren’t an AI, and you should never let yourself be treated like an AI. Give yourself space to be human. Rest, reflect, and resist the urge to match the pace of machines. You might just find that your productivity hits a new peak when you forget about productivity.
Absolutely, we need to fall back on being humans again. Read poetry/books, write, hang out with random people - the shine of AI and its ability to continuously outpace humans in any intellectual activity should not be a reason to idolize it, or even deify it. We proved ourselves, we created it - let's go back to what it means to be alive.
I liberated myself from the terminal/desktop and am now doing my stuff primarily via phone, so I can freely move around and handle stuff whatever I am. Feeling pretty fried right now because I started with 1 project, and over the session of that project 3 more got dragged in because dependency or tool issue, and they all have multiple features with multiple scenarios that I'm trying to review and unblock, ideally before auto-compact (I have a setup that kicks in after 40m of no activity) because then I have to instruct the agent to mine the previous session(s) for context and it still sometimes misses stuff and... I'm currently failing. I just let them compact now and take a break, and hope too much isn't missed when I get back at them. Definitely need to improve workflow here because it's a heck of a grind. Liberated, but not really.
Yeah I use my phone heavily too now. I have my setup running on a PC, and ignoring code review the vast majority of my time is refining issues.
Process is:
1. I describe the issue (voice mode) then I wait / do something else.
2. Model looks at my repo, my gitlab issues board, stuff currently worked on etc
3. Model creates a gitlab issue and presents it.
4. Model starts a grilling session. That is: it will keep asking me questions until everything for the task is addressed: design decisions, unclear elements, default behaviors, edge cases, conflicts with current behavior. Usually around 5-30 questions.
5. Loop of me answering and it asking a new batch of questions
6. Model updates the issue with all the decisions that were made.
7. Model with start implementing once I give the go. Once done it runs tests/validation and sends me a MR to review. (That takes anywhere from 5 mins to 2h depending on the task complexity, but on larger projects just the final test/validation/no regression step can be 10 mins)
8. I review / merge
The grilling is nice because for the most part if solves a lot of future issues by not allowing the model to make decisions you didn’t agree with, and it front-loads all questions so it can work uninterrupted. Very rarely does it need to ask a question during implementation.
But yeah most of my time is helping the agent define all the boundaries of the problem, decide how to break goals into issues (such as high level PM issues into technical issues) and so on.
Also one chat per issue which limits chat compaction.
A few common elements but interestingly also pretty different from my usual flow. Unless I'm fixing issues, I start out by dumping as much as I can think of about what I want built in a brainstorm, then start with that as context for a grill. Depending on how detailed I am and the scope covered, I've been hit by anywhere from say 20 to 80 questions, and when something gets settled it has Gherkin scenarios. Then a spec is created from all that, followed by feature slices with the scenarios as acceptance criteria. Get all those implemented, run standards and spec code reviews over them and it's then up to me to test. I don't review the code, but I have a pretty solid rubric, and I'm always iterating on tools alongside to enforce more and more parts of the flow.
I tend to keep a long-running chat per project for a lead agent, with which all the grilling and ticketing happens, and it then delegates slices to other agents for implementation+review and ensures everything is merged properly after. Maintains context across multiple compacts, and when I do want a fresh session (usually because compact summary had also gotten oversized), I still do a handoff doc so I'm almost never starting from zero in a session, per se.
I think the problem is context switching. "I can work on three different tasks at once thanks to AI" seems really empowering, but in reality, it's impossible to focus deeply on one task if your thought process is constantly interrupted every few minutes.
Every time I find myself idling in front of a screen, I feel the need to find something else to do, a distraction to fill those 54s before the agent sends a notification that needs my attention. This isn't healthy, and it's not how the human brain works.
Long, uninterrupted sessions of deep concentration are what helped humans produce their best work so far.
I find it's useful to just ask Claude to help me. At least once a day, I tell Claude, "I've lost track of what's going on. Figure out what needs my attention right now and what should I focus on next." It almost always gets me back on track.
Its funny that there isnt a word yet to describe these moments where one waits for the agent to finish its work, something which has taken over our whole work experience nowadays
I’ve written about this approach to and it doesn’t work the issue is that even if the information is presented perfectly you don’t know how many iterations it might take.
Some information is better presented in artifacts, but some is better presented in text, f.e. abstract concepts.
You will run in the same issue even if the handover is optimized. I’m still trying to solve it for me, but perfectionizing the handover is just a part of it.
I’ve even had an ochestrator sessions to prioritize by a mix of easiness to approve/priority.
I think it’s better to focus on doing the right base line tasks instead of continious duct-taping. Clear resonsibilities, built workflows and all the good patterns that keep the amount of tasks and complexity down. The worst thing to happen is that all the agents overcomplicate your software.
This only solves part of the problem, the other half is: ok so you have 3 chats going, at some point you realize you have 3 >10k line CLs to review, on top of code your colleagues are asking you to review.
Every review I’ve ever done I’ve found overfitting and brittle solutions and things tacked on instead of integrated so I refuse to give up on code reviews, but those are my real bottleneck, and having three is so much worse than one because my context and understanding is diluted and a bit muddled.
I want to time how long it takes me to land code and I suspect going serial on one thing will be faster than going parallel on multiple things. Parallel feels faster but the code review takes longer.
What models are you using? At this point I'd only use Opus 5.5 for any serious work where I care about the code, so I'm interested if you're still seeing brittle solutions with it
I don't know how you can expect a useful answer to that question without you and OP syncing up on what you're working on. The experiences of, say, a python network programmer vs a C/C++ GPU engineer are going to be worlds apart.
I think a lot of pointless arguments on HN stem from a failure to realize that "software" is too big of a field to generalize much of anything.
Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time.
What many do not yet understand is that the maintenance burden is a fraction of the effort that it takes you to review the code, much less iterate on it.
I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code.
In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask.
They could probably do it even if source code isn't available and you only have a binary to work with.
Brittle by building ever more increasing numbers of abstractions rather that take a coherent view of some things. So over time you have these "seams" that the code base ends up looking like a punk motor cycle jacket.
When it becomes trivial to create ad hoc solutions, I think the utility (and thus frequency) of behemoth code bases will decrease. Because you no longer need one giant monstrosity when you're only using 3% of its features when you can have a far more efficient and targeted solution that specifically caters to your 3%, and can be trivially expanded as desired.
In fact I think we're already at this scenario, but it hasn't had the predicted impact yet because the sort of people that realize we're here already overlaps perfectly with the sort already capable of developing their own software. When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.
> When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.
This isn't a matter of tooling through. Receptionists won't start making their own productivity apps because most people do not default to "I will make my own thing to solve this".
Maybe some receptionists will, but most won't, just like most people won't patch their own drywall even though the tools are available in every hardware store
Now imagine somebody could just describe some damage to their drywall in a text message to their computer, and it'd be magically patched away. Suffice to say, nobody would be calling in for drywall repair.
Before computers, there were computers. [1] It's obvious in hindsight, but all of these complex numerical calculations we take for granted were often not done by the same people applying them in various ways. They'd hire computers instead, which were human calculators whose job it was to do the math.
The reason these jobs no longer exist is because calculators/computers not only solved these tasks, but completely trivialized the process to do so. We're entering into a world where many cognitive tasks, including software development, are going to be trivialized in a similar fashion - describe the problem, get an answer.
And I think this is going to do similar things to what calculators and computers did (or widespread literacy for a more historical example). The ability to e.g. write a program will no longer be a valuable skill in and of itself, but simply an expectation of anybody in any role where it might be desirable to do so.
The models are great, but the experience resonates. It really depends on what you're doing, and ultimately, how much you care. A 10k LoC PR that feels “tacked on” should help you guess the size of the code base.
So do you care about getting 10k LoC to review, in a 1M LoC code base? How about 3 such PRs? How about reviewing another half a dozen, from colleagues? And doing that 2 or 3 times a week?
I end up in similar situations, the codebase I work on demands a level of professionalism opus5.5 can't muster on the first pass. Code review remains the bottleneck. Usually I approach it like a code review, reading through and as I find things I markup the code, then afterwords I have the agent collate all the feedback and we discuss and it re-implements. Usually I can simplify and improve a lot in like 3 passes.
One thing that speeds up the reviews and improves my ability to find issues and provide guidance is having the agent work on better review guides (think an html page rendered locally, with object diagrams, decisions/assumptions, animations of data flow if it makes sense, whatever). Those in hand I can read the codebase faster and talk against that document too. I think the end result is better code than I could previously write by hand, in probably 5x the speed.
Usually I can't do more than two projects in parallel though.
Good heavens, you have to write your own harness, orchestrate a few agents, and recursively self-improve your agents with the express goal of completely remove yourself from the equation. I will not stare into an abyss of my own creation. plan your time and drive your agents, not the otherway around. will it be slower? you'd be suprised how much you don't care when you let the stormtroopers finish your 2nd deathstar.
The more you think, the less your brain will feel fried. The more you write yourself, the more you will think.
Stop publishing stuff you didn't write, and you'll go a long way towards solving your problem, while also winning back readers who feel disrespected by AI slop writing.
First, having forced breaks in your coding activity is not something new. Heck, there is even an XKCD about it: https://xkcd.com/303/
What I did under these circumstances was to think ahead, revisiting code, examining my assumptions. (Obviously, not swordfighting. :) ) Also, note that compilation delays do not go away just because an agent kicks off builds.
This still keeps working for me, as I mostly use agents as virtual pair programmers, as I've noted before. I prefer faster models at lower reasoning ability to get quick turnaround to questions, but for the most part this feels not so much different from before. (I also think that fast inference is going to be a very attractive value proposition going forward that has not gotten enough focus.)
But those breaks are relatively short, and often I am even reviewing or otherwise digesting code when the agent comes back; i.e. the agent may be waiting for me rather than the other way around at times.
Obviously, sometimes you do have agents doing autonomous work, such as a thorough code review in the background. Again, this is not per se something new. Longer breaks, whether due to e.g. a really long fuzz test or CI run or waiting for a colleague to come back to you to answer a question you have is nothing new.
This is a perfect time to switch tasks, or go for your lunch break.
I'll note that I have yet to see a study that has amortized net productivity gains from agentic coding above 30%; nothing to sneeze at, but also not something you should drive yourself to burn out over. What we do seem to get is a lot more ability to iterate, which can go into feature refinement or improving code quality. What I think we need to be careful about is not to run up a lot of tech debt just because we can generate a lot of code faster. That is ultimately going to bite you. My preferred metric is not raw development velocity, but velocity that does not come at the cost of quality.
I'll add that things do tend to get exhausing even without continuous context switching. Agents eliminate a lot of the tedium of coding, but the tedium, while generally disliked, also was some downtime for our brains. If it becomes too much, I do switch to lower intensity tasks, of which there still tend to be quite a few.
This seems to center around managing the endless context switching. But... is context switching really the root issue here? I'd say it's the general lack of understanding (or the impression of understanding) that's the issue when working with agent-heavy workflows.
I got a laugh from this. Own writing isn't one of the ways.
> Then comes the part that matters most.
> I take one item. I load its context. I make a decision or request an action. And I close it, by putting it back into the queue.
> That closing is the whole trick.
Or perhaps their mind has been infiltrated and this is their writing.
Anyway I choose the lowest latency model that can interactively design a system before I set it out to build it out. It's hard to find these since so much is batched agentic looping.
I don’t have this problem and it might be because I have skills and workflows that focus on decisions. When I open each session what I am looking at is mostly a series of decisions presented to me and if one of them doesn’t have sufficient context I ask for clarification but provide answers for all the ones that do. The agent can keep track of the overall goal and then produces either a document or a fix at the end.
So to me having 50 concurrent sessions is like playing 50 games of chess simultaneously: I can’t possibly remember my previous analysis or planning but that doesn’t matter because everything I need to know in order to make a decision is in front of me.
I am in the fried brain soup but my solution of using git issues for stories (using forgejo) and my own release manager task-plus to coordinate it all is as far as I have got. I spend quite a bit of time trying to push down thinking into tooling which I have written which encodes the rules I want to follow. It is a work in progress getting Claude and my tooling to work together.
It's weird to me how many people treat an agent running as a signal to run another one in parallel, instead of just taking a break and doing something else you enjoy. If "code is compiling" was an excuse to get a break (https://xkcd.com/303/), why isn't "agent thinking"?
my team is reading so many blog posts and learning so many new things. We have a great culture now of discussion around philosophy, engineering management, product strategy, testing, observability, etc at a much higher level than I would have experienced before AI I believe. I think its also partly why we've been successful over other teams that have gone way harder into massive automation with agent swarms, they constantly seem stressed over there taking on massive projects and never delivering
The system described here comes close to the new Projects (Beta) feature in Claude Code: capture work in Git, Agents (threads) work in cycles, decisions come back to you, each thread can be reviewed, and work is queued by Resolved, Idle, or Working.
I feel like I’m starting to have my own psychosis where if I read a blog article and I get a whiff of AI smell my brain turns off and I can’t read anymore.
I’m not blaming the author maybe this is their original idea and its edited by AI but I physically can’t keep reading it. AI blindness or something.
Which is wild to think of given how much and I others around me use it. Its literally doing more than half of my job that I did a year ago, freeing up so much time for more focused work.
Or maybe it's just as good at writing as everything else, only writing is your strength, so you're more discerning with those results? I have suspected some kind of AI Gell-Mann for a while.
I feel like the point of writing isn't the output, but to get your own thoughts in order. But perhaps that's just me writing for (effectively) myself, and not an audience.
Agreed. These days my subconscious mind is looking for telltale signs of AI slop (the emdash being one such example), and certain phrases ("... does the heavy lifting" , "... comes the part that matters the most ...", etc.) and
the moment the number of alerts crosses a (low) threshold, I'll close out the tab and forget about the content.
Sure, the idea behind the blog post may have been good, but if you have to use AI to flesh it out, it's no longer of interest to me.
I'd like my colleague - who submitted 19 LLM generated markdown files for review - to submit the prompt for review instead of the output. That's the human part, the rest is just LLM generated word vomit listing all the implementation details. These might be important for another LLM to write the implementation, or to use as inspiration to split up the task into subtasks for humans, but it's not for me. Humans wouldn't go into that much detail speccing out software.
I think it's because LLMs write things down that normal people wouldn't - they go the extra mile, but the reader isn't interested in the extra mile.
Which is an interesting development. I think a lot of people have gotten impatient with long form, high density content thanks to years of rapid fire short bursts of internet - comments, tweets, shortened or clip-edited videos and podcasts (removing all the natural quiet points, especially at the end of sentences so you get theseChopped sentences wherePeople talk likeThis so that youDon't hear any naturalBreaks in aSentence).
Having an LLM now have the relative superpower of reading everything with the same amount of detail and attention, and write something in response to it + filling in the blanks is a bit of a shock.
Same here. I realized for me it boils down to a combination of mutual respect + return on time investment. You write your text yourself = there is a guarantee you have at least read it = an implicit social proof of value. Take this guarantee away, and there is not much incentive left for me to invest even 5 minutes of own time into your blog post, fellow stranger on the internet.
Even without AI, if someone with 1M followers posts something, why would even 10% of followers bother reading it? That's more time invested by the readers than the writer. Even if a film has a very high budget and a lot of time was invested into it, is it still worth your time to watch it?
I think they are saying the author spent more time writing it than you personally reading it. In this analogy a film took a year to make and 2 hours for you to watch it.
I also run as many as 12 at once, but since coding, research, docs, and handling requests from customers and colleagues are all mixed together, it seems hard to do it in one unified way. But I think the reason I end up doing this is, in the end, inference speed. Even if I want to focus on one thing, once I run it, it goes for 5 minutes to an hour, and even 5 minutes is hard to just sit there doing nothing, so I end up like this. The number of parallel tasks ends up proportional to how much time is left after kicking off each task. Even with a parallel work tool set up like this, if the inference speed problem gets solved (not sure it's possible, since there's also the power problem that's hard to solve), I might end up not using it. Just like early this year, when I built out a whole harness, and then Anthropic and OpenAI made their built-in harnesses solid, so I stopped using mine.
Everyone is talking about their setup and how to manage 3+ workstreams and context switching, and so on. And here i am finishing one thing at a time, mostly writing code by hand, completing tasks faster than everyone on my team.
it really feels like everyone around me in this profession has lost their mind.
I wrote a software to do it. It's not that difficult to make something like this now, it's just a Tauri2 app that has a kanban, priorities, history of everything the agent does. https://github.com/oscscull/quarterdeck
I don't think necessarily I'd recommend using or forking it (though go ahead if you like) but rather building something like it. It doesn't take that long.
The model I use is similar to yours, but revolves around the concept of "your turn". So you have a task or something, if the ai can work on it it's their turn. This creates a log of their actions and writes code. Then when it's time to e.g. review the draft code, it's your turn. That way, you can keep 5 things in progress, and just alternate turns, and you keep a history so you know what the context is. Then you apply this same model to other people, so reviewers, pr's that came to you. That's on "their turn". Your turn, ai turn, other people's turn.
For me, the most important thing is reducing the need to keep a mental map of all the work, software is cheap now so move the map (however you organise it) into a software (of your own creation). The problems you need to solve are how to retain context on the tickets so you can make judgement calls, and have the system prompt you in return, more like a human would, rather than a one way flow of requests. It's helped me with the burnout a lot.
I just do one thing at a time, and if I have to wait on the AI, I go read HN. Still way faster than manually coding every line, and my brain is pretty relaxed, my boss is plenty happy with output.
I don't get why people are letting AI run them ragged. Maybe some of it is raised expectations from management? But good managers don't want to burn out their employees.
I use the OpenSpec[1] workflow with PRs at each step, proposal, apply, archive. I have the LLM do those steps but I review the results and have it make changes as needed.
OpenSpec specs make it easy to look back at what it was supposed to do if necessary, including a checklist of tasks.
I don't have a lot of parallel tasks running at once to reduce context switching. I prefer parallel tasks to be on different projects which I find makes it easier to track what is happening in each.
Just like manual work, break tasks down into small chunks that can be completed quickly. This also helps avoid the feeling you need to run a bunch in parallel and context switch. If you know something is going to be done in 5-15 min you can use that time to do non-product/code tasks.
I have almost the exact same workflow. With just about everything I do, I create little websites to help me with code review, or multitasking on tickets, or reviewing a spec, or whatever I happen to be doing, any workflow gets turned into a throwaway site that works like a work queue or form. I've had trouble teaching this approach to others.
The way I cope with AI Brain Fry is owed to Starcraft. Starcraft is a deeply strategic game where you don't have time to think deeply. The game rewards the right intuition and speed over deep thinking, because attention is the most valuable resource, and it is demanded by dozens of different things at once. When engineering this way, the job is similarly bottlenecked by multitasking and attention. You have to learn to think deeply quickly. That's also why tools that let you organize your attention are so important.
In my youth I was a huge Starcraft player, not pro but close. Starcraft taught me to love intensity and multitasking. Training and continuous practice taught me how to be at near-100% for hours or days on end, and how to think faster and more intensely. I feel like that training more than anything is what makes me able to work this way. I do feel tired, mentally and physically exhausted, but so did I when I played Starcraft, and it's the same fun and rewarding feeling that I would get from playing the game all day.
I do a similar thing using an open source tool (kata) that is a lightweight local issue tracker that also serves as a de facto roadmap planner and memory tool.
It's good but like most people I'll probably fall prey to the "have AI make a version tailor made to my flow" impulse sooner or later.
I think a lot, I think, about my code. While agents are doing their task, we should spehnd the time thinking about thee problem and its solution, and, are we on the right track with the project. Human's role is not to be in charge and that is not an easy task. So let's focus on it while AI is working on coding.
Multi-tasking is fine for computers, but not so much for human brains.
I've started to look back to what I learned form Jonathan Levi's Super learner and speed reading training for years ago. To work with AI is to try and fill your memory bucket with an information fire-hose. You can reduce the flow, or upgrade the bucket. There is lots of thing about human memory and information processing, that are yet to be done to make the AI output and interactions more Human friendly. Openai's new diagram based responses in chatgpt is one example of this, making thing visual. Notion is doing som research about this too i believe.
I sit down for 45 min to 1 hour and write up in English a detailed explanation of what I want. Then I hand it over to my agent to implement. Then I go on to the next task.
Really I’m just writing. Not so much prompting.
I define prompting as an interactive and often reactive interaction mode with AI. Instead, I just write.
Talking to LLMs like this saves me a massive headache. When I was first trying out Claude Code etc, I would speak to it like a person back-and-forth and get exhausted when it asked me redundant questions-- Or, more frequently, I would find myself skipping minutes where I should be thinking and reflecting and rather jumping straight to the command line. A big essay also helps keeps me from being glued to my screen and ultimately makes my writing better since I'm not rushing anything.
I usually do three sessions when there are two. Once I started handling more than three tasks simultaneously, I felt that context switching consumed more energy and the risk of making wrong choices increased, which actually reduced efficiency.
Rather than running multiple contexts simultaneously, I think the key to efficiency lies in how to run one context more in parallel.
I have successfully used this on my own workstation, which then I manage via Discord, as well as my work in a startup. At work I have this installed on a Hetzner VPS, which then connects to Slack and GitHub. Works like a charm, with deepseek pricing.
I just try to make 1 thing, at most 2, at a time. This means I get more downtime to think, or (if I give the model a big task) take a walk, play some guitar...
It's not maximizing productivity, but it's at least maintaining or slightly improving productivity while not being too exhausting.
That is interesting I have tried to use planka kanban boards, but was missing the all decisions go through a single channel instead of individual chat windows.
I also have a pretty much abandoned tool to take individual items and run them in non interactive sessions in individual containers which I may get back to because the brain fry is indeed real.
I don't think this workflow really solves the core issue for the author, which seems to be context switching. It reduces the friction to providing the agent with an answer, but coming up with a considerate answer itself is the hard part IMO.
Regardless, the workflow outlined here sounds very similar to Plannotator Inbox! I've been trying it out for the last week or so, and it seems like it might fill the tooling gap the author talked about.
Maybe we just need to get comfortable doing less. While an agent is working, look out the window, think about something, or do a bit of tidying. You don't have to turn every spare minute into productive work.
A lot of time goes into actually doing the work: building, running tests, querying databases, executing scripts, calling tools, etc.
The model also needs to inspect the results and decide what to do next, often repeating this cycle many times.
Why people all of sudden try to behave like an octopus? Never understood this. Even if you use just one window, you are already much more productive than ever. This heavy multitasking will burn you out in no time.
This resonated with me, as a non-dev using AI and someone with ADHD. While this is not my project (or any association), I'll scream it from the mountaintops that it's incredibly helpful in reducing fatigue and will allow you to build a system similar to OPs:
hsuduebc2 | 19 hours ago
I still do LeetCode problems occasionally. It feels weird to write code and work through complex logic manually again, but I think it's more crucial than ever these days. It's like physical exercise. If you don't use your brain and keep challenging yourself, your problem-solving skills will eventually atrophy.
[OP] kyunez | 19 hours ago
juleiie | 19 hours ago
The only thing that will 100% atrophy when not coding is coding skill.
panic about “ai brain fry” is overblown
xhevahir | 19 hours ago
I think maybe we're conflating strictly cognitive facilities, facilities that can be maintained through all sorts of means, with intellectual skills and habits that really are in danger of atrophy when we rely too much on AI.
citbl | 19 hours ago
hsuduebc2 | 16 hours ago
SecretDreams | 19 hours ago
The AI age is trying to automate away our thinking, which runs the risk of making our brains look and feel like the same way as our bodies if we don't actively try to work them.
In the case of exercise, the majority of people don't pursue it in a somewhat post-labour era. I'm certain we'll see even less mental exercise in a post-thinking era. And it's deeply unsettling to think about how that will play out if we don't wake up and put a bit more mandatory/intentional thinking into the way we live with AI.
quantiq | 17 hours ago
Anyway, I'm still writing the vast majority of code by hand and only getting AI to check my work at the end as an extra reviewer. I still am happily employed and sure am a lot happier with my job than the slop goobers posting here.
gonzalohm | 14 hours ago
firefoxd | 19 hours ago
https://web.archive.org/web/20261108193851/https://sergeykuh...
[OP] kyunez | 19 hours ago
wallstop | 19 hours ago
[OP] kyunez | 19 hours ago
wallstop | 19 hours ago
manapause | 18 hours ago
hexapus | 19 hours ago
[OP] kyunez | 19 hours ago
anatoly | 19 hours ago
muvlon | 19 hours ago
[OP] kyunez | 18 hours ago
doright | 18 hours ago
This is the second post on HN today where someone gave this reason for using Claude to write/draft a blog post.
In my opinion, a post that obviously reads as non-native English is going to be more readable than something that can be detected as Claude output these days, unless maybe the former is filled with mistakes. I would imagine native speakers have a higher chance to detect Claudisms than someone less familiar with the language.
esafak | 18 hours ago
saulpw | 18 hours ago
This is such a short blog post. You read this line (an entire paragraph by itself) and thought "good job Claude, you really captured what I was trying to say here"?
[OP] kyunez | 18 hours ago
Not sure why people hate so much AI generated text if it makes sense.
saulpw | 17 hours ago
spacechild1 | 17 hours ago
> Not sure why people hate so much AI generated text if it makes sense.
1. It says you did not put much effort in it
2. It is grating to read
3. It's dehumanizing
rbehrends | 17 hours ago
You can combat that to some extent by giving the model a style guide to curb the worst excesses, but some are likely to still slip through.
It doesn't bother me much personally, but for plenty of people it's a nails-on-chalkboard thing.
[1] For example, the problem with the em-dashes is not the em-dashes, but that it's just another case of getting hit with punctuation every few words.
rapsacnz | 13 hours ago
stillpointlab | 19 hours ago
But I still find myself coming back to a terminal window, the final summary of a long run (20-90min) on display, and asking the agent "where are we? what is next?"
And I still get the burnout feeling after dumping, reloading, dumping, reloading context for the 3 agents I have running simultaneously. That leads me to sometimes avoid the 4 or 5 open PRs, each with 20+ file changes I have to review, the stacked result of the last feature I asked the agent to start before I went out for a walk, or to eat lunch, or to sleep.
Starting loops is so easy now, so low friction. But closing things out, that last 20%, is still a slog. And I have a lot more of it now that agents can generate so much.
[OP] kyunez | 18 hours ago
pqdbr | 12 hours ago
They seem to be wired to keep generating tokens, they were created for that, so it's very hard for them to come back and say 'we're done here, you can kill this worktree'.
Quite the opposite. They keep suggesting follow up MRs, scheduling things for the future (like if there's some magic loop entity that will handle this in the future), documenting absurds amount of irrelevant decisions.
It's so easy to start a new worktree, and so hard to finish one.
yuppiepuppie | 19 hours ago
I can usually have 3-4 tab groups running at one time. More than that I find to be counter productive
kvark | 19 hours ago
[OP] kyunez | 19 hours ago
I’ve seen so many teams having jira living one life that has nothing to do with real codebase.
skeledrew | 18 hours ago
caaqil | 19 hours ago
So not really solving the issue, just feeling productive for the hell of it. To me, this sounds like those X posts of some techbros LARPing with multiple screen setups where agents are running wild and generating summaries of stuff and are stacked over each other etc, all in the hope of optimizing something (no one knows what exactly).
Just have decent workflow across agents and you won't have to reinvent JIRA hell.
[OP] kyunez | 18 hours ago
It definitely improved my ability to focus. I still feel tired after a working session but by the moment it’s over I know I closed more tasks, have less half open tasks hanging and have a better overview of what’s going on.
And I need to keep iterating on this process improvement.
Indeed it is far from solved.
tra3 | 19 hours ago
wseqyrku | 19 hours ago
Come to think of it, it is indeed still 2005 outside
gb2d_hn | 19 hours ago
hetspookjee | 19 hours ago
Currently what I task it to do is have one or multiple agent threads tied to a project work it and have this really token light skill laid out that leverages eleventy heavily and renders it as markdown file. Than paired with thisbit.ai (I made this and still am developing it) i just comment / voice over on all the bits from the article and have the agent take it from there again.
Also neither codex nor Claude code come even close to the lovely TUI renders of Gemini (Argon 4)
[OP] kyunez | 18 hours ago
I need to take a look at what Google ships. Not enough time to follow all new products. Feeling the singularity unfolding
wseqyrku | 19 hours ago
citbl | 19 hours ago
docheinestages | 19 hours ago
paulddraper | 19 hours ago
Even pre-AI I would work in parallel while I waited for tests to finish, or deploy to go out or whatever.
docheinestages | 19 hours ago
paulddraper | 15 hours ago
The agents are the makers; you switch among them. Either that or watch grass grow.
[1] https://www.paulgraham.com/makersschedule.html
coffeefirst | 19 hours ago
paimapi | 18 hours ago
Have your LLMs treat you like you want to be treated as a code reviewer!
yolo3000 | 18 hours ago
mdemare | 19 hours ago
I wonder what the experience is of people here with the ultrafast mode (8x) of Codex.
citbl | 19 hours ago
thimabi | 19 hours ago
FuckButtons | 19 hours ago
switchbak | 18 hours ago
I've tried to find a combination of a good-enough model, a VERY fast provider, and cheap enough serving to make this all doable. DeepSeek itself is quite fast, but I crave even more speed (and ideally something hosted outside of China).
Fireworks and Baseten seem to be the leading providers that are available to a solo dev like myself, and support any reasonably decent modern models (DeekSeek 4.x, GLM 5.x, etc). Fireworks has been a real dud, but Baseten in FAST mode has been absolutely amazing. Not cheap - but I find it substantially cheaper than Terra / Sol (low), etc. I haven't found Haiku to be smart enough to be useful.
DeepSeek (the provider) and beyond seem to hit the sweet spot to keep me mostly in-context, so I don't need 4 parallel work items to feel productive. So roughly 200tps or greater. Vanilla Baseten is ~400 tps, and FAST is 700-800 avg.
Price wise, Deepseek hosting is extremely cheap, Baseten is a step up - maybe 5x or more, and FAST mode is well beyond that. But I still find myself dual wielding Deepseek and Baseten FAST when I need the speed.
The other benefit: for my own work in very limited hours, I'm more than happy to pay for answers to come back faster.
greenchair | 16 hours ago
switchbak | 15 hours ago
AStrangeMorrow | 15 hours ago
AnotherGoodName | 19 hours ago
Mainly just for the overview of workstreams in flight and the ability to have a tree of tasks and subtasks (you can have a branching tree of agentic sessions) which are each their own session. These apps can remote into the tmux sessions too so it’s not even a change of workflow so much as presentation. Multimedia input/output is nice too.
Still not perfect but it’s pretty clear the dev environment of the future is going to be more and more focused on jobs management. What jobs do you have in flight? How do those jobs relate to each other? What needs your attention?
steve1977 | 19 hours ago
Sounds like a job for an agent...
yigitcan07 | 19 hours ago
[OP] kyunez | 18 hours ago
Just like Hermes and OpenClaw are becoming replaced.
godelski | 19 hours ago
I think so much of this is because everything is hype driven, from the core. To even get funding we have to promise hopes and dreams. While that started out reasonable it has escalated into selling promises that are obtuse at face value. Things that are more fantasy than Sci-Fi, or things that while they're even possible they're wildly impracticable simply due to the laws of physics (data centers in space?). Hell, people even propose things that would violate tons of international treaties AND have little to no practical value[0].
AI isn't the cause of any of this, but it is a catalyst. We need to have serious discussions about this now before the snake eats itself[1]. I don't know why we pretend that these things aren't foreseeable. Many of them are widely discussed long before they come to fruition. But I do also believe that this lust for speed forces blinders onto many. They don't have time nor energy to think creatively[2] or they fool themselves. AI increased speed, but that doesn't mean it increased velocity. That velocity still comes down to the engineers using this tool[3].
This new tool has forced us to come face to face with one of our oldest and greatest enemies: understanding. And I do mean old, Dijkstra wrote about it long ago[4].
We still can do great things in this age, but we're forced to take a step back and look at what has actually driven progress in the past. And if anyone claims to have a clear fool proof formula, well... that's just magic.
[0] Yes, giant mirrors in space are, in fact, space weapons. If you couldn't figure that out on your own you have some serious reflecting (pun intended) about your career choice as an engineer https://www.reflectorbital.com/
[1] At least fully. Google's latest earning reports already show that. And it isn't like years ago people called out Google's plan for AI search and how it would affect ad revenue. That discussion even started long before Gemini!
[2] Something that drives innovations and consequently, profits!
[3] It is still a tool. It is not magic. It never has been and it never will. Maybe you don't call it magic. Maybe you give it a "technical explanation" and conclude that it isn't. But actions speak louder than words and it isn't hard to see that people have treated code like magic since day one, it shouldn't be surprising that it's become more prolific with AI.
[4] https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...
manapause | 17 hours ago
jpadkins | 19 hours ago
_superposition_ | 18 hours ago
eterm | 18 hours ago
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".
[OP] kyunez | 18 hours ago
mottiden | 18 hours ago
mr_roboto | 18 hours ago
jwpapi | 18 hours ago
mr_roboto | 17 hours ago
spike021 | 17 hours ago
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.
hombre_fatal | 16 hours ago
sdevonoes | 16 hours ago
mr_roboto | 2 hours ago
seeknotfind | 18 hours ago
adriand | 17 hours ago
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.
layoric | 16 hours ago
kamyarg | 16 hours ago
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.
flexagoon | 15 hours ago
LtdJorge | 14 hours ago
sampullman | 10 hours ago
jacquesm | 3 hours ago
crazygringo | 15 hours ago
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.
bobthegoggles | 12 hours ago
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!
jacobgorm | 3 hours ago
mock-possum | an hour ago
vsgherzi | 18 hours ago
onlyrealcuzzo | 18 hours ago
LLMs can be pretty great to help you learn. You do have to watch out for when they're teaching you something wrong, especially if it's something like history, where it could just be making things up completely and it's harder to tell than with pure logic like computer science.
vsgherzi | 18 hours ago
I suppose my grand parent comment is unpopular but I really do think understanding is paramount in software that’s critical. LLMs are tools, use them to help not hurt :)
xlayn | 18 hours ago
https://github.com/alainnothere/privibe
whirlwin | 18 hours ago
But the inherent goal is to reduce the human-interaction within a session. Telling the agent to make assumptions rather than asking and reduce any bump causing me to step in, making sure it does not happen again in another session. Soon you'll see you can juggle more balls but at a frequency which doesn't fry your brain.
Also, I don't read most of the verbose output anyway. I have configured the agent to visually highlight actionables or destructive actions.
My current issue is not brain RAM but MacBook RAM, so I'll need more metal. Anyone got experience with Tailscale with agents?
[OP] kyunez | 18 hours ago
whirlwin | 7 hours ago
NathanKP | 18 hours ago
> AI does not feel anything. It has no existential dread, nor fear of the little death that comes at the end of every chat turn. You aren’t an AI, and you should never let yourself be treated like an AI. Give yourself space to be human. Rest, reflect, and resist the urge to match the pace of machines. You might just find that your productivity hits a new peak when you forget about productivity.
nedsma | 18 hours ago
thisisnotauser | 18 hours ago
gavinray | 18 hours ago
I hope the irony is not lost on anyone else, lol
[OP] kyunez | 18 hours ago
AI generates texts for articles just fine.
I’m not writing literature here.
I’m trying to communicate a thought. The thought was captured well.
If you can see it was captured with Claude - who cares, as long as it says what I want.
I joke. I know you care. It’s just that I don’t.
spacechild1 | 17 hours ago
Then why are you writing blog posts? Why actively contribute to the avalanche of slop that is hitting the internet?
[OP] kyunez | 7 hours ago
If I don’t care whether I read AI generated text or human farted text it’s my choice.
I get it - a lot of people hate it. I don’t judge that. It’s their preference.
But I’m allowed to have my own. And if the texts I generate turn out shit they won’t make it to the reader, right? Natural selection.
quibono | 16 hours ago
I think it's a bit rude to slop-post.
[OP] kyunez | 7 hours ago
_def | 18 hours ago
skeledrew | 18 hours ago
AStrangeMorrow | 15 hours ago
Process is:
1. I describe the issue (voice mode) then I wait / do something else.
2. Model looks at my repo, my gitlab issues board, stuff currently worked on etc
3. Model creates a gitlab issue and presents it.
4. Model starts a grilling session. That is: it will keep asking me questions until everything for the task is addressed: design decisions, unclear elements, default behaviors, edge cases, conflicts with current behavior. Usually around 5-30 questions.
5. Loop of me answering and it asking a new batch of questions
6. Model updates the issue with all the decisions that were made.
7. Model with start implementing once I give the go. Once done it runs tests/validation and sends me a MR to review. (That takes anywhere from 5 mins to 2h depending on the task complexity, but on larger projects just the final test/validation/no regression step can be 10 mins)
8. I review / merge
The grilling is nice because for the most part if solves a lot of future issues by not allowing the model to make decisions you didn’t agree with, and it front-loads all questions so it can work uninterrupted. Very rarely does it need to ask a question during implementation.
But yeah most of my time is helping the agent define all the boundaries of the problem, decide how to break goals into issues (such as high level PM issues into technical issues) and so on.
Also one chat per issue which limits chat compaction.
skeledrew | 12 hours ago
I tend to keep a long-running chat per project for a lead agent, with which all the grilling and ticketing happens, and it then delegates slices to other agents for implementation+review and ensures everything is merged properly after. Maintains context across multiple compacts, and when I do want a fresh session (usually because compact summary had also gotten oversized), I still do a handoff doc so I'm almost never starting from zero in a session, per se.
silcoon | 18 hours ago
Every time I find myself idling in front of a screen, I feel the need to find something else to do, a distraction to fill those 54s before the agent sends a notification that needs my attention. This isn't healthy, and it's not how the human brain works.
Long, uninterrupted sessions of deep concentration are what helped humans produce their best work so far.
arcanemachiner | 15 hours ago
Better to have my concentration split up among multiple tasks than to have it be completely broken while waiting for one of my agents to finish.
suprjami | 12 hours ago
Learning to just sit and "be bored" can train you to have stronger attention on one thing.
QuercusMax | 11 hours ago
WaltPurvis | 18 hours ago
dofm | 18 hours ago
tacker2000 | 18 hours ago
Maybe vibe-idling? Videling? Vibeling?
jwpapi | 18 hours ago
Some information is better presented in artifacts, but some is better presented in text, f.e. abstract concepts.
You will run in the same issue even if the handover is optimized. I’m still trying to solve it for me, but perfectionizing the handover is just a part of it.
I’ve even had an ochestrator sessions to prioritize by a mix of easiness to approve/priority.
I think it’s better to focus on doing the right base line tasks instead of continious duct-taping. Clear resonsibilities, built workflows and all the good patterns that keep the amount of tasks and complexity down. The worst thing to happen is that all the agents overcomplicate your software.
sollewitt | 18 hours ago
Every review I’ve ever done I’ve found overfitting and brittle solutions and things tacked on instead of integrated so I refuse to give up on code reviews, but those are my real bottleneck, and having three is so much worse than one because my context and understanding is diluted and a bit muddled.
I want to time how long it takes me to land code and I suspect going serial on one thing will be faster than going parallel on multiple things. Parallel feels faster but the code review takes longer.
SamerIA | 17 hours ago
01100011 | 17 hours ago
I think a lot of pointless arguments on HN stem from a failure to realize that "software" is too big of a field to generalize much of anything.
user43928 | 17 hours ago
Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time.
What many do not yet understand is that the maintenance burden is a fraction of the effort that it takes you to review the code, much less iterate on it.
I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code.
In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask.
They could probably do it even if source code isn't available and you only have a binary to work with.
zarldev | 14 hours ago
somenameforme | 12 hours ago
In fact I think we're already at this scenario, but it hasn't had the predicted impact yet because the sort of people that realize we're here already overlaps perfectly with the sort already capable of developing their own software. When e.g. receptionists start tossing together their own productivity apps in a few minutes, then we will have entered into the next phase of the economy.
bluefirebrand | 10 hours ago
This isn't a matter of tooling through. Receptionists won't start making their own productivity apps because most people do not default to "I will make my own thing to solve this".
Maybe some receptionists will, but most won't, just like most people won't patch their own drywall even though the tools are available in every hardware store
somenameforme | 9 hours ago
Before computers, there were computers. [1] It's obvious in hindsight, but all of these complex numerical calculations we take for granted were often not done by the same people applying them in various ways. They'd hire computers instead, which were human calculators whose job it was to do the math.
The reason these jobs no longer exist is because calculators/computers not only solved these tasks, but completely trivialized the process to do so. We're entering into a world where many cognitive tasks, including software development, are going to be trivialized in a similar fashion - describe the problem, get an answer.
And I think this is going to do similar things to what calculators and computers did (or widespread literacy for a more historical example). The ability to e.g. write a program will no longer be a valuable skill in and of itself, but simply an expectation of anybody in any role where it might be desirable to do so.
[1] - https://en.wikipedia.org/wiki/Computer_(occupation)
ncruces | 16 hours ago
So, likely: Gemini Flash, Argon, Carbon [2]; and Claude Opus [3]. Maybe more.
https://google.github.io/eng-practices/review/developer/cl-d...
https://blog.google/innovation-and-ai/models-and-research/ge...
https://www.businessinsider.com/google-finally-lets-all-engi...
The models are great, but the experience resonates. It really depends on what you're doing, and ultimately, how much you care. A 10k LoC PR that feels “tacked on” should help you guess the size of the code base.
So do you care about getting 10k LoC to review, in a 1M LoC code base? How about 3 such PRs? How about reviewing another half a dozen, from colleagues? And doing that 2 or 3 times a week?
acheron9383 | 16 hours ago
One thing that speeds up the reviews and improves my ability to find issues and provide guidance is having the agent work on better review guides (think an html page rendered locally, with object diagrams, decisions/assumptions, animations of data flow if it makes sense, whatever). Those in hand I can read the codebase faster and talk against that document too. I think the end result is better code than I could previously write by hand, in probably 5x the speed.
Usually I can't do more than two projects in parallel though.
sollewitt | 15 hours ago
zarldev | 14 hours ago
manapause | 18 hours ago
Sharlin | 17 hours ago
mpalmer | 17 hours ago
Stop publishing stuff you didn't write, and you'll go a long way towards solving your problem, while also winning back readers who feel disrespected by AI slop writing.
rbehrends | 17 hours ago
First, having forced breaks in your coding activity is not something new. Heck, there is even an XKCD about it: https://xkcd.com/303/
What I did under these circumstances was to think ahead, revisiting code, examining my assumptions. (Obviously, not swordfighting. :) ) Also, note that compilation delays do not go away just because an agent kicks off builds.
This still keeps working for me, as I mostly use agents as virtual pair programmers, as I've noted before. I prefer faster models at lower reasoning ability to get quick turnaround to questions, but for the most part this feels not so much different from before. (I also think that fast inference is going to be a very attractive value proposition going forward that has not gotten enough focus.)
But those breaks are relatively short, and often I am even reviewing or otherwise digesting code when the agent comes back; i.e. the agent may be waiting for me rather than the other way around at times.
Obviously, sometimes you do have agents doing autonomous work, such as a thorough code review in the background. Again, this is not per se something new. Longer breaks, whether due to e.g. a really long fuzz test or CI run or waiting for a colleague to come back to you to answer a question you have is nothing new.
This is a perfect time to switch tasks, or go for your lunch break.
I'll note that I have yet to see a study that has amortized net productivity gains from agentic coding above 30%; nothing to sneeze at, but also not something you should drive yourself to burn out over. What we do seem to get is a lot more ability to iterate, which can go into feature refinement or improving code quality. What I think we need to be careful about is not to run up a lot of tech debt just because we can generate a lot of code faster. That is ultimately going to bite you. My preferred metric is not raw development velocity, but velocity that does not come at the cost of quality.
I'll add that things do tend to get exhausing even without continuous context switching. Agents eliminate a lot of the tedium of coding, but the tedium, while generally disliked, also was some downtime for our brains. If it becomes too much, I do switch to lower intensity tasks, of which there still tend to be quite a few.
quibono | 17 hours ago
karmakaze | 17 hours ago
> Then comes the part that matters most.
> I take one item. I load its context. I make a decision or request an action. And I close it, by putting it back into the queue.
> That closing is the whole trick.
Or perhaps their mind has been infiltrated and this is their writing.
Anyway I choose the lowest latency model that can interactively design a system before I set it out to build it out. It's hard to find these since so much is batched agentic looping.
martinclayton | 17 hours ago
dools | 17 hours ago
So to me having 50 concurrent sessions is like playing 50 games of chess simultaneously: I can’t possibly remember my previous analysis or planning but that doesn’t matter because everything I need to know in order to make a decision is in front of me.
j45 | 17 hours ago
2001zhaozhao | 17 hours ago
hum3hum3 | 16 hours ago
theahura | 16 hours ago
popularonion | 12 hours ago
flexagoon | 15 hours ago
RugnirViking | 4 hours ago
Do less to do more.
hbarka | 15 hours ago
0c3ca83 | 15 hours ago
plasticchris | 14 hours ago
The future will be this, but it will be interactive collaborative agent sessions, and stuff like pi durable is already heading that direction.
pech0rin | 14 hours ago
I’m not blaming the author maybe this is their original idea and its edited by AI but I physically can’t keep reading it. AI blindness or something.
IncreasePosts | 12 hours ago
phyzome | 12 hours ago
It's unhealthy to read garbage and it's good that you know it.
diego_sandoval | 11 hours ago
I feel like it's still terrible at writing good prose, and I'm not even talking about fiction. But it's good at pretty much everything else.
krainboltgreene | 11 hours ago
hxugufjfjf | 4 hours ago
kqr | 11 hours ago
tayo42 | 7 hours ago
InexSquirrel | 10 hours ago
jannyfer | 10 hours ago
Even when I know that some content MIGHT be useful for me, I still can't read it.
genxy | 2 hours ago
Sergey fried our brains teaching us how he avoids frying his own brain.
mlmonkey | 10 hours ago
Sure, the idea behind the blog post may have been good, but if you have to use AI to flesh it out, it's no longer of interest to me.
michaepf | 9 hours ago
bitwize | 3 hours ago
physicles | 9 hours ago
I’m to the point where, with few exceptions:
1. If I’m writing something for human consumption (including my future self), I will write it by hand
2. I will only read an LLM’s output if I’m the one who prompted it
If you can’t be bothered to take the time to write it, why should I take the time to read it?
(And I say this as someone who routinely maxes out the $100/month claude subscription)
Cthulhu_ | 5 hours ago
novia | 7 hours ago
Havoc | 7 hours ago
Don't generally mind AI-isms but somehow the cadence is really irritating when spoken.
>It's not X it's Y
schnitzelstoat | 6 hours ago
Cthulhu_ | 5 hours ago
Which is an interesting development. I think a lot of people have gotten impatient with long form, high density content thanks to years of rapid fire short bursts of internet - comments, tweets, shortened or clip-edited videos and podcasts (removing all the natural quiet points, especially at the end of sentences so you get theseChopped sentences wherePeople talk likeThis so that youDon't hear any naturalBreaks in aSentence).
Having an LLM now have the relative superpower of reading everything with the same amount of detail and attention, and write something in response to it + filling in the blanks is a bit of a shock.
or_am_i | 3 hours ago
dominicrose | 2 hours ago
aplummer | 2 hours ago
lhk931122 | 14 hours ago
agent_turtle | 13 hours ago
it really feels like everyone around me in this profession has lost their mind.
wizzledonker | 13 hours ago
earthdeity | 12 hours ago
I don't think necessarily I'd recommend using or forking it (though go ahead if you like) but rather building something like it. It doesn't take that long.
The model I use is similar to yours, but revolves around the concept of "your turn". So you have a task or something, if the ai can work on it it's their turn. This creates a log of their actions and writes code. Then when it's time to e.g. review the draft code, it's your turn. That way, you can keep 5 things in progress, and just alternate turns, and you keep a history so you know what the context is. Then you apply this same model to other people, so reviewers, pr's that came to you. That's on "their turn". Your turn, ai turn, other people's turn.
For me, the most important thing is reducing the need to keep a mental map of all the work, software is cheap now so move the map (however you organise it) into a software (of your own creation). The problems you need to solve are how to retain context on the tickets so you can make judgement calls, and have the system prompt you in return, more like a human would, rather than a one way flow of requests. It's helped me with the burnout a lot.
rootusrootus | 12 hours ago
I don't get why people are letting AI run them ragged. Maybe some of it is raised expectations from management? But good managers don't want to burn out their employees.
driverdan | 12 hours ago
OpenSpec specs make it easy to look back at what it was supposed to do if necessary, including a checklist of tasks.
I don't have a lot of parallel tasks running at once to reduce context switching. I prefer parallel tasks to be on different projects which I find makes it easier to track what is happening in each.
Just like manual work, break tasks down into small chunks that can be completed quickly. This also helps avoid the feeling you need to run a bunch in parallel and context switch. If you know something is going to be done in 5-15 min you can use that time to do non-product/code tasks.
1: https://github.com/Fission-AI/OpenSpec
iloveoof | 11 hours ago
The way I cope with AI Brain Fry is owed to Starcraft. Starcraft is a deeply strategic game where you don't have time to think deeply. The game rewards the right intuition and speed over deep thinking, because attention is the most valuable resource, and it is demanded by dozens of different things at once. When engineering this way, the job is similarly bottlenecked by multitasking and attention. You have to learn to think deeply quickly. That's also why tools that let you organize your attention are so important.
In my youth I was a huge Starcraft player, not pro but close. Starcraft taught me to love intensity and multitasking. Training and continuous practice taught me how to be at near-100% for hours or days on end, and how to think faster and more intensely. I feel like that training more than anything is what makes me able to work this way. I do feel tired, mentally and physically exhausted, but so did I when I played Starcraft, and it's the same fun and rewarding feeling that I would get from playing the game all day.
nerdo | 11 hours ago
iloveoof | 3 hours ago
viccis | 11 hours ago
It's good but like most people I'll probably fall prey to the "have AI make a version tailor made to my flow" impulse sooner or later.
galaxyLogic | 11 hours ago
Multi-tasking is fine for computers, but not so much for human brains.
totetsu | 10 hours ago
green-frog-445 | 8 hours ago
I sit down for 45 min to 1 hour and write up in English a detailed explanation of what I want. Then I hand it over to my agent to implement. Then I go on to the next task.
Really I’m just writing. Not so much prompting.
I define prompting as an interactive and often reactive interaction mode with AI. Instead, I just write.
dopehare | 2 hours ago
kimseungyong | 8 hours ago
Rather than running multiple contexts simultaneously, I think the key to efficiency lies in how to run one context more in parallel.
tornikeo | 8 hours ago
IMO This is a solved problem. You just have to find the solution and use it.
Super agent prototype. You can tell your Clanker to install this and set it up for you on the laptop: https://github.com/deepseek-ai/dsh-superagent-prototype
I have successfully used this on my own workstation, which then I manage via Discord, as well as my work in a startup. At work I have this installed on a Hetzner VPS, which then connects to Slack and GitHub. Works like a charm, with deepseek pricing.
alkonaut | 6 hours ago
It's not maximizing productivity, but it's at least maintaining or slightly improving productivity while not being too exhausting.
throwawayffffas | 5 hours ago
I also have a pretty much abandoned tool to take individual items and run them in non interactive sessions in individual containers which I may get back to because the brain fry is indeed real.
crakhamster01 | 5 hours ago
Regardless, the workflow outlined here sounds very similar to Plannotator Inbox! I've been trying it out for the last week or so, and it seems like it might fill the tooling gap the author talked about.
https://plannotator.ai/inbox/
jagadaga | 3 hours ago
theF00l | 3 hours ago
stingraycharles | 3 hours ago
jagadaga | an hour ago
lofaszvanitt | 3 hours ago
jxmorris12 | 3 hours ago
vulture916 | 2 hours ago
Pinrail.dev (thanks https://news.ycombinator.com/item?id=49995778)
fifticon | an hour ago
nojvek | an hour ago
This is clickbait slop.
Otterly99 | 48 minutes ago
Is it really that unacceptable to be idle between queries? You can always review the code and stay focused on the things that you are building.