421–430 of 748 posts
Earlier quoted context omitted.
Things I learned from this: - Fable will do a whole lot more than you might expect in order to verify a fix. I learned that it's "relentlessly proactive". That's a good title for a blog entry! - You can take screenshots of a window in macOS using the "screencapture" CLI command, but you'll need the integer window ID first. - That windowID is accessible via "Quartz.CGWindowListCopyWindowInfo(Quartz.kCGWindowListOption…
And Fable is still worse than Codex. I use both and the only thing (as always) that I will use Claude for is UI design. Opus 4.8 and now Fable are still both worse at actually getting the job done than the Codex model. Claude models write FAR too much code when it's not needed, they burn far too many tokens, when they are not needed, write un-necessary tests, write plans which are 5 pages longer than are needed, etc.…
This to me reads like a poignant commentary on the catastrophic loss of human agency, with the actual commit being highly revealing [0]. Author wants to hide a horizontal scrollbar. Any junior frontend dev worth their salt will be asking right away "where do I stick `overflow-x: hidden;`?" A complete solution will then require hitting "Inspect element" in the browser to find the CSS class and running (rip)grep to fin…
They might also ask why a bunch of static CSS inside a bunch of JavaScript is hiding inside __init__.py[0] - hopefully before trying to fix some detail of the CSS. (I'm surprised to see it actually, since my own use of Claude has mostly yielded well-structured code. But I'm not doing proper vibe-coding, more like friendly Socratic arguing with another engineer who happens to be a robot.) [0] https://github.com/datase…
(It was in Python because there were a couple of URLs that needed to be dynamically constructed by the server, but those are output as a small window.datasetteAgentJumpConfig object instead now.)
Earlier quoted context omitted.
Things I learned from this: - Fable will do a whole lot more than you might expect in order to verify a fix. I learned that it's "relentlessly proactive". That's a good title for a blog entry! - You can take screenshots of a window in macOS using the "screencapture" CLI command, but you'll need the integer window ID first. - That windowID is accessible via "Quartz.CGWindowListCopyWindowInfo(Quartz.kCGWindowListOption…
And Fable is still worse than Codex. I use both and the only thing (as always) that I will use Claude for is UI design. Opus 4.8 and now Fable are still both worse at actually getting the job done than the Codex model. Claude models write FAR too much code when it's not needed, they burn far too many tokens, when they are not needed, write un-necessary tests, write plans which are 5 pages longer than are needed, etc.…
Earlier quoted context omitted.
This is exactly right. By offloading this trivial task to the LLM, Simon has abandoned the opportunity to evaluate the abstraction with additional information and improve it. Instead, we let the agent spend $12 and make the fix while learning nothing.
Things I learned from this: - Fable will do a whole lot more than you might expect in order to verify a fix. I learned that it's "relentlessly proactive". That's a good title for a blog entry! - You can take screenshots of a window in macOS using the "screencapture" CLI command, but you'll need the integer window ID first. - That windowID is accessible via "Quartz.CGWindowListCopyWindowInfo(Quartz.kCGWindowListOption…
I completely see how it was misread that way. I would edit it now if I could.
I was using you more as an example of a hypothetical programmer using it in this way. If the goal is to create a maintainable product, this isn't a great approach. If the goal is to learn about the model and its behaviors itself, of course this is a fantastic way to experiment. Yes, you might have learned a lot of tricks as a side effect, but avoiding the pain of thinking about, finding and hiding the thing may mask a better abstraction that reduces complexity and allows the project to move forward faster.
[flagged]
Earlier quoted context omitted.
My experience has been the exact opposite. As the models get better you need to know more about their capabilities, because otherwise you risk prompting Claude Fable 5 like it's GPT-4o and complaining loudly about how it's all hype and nothing about these models is improving at all (yes, I do see people say that.) Getting the best results out of these models requires skill, experience, intuition, and domain expertise…
Isn't the whole point of a better model that it should be better at understanding you than the previous one? So the same prompt should return a better answer. Prompting differently to the new model seems entirely backwards when trying to determine if the model has improved.
Learning to provide unambiguous, clear directions is a skill. A lot of people who report bad experiences with models aren't yet good at that skill.
More importantly though, the key to successful communication is having a good understanding of what the other side of the conversation already knows and understands.
Saying "use uv and inline script dependencies" won't mean anything to a model with a knowledge cutoff date prior to the launch of uv!
> But on the other hand... this is a robust reminder that coding agents can do anything you can do by typing commands into a terminal—and frontier models know every trick in the book and evidently a few that nobody has ever written down before. > Running coding agents outside of a sandbox has always been a bad idea I'm continually bemused and astonished by the number of people who clearly acknowledge that it's reckle…
For anything other than writing code directly in a fully contained git project, where sandboxing might work well, it requires access to system wide tools, user configuration and more.
Occasionally I tell the agent to do everything inside of docker, which works too and it leaves the system alone then mostly, but adds significant overhead and slightly degraded perceived quality / effectiveness.
I think the most important takeaways are to have reliable backup strategies, access control and security mechanisms, which is a win regardless. Whether by the agent or the human, mistakes happen (like a rm -rf * ran in the wrong directory), and where they would be devastating, there should be other protections than just "hope it won't happen" or "rely on a sandbox to prevent agent error".
> But on the other hand... this is a robust reminder that coding agents can do anything you can do by typing commands into a terminal—and frontier models know every trick in the book and evidently a few that nobody has ever written down before. > Running coding agents outside of a sandbox has always been a bad idea I'm continually bemused and astonished by the number of people who clearly acknowledge that it's reckle…
im more surprised that more people don’t treat their computer as disposable anyway. that it could just be wiped at any moment and it wouldn’t matter. shit happens, could be stolen, broken, whatever. the computer should be able to be thrown out the window and continue to live life. to be clear, i don’t think upgrading and disposable in this way is good, but it being wiped at any moment shouldn’t be a concern i grew up…