cstrahan

Probably not, given that "terrific" was almost certainly used sarcastically here.

“that code” refers to the body of the loop.

Unless the loop is unrolled, yes, there is a branch to exit the loop. But then that doesn’t matter because the whole goal at the beginning was to avoid branch misprediction (which is not the same thing as avoiding branches entirely).

IIUC

1) It isn’t a matter of literally “pasting into a terminal” (with the terminal emulator shoveling bytes into the TUI’s stdin), rather it’s “a TUI key-binding tells TUI app to read system clipboard”. No different than any other app.

2) This works on macOS, Linux and Windows, but not WSL. Sounds fair game to call this a bug, or at the very least a feature disparity.

I've had an upper endoscopy and a colonoscopy, both the same day, and both without anesthesia. If they didn't take a biopsy, it likely shouldn't have been too traumatic, consciously or subconsciously - maybe that's a bit comforting to know.

I agree on the commit messages not being ideal, though a bit of by-hand rewording goes a long way.

Recently let Claude Code handle some commit history clean up: split a couple commits, reordered some, and identified some that could/should have been fixups, and reduced the number of commits from ~70 down to ~40. Very happy with the results and time savings.

FWIW, here’s my interactive rebase skill: https://github.com/cstrahan/claude-plugins/blob/main/skills/...

Do you believe what teachers told you in school? Yes?

Nope. At least, not without proof. That would, IMO, be kinda crazy. We could argue semantics - maybe “stupid” would be a better word? Lacking in critical thinking skills? Whatever “it” is, it isn’t good.

That seems like an odd way to interpret what they wrote.

Imagine old school machinists saying to a CNC machinist “Ha! See, maybe you don’t jog the axes manually, but you still have to be involved in placing the stock material, and you have to do the CAD/CAM work - so did it really machine the part for you? No!”

AI is a tool like any other. It has its limitations. It has classes of problems that it is suited to handle, and others it isn’t. If it’s true that they haven’t written (as in “typed out by hand”) a single line of code, why can’t they say that without you making that statement into more than it is?

I haven’t written a single line of code in 6 months, and that’s simply fact. It is also true that I put in a lot of other work to make that feasible, but that work isn’t in the form of writing code.

“it’s mature and the next step of engineering”

Tautologically, it’s mature enough for what it is mature enough for, and it certainly is the next step in the same way that CNC was the next step for machining — if you’re not using it as a machinist, you’re going to produce less compared to those who are.

Same thing with garden hoses. Yes, you can go fetch water from a lake and splash it on your lawn, or, you know, you could just use a sprinkler connected to your garden hose. Doesn’t replace buckets. Buckets just have a narrower scope in a world where garden hoses exist.

People vary in their ability to differentiate colors and sounds.

I’d be curious how you’d do on a hue test: https://www.xrite.com/hue-test

For me, each colored square is plainly, obviously different, and it is immediately obvious how they need to be sorted. But I also know people I’ve shown the test to who thought it was a trick - “there’s only 3 or 4 distinct colors, so how am I supposed to sort the same-colored squares?”

If one’s perception is particularly lossy, it makes sense that lower fidelity displays and audio will likely be indistinguishable from higher fidelity ones.

Slack requires shift+enter to create a new-line, while in JIRA shift+enter creates a new-line instead of new paragraph, creates all sorts of confusing layout issues, and because the difference is invisible, it's hard to to figure out where/when you've made this mistake of using shift+enter instead of just enter.

Nearly drove me insane, until I developed separate muscle memory between the two apps/sites.

Nah, I think it’s pretty clear. It would look like a terminal emulator. Just like how Electron looks like a bunch of browser widgets - because it’s literally a single-web-app browser.

I had a colonoscopy and esophagogastroduodenoscopy (thankfully not in that order) without sedation. Had it done in D.C.

My doc looked at me like I was crazy when I asked if it could be done without sedation, and reminded me that it would be uncomfortable, but otherwise didn't have any problem with it. I've endured 50k runs, brutal workouts, and traumatizing childhood neglect - I really can't see what the fuss is with mild discomfort that, by comparison, barely registers, and for such a short amount of time at that.

Not at all. Some things are fundamentally unsafe. mmap is inherently unsafe, but that doesn’t mean a library for it shouldn’t exist.

