samstokes · HackerTrans

letzten Monatdiscuss

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.

samstokes

letzten Monatdiscuss

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".

samstokes

vor 2 Monatendiscuss

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

samstokes

vor 2 Monatendiscuss

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.

samstokes

vor 2 Monatendiscuss

[dead]

samstokes

vor 2 Monatendiscuss

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".

samstokes

vor 5 Monatendiscuss

Does it? Claude the chatbot is available for free, and it can write code, but Claude Code is a separate product that as far as I know is only available on paid plans. Source: https://claude.com/product/claude-code

samstokes

vor 5 Monatendiscuss

Bit of a buried lede:

> For a limited time we're including Codex with ChatGPT Free

Is this the first free frontier coding agent? (I know there have been OSS coding agents for years, but not Codex/Claude Code.)

samstokes

vor 6 Monatendiscuss

https://five-eights.com

samstokes

vor 10 Monatendiscuss

This seems lazy. It's ad hominem but not even, since you don't know what inept bureaucracy I am defending. Is there any argument that you couldn't level this accusation at?

samstokes

vor 10 Monatendiscuss

One could interpret the title that way, but not consistently with the rest of the article, which includes assertions like "in the realm of societies, governments and economies, systems thinking becomes a liability".

I think there's plenty to agree with in the article's descriptions of failure and hubris. What the critical commenters are taking issue with is that the article blames those symptoms on a straw man. It's a persuasive article, not a historical review, so it's reasonable to debate its conclusion and reasoning as well as its supporting evidence.

samstokes

vor 10 Monatendiscuss

The title of the article is an intentional conflation of "systems thinking" with "magical thinking", which is not a compliment.

samstokes

vor 10 Monatendiscuss

What an interesting and strange article. The author barely offers a definition of "systems thinking", only names one person to represent it, and then claims to refute the whole discipline based on a single incorrect prediction and the fact that government is bad at software projects. It's not clear what positive suggestions this article offers except to always disregard regulation and build your own thing from scratch, which is ... certainly consistent with the Works In Progress imprint.

The way I learned "systems thinking" explicitly includes the perspectives this article offers to refute it - a system model is useful but only a model, it is better used to understand an existing system than to design a new one, assume the system will react to resist intervention. I've found this definition of systems thinking extremely useful as a way to look reductively at a complex system - e.g. we keep investing in quality but having more outages anyway, maybe something is optimizing for the wrong goal - and intervene to shift behaviour without tearing down the whole thing, something this article dismisses as impossible.

The author and I would agree on Gall's Law. But the author's conclusion to "start with a simple system that works" commits the same hubris that the article, and Gall, warn against - how do you know the "simple" system you design will work, or will be simple? You can't know either of those things just by being clever. You have to see the system working in reality, and you have to see if the simplicity you imagined actually corresponds to how it works in reality. Gall's Law isn't saying "if you start simple it will work", it's saying "if it doesn't work then adding complexity won't fix it".

This article reads a bit like the author has encountered resistance from people in the past from people who cited "systems thinking" as the reason for their resistance, and so the author wants to discredit that term. Maybe the term means different things to different people, or it's been used in bad faith. But what the article attacks isn't systems thinking as I know it, more like high modernism. The author and systems thinking might get along quite well if they ever actually met.