the_duke

Of course they will.

Right now they want to prevent the US labs from gaining any sort of self-reinforcing oligopoly on the space, and to let the ecosystem in China flourish.

That will all die sooner or later.

This is often due to (privacy) extensions disabling canvas/webgl.

In codex CLI /status works just fine during a turn.

Other things don't though.

I exclusively use thinking mode, which is slower but much more likely to double-check things with web search etc.

Config based hooks seem to miss the mark though?

The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?

So not very useful at all...

I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.

That's in part because many EU countries would like to ship the Syrian refugees back to Syria.

Any recommendations?

You shouldn't be downvoted - LLMs could in theory be deterministic, but they currently are not, due to how models are implemented.

I think many have adopted "spec driven development" in the way you describe.

I found it works very well in once-off scenarios, but the specs often drift from the implementation. Even if you let the model update the spec at the end, the next few work items will make parts of it obsolete.

Maybe that's exactly the goal that "codespeak" is trying to solve, but I'm skeptical this will work well without more formal specifications in the mix.

This doesn't make too much sense to me.

* This isn't a language, it's some tooling to map specs to code and re-generate

* Models aren't deterministic - every time you would try to re-apply you'd likely get different output (without feeding the current code into the re-apply and let it just recommend changes)

* Models are evolving rapidly, this months flavour of Codex/Sonnet/etc would very likely generate different code from last months

* Text specifications are always under-specified, lossy and tend to gloss over a huge amount of details that the code has to make concrete - this is fine in a small example, but in a larger code base?

* Every non-trivial codebase would be made up of of hundreds of specs that interact and influence each other - very hard (and context - heavy) to read all specs that impact functionality and keep it coherent

I do think there are opportunities in this space, but what I'd like to see is:

* write text specifications

* model transforms text into a *formal* specification

* then the formal spec is translated into code which can be verified against the spec

2 and three could be merged into one if there were practical/popular languages that also support verification, in the vain of ADA/Spark.

But you can also get there by generating tests from the formal specification that validate the implementation.

Rust has managed just fine to remain mostly backwards compatible since 1.0 , while still allowing for evolution of the language through editions.

This puts much more work on the compiler development side, but it's a great boon for the ecosystem.

To be fair, zig is pre 1.0, but Zig is also already 8 years old. Rust turned 1.0 at ~ 5 years, I think.

What context length and related performance are you getting out if this setup?

At least 100k context without huge degradation is important for coding tasks. Most "I'm running this locally" reports only cover testing with very small context.

Musk is actually a brilliant marketer. He built his companies around a "vision", used it to attract high quality talent and push that talent to give their best.

For Tesla it was "electrify transport to end dependence on fossil fuels and save the planet", for SpaceX it was "save humanity by becoming a multi-planetary species".

With how much he talked about it, he did probably actually believe in Mars.

But now both of these ideals have come into conflict with his newfound political affiliations, so they have to be dropped.

Good PR moves.

Rust has an interesting crate for this, arc-swap [1].

It's essentially just an atomic pointer that can be swapped out.

[1] https://docs.rs/arc-swap/latest/arc_swap/

Rust has a very strict type system and an ecosystem that often utilizes the type system well.

Many things that would only be caught at runtime in other languages are caught at compile time in Rust, making coding agents iterate until things compile and work well.

Rust also has great error messages, which help the agents in fixing compilation errors.

Even Chrome has started to adopt Rust due to recurring memory vulnerabilities.... that's a big enough reason.

Gemini 3 is pretty good, even Flash is very smart for certain things, and fast!

BUT it is not good at all at tool calling and agentic workflows, especially compared to the recent two mini-generations of models (Codex 5.2/5.3, the last two versions of Anthropic models), and also fell behind a bit in reasoning.

I hope they manage to improve things on that front, because then Flash would be great for many tasks.

