You must learn to write good reviews. That doesn't happen without writing quite a few.

Of course grad students should generate the first draft of talks, collect data, and generate graphics. That's exactly the point of grad school. You need to learn how to organize and present knowledge. How to tell a story.

>My friend said that nothing in the first five years of his PhD work contributed to his dissertation.

The point of the PhD is to learn to think about hard problems that are vague, to find your way around them, and learn how to do something new. It's not to stuff as much as possible into a dissertation or anything else.

And 6 years for a PhD? That's about right. You need to go from 0 to being the go-to expert everywhere on a totally new problem.

I am A YIMBY too. But no, big money is not on your side. Big money wants to make money, not make your life better. It would like to build as much as possible for as little as possible, at the lowest quality possible, and sell it for an extremely high price. This isn't good for any of us.

> 1. Non-interactive by default > Commands have to run without interactive prompts when an agent invokes them. When a subagent spawns a background process, there's nothing answering the prompt. The command hangs.

If a command has stdout/stdin attached, you can be interactive mode. If it doesn't you can be in non-interactive mode. This isn't even wrong, it's just nonsense.

> 2. Structured, parseable output > A nicely aligned table with ANSI colors is for humans. An agent extracting a post ID needs JSON.

It's a natural language agent. It obviously doesn't need JSON. And JSON is extremely wasteful in terms of tokens.

> 3. Errors that teach, and enumerate > The original principle was "fail fast with actionable errors." That still holds, with one refinement I missed the first time. When the failure is "you passed an invalid value for X," the error should include the valid set.

Except that the valid set can be huge. You're much better off describing what's valid. It's a natural language agent. Talk to it!

> 4. Safe retries and explicit mutation boundaries > Agents retry. Humans glance at a duplicate row and notice; agents don't.

What does this have to do with agents? Yeah, if possible make your operations idempotent. If not, well, .. then don't? Humans will make exactly the same mistakes as agents here.

> 5. Bounded responses, at every layer > Tokens cost money and context. Big outputs are sometimes justified, but the default should be narrow.

How do you know what your agent needs? Let the agent bound and select. Agents are perfectly capable of sending your output through grep or through head/tail.

> 6. Cross-CLI vocabulary consistency > This is the principle I'm most certain about, and the one most under-stated in the original. > Agents don't memorize one CLI at a time. They build a generalized model of what CLIs do, drawn from every CLI they've seen. When your tool uses info for what every other tool calls get, the agent doesn't fail; it succeeds slowly, with extra retries, after burning tokens on --help. Multiply that across thousands of agent invocations per week and the cost is real.

Agents need to deal with hundreds of CLIs that are all inconsistent. What matters is that you describe to the agent how each CLI works. It doesn't matter if they're consistent.

> 7. Three-layer introspection > The original principle here was "progressive help discovery": top-level --help lists commands, subcommand --help shows usage. That's still true, but it's now the bottom layer of a three-layer stack. Each layer answers a different question.

Truly the worst advice. Take a simple clean output that's easy to understand in one go and turn it into a crazy complex json that requires multiple inferences to understand. Not only are you wasting compute, you're wasting your time waiting for that compute.

> 8. Async-aware execution > Most CLIs treat async APIs the way the underlying HTTP endpoint does: submit returns a job ID, poll returns a status, that's the agent's problem. Two failure modes follow. Either the agent writes its own poll loop (wasting tokens and getting it subtly wrong), or it doesn't, and the workflow fails because the result wasn't ready when the next step ran.

No, it got worse. Horrific advice. Take a simple API that an agent can easily wait for in the background and turn it into a stateful monster that can clog everything up with junk. Oh and now when you have multiple agents they get to have a fun conflict.

> 9. Persistent identity through profiles > Agents don't show up once. They show up tomorrow, and the day after, and a week from now, in a different shell, with the same underlying intent and a different specific input. Stateless leaf-shaped CLIs make every invocation re-specify the same eight flags.

Ok, I was wrong. 8 was bad. 9 is much much worse. It's a guarantee that your agents will get things wrong. Why? Because agents forget all the time!

> 10. Two-way I/O > The original principle 6 (composable and predictable structure) covered stdin/stdout pipelining. That's still true. But agents don't only consume CLIs through pipes, and the CLI doesn't only emit through stdout. There are two new mechanisms worth adding: a way for the CLI to emit artifacts where the agent actually needs them, and a way for the agent to report friction back.

