The inherent problem with evaluating coding performance of models remains: most day-to-day coding tasks are open-ended/partially-spec'd, and as such there is huge uncertainty on how the "right" solution looks.
It's very hard to rank models' solutions on such problems, which is why they rarely appear in benchmarks (I'd be glad to stand corrected).
Even Opus 4.5 coding a C compiler from scratch - jaw-dropping as it is - doesn't tell the whole story. Most of my tasks are not that well spec'd.
My second reaction: still incredible, but noting that a C compiler is one of the most rigorously specified pieces of software out there. The spec is precise, the expected behavior is well-defined, and test cases are unambiguous.
I'm curious how well this translates to the kind of work most of us do day-to-day where requirements are fuzzy, many edge cases are discovered on the go, and what we want to build is a moving target.
Important: I didn't see opus 4.6 in claude code. I have native install (which is the recommended instllation). So, I re-run the installation command and, voila, I have it now (v 2.1.32)
agree on that and the speed is fantastic with them, and also that the dynamics of questioning the current session's assumptions has gotten way better.
yet - given an existing codebase (even not huge) they often won't suggest "we need to restructure this part differently to solve this bug". Instead they tend to push forward.
Impressive results, but I keep coming back to a question: are there modes of thinking that fundamentally require something other than what current LLM architectures do?
Take critical thinking — genuinely questioning your own assumptions, noticing when a framing is wrong, deciding that the obvious approach to a problem is a dead end. Or creativity — not recombination of known patterns, but the kind of leap where you redefine the problem space itself. These feel like they involve something beyond "predict the next token really well, with a reasoning trace."
I'm not saying LLMs will never get there. But I wonder if getting there requires architectural or methodological changes we haven't seen yet, not just scaling what we have.
There's an interesting historical angle here: Church's lambda calculus actually predates Turing machines by a few months (both 1936), and they're provably equivalent in computational power. Church even proved undecidability of the Entscheidungsproblem first, using lambda calculus.
Yet despite this head start, the Turing machine formalism became the dominant framework for CS theory—complexity classes, computability, formal verification. Whether that's path dependence, historical accident, or something deeper about how humans reason about computation, I'm not sure.
But it does make me wonder: if the imperative, state-based model proved more tractable even for theorists, maybe FP's learning curve isn't purely about unfamiliarity. There might be something genuinely harder about reasoning in terms of pure functions and recursion vs. "do X, then Y, update Z."
Fully acknowledge this is handwavy—curious if others have thoughts.
The term "B2B SaaS" is doing a lot of heavy lifting here and I think conflates two different things:
(1) Business model: hosted software you pay monthly for (vs self-hosted/one-time purchase)
(2) "Glue" products: tools like Monday.com that primarily provide synergy between data sources and workflows
The article is really about (2) - and yes, those are vulnerable to vibe-coding. If your product's core value is "we connect X to Y and show you a dashboard," that's now a weekend project.
But there's a huge category of SaaS where the value is in the product itself, not the integration layer. Take Excalidraw - fits the SaaS model, but try vibe-coding a collaborative whiteboard with real-time sync, proper data persistence, conflict resolution, export formats, etc. The hard problems aren't "connect API A to API B."
Or PostHog - sure you could vibe-code some analytics tracking, but building reliable event ingestion at scale, session replay, feature flags with proper rollout controls? That's years of engineering.
The "vibecodeable" SaaS products were always somewhat commoditized - AI just accelerated the timeline. The ones solving genuinely hard technical problems seem a lot safer to me.
This looks really promising. I understand the rationale behind BYOS, but I think there's a segment of builders who'd prefer a managed service over provisioning/securing their own machine.
There's another angle here: in the LLM era, markdown files in a public repo actually are apps.
When Google announced free turn-by-turn navigation in 2009, Garmin dropped 16% and TomTom dropped 21% — in a single day[1]. Investors weren't irrational; they recognized Google was giving away for free what others charged $150+ for.
Same dynamic here. Haiku/Sonnet/Opus are the hardware, Cowork is the operating system, and those markdown files are the apps. Together they deliver real utility that previously required paid SaaS or billable hours — at near-zero marginal cost. The market's read may have been hasty, but the underlying concern is real.
This is brilliant. I'm pretty sure I'll use it when the need arises.
One point: the pricing model wasn't immediately clear. I was a bit perplexed by "own this brand for $49" — I get why this is the business model, and it makes sense. But getting a hint about it earlier in the process would have helped set expectations.
I really like this direction - I think it certainly clicks with your audience and solves a real problem.
One thing: my immediate gut reaction was "will they steal my idea?" On reflection, I think that's actually a super common concern among your target users. Early-stage founders are often paranoid about idea theft - even if it's usually irrational (execution >> ideas), the anxiety is real. This could be a conversion killer if not addressed.
Might be worth adding something visible about data privacy/handling right on the landing page.
Two thoughts this sparked, somewhat in tension with each other:
The HTML→React evolution is a good parallel. Writing long-term maintainable markup without loops, reuse, and parameterization became untenable at scale. React (and similar) emerged precisely because "data" (HTML) needed to become "code." Not everyone loves frameworks, but clearly many developers found the abstraction ceiling of pure markup too low.
That said, declarativity has real advantages — mostly around security and sandboxing. CloudFormation is instructive: CDK eventually outputs CloudFormation YAML. AWS could let you run arbitrary code inside CloudFormation, but they don't — because if you can send code there, you can also make it mine bitcoin. The declarative layer is the trust boundary.
So maybe the sweet spot is code-that-emits-data. You get loops, abstraction, and type safety at authoring time, but the execution environment only sees the constrained, analyzable output. CDK got this right. The problem is when systems skip the "emit data" step and try to grow a DSL organically inside YAML.
I am not sure how this use case is prevelant on your system but in my sessions with chatgpt, claude web, claude code, I often find myself in a situation where I enjoy the fact that it is stateless. I can give a fresh context of who I am and get a suitable reply.