This isn't the kind of thing you can hash out in public and go back and forth on. Once you put it out there, the other party will take steps to make sure they don't have to rely on us in the long run.

Although I'm sure there are some efficiency gains, the technology is too new and labs are scrambling to release too quickly to think that the low-hanging optimization fruit has been picked already.

Most new product launches are an exercise in figuring out what the product requirements should be through trial and error (really: through ongoing dialogue with your users). Even mature products can have requirements change over time as the market changes.

I think internalizing this reality is why most senior engineers who work in domains that touch the messy real world will reflexively push back against perfectionism.

So I don't "need" the SOTA models, but they do help considerably. And I am also working on some other projects that may have been outside the reach of the earlier models entirely.

This obviously doesn't work at all when the agents start doing real things in the real world, though. "Hey AI, I don't like my neighbor, find an exploit in the firmware for his car and make the cruise control malfunction and crash him next time he gets on the highway". This is committing a crime, not just talking about theoretical crimes. The AI can and should refuse it.

I think he's anticipating and discarding this objection with his introduction, which otherwise feels disconnected from the rest of the article. FWIW, I have changed a bike tire and I'm pretty sure most of the MTS at the big labs could. This sort of "they're just bookworms who don't understand the physical world" rhetoric aside, we are currently seeing a ton of effort and expense go towards giving the AI agents hooks into being able to perform as many real-world-consequential actions as possible. And you can do a surprising amount with just bits, from writing code to breaking into systems to sending some combination of emails, phone calls, and currency to instruct meatspace humans to do things, etc.

Export controls are governed by the Export Control Reform Act of 2018. The procedures the government must follow to enact a rule is defined by the Administrative Procedures Act. It's not a slam-dunk case, but I think there are significant questions around the arbitrary nature of the approved company list, the control restricting US-based permanent resident employees from accessing models, and how the rule was enacted in general which would make a viable case.

Suing the government saying that APA was not correctly followed or that the export control in question does not comply with the ECRA will absolutely not get you put in prison, that's not the kind of country we live in and honestly I have no clue what you're talking about.

Lots of these moves would and should be struck down in court as an arbitrary and capricious use of administrative power. Some of them might not be, and in the meantime you're signing up for tons of trouble. A trillion-dollar company does not simply go to war with the US government.

A more mid-sized company that's not so intertwined, but not so small that they can't get a good legal team, might be another story.

I remember someone who literally announced they were dropping the class to the whole room at the end of a lecture, saying "This isn't AI!!!"

But would another company who is not on the trusted partner list and has less to lose taking on the admin have standing to sue here? On the basis of the export control being illegal and this putting their business at a disadvantage vs. competitors with access

Other technologies like surveillance (and, perhaps, AI) are more clearly centralizing and enabling of power.

The difference matters a lot if you're having mixed feelings about working in technology.

A small app, or a task that touches one clear smaller subsection of a larger codebase, or a refactor that applies the same pattern independently to many different spots in a large codebase - the coding agents do extremely well, better than the median engineer I think.

Basically "do something really hard on this one section of code, whose contract of how it intereacts with other code is clear, documented, and respected" is an ideal case for these tools.

As soon as the codebase is large and there are gotchas, edge cases where one area of the code affects the other, or old requirements - things get treacherous. It will forget something was implemented somewhere else and write a duplicate version, it will hallucinate what the API shapes are, it will assume how a data field is used downstream based on its name and write something incorrect.

IMO you can still work around this and move net-faster, especially with good test coverage, but you certainly have to pay attention. Larger codebases also work better when you started them with CC from the beginning, because it's older code is more likely to actually work how it exepects/hallucinates.

That said, there is now much better competition with Codex, so there's only so much rope they have now.