An Anthropic safety researcher just recently quit with very cryptic messages , saying "the world is in peril"... [1] (which may mean something, or nothing at all)

Codex quite often refuses to do "unsafe/unethical" things that Anthropic models will happily do without question.

Anthropic just raised 30 bn... OpenAI wants to raise 100bn+.

Thinking any of them will actually be restrained by ethics is foolish.

[1] https://news.ycombinator.com/item?id=46972496

From all indications the big players have healthy margins on inference.

Research and training are the cost sinks.

They claim the opposite, though, saying the chip is designed to tolerate many defects and work around them.

That's because many developers are used to working like this.

With AI, the correct approach is to think more like a software architect.

Learning to plan things out in your head upfront without to figure things out while coding requires a mindset shift, but is important to work effectively with the new tools.

To some this comes naturally, for others it is very hard.

I do not trust the AI benchmarks much, they often do not line up with my experience.

That said ... I do think Codex 5.2 was the best coding model for more complex tasks, albeit quite slow.

So very much looking forward to trying out 5.3.

Do you have a source for that?

This is very confusingly written.

From the post I expected that the tasks were about analysing traces, but all the tasks in the repository are about adding instrumentation to code!

Some of the instructions don't give any guidance how to do it, some specify which libraries to use.

"Use standard OTEL patterns" ... that's about as useful as saying "go write some code". There are a lot of ways to do instrumentation....

I'd be very curious HOW exactly the models fail.

Are the test sets just incredibly specific about what output they except, and you get a lot of failures because of tiny subtle mismatches? Or do they just get the instrumentation categorically wrong?

Also important: do the models have access to a web search tool to read the library docs? Otel libraries are often complicated to use... without reading latest docs or source code this would be quite tricky.

Some models have gotten better at adding dependencies, installing them and then reading the code from the respective directory where dependencies get stored, but many don't do well with this.

All in all, I'm very skeptical that this is very useful as a benchmark as is.

I'd be much more interested in tasks like:

Here are trace/log outputs , here is the source code, find and fix the bug.

According to USTR data the EU had a 200bn goods surplus, but a 100bn services deficit in 2024.

So a 100bn deficit out of 800bn total US imports.

The deficit is there, but it's not nearly as lopsided as some reporting would have you believe.

Tell that to all the companies that built their entire tech stacks on US cloud providers...

Massive endeavor for a lot of setups.

The more advanced AI related workflows are the reason I finally switched away from neovim as my main coding IDE - for now.

The existing AI plugins for neovim aren't great.

With a bit of education one would know that manus is Latin for hand. That's where "manual" comes from.

And their logo is, lo and behold ... a hand!

I've been preaching similar thoughts for the last half year.

Most popular programming languages are optimized for human convenience, not for correctness! Even most of the popular typed languages (Java/Kotlin/Go/...) have a wide surface area for misuse that is not caught at compile time.

Case in point: In my experience, LLMs produce correct code way more regularly for Rust than for Js/Ts/Python/... . Rust has a very strict type system. Both the standard library and the whole library ecosystem lean towards strict APIs that enforce correctness, prevent invalid operations, and push towards handling or at least propagating errors.

The AIs will often write code that won't compile initially, but after a few iterations with the compiler the result is often correct. Strong typing also makes it much easier to validate the output when reviewing.

With AIs being able to do more and more of the implementation, the "feel-good" factor of languages will become much less relevant. Iteration speed is not so important when parallel AI agents do the "grunt work". I'd much rather wait 10 minutes for solid output rather than 2 minutes for something fragile.

We can finally move the industry away from wild-west languages like Python/JS and towards more rigorous standards.

Rust is probably the sweet spot at the moment, thanks to it being semi-popular with a reasonably active ecosystem, sadly I don't think the right language exists at the moment.

What we really want is a language with a very strict, comprehensive type system with dependent types, maybe linear types, structured concurrency, and a built-in formal proof system.

Something like ADA/Spark, but more modern.