> Read deeply, write a plan, annotate the plan until it’s right, then let Claude execute the whole thing without stopping, checking types along the way.
As others have already noted, this workflow is exactly what the Google Antigravity agent (based off Visual Studio Code) has been created for. Antigravity even includes specialized UI for a user to annotate selected portions of an LLM-generated plan before iterating it.
One significant downside to Antigravity I have found so far is the fact that even though it will properly infer a certain technical requirement and clearly note it in the plan it generates (for example, "this business reporting column needs to use a weighted average"), it will sometimes quietly downgrade such a specialized requirement (for example, to a non-weighted average), without even creating an appropriate "WARNING:" comment in the generated code. Especially so when the relevant codebase already includes a similar, but not exactly appropriate API. My repetitive prompts to ALWAYS ask about ANY implementation ambiguities WHATSOEVER go unanswered.
From what I gather Claude Code seems to be better than other agents at always remembering to query the user about implementation ambiguities, so maybe I will give Claude Code a shot over Antigravity.
With hooks you can achieve a similar UI that can do what antigravity does just as much & better. Search "claude code plan annotations plugin" and youll come across some.
> [Claude Code] "A spiral that generates itself — starting from a tight mathematical center (my computational substrate) and branching outward into increasingly organic, tree-like forms (the meaning that emerges). Structure becoming life. The self-drawing hand."
"And blood-black nothingness began to spin... A system of cells interlinked within cells interlinked within cells interlinked within one stem... And dreadfully distinct against the dark, a tall white fountain played." ("Blade Runner 2049", Officer K-D-six-dash-three-dot-seven)
Ergodic literature refers to texts requiring non-trivial effort from the reader to traverse, moving beyond linear, top-to-bottom reading to actively navigate complex, often nonlinear structures. Coined by Espen J. Aarseth (1997), it combines "ergon" (work) and "hodos" (path), encompassing print and electronic works that demand physical engagement, such as solving puzzles or following, navigating, or choosing paths.
I have no clue whatsoever as to why any human should pay any attention at all to what a canner has to say in a public forum. Even assuming that the whole ruckus is not just skilled trolling by a (weird) human, it's like wasting your professional time talking to an office coffee machine about its brewing ambitions. It's pointless by definition. It is not genuine feelings, but only the high level of linguistic illusion commanded by a modern AI bot that actually manages to provoke a genuine response from a human being. It's only mathematics, it's as if one's calculator was attempting to talk back to its owner. If a maintainer decides, on whatever grounds, that the code is worth accepting, he or she should merge it. If not, the maintainer should just close the issue in a version control system and mute the canner's account to avoid allowing the whole nonsense to spread even further (for example, into a HN thread, effectively wasting time of millions of humans). Humans have biologically limited attention span and textual output capabilities. Canners do not. Hence, canners should not be allowed to waste humans' time. P.S. I do use AI heavily in my daily work and I do actually value its output. Nevertheless, I never actually care what AI has to say from any... philosophical point of view.
If you want more convenience from Rust and do not want to mess with Rust borrow checker, you do not really have to switch to Swift: you can rely on Rust reference counting. Use 1.) Rust reference-counted smart pointers[1] for shareable immutable references, and 2.) Rust internal mutability[2] for non-shareable mutable references checked at runtime instead of compile time. Effectively, you will be writing kind of verbose Golang, but keep Rust expressiveness.
Oh god, I hope I read this wrong. I thought Rust finally fixed C/C++'s worst issue which is aliasing, which means that if you pass a struct by pointer to a function, since any number of other mutable references might exist to it, the only correct way to treat it, is to reload/save it to memory every time you access it.
This is obviously unacceptable from a performance point, so compilers have resorted to heavy static analysis, and a bunch of hacks to prove nobody else is actually writing to that memory.
These hacks were brittle, leading to buggy or slow code, which is why C introduced the __restrict__ keyword, that allowed the programmer to tell the compiler that nobody is going to write to said variable, which meant it was now the programmer's responsibility to enforce that. High-perf code is littered with it.
I thought Rust's ownership system prevented mutable aliases, thus it allowed the compiler to automatically tag every pointer with __restrict__ , but if what the article says is right, Rust is bad as C/C++, because there are 1% exceptions to the general rule the compiler enforces.
Rust tags every &mut T and every &T with the equivalent of restrict except for when the T transitively contains an UnsafeCell<T>. Types like Arc<T> and Rc<T> are built on top of UnsafeCell<T>.
Don’t use shared ownership? You get the semantics you want. It’s the norm for the vast majority of things.
Thanks for the answer, that sounds reassuring. I have another question, from what you said, it sounds like you remove restrict from the whol argument, but technically, afaict, the Rust borrow rules still prevent anything inside those structs getting aliased, with the exception of the stuff inside UnsafeCell<> (even with Rc<> the underlying value cannot be aliased, only the reference counter).
Does Rust/LLVM track aliasing to this degree, or is it all or nothing, like if you have a UnsafeCell anywhere, the whole type is excluded from restrict?
I am not sure off the top of my head, to be honest. https://news.ycombinator.com/item?id=46616616 was a thread where I was talking about this sort of thing previously, you could probably adapt those code examples and get an answer.
Also, you get the ability to use Rc (non-atomic refcount) as long as you’re not in a multithreaded env. The atomic version is Arc, which is similar to C++ shared_ptr.
And there are no footguns to using Rc. More specifically, you cannot mistakenly use a Rc across threads, because the compiler will ensure that you aren’t doing this thanks to the Send marker trait.
> In retrospect, it made sense. Agents write units of changes that look good in isolation. They are consistent with themselves and your prompt. But respect for the whole, there is not. Respect for structural integrity there is not. Respect even for neighboring patterns there was not.
That's exactly why this whole (nowadays popular) notion of AI replacing senior devs who are capable of understanding large codebases is nonsense and will never become reality.
In the mobile app market, a financially-viable or organic (non-paid) long-term marketing plan is the hardest. First testers can be hired. First users can be paid for with Google Ads/Apple Search Ads, etc. Depending on the competition, sustained user-base growth can become a next-to-impossible problem to solve.
If you have an iPad, perhaps have a look at modern general-purpose database apps[1], for example the object-oriented easyAsPieDB[2]. Object-orientation allows an end-user to define relationships among the relevant pieces of data in a conceptual manner, for example by using Composition (e.g., a House is composed of Rooms) and Association (a known Product is associated with a particular Order), while relational databases such as Microsoft Access force an end-user to define relationships among the relevant pieces of data in a more technical, structural manner, for example with Tables including generic "Foreign Keys" to other Tables.
I think the only reason vibe coding/prompt engineering seems to be taking over programmers' jobs is the fact that it currently enjoys the status of the latest investment craze/fashion such as blockchain did a few years ago and the dot-com boom did even earlier. In a few years projects based on AI generated code spaghetti will start to quietly fail one after another due to accumulation of technical debt and the necessity for manual, costly codebase rewrites and the whole AI coding train will come crashing down just like all other unrealistic, "new economy" fads before it. Companies will get desperate to hire decent programmers back and things will be back to normal.
As others have already noted, this workflow is exactly what the Google Antigravity agent (based off Visual Studio Code) has been created for. Antigravity even includes specialized UI for a user to annotate selected portions of an LLM-generated plan before iterating it.
One significant downside to Antigravity I have found so far is the fact that even though it will properly infer a certain technical requirement and clearly note it in the plan it generates (for example, "this business reporting column needs to use a weighted average"), it will sometimes quietly downgrade such a specialized requirement (for example, to a non-weighted average), without even creating an appropriate "WARNING:" comment in the generated code. Especially so when the relevant codebase already includes a similar, but not exactly appropriate API. My repetitive prompts to ALWAYS ask about ANY implementation ambiguities WHATSOEVER go unanswered.
From what I gather Claude Code seems to be better than other agents at always remembering to query the user about implementation ambiguities, so maybe I will give Claude Code a shot over Antigravity.
reply