samstokes

I love the idea of helping people learn good debugging habits and understand their code. But this seems like it is still just giving the answers, and would still create the same dependence on AI to do your thinking:

  You: I'm not sure, it seems random

  Nietzschian: "Random" is the word we use when we haven't looked
  hard enough. What do the server logs say for the 403
  responses? Go look. I'll wait.

That move from "I don't know" to "where could I look to find out" is one of the key habits that makes someone good at debugging, and here "Nietzsche" is just doing it for you.

It might seem obvious to look at the logs, but in my experience 90% of being stuck debugging something is just not yet having looked at all the available evidence.

It's true you could learn these habits by exposure to them, and this could be a neat alternative to pairing with a more senior engineer for that. But it looks like you could easily just keep saying "it's random", "I don't know", and the model would keep telling you what to do next, without you actually having to think.

I wonder if making it even more Socratic would fix this? E.g. "how do you know it's returning 403s? Oh, logs you say? Is there anything else they could tell you?"

... in 2023. (Thanks to whoever updated the submission title to include a year tag since I wrote this comment.)

This is a little misleading as written (with a 2026 timestamp but citing only 2023 data) given there is a wealth tax on the California ballot and wealth migration is cited as a reason to oppose it. This article looks like it supports that argument, but it doesn't.

  The best lack all conviction, while the worst
  Are full of passionate intensity.

- W.B. Yeats

Is that "difficult" quote from a separate source? I can't find it in the text of the linked report.

Also, the report says that both red and blue states had both overcounts and undercounts, which is a different picture than "over counts in blue states". It is accurate that more blue states had overcounts and more red states had undercounts.

I realise your question is rhetorical, but the report does offer a possible answer: "The 2020 Census faced many challenges such as conducting fieldwork during the COVID-19 pandemic. Other challenges to the 2020 Census included con- troversy around a proposed citizenship question and changes in the duration of the Nonresponse Followup operation." It's plausible that those "challenges" could have been experienced unevenly by state, particularly with how politicised the pandemic and its mitigations were in the US.

You might enjoy Spirit Island, a cooperative game designed explicitly to make that "quarterbacking" strategy infeasible and encourage more interesting player interaction. Players have asymmetrical abilities and power progression, so it's hard to micromanage everyone, and everyone has enough choices to make that even the "I think we can win this turn if..." conversation generally depends on each person making their own reasonable choices rather than one person planning out the whole turn.

Code being expensive would be one reason to plan, but hardly the only one. Some other reasons: cost of failure (don't leak customer PII), maintenance, unclear requirements, unclear success criteria.

Most of the comments so far are responding to the first few paragraphs of this article. On reading further, I thought this was actually an unusually balanced take on how to use LLMs in a software org.

I can't help but cringe at the "cost of code is now zero" meme that this article repeats because in my experience the biggest cost of code was always the activities around the code - planning, communicating, reviewing, validating. This author, despite repeating the meme, seems to agree. Their emphasis on writing PR descriptions and specs for humans rhymes with my experience and it sounds like a nicer way to work than chasing some dark factory fever dream.

I also thought the "Two Modes of Working" section was useful. People get wildly different results from coding agents depending on how they use them, but I've not seen a lot of actual guidance on when to do X vs Y.

Personally, I've been using what the author calls "sidekick mode" since last October - before the supposed "AI got good now" threshold - and agree it's a more useful default for an engineer than "delegate mode".

I don't have an MBA or anything but is it common practice to describe "revenue - capex" as "profit"?

The post says they wrote a custom harness that orchestrates work between multiple separate model invocations. That is different from running Claude Code (which is a specific existing harness around the Claude models).

The post takes a while to get around to saying that, and could have included more detail besides the workflow diagram and table (which they flag as only "an example of" such a harness), but it does answer the question. It's a different kind of tool because it's a model rather than a harness+model pair.

I wouldn't agree that LLMs are a higher level of abstraction, but I've found they do help me think at a higher level of abstraction, by temporarily outsourcing cognitive load.

With changes like substantial refactors or ambitious feature additions, it's easy to exceed the infamous "seven things I can remember at once":

  * the idea for the big change itself
  * my reason for making the change
  * the relevant components and how they currently work
  * the new way they'll fit together after the change
  * the messy intermediate state when I'm half finished but still need a working system to get feedback
  * edge cases I'm ignoring for now but will have to tackle eventually
  * actual code changes
  * how I'm going to test this

Good lab notes, specs etc can help, but it's a lot to keep in mind. In practice these often turn into multi person projects, and communication is hard so that often means delay or drift. Having an agent temporarily worry about

  * wiring a new parameter through several layers
  * writing a test harness for an untested component
  * experimentally adding multibyte character support on a branch

frees up my mental bandwidth for the harder parts of the problem.

The main benefit is to defer the concern until I have a mostly working system. Then I come back and review its output, since I'm still responsible for what it delivers, and I want better than "mostly working".