If you’re thinking of higher level libraries, involving http, html, more typical file operations, etc, what you’re saying may generally be true. But if you’re dealing with Direct Memory Access, MCU peripherals, device drivers, etc, some or all of those libraries have two options: accept unsafe in the public interface, or simply don’t exist.

(I guess there’s a third option: lie about the unsafety and mark things as safe when they fundamentally, inherently are not and cannot be safe)

I think they are likely referring to doubly linked lists in Rust, specifically.

See, for example:

https://rust-unofficial.github.io/too-many-lists/

https://news.ycombinator.com/item?id=22390662

https://bablr.org/

The next-gen LR parser framework for creating elegant and efficient language tools

BABLR is a new kind of thing that does not quite fit into any category of things that has existed before it. In purpose it is made to be an instrument of code literacy -- a unified toolchain for software developers that supports a new generation of richly visual interfaces for coding. In form BABLR is a collection of scripts and virtual machines written in plain Javascript that run in almost any modern web browser. BABLR is also a community and an ecosystem, including a small but rapidly growing collection of ready-to-use parsers for popular languages.

Any self respecting engineer should recognize that these tools and models only serve to lower the value of your labor.

Depends on what the aim of your labor is. Is it typing on a keyboard, memorizing (or looking up) whether that function was verb_noun() or noun_verb(), etc? Then, yeah, these tools will lower your value. If your aim is to get things done, and generate value, then no, I don't think these tools will lower your value.

This isn't all that different from CNC machining. A CNC machinist can generate a whole lot more value than someone manually jogging X/Y/Z axes on an old manual mill. If you absolutely love spinning handwheels, then it sucks to be you. CNC definitely didn't lower the value of my brother's labor -- there's no way he'd be able to manually machine enough of his product (https://www.trtvault.com/) to support himself and his family.

Using these things will fry your brain's ability to think through hard solutions.

CNC hasn't made machinists forget about basic principles, like when to use conventional vs climb milling, speeds and feeds, or whatever. Same thing with AI. Same thing with induction cooktops. Same thing with any tool. Lazy, incompetent people will do lazy, incompetent things with whatever they are given. Yes, an idiot with a power tool is dangerous, as that tool magnifies and accelerates the messes they were already destined to make. But that doesn't make power tools intrinsically bad.

Do you want your competency to be correlated 1:1 to the quality and quantity of tokens you can afford (or be loaned!!)?

We are already dependent on electricity. If the power goes out, we work around that as best as we can. If you can't run your power tool, but you absolutely need to make progress on whatever it is you're working on, then you pick up a hand tool. If you're using AI and it stops working for whatever reason, you simply continue without it.

I really dislike this anti-AI rhetoric. Not because I want to advocate for AI, but because it distracts from the real issue: if your work is crap, that's on you. Blaming a category of tool as inherently bad (with guaranteed bad results) suggests that there are tools that are inherently good (with guaranteed good results). No. That's absolutely incorrect. It is people who fall on the spectrum of mediocrity-to-greatness, and the tools merely help or hinder them. If someone uses AI and generates a bunch of slop, the focus should be on that person's ineptitude and/or poor judgement.

We'd all be a lot better off if we held each other to higher standards, rather than complaining about tools as a way to signal superiority.

Vertical CNC mills and CNC lathes are, obviously, different machines with different use cases. But if you compare within the categories, the designs are almost all conceptually the same.

So, what about outside of some set of categories? Well, generally, no such thing exists: new ideas are extremely rare.

Anyone who truly enjoys entering code character for character, refusing to use refactoring tools (e.g. rename symbol), and/or not using AI assistance should feel free to do so.

I, on the other hand, want to concern myself with the end product, which is a matter of knowing what to build and how to build it. There’s nothing about AI assistance that entails that one isn’t in the driver’s seat wrt algorithm design/choices, database schema design, using SIMD where possible, understanding and implementing protocols (whether HTTP or CMSIS-DAP for debugging microcontrollers over USB JTAG probe), etc, etc.

AI helps me write exactly what I would write without it, but in a fraction of the time. Of course, when the rare novel thing comes up, I either need to coach the LLM, or step in and write that part myself.