This literally exists in a form that every single agent knows: bash pipes and redirects. They've been trained on billions of examples of this. Now instead of just using that, you're adding a custom version that will just confuse the agent.

I'm not sure I could have written a worse list if I tried.

Almost everything we have in modern medicine is.

This whole position is nonsense. The paper stands on its own.

This just isn't true.

In any dynamic language you would not get these guarantees at compile time. You'd get random failures at runtime. That's not safety of any kind.

Also, part of the goal of languages like Haskell is that they help you think about your code before it runs. All of that is lost.

> Imagine you have to distinguish between unescaped and escaped strings for security purposes

That would be a nightmare in many languages. You'd have to rewrite large parts of the code to be compatible with one or both. And in many languages you'd have to duplicate your code entirely.

In other languages, the result would so ugly, you would never want to touch that code. Imagine doing this with say, templates in C++.

>There's a performance cost to this

There is no performance cost in Haskell! This is entirely undone by the compiler.

Also, because the compiler understands what's going on at a much higher level, you can do things like deriving code. You can say that your classified strings behave like your regular strings in most contexts, like say, they're the same for the purpose of printing but not for the purpose of equality, in one line.

There are plenty of open models you can download today and run. No gatekeeping. No fencing.

This whole "AI is evil" trope is getting a bit tired.

This model is contaminated in subtle ways that make me skeptical of the results.

Can we stop repeating this nonsense headline please? We did not stop manufacturing things.

Manufacturing is a huge industry in the West. https://en.wikipedia.org/wiki/Manufacturing_in_the_United_St...

The US manufacturing sector is the biggest it has ever been. Exports are at all time record highs. The only thing that declined about manufacturing is the jobs. We build way more than we ever did but with far fewer people.

What we did do is decide that basic items aren't worth it. Our capacity is limited, our labor pool is limited, expenses are high, it doesn't make sense to make trinkets when we can make complex high precision parts and devices.

But no, we did not forget how to make things. We chose to use our capacity in a smarter way.

First they can shoot down your drone. Second they can ban you from ever flying one again. All without any criminal prosection.

To prosecute you, it is not willfully and knowingly. It is willfully or knowingly.

If you expect there to be ice and put your drone in a spot where it will film them, well you didn't know. But it was willful.

So this isn't narrow, it's extremely broad. You can't read such rules in a vacuum without knowing their context.

Reports are heavily redacted. They aren't shared. Failures aren't acknowledged. Engineering models aren't released. That secrecy eventually causes what we see today.

In C++ you don't get lockfiles, you don't get automatic dependency install, you don't get local dependencies, there's no package registry, no version support, no dependency-wide feature flags (this is an incoherent mess in Meson), no notion of workspaces, etc.

Compared to Cargo, Meson isn't even in the same galaxy. And even compared to CMake, Meson is yet another incompatible incremental "improvement" that offers basically nothing other than cute syntax (which in an era when AI writes all of your build system anyway, doesn't even matter). I'd much rather just pick CMake and move on.

Cancer research, and all research in general, is massively underfunded. The US spends $7 billion dollars per year on the National Cancer Institute. The EU spends about as much as well. That's $14 billion per year for all cancer, never mind bone cancer. This just isn't a lot of money. That's like 6 days of running the US DoD. For cancer.

The entire yearly budget for the National Cancer Institute is $7 billion dollars. To put this in perspective, that's 3 days of funding the DoD. For cancer. That kills well over half a million Americans per year.

The takeaway is that we should invest in research rather than letting people die.

What's going to happen immediately is that kids with equivalent phones will compare, realize that one has a lot of restrictions and the other doesn't, and it becomes a nightmare. They know that all you need to do is unlock it for them.

It's the same mental distinction between "For $200 we'll install rear seat warmers in your Tesla" and "For $200 we'll 'unlock' the already-present rear seat warmers" (that's the only hardware unlock I've ever paid for and I'm still bitter 7 years later).

This just isn't true. arXiv is not a venue. There's no place that gives you credit for arXiv papers. No one cares if you cite an arXiv paper or some random website. The vast vast majority of papers that have any kind of attention or citations are published in another venue.

The airlines have no problem with this. T-mobile has no problem with it either.

The issue isn't just Musk's politics. It's that his actions have been evil, the kind of negative impact that major wars have.

We're talking something like 1 million dead people per year with a quarter of those being children. For a level of assistance that cost the US nothing (0.43% of federal spending). This is an evil that in a few years puts you on the list of biggest mass murderers in history.