[–] [S] 1 point 4 days ago

I had never really thought too much about WIP limits before reading this. I assumed they existed to encourage team members to help unblock each other, instead of picking up another ticket. However there is a cognitive reason, which is all the more pertinent with agentic coding.

We looked at the agents and thought: these things are cheap, they run in parallel, there’s no reason to limit how many I spin up. And that’s true — for the agents. The constraint was never the agents. The constraint is the single human in the middle whose job is to actually understand what came back.

This is old, old wisdom and we keep re-learning it. Jerry Weinberg, in Quality Software Management back in 1992, put a number on context switching: split your attention across two projects and you lose roughly 20% of your time to the switching itself. Add a third and you’re bleeding something like 40%. The lines on that chart are brutal, and — this is the important bit — they don’t care that your workers are robots. The switching tax is levied on you, the one doing the switching. Eight agents means you are basically not paying attention to any of them.

Kanban people have been shouting about WIP limits for twenty years for exactly this reason. Limiting work-in-progress isn’t about the capacity of the workers. It’s about the capacity of the system to finish things well. And a pile of half-attended-to agent output isn’t finished. It’s inventory. Expensive, unread, possibly-wrong inventory.

  • source
  • [–] 4 points 4 days ago*

    Interesting read. I agree with the author, especially about the part about the normalizing of deviance. Although I do not interact with agents or LLM's anywhere close to the scale as the author does, and let's be honest here - running 8 different agents simultaneously, all with different tasks while telling yourself that you know what is being done, is honestly just poor judgement.

    But I can absolutely see how a combination of the over-confident attitude from the LLM, with repeated success from tasks, and tiredness, will eventually lead the user to start assuming that repeated success, and forgetting to actually pay attention to what changes are being done and what the agent isn't proudly boasting about.

  • source
  • [–] 3 points 1 week ago

    No one doing this workflow is actually coding. You're having machines do the coding. What's being described and complained about here is people being bad at project management.

  • source
  • [–] [S] 6 points 1 week ago

    The big shift with agents is that it’s now technically feasible — and consequently tempting — to launch multiple workstreams. In fact, the entire agentic workflow actively encourages it. I mean, when launching an agentic task, I never know what the wait time will be. Are we talking 30 seconds, or do I have to watch the internal LLM ramblings for 25 minutes? That wait time is like an open invitation for self-interruptions, which are the most damaging types of context switches. AI coding just gives us so many passive pause points: waiting, reviewing, correcting, waiting again, ad infinitum.

    To avoid getting bored, it’s tempting to embark on a second and third task in parallel just to stay busy. This is often a mistake: agents scale; human attention doesn’t.

    I can very much relate to this, particularly with my neurodiverse brain that wants to remain stimulated. I've fallen into the trap of launching multiple agents, all working on different projects, and it never works out well as my attention gets fragmented, and I become overwhelmed.

  • source
  • [–] 1 point 1 week ago

    Yeah, I've been using Qwen 3.8 lately, the infamous overthinker, and ooh boy watching it think made me realize my context is full of contradictions. Using Hermes, and by default it came chock full of skills that are very uh... not my ethos.

    For example, I impressed upon it immediately to never commit to git, but I've seen Qwen confuse itself repeatedly because half the default skills: review, plan, execute a plan, etc all include instructions to commit often, with lots of little commits after every step. Makes sense if you're all-in on AI and don't even read your commits anymore, but I very much do, and need to present the final product to my coworkers with confidence. And I've also seen my own skills include contradictions, the AI getting confused and hardcoding its misunderstandings into self-written skills for it to reference.

    So I can definitely agree, if you're using a tool like Hermes, and not watching the thought traces with a self-doubting AI like Qwen, your context is probably full of contradictions too.

  • source
  • parent
  • context
  • [–] [S] 3 points 1 week ago (1 child)

    Giving clear instructions about what to do and what not to do, and ensuring those instructions are consistent and not noisy, will forever be a challenge with AI, no matter how good it gets.

    We have coworkers, partners, and other people we know and interact with who are sentient. They pass the Turing test, they are “AGI,” and yet: we still have a hard time conveying instructions, ideas, and concepts among each other.

    I've been thinking about this lately, and I can very much relate to this statement. Regardless of whether you're working with an agent or a living and breathing colleague, if you don't give them clear requirements and historical context, there is a very good chance they will go off-piste.

  • source
  • [–] 2 points 2 weeks ago

    Across those runs, regression-hunt produced 25% fewer false-positive findings than the baseline, with a 95% confidence interval of 14% to 38%.

    What were the baseline numbers of false positives? No mention? Silly me, expecting some rigor in numbers that make AI look good

    I checked the Scapy repo linked, no mention of how many false positives there were before and after. The only concrete numbers are

    Eleven search runs across 670 agent sessions reported 471 crashes and bugs, which deduplicated to 265 distinct bugs. Of those, 129 went to the maintainers (92 private reports, 37 pull requests); as of Sep 14, 2026, 80 patches had been merged (85% of patches) and 89% of reported issues were resolved.

    So, of the 265 bugs, 236 were fixed. Those are the only concrete numbers we got.

  • source
  • [–] 7 points 2 weeks ago

    Ah, my favorite kind of metric: unreliable correlation.

    Let's see, how many new users has Steam got this year, compared to 2025? No idea? Oh well, then that "new games with 100+ reviews" already looks off. Say, doesn't steam treat early access games that get fully released as "new" in the same year? Welp, that's another thing that's not accounted for, but hey, AI is totally helping, trust me bro!

    Let's see, what about the Flathub packages? Oh, just a "1k+ downloads in the last 90 days"? I'll go out a limb and assume it's "packages first published in the last 90 days that got over 1k downloads since". What was linux' userbase growth again? Irrelevant? Oh. Can you at least give a rundown of categories of said apps? No? Uh... What about at least checking if the repo of said app says if it had any AI use? Not even that, eh?

  • source
  • [–] 2 points 3 weeks ago

    Median weekly TrueThroughput, our complexity-weighted PR throughput metric, is still climbing, up 75.5% over the last four quarters.

    I'm always suspicious of metrics like these. It feels like it is counting lines of code but made more complicated to disguise the fact that it's counting lines of code.

  • source
  • [–] 8 points 3 weeks ago

    In the workplaces where I've been pressured to use LLMs for coding, this would not faze them. Management would just say “See, waiting for reviews is taking longer, we can't afford it any more. No reviews, just productivity.”

    Plummeting quality of the result is no barrier to a boss that just wants higher numbers to please their boss.

  • source
  • [–] 5 points 3 weeks ago

    Interesting, I've felt the opposite, that the model is largely moot, so long as your harness feeds it the right context and gives it the right tool calls. Although I do agree with the points they make here. OpenCode has an absurd number of features that I will never use, but actual isolation is left as an exercise for the reader.

  • source
  • [–] 6 points 3 weeks ago

    Reading this article I see that the problem is located roughly two feet in front of the monitor.

    Coding Agents are no humans, they don't think for themselves, they follow orders literally to the letter of the word.

    I ran into similar problems like the author but instead of writing a click baity article I developed a more reasonable scheme with the agent. No my agents split tasks into smaller chunks, delegate tasks and select the appropriate agent who knows about the capabilities of my available models.

    It still happens that the coding agent burns a couple of dollars worth of tokens but that usually happens, because I was not clear enough with my prompts.

    You have to treat the coding agent like a hyper intelligent 5 year old with no sense of sarcasm whatsoever.

    And yes, we're still not there where we wish to be but there is still a lot of development.

  • source
  • [–] 8 points 4 weeks ago (1 child)

    Study finds coding efficiency gains get “absorbed” by human review “bottleneck.”

    Reviews? I very much doubt anyone is reviewing anything.

    At best tests (also made by the machine) pass... but since no one is reviewing the tests either, who knows if they're actually testing what they're supposed to test.

    Easier to vibe code a new update whenever the latest one breaks anything important. Who cares if every windows update causes widespread errors and millions in losses? Certainly not microsoft.

  • source
  • [–] 1 point 4 weeks ago

    I know "AI bad" but some of these things would help people to avoid overusing AI, like telling AI to automate repeated tasks using deterministic methods rather than asking the AI to do the same thing every day or something.

    Other points like dictating your task list for the day because you're "too tired to type" seem ridiculous to me though. Typing really isn't that hard. If the barrier is speed or allowing yourself to not apply structure to your thoughts that's completely separate from AI.

  • source
  • [–] 4 points 4 weeks ago*

    Note that the system prompts and tooling can make a significant difference. I recall the old haiku specifically having like a 30-40k token floor by default.

    If you don't mind risking some behavioral changes and you know what to ask for, you can extract the existing prompts and carefully boil them down to the important bits you care about. Debloating skills, tools, and MCP also helps.

  • source
  • [–] 2 points 1 month ago* (last edited 1 month ago)

    Will posting about AI cost us clients?

    Maybe.

    The respect of our peers?

    Absolutely.

    For better or worse, there's more idiots thoughtlessly adopting AI today, than engineers carefully working with it.

    Also, it's not a coincidence that the very best of the best have less use for AI.

    AI provides access to faster-but-worse solutions for folks who lacked access before.

    That former lack of access can be for many different reaaons, but inexperience is perceived as the most common.

    So, whether fair or not, talking about use of AI signals:

    1. Willingness to try new things.
    2. Disregard to the harm done to the original creators whose work is being ripped off.
    3. Disregard for the harm being done to the planet.

    and

    1. Inexperience with computers.

    Edit: My source is that I, myself, work with AI and frequently must talk about it professionally - often in nuanced ways to un-receptive audiences.

    So I try to stay aware of how it is impacting my professional image. The above is from my experiences.

  • source
  • [–] 4 points 1 month ago

    That's OK, wisdom isn't one of our metrics. All we track is how many artists' creativity we scrape, and how many rubes we can sucker into paying us a monthly subscription for our plagiarism machine.

  • source
  • [–] 2 points 1 month ago* (last edited 1 month ago)

    I'm using offline LLMs just for fun, I don't care too much that they take a few minutes to spit out code for me. It helps me be deliberate and ensure I review and check what it synthesizes.

  • source
  • [–] 1 point 1 month ago

    First, tools that are good for AI agents are also good for humans.

    AI tools are as good as the AI themselves, which is not much

    As an example, let’s imagine that humanoid robots have become ubiquitous. What kind of tools would you build for them?

    If we're building a robot and thinking about efficiency, we wouldn't make them humanoid, even if we want it to do a wide range of tasks, because the human form is full of limitations - just try scratching your back or looking behind you.

    if you’re building a robot, you should make them humanoid so they can do a wide range of human tasks1, and that means they’ll be best suited to use human tools. The same principle applies to AI agents.

    Meanwhile, if you want a robot to do something as efficiently as possible, you make it the specialized tool. Say you make an android and make it use a loom. Wow, it can move its arms like a human! Now, if only there was some way of making that sort of work faster and more efficient!! Oh, look, specialized automation.

    Second, being in the training data is a huge advantage for existing tools. Suppose your new tool for AI agents is 20% better for them than the equivalent piece of software for humans.

    Now that sounds like corporate bullshit. Our software is 20% better... By which metric? 20% less code? 20% more performant? 20% less resource intensive? 20% more features? Let's assume it's simply "20% better"

    If the benefit of the agent already knowing the human software is greater than 20%, they shouldn’t use your new tool

    This makes no sense for 2 reasons, the first being that the software being "greater" or "better" does not automatically mean it's more efficient, the second being that the existence of "better" software doesn't mean you should ditch "worse" software for it.

    This is why I’m always suspicious of plans to develop a new programming language for AI agents.

    That would be a stupid idea mainly because humans use programming languages because it is much easier to grasp than looking at a given CPU's Assembly instructions. The "ideal" ai agent would be programming in pure assembly, avoiding compilers or scripted languages, but since there's almost no training data for that, we don't see any agent doing that and likely won't for a good while. That's the "20% better" software/tool that neither humans nor AI are using

  • source
  • [–] 3 points 1 month ago

    With AI, externalization is hitting my time and attention. Polished-looking text or code became cheap to produce, but reading it and providing feedback did not. I can no longer rely on the heuristic that producing text took effort as a sign that somebody is trying to communicate something of value.

    Given that what’s exploited is mostly attention and mental labor, traditional economic solutions to externalities like privatization and structures for maintaining commons are unlikely to help, and anonymity in peer review and open source also eliminates any control through reputation or shame (though I hope somebody will figure this out eventually). What’s left is disengagement, defensive AI use, and approaches that introduce cost and friction, such as capping feedback and revision opportunities, imposing costs per submission, or requiring deposits. All of these hit everybody, not just bad actors or well-intentioned actors who use AI without knowing better.

    Really thoughtful blog post. It's funny how communication heuristics like that are taken for granted and basically invisible until we have to contend with not having them anymore. How can we get signal through the noise efficiently when it's only going to get harder to distinguish?

  • source
  • [–] 7 points 1 month ago

    It's funny how AI made computers, marvelous machines that are supposed to do exactly what it is asked for with precision and precisely replicable results, and made them boxes that, for any given command, can spurt out different results with an unknown margin of error.

  • source
  • view more: next ›