Non-developers that try vibecoding default to a "yes, and" style.
561 karma · joined February 22, 2019
Non-developers that try vibecoding default to a "yes, and" style.
5x is calculated in terms of API costs, nobody pays those extreme Anthropic prices outside enterprise users.
> like they didn't just double the cost for most users
Most users aren't on their $200 plan. Most users (including on the $200 plan) continue being subsidized.
I'm optimistic about them tackling frontier intelligence next. Astra 6.1 please?
Have you tried Astra?
I'm designing an analog ASIC. It will suggest e.g. transistor matching. You can also give it hints for layout.
You still need to validate with SPICE simulation (and obviously silicon).
I'm also looking into non-LLM scripts that use brute force aided by heuristics (e.g. lookup tables) to efficiently search the solution space.
"No, but I have seen the house that the project built, and it is terrific." ~ some Google director
The same goes for a binary protected by TPM 2.0, but the attacker would have to re-implement the protected parts. The defender's bet is that this should require too much effort/time/knowledge to bother.
So you can ignore the newly-enabled games in this proposal and you're not missing anything you had previously.
Actually, let me grab it. [...] Hmmm, better than expected. It works out of the box, but there's note latency compared to native apps. Also, zooming and text selection appear even when you don't want them. Janky for real playing, okay for a demo.
It doesn't have nearly enough power for proper circuit modeling. You might as well use samples.
You CAN get an STM32 to sound beautiful and fun (shout out MI Braids), but in 2026 that's available in VCV Rack for free.
Every chip? I bet it can't target analog chips, what with the pointer talk and all...
DRC/LVS/PEX/SPICE are deterministic, but the tools themselves are not without faults.
I'm getting 50x faster code with manual ASM. That's the difference between audio code that runs in realtime and code that does not.
The competing implementations use SIMD and native code, autovec works nicely there. I symbolically invert the LinAlg system at compile time.
You can either have performance (=write manual ASM for each platform), or portability, but not both.
What so-called "portable SIMD" libraries give you is "portable auto-vectorization". "Portable performance" is a global property of the algorithm. Relying on auto-vectorization will result in e.g. sub-optimal register spills in practice. The microbenchmarks will look great, though. ;)
On what, microbenchmarks? I have realtime audio workloads where the hot loop is essentially linear algebra. Exactly the kind of work that suits AVX2/AVX512. Guess what, Apple Silicon still pulls ahead because real workloads are branchy, cache-hungry, full of dependencies and do not line up in 8 neat f64 operations per cycle.
+ hopefully reset?
As others said, the killer app is XCode. Even if you can technically get it to run, you'll still need the full support and test flows of a native solution, so you might as well follow the proper path and use a Mac.
I can get Visual Studio to run in Parallels today. I still test with a real Windows machine.