But, as a Staff Engineer, this is no different than what I already do with my human peers: I describe what needs doing and how it should be done, delegate that work to N other less senior people, provide coaching when something doesn’t meet my expectations, and I personally solve the problems that no one else has a chance of beginning to solve if they spent the next year or two solely focused on it.

Could I solve any one of those individual, delegated tasks faster if I did it myself? Absolutely. But could I achieve the same progress, in aggregate, as a legion of less experienced developers working in parallel? No.

LLM usage is like having an army of Juniors. If the result is crap, that’s on the user for their poor management and/or lack of good judgement in assessing the results, much like how it is my failing if a project I lead as a Staff Engineer is a flop.

Or you already know all of the details, and you don’t want typing to be the bottleneck to getting things done.

https://vimhelp.org/motion.txt.html#%7B

    { [count] paragraphs backward.  exclusive motion.
    } [count] paragraphs forward.  exclusive motion.

Do you take issue with companies stating that they (the company) built something, instead of stating that their employees built something? Should the architects and senior developers disclaim any credit, because the majority of tickets were completed by junior and mid-level developers?

Do you take issue with a CNC machinist stating that they made something, rather than stating that they did the CAD and CAM work but that it was the CNC machine that made the part?

Non-zero delegation doesn’t mean that the person(s) doing the delegating have put zero effort into making something, so I don’t think that delegation makes it dishonest to say that you made something. But perhaps you disagree. Or, maybe you think the use of AI means that the person using AI isn’t putting any constructive effort into what was made — but then I’d say that you’re likely way overestimating the ability of LLMs.

Let me rephrase GP into (I hope) a more useful analogy. — actually, here’s the whole analogous exchange:

“A rectangle is an equal-sided rectangle (i.e. “square”) though. That’s what the R stands for.”

“No? Why would you think a rectangle is a square?”

Just as not all rectangles are squares (squares are a specific subset of rectangles), not all datagram protocols are UDP (UDP is just one particular datagram protocol).

You read it that way because that’s the sensible way to read it. Everyone suggesting you missed the plot is in turn making a rather large logical leap.

These issues would still exist.

I just explained why these issues don't apply to the LLM writing and invoking code: again, this is because code can apply successive transformations to the input without having to feed the intermediate results into the LLM's context. That code can read a file that would weigh in at 50,000 tokens, chain 100 functions together, producing a line that would be 20 tokens, and only the LLM will only see the final 20 token result. That really is only 20 tokens for the entire result -- the LLM never sees the 50,000 tokens from the file that was read via the program, nor does the LLM see the 10s of thousands of tokens worth of intermediate results between the successive transformations from each of the 100 functions.

With MCP, there's no way for the LLM to invoke one tool call that expresses "compose/pipeline these 100 tools, please, and just give me the final result" -- the LLM must make 100 individual tool calls, manually threading the results through each tool call, which represents 100 opportunities for the LLM to make a mistake.

It sounds like you are disagreeing with what I am saying, but it doesn't look you're giving any reason why you disagree, so I'm a bit confused.

Okay....now what function calls or libraries should the API use to write that code?

Whatever the most popular library is which provides a client to whatever "thing" (locally running process, or service, or whatever) you are trying to interact with via LLM.

I have had LLMs generate probably 10s of thousands of lines of code, all without providing an MCP. LLMs can do that. They are trained on code.

What if there isn't a library available? Well, sure, then you could go implement an MCP server... or you could just write a library. It's practically the same effort.

Not that I'm 100% against MCP servers. But I think there's some misconception spreading across the software community that an MCP server is always inherently the optimal, obvious solution; all I'm suggesting is that people actually think about the problem, instead of outsourcing that responsibility via a "no one ever got fired for buying IBM" type of appeal to bandwagon fallacy.

What whoknowsidont is trying to say (IIUC): the models aren't trained on particular MCP use. Yes, the models "know" what MCP is. But the point is that they don't necessarily have MCP details baked in -- if they did, there would be no point in having MCP support serving prompts / tool descriptions.

