EFLKumo

However, it seems like OpenAI didn't pay much attention on these perspectives and I didn't find if Astra could write a more elegant code, or communicate more naturally, etc., which made me somehow a little disappointed.

They indeed mentioned the code Astra delivered is closer to production grade but production-grade code is different from what I want since there can be a kind of messy code blowing up your whole architecture design with control flows nobody truly understands but just passes all tests perfectly. There is no difficulty in maintaining this kind of code because you only need to paste the problems into Codex. And we all know this sounds incorrect. I don't know if my appetite towards a good code (no matter how) is sound but I just imagined frontier labs to give more attention on this.

Note: fwiw Fable 5.1's release page says it's better at these perspectives of coding and per my experience, yes it is.

On the Rust side, IMO the windows-rs even has not thought about authoring new com interfaces, only consuming or impl-ing existing ones. In fact the experience of consuming windows apis in rust feels good if one would like to get rid of C++. Rust with NAPI or BoltFFI etc. offers an maintaining-friendly option for cross-platform app authors to interact with the OS more deeply. So in conclusion the situation right now is that windows apis just become not so unapproachable, while in-depth things keeping comfortable only with C# or .NET.

This reminds me the article above. Now people have diverse ideas on agentic coding. Some suggest human-in-the-loop while others suggest giving a detailed specification and let the agent run freely; some suggest leveraging LLM's high productivity and here we get an opinion that LLM can actually slowly write good code.

It's happy to see opinions that are more practical and variant emerging, turning LLM into literally a tool instead of something to be hated or hyped.

In my own practice, I find LLMs (SOTA ones) good at medium-level tasks, those needed to reason and plan for a while. However, the design taste on architecture is unexpectedly disgusting. Sometimes writing interfaces myself and asking LLMs to fill in implementations, alongside context-completing tools like context7, deepwiki, docs.rs MCPs, etc. and giving a escape hatch (e.g. encouraging it to use the AskUser tool in Claude Code), may be considered my best practice.

Yes I'm a builder of an agent infra on PCs, so I can completely sense that the protective measures are weak and inadequate, sometimes seeming like an unsolvable problem. But according to the article, what Microsoft did was hard to tell in a polite way. If they had even a little security awareness, I could completely understand, but it's like they've vibe coded the entire permissions system of Cowork.

To be honest, I'm 17 y.o., I'm coding by chatting with an agent, but it seems like we can't tell the distinction too absolutely.

At the first time writing a React app, I forgot to name a file with a .tsx extension and I used .ts instead, then spotting ugly error lines across my JSX syntax, confusing and sharing with my friend, and laughing this little funny thing all the day.

I once spent the whole afternoon choosing a js linter, reading their docs and perceiving different tastes. In my early twelve-ties (uh this sounds funny too) I'm always arrested by configuring Windows PEs, installing different Linux distributions on my PC, etc. Today I still read tech books, alongside videos, articles and also chatbots. Chatbot is a new tool, but there's no doubt it cannot replace other media types and what they bring to us/me.

What may I express is that a natural interest in programming or computer things cannot really be overwhelmed by LLM things. I don't know how to use vim skillfully since I majorly used Windows at my early age and I'm not familiar with vim's logic, but this practically doesn't stop anything. I still found Linux's fantasy, at last. And same for LLMs.

OpenAI released their LLM-driven browser Atlas last year. Though their team is brilliant (https://openai.com/index/hardening-atlas-against-prompt-inje...), there has been a number of succeeded injection attacks.

IMO the real vulnerability is located at the "Act" part of "ReAct" (reasoning and action) agent framework.

> “[Copilot] Cowork asks for your permission before taking sensitive actions...” ... when the recipient is the active user, these actions execute immediately without requiring human approval (users do not have a setting to modify this behavior).

> Copilot Cowork can retrieve ‘pre-authenticated download links’ for files the user has access to, which allow anyone who opens the link to download that file.

> Microsoft Copilot Cowork has read access to essentially any resource a user does through Microsoft Graph. As such, the primary mechanism to reduce the blast radius of attacks like this is to restrict excessive permissioning across one’s Microsoft ecosystem.

Take it easy. Inside the whole attack flow, Microsoft gives Cowork unrestricted access and the ability to bypass approvals. I don't find much problem with LLMs here. It's said the attack is also a threat for Opus 4.7, but I've found several times Opus 4.7 forbidding context7.com's "prompt injections" only requiring opus to ask me creating an context7 API key to get more requests for free. From my personal experience, such models indeed are trained to perceive injections, but these injections could mask themselves as sth like Agent Skills, and there are always ways to win as red teams.

We may not lay our hope too much on defense of injections, but concentrating on restricting LLM's permissions. The popular usage of CLIs in agents' (especially coding agents) workflow has also concerned me since most cli tools an agent can access actually have the same permissions with users.

This makes sense since certain higher-level code produces certain lower-level code, while LLM cannot. If the transpired JS code doesn't work we could just find out the bug in minifiers, etc. but one cannot figure out why LLM fails at one task, especially considering LLMs, even SOTA ones, could be strongly affected by even small prompt changes. Taking this into consideration, I don't think this is a sound reasoning why we don't need to review ai-generated code.

> The LLMs produce non-deterministic output and generate code much faster than we can read it, so we can’t seriously expect to effectively review, understand, and approve every diff anymore.

Exactly. However, this could also indicate a weaker review standard instead of just dropping review. We could also suggest an idea where devs mainly review code design or interfaces, leveraging one's *taste*, while leaving strict logic reasoning, validating and testing to other tools or approaches. It cannot pursuade me that the nature of LLM's code generation must lead to a complete cancel of the code review.

Anyway, I'm not opposing this article and its thought of shift in the future is really good.