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.<p>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.<p>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 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.<p>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.<p>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.
The bottleneck is not only the model latency, Although it would help.<p>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.<p>Models getting faster would help but would not eliminate the problem.
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.
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.
Not too dissimilar from my approach at work these days, sans the "up to 32 agents" bit.<p>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.<p>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.<p>I feel like I'm exercising my brain similarly to how I had in the past. Before LLMs we'd whiteboard things similarly and figure out if a design made sense and like you said, chunk it into Jira tickets. it's really just the implementor (?) that's changed.
After a week, my throughput is limited by compute to run tests/checks. Worse if I'm compiling Rust.
What’s the point of opening a PR in such a setup? Why not simply merge to trunk, and spin review agents?
What are you working on?
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.
Yeah and also being okay with throwing away that other stuff if it doesn't work out.
I feel you
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.<p>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.<p>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.
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.<p>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.<p>Usually I can't do more than two projects in parallel though.
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
CL (change list) is Google speak for a PR [1].<p>So, likely: Gemini Flash, Argon, Carbon [2]; and Claude Opus [3]. Maybe more.<p><a href="https://google.github.io/eng-practices/review/developer/cl-descriptions.html" rel="nofollow">https://google.github.io/eng-practices/review/developer/cl-d...</a><p><a href="https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-carbon/" rel="nofollow">https://blog.google/innovation-and-ai/models-and-research/ge...</a><p><a href="https://www.businessinsider.com/google-finally-lets-all-engineers-use-anthropics-claude-2026-9" rel="nofollow">https://www.businessinsider.com/google-finally-lets-all-engi...</a><p>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.<p>So do <i>you</i> care about getting 10k LoC to review, in a 1M LoC code base? How about 3 such PRs? How about reviewing <i>another</i> half a dozen, from colleagues? And doing that 2 or 3 times a week?
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.<p>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.
It depends on how you define brittle.<p>Functional code that is perhaps overly defensive or specific in ways that will require updating it in the future? All the time.<p>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.<p>I see people on here talk about a supposed eventual collapse of maintainability if they do not review or understand the code.<p>In reality this never happens. The latest models can salvage and refactor even the biggest mess; all you need to do is ask.<p>They could probably do it even if source code isn't available and you only have a binary to work with.
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.
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.<p>Have your LLMs treat you like you want to be treated as a code reviewer!
This is the right question. The science on multitasking and frenetic context switching is pretty clear. New software doesn’t change that.
Because LLMs and tools are not instant.<p>Even pre-AI I would work in parallel while I waited for tests to finish, or deploy to go out or whatever.
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.
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.<p>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.<p>Also neither codex nor Claude code come even close to the lovely TUI renders of Gemini (Argon 4)
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 <a href="https://app.etherpk.com" rel="nofollow">https://app.etherpk.com</a> 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 moved on from tmux to the apps that come with the agents at this point.<p>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.<p>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?
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.<p>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.<p>Long, uninterrupted sessions of deep concentration are what helped humans produce their best work so far.
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.
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.<p>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?"<p>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.<p>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.
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:<p>> 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.
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.<p>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.
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.<p>I can usually have 3-4 tab groups running at one time. More than that I find to be counter productive
I've been using herdr without much trouble. Very easy to use. You'll have to pry my terminal from my cold, dead hands.
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.<p>I wonder what the experience is of people here with the ultrafast mode (8x) of Codex.
Speed is the real solution here.<p>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).<p>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.<p>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.<p>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.<p>The other benefit: for my own work in very limited hours, I'm more than happy to pay for answers to come back faster.
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.
The price...
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.
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.<p>Some information is better presented in artifacts, but some is better presented in text, f.e. abstract concepts.<p>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.<p>I’ve even had an ochestrator sessions to prioritize by a mix of easiness to approve/priority.<p>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.
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.
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.
I kind of enjoy the juggling between multiple tasks.<p>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.<p>Also, I don't read most of the verbose output anyway. I have configured the agent to visually highlight actionables or destructive actions.<p>My current issue is not brain RAM but MacBook RAM, so I'll need more metal. Anyone got experience with Tailscale with agents?
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.
Non-hugged link:<p><a href="https://web.archive.org/web/20261108193851/https://sergeykuhne.com/blog/fighting-ai-brain-fry" rel="nofollow">https://web.archive.org/web/20261108193851/https://sergeykuh...</a>
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<p><a href="https://github.com/alainnothere/privibe" rel="nofollow">https://github.com/alainnothere/privibe</a>
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.
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.
> We already kinda know how to do that. Issue trackers, stand ups, design documents.<p>Come to think of it, it is indeed still 2005 outside
HN hug of death strikes again.<p>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.
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.<p>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.<p>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.
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.<p>The <i>only</i> thing that will 100% atrophy when not coding is coding skill.<p>panic about “ai brain fry” is overblown
Been programming for about 30 years... this AI brain fry is very real. I would be very scared to take an interview right now...
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.<p>I think maybe we're conflating strictly cognitive facilities, facilities that can be maintained through all sorts of means, with <i>intellectual</i> skills and habits that really are in danger of atrophy when we rely too much on 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.<p>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 sharing a blog post you let Claude write for you is a pretty good sign you have not successfully evaded AI Brain Fry.
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)".
<p><pre><code> > "The page is only a viewer — git is the record."
> "Then comes the part that matters most."
> "That closing is the whole trick."
</code></pre>
Not sure how much I trust an article on fighting AI brain fry in which the author outsourced writing a handful of paragraphs to AI...<p>I hope the irony is not lost on anyone else, lol
I already commented on similar complaint but will say this again.<p>AI generates texts for articles just fine.<p>I’m not writing literature here.<p>I’m trying to communicate a thought. The thought was captured well.<p>If you can see it was captured with Claude - who cares, as long as it says what I want.<p>I joke. I know you care. It’s just that I don’t.
> It’s just that I don’t.<p>Then why are you writing blog posts? Why actively contribute to the avalanche of slop that is hitting the internet?
No one would care if it was just a personal note. Since it's something meant for other people they do care.<p>I think it's a bit rude to slop-post.
I got a laugh from this. Own writing isn't one of the ways.<p>> Then comes the part that matters most.<p>> 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.<p>> That closing is the whole trick.<p>Or perhaps their mind has been infiltrated and this is their writing.<p>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 like how that resembles the unix philosophy, do five things and do nothing well
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<p>Maybe vibe-idling? Videling? Vibeling?
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.
I thought you’re supposed to roll around on your chair swordfighting while your agents are agenting.
It's funny watching people slowly (re-)discover that a kanban board seems like a good idea for agentic coding.
Thought it was “How I'm fighting the AI Brian Ferry”. Sad it wasn’t that. (Bryan, I know.)
I read this and I think, OK, that seems like a strategy. And then a bit of my brain says "dude, dude, you've seen <i>Metropolis</i> right?"
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.<p>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.
I basically made a jira for my agents. It's super handy for context switching.
I go about this somewhat differently.<p>First, having forced breaks in your coding activity is not something new. Heck, there is even an XKCD about it: <a href="https://xkcd.com/303/" rel="nofollow">https://xkcd.com/303/</a><p>What I did under these circumstances was to think ahead, revisiting code, examining my assumptions. (Obviously, not swordfighting. :) )<p>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.)<p>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.<p>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.<p>This is a perfect time to switch tasks, or go for your lunch break.<p>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.<p>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.
i've been using git-bug for this and it helps a lot in complex projects
Reading books is critical.
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.<p>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.
<p><pre><code> > A lot of people are suggesting taking breaks, thinking before typing
</code></pre>
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.<p>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].<p>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].<p>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].<p>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.<p>[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 <a href="https://www.reflectorbital.com/" rel="nofollow">https://www.reflectorbital.com/</a><p>[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!<p>[2] Something that drives innovations and consequently, profits!<p>[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.<p>[4] <a href="https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288.html" rel="nofollow">https://www.cs.utexas.edu/~EWD/transcriptions/EWD02xx/EWD288...</a>
> It is still exhausting. But I don't feel distracted or lost.<p>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 <i>what</i> exactly).<p>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.<p>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.<p>And I need to keep iterating on this process improvement.<p>Indeed it is far from solved.
The more you think, the less your brain will feel fried. The more you write yourself, the more you will think.<p>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.
[dead]
[flagged]
[flagged]