@galluzzo_julian @alexchristou_ I'm assuming you're primarily on mac, but if you use Windows I can share my voice tool, it might work for you.
English
Michael Wells
121 posts
Michael Wells
@memetican
Entrepreneur. Programmer. Webflow dev. Zouk enthusiast.
Auckland, NZ Katılım Mayıs 2009
71 Takip Edilen126 Takipçiler
@memetican @alexchristou_ Ehhhhh I’d say for AI prompting + short messages! I couldn’t see writing a video script or something just straight up with voice haha
English
I have a feeling voice transcription is gonna be the next thing i try and then wonder how I haven't been using it forever
@alexchristou_ has been telling me for months now that I gotta do it, and every time he tells me to do something, I lag for a few months, eventually cave in, then wish I did so sooner
last thing was --dangerously-skip-permissions. IDK how it took me so long to do this but I'm never going back
before that, Claude Code. I was using Cursor for months and had no idea why I should try Claude Code.
AND before that this dude was the one who got me hooked on vibe coding to begin with
anyways if Alex recommends something, it's the real deal
and his latest tool is live today on producthunt, so go check it out :)
producthunt.com/products/blazi…
English
@SebAaltonen Every serious project I do feels like a postgraduate thesis in terms of the amount I learn. Half of my prompting is engineering. The other half is "why this approach?" "explain the pros and cons" "is there a more optimal approach?"...
English
You can also use AI as your personal tutor. Ask all the stupid questions you never could ask in Stack Overflow. There's two paths: You use AI for continuous self improvement and understand what you are doing. Or you use AI to skip your work and never understand.
Rohan Paul@rohanpaul_ai
Anthropic's own study proves Vibe-Coding and AI coding assistants harm skill building. "AI use impairs conceptual understanding, code reading, and debugging abilities, without delivering significant efficiency gains on average" Developers learning 1 new Python library scored 17% lower on tests when using AI. Delegating code generation to AI stops you from actually understanding the software. Using AI did not make the programmers statistically faster at completing tasks. Participants wasted time writing prompts instead of actually coding. Scores crashed below 40% when developers let AI write everything. Developers who only asked AI for simple concepts scored above 65%. Managers should not pressure engineers to use AI for endless productivity. Forcing top speed means workers lose the ability to debug systems later. ---- Paper Link – arxiv. org/abs/2601.20245 Paper Title: "How AI Impacts Skill Formation"
English
If you're sleeping on the @webflow MCP, change that.
loom.com/share/225e0dfb…
English
@zeeg agreed - i think i've quantified it, but explaining it simply is the hard part
best i have: you add one thing and now you need to check four things
another, and it's 16 things, then 32, etc. until you can't keep up
English
im fully convinced that LLMs are not an actual net productivity boost (today)
they remove the barrier to get started, but they create increasingly complex software which does not appear to be maintainable
so far, in my situations, they appear to slow down long term velocity
English
They do, but the same was always true for trad software dev. We just didn't really notice because the beginning of the curve was also flat-ish. limited by typing speed.
But once you're in the flat part of the curve, are you still seeing substantial efficiency gains? I still do, it just shifts the workload hard towards context engineering.
I'm also noticing that you regain velocity when you're building a new external feature, outside of the existing code base. Perhaps there are techniques to break that curve, dev patterns tied closer to e.g. city building. Tear down and cart away the building first. Then build the new one in its place. New challenges of course, but it solves for complexity during the build itself.
x.com/memetican/stat…
English
@zeeg I agree. They remove the barrier to get started, and propel you straight into the barrier of complexity.
x.com/whusterj/statu…
William Huster@whusterj
I am developing a formal theorem I call the Verification Complexity Barrier. In a nutshell, if a program has some components `n` that have connectivity factor of `k > 0` , then verification complexity increases superlinearly for each new component. Therefore the time required to fully verify the system always exceeds time to generate components. After a while, because it's superlinear, the verification complexity takes off and becomes impossible to keep up with in some finite amount of time. This was true before AI, but is much starker now as code generation time trends towards zero. You hit the barrier sooner. We all have finite capacity - even AI agents - so there will always be a certain number of components `n` where the wall is hit. You must spend more and more effort on verification for each new component in the system. The best thing you can do is spend time changing the "topology" of the problem - change the software architecture - so that the exponent of verification complexity is lowered ([1] Lehman) and the curve is flattened. You can bundle components into modules, you can add automated tests, you can use formal proofs, you can use type systems. These things push the barrier to the right. They buy you more components and a more complex system. But the theorem suggests you can only ever defer the barrier, never completely eliminate it. AI Agents can burn tokens all day long generating software components and tests for those components. They can find bugs and fix them, but they cannot prove the absence of bugs (per [2] Dijkstra, [3] Rice, [4] Smith, and others). And "Bug" needs to be defined against someone's spec for what "working" and "not buggy" looks like. The more you build with Agents, the heavier the verification burden becomes. This may sound like the same trite observation others have made here on X: "Our bottleneck is no longer writing code, but reviewing code" [5] and "I am the bottleneck now." [6] True, but I don't think anyone has captured the magnitude of the problem. The math is: at a certain component count `n`, it is literally impossible for you, your team, and your agents to completely verify a system. The bottleneck goes to zero, and nothing gets through. So what software companies do in the real world is release incompletely verified software and massively scale up. This shifts the burden of verification onto their customers, because "given enough eyeballs, all bugs are shallow" ([7] Raymond). If you can get enough eyeballs, this is a very cost-effective way to shift the barrier to the right by massively increasing your team's capacity. You walk the tightrope of doing enough internal verification before release so you don't lose customers, while tolerating a certain amount of escaped bugs, which - if those bugs matter at all - your customers will find for you. Meanwhile, massively scaling up just accepts the growing cost of complexity. You can push `n*` from 15 to 30 by quadrupling your capacity. To get to 60 you need to quadruple again, and then again to get to 120. Your cost curve is superlinear to get linear gains in system size. At a big enough scale, you amortize the cost across your customer base and the economics work. Contrast that with a sufficiently complex vibecoded app built for a small audience - high complexity costs can't be amortized at small scale. I expect to see many people and companies try and fail at vibecloning complex SaaS in the near term. Complexity cost economics only scale with audience size (I will share another model for this). I do think SaaS prices will be corrected downwards to account for savings in code generation, but I predict that once the irrational exuberance for vibing fades, we'll see that it still makes sense to buy rather than self-build complex SaaS. A broader implication is that AI Agents will never be able to self-verify. Humans, too, will never be able to fully verify their behavior, because LLMs are by design of maximal complexity. Did you see the size of those error bars in the latest METR results? [8] The longer the horizon on a task, the more spread in AI agent outcomes. This is the Barrier in action. Spread is a feature of GenAI, but in practice it means heaps more output to review and verify. The Complexity Barrier shows you literally won't have time to review it all. At the inflection point of verification complexity, you have to fall back on vibes. The implication for fast-takeoff AGI is even scarier: if AI does reach a point of recursive self-improvement, this theorem suggests it will be structurally impossible to know that behavior is aligned, because you won't be able to completely verify. Drift is bad enough in vibe coding. Runaway AI will drift massively and there's no way of knowing where it will end up. All that's to say, verification should be the focal point of AI Engineering for the foreseeable future and maybe forever. That is: how do you capture what you want to do, refine that into specifics, and then follow up with automated tests, assertions, evals, and customer feedback to progressively harden your software? The verification problem is acute now because of how cheap software generation is. Because of the superlinear nature of software verification complexity, companies that push hard on the barrier and successfully shift it right will have a built-in moat versus those who fail to put in the verification work. Detailed blog post and interactive model incoming. Links: [1] en.wikipedia.org/wiki/Lehman%27… [2] cs.utexas.edu/~EWD/transcrip… [3] en.wikipedia.org/wiki/Rice%27s_… [4] cse.buffalo.edu/~rapaport/Pape… [5] x.com/shl/status/194… [6] x.com/thorstenball/s… [7] en.wikipedia.org/wiki/Linus%27s… [8] metr.org/blog/2025-03-1…
English
@galluzzo_julian Like yesterday. Maybe the day before. But 100k tokens is probably still the sweet spot for context engineering.
English
1M context with Opus 4.6 in Claude Code is insane
When did this come out?!?!
English
@MarcelDeelen @marvinblach I am using it this way every single day. Phenomenal.
English
@marvinblach Totally, also handy for opening two different pages within the same project.
English
I have Meta oakleys, solid mic + audio. Might there be a way to link this in so I can get Claude Code hook prompts and respond with approvals, hands free? Raybans might even be better, adding the HUD aspect. I'm looking for any kind of solid, free-range, handsfree remote integration.
English
Announcing a new Claude Code feature: Remote Control. It's rolling out now to Max users in research preview. Try it with /remote-control
Start local sessions from the terminal, then continue them from your phone. Take a walk, see the sun, walk your dog without losing your flow.
English
I'm seeing some interesting shifts in Claude's thinking over the past few months. Some of it I'd guess is an effort by Anthropic to keep it "on the rails" towards the stated goal- e.g. enforced planning, adherence to plan even when it's overkill for a simple feature. etc.
But a new one surfaced today while I was refactoring a module. It wrote the description as "current state" and "desired state", very K8 like. I think we're getting closer to that reality of describe the goal and Claude will figure out how to get you there.
But therein lies the "genie" problem. Better be careful what we ask for.
English
I really feel like Opus 4.6 and Sonnet 4.5 have a fatal flaw. There's a strange kind of "rebellion" in the models that's ignoring rules and instructions and just "pushing all the buttons." If I give it an MCP, it will make nonsensical tool calls that the previous model didn't. Using Claude in Chrome, it takes more screenshots- why? No idea, it has nothing to do with my question. It seems to just like... pushing buttons and burning tokens.
This seems like a small problem but it's like trying to ride a motorcycle with the front wheel loose. You have to go extra slow, avoid bumps, take curves extra cautiously. Sometimes stop and try to hand tighten them a bit before continuing. Worse, it means the models burn tokens FAR more quickly which pushes them into the "dumb zone" ( Wiggum terminology ), very quickly, where context drift makes it even more difficult to stay on the rails.
Weirdly that means Sonnet is better than Opus at the same programming tasks- just slightly less wobbly, burning slightly less fuel. But still the rebellious teenager.
I don't know where this is going but I sure hope they grow up to be decent adults.
English
@DigiHotshot Install Claude Code on your phone too, once you setup the connector on your desktop you can access it from your phone as well... walk down the street and write blog articles. I'm looking forward to when I can casually check things like Analyze and Optimize stats.
English
I just tested out Webflow connector in Claude
and I'm just wow'ed
I just updated all meta data, schema, FAQschema for a page that we are launching tomorrow, reviewed 3 case studies against aeo principles and updated 1 blog with more authority based content from our projects
All from a Claude chat
Crazy 🤯
English
Using Opus 4.6 feels like raising a teenager. It's constantly pushing boundaries, ignoring house rules, wasting time on irrelevant pursuits. And so hungry, every time I look my token fridge is empty.
Jeez.
English