Well, arguably descriptions could be beneficial for interfaces that let you interactively test MCP tools, but that's certainly not the main reason. The main reason is that the models need to be informed about what the MCP server provides, and how to use it (where "how to use it" in this context means "what is the schema and intent behind the specific inputs/outputs" -- tool calls are baked into the training, and the OpenAI docs give a good example: https://platform.openai.com/docs/guides/function-calling).

but those that I have used (GitHub, [...])

Most MCP severs don't sit in between the LLM and the API endpoints [...]

Your first example certainly isn't an example of that: https://github.com/github/github-mcp-server

I suppose someone could try to abuse MCP by stuffing information about REST API endpoints into a the prompt/descriptions in a small MCP "skeleton" service, but I don't know of any. Can you provide examples?

they just teach them how to use the tools and then the LLM calls the APIs directly as any HTTP client would.

I suspect you might have some deep misunderstandings about MCP.

I just skimmed the README.

I believe the point is to do something akin to "promise pipelining":

https://capnproto.org/rpc.html

http://erights.org/elib/distrib/pipeline.html

When an MCP tool is used, all of the output is piped straight into the LLM's context. If another MCP tool is needed to aggregate/filter/transform/etc the previous output, the LLM has to try ("try" is a keyword -- LLMs are by their nature nondeterministic) and reproduce the needed bits as inputs into the next tool use. This increases latency dramatically and is an inefficient use of tokens.

This "a1" project, if I'm reading it correctly, allows for pipelining multiple consecutive tool uses without the LLM/agent being in the loop, until the very end when the final results are handed off to the LLM.

An alternative approach inspired by the same problems identified in MCP: https://blog.cloudflare.com/code-mode/

I don't think there is any attempt at lock in here, it's simply that skills are superior to MCP.

See this previous discussion on "Show HN: Playwright Skill for Claude Code – Less context than playwright-MCP (github.com/lackeyjb)": https://news.ycombinator.com/item?id=45642911

MCP deficiencies are well known:

https://www.anthropic.com/engineering/code-execution-with-mc...

https://blog.cloudflare.com/code-mode/

The LLM output differentiates between text output intended for the user to see, vs tool usage.

You might be thinking "but I've never seen any sort of metadata in textual output from LLMs, so how does the client/agent know?"

To which I will ask: when you loaded this page in your browser, did you see any HTML tags, CSS, etc? No. But that's only because your browser read the HTML rendered the page, hiding the markup from you.

Similarly, what the LLM generates looks quite different compared to what you'll see in typical, interactive usage.

See for example: https://platform.openai.com/docs/guides/function-calling

The LLM might generate something like this for text:

    {
      "content": [
        {
          "type": "text",
          "text": "Hello there!"
        }
      ],
      "role": "assistant",
      "stop_reason": "end_turn"
    }

    {
      "content": [
        {
          "type": "tool_use",
          "id": "toolu_abc123",
          "name": "get_current_weather",
          "input": {
            "location": "Boston, MA"
          }
        }
      ],
      "role": "assistant",
      "stop_reason": "tool_use"
    }

https://simonwillison.net/2025/Feb/28/llm-schemas/

https://platform.openai.com/docs/guides/structured-outputs

You're not wrong, but I figured I'd point out the cons / alternatives:

They can encapsulate (API) credentials, keeping those out of reach of the model

An alternative to MCP, which would still provide this: code (as suggested in https://www.anthropic.com/engineering/code-execution-with-mc... and https://blog.cloudflare.com/code-mode/).

Put the creds in a file, or secret manager of some sort, and let the LLM write code to read and use the creds. The downside is that you'd need to review the code to make sure that it isn't printing (or otherwise moving) the credentials, but then again you should probably be reviewing what the LLM is doing anyway.

* Contrary to APIs, they can change their interface whenever they want and with little consequences.

The upside is as stated, but the downside is that you're always polluting the context window with MCP tool descriptions.

You are correct.

I think many here have no idea what exactly MCP is, and think it's some sort of magic sauce that transcends how LLMs usually work.

    “But Brawndo has what plants crave! It's got electrolytes! '...Okay - what are electrolytes? Do you know? Yeah. It's what they use to make Brawndo.' But why do they use them in Brawndo? What do they do?''They're part of what plants crave.'But why do plants crave them?'Because plants crave Brawndo, and Brawndo has electrolytes.”
    ― Idiocracy Movie