Loop Til It Works Is Great for Some Things

-
I've been tuning and refining ui-engine.

Man, design choices early on dramatically affect the quality, capabilities, and potential responsiveness of a platform, especially if it has a UI. I've been using a lot of UI experience I've acquired since the 80s and tuning this platform is making me pull out some pretty weird heuristics, like "use a debounce," except in certain situations where that actually interferes with responsiveness.

And, yep, I just scrutinized what Claude did and it's starting the debounce timer on the first send after processing a batch, so when processing a batch takes a lot of time, debounce will actually make responsiveness worse by adding yet more of a wait on top of that. Bad decision.

My friend says Claude's a lazy coder.

Claude does the easy thing if you just tell it, "build X". That's pretty much at every level throughout the system. Even a good design ends up with Claude cutting corners when it writes code because it "thought that wasn't necessary for reasons", even if you give it guidelines like "use SOLID principles" combined with "use OO techniques". I typically collaborate with Claude on my own planning files or in plan mode before I start a project but even with this, it just doesn't really know where you're going with your project.

Since these early choices have such an impact down the line, it seems like "loop 'til it works" will result in stuff that works but has built-in limitations that make it slower and brittle to changes, causing Claude to do a ton more work than it should have when you ask for mods. Like you ask for an addition and it has to rewrite a ton of stuff because it didn't allow for that possibility.

As an example, consider how Claude Code implements its TUI (terminal user interface). Here's a video on it and here's an analysis of some of its... regrettable engineering decisions.

I think loop-til-it-works will be good for apps that are innovative at the human level but not at the technical level. You can build those on top of platforms that are very user-responsive, like ui-engine (which is what frictionless uses), and not worry. Just having Claude poop out an app without choosing good platforms risks the above problems. Web browsers themselves are examples of tuned, user-responsive platforms that need a lot of engineering.

So I guess what matters is whether a project depends on new engineering. Most apps in the world use current engineering, not new stuff, even most games. A minority of games develop their own technology but that's just generally improvements to platforms that already exist, like extensions to Unreal Engine.

Comments

Post a Comment

Popular posts from this blog

Safe navigaion in Scala, take 2

-
OK, revisiting this topic after a very short time, I have a new implementation, again using that interesting anonymous class technique from James Iry's comment: implicit def richOption[T](x : T) = new { def ??[B](f : T => B):B = if (x != null) f(x) else null.asInstanceOf[B] } I changed the operator from "?!" to "??" because that's a lot easier to type and I chose "??" instead of "?" so people wouldn't confuse it with the questi-colon operator from Java and C. It's stand-alone (doesn't depend on Option or anything) and I had to use a cast to get the types to work out properly, but the test case from my last post does work println(p3??(_.bud)??(_.bud)??(_.bud)??(_.name.drop(1))) prints null and println(p3??(_.bud)??(_.bud)??(_.name.drop(1))) prints ubba. For those new to Scala, the expressions in parentheses are anonymous functions because they use "_" as identifiers. (_.bud) expands to (x => x.bud), where Sca...
Read more

Calculator/spreadsheet tool for Acme

-
I got Plan9 from User Space and started messing with it in the hopes of getting a nice toolbench going with Acme. Since I wrote Ober , I've been interested in this idea. Now, I'll probably rewrite it in Go. I'm wondering if I can just use named pipes to mimic what Acme does with its 9p interface. Anyway, I wrote a simplified version of the Calc tool I wrote for Ober and I put it, here . The calc tool searches an Acme window for variables and their values and some code at the bottom. Then, it executes the code, sending the variables and values to its stdin. The code is expected to output new values for some of the variables. Calc parses the output and replaces the new values into the window. I'm also including two wrappers that make it easy to write calc scripts in rc or Go, so you can say something like this: Bob's age=30, he is yearsleft=0 years away from retirement (calc). #!/usr/bin/env calcgo yearsleft = 55 - age If you middle-click "calc" in t...
Read more

Quick update on The Philosopher's Stone

-
I have changed TPS many times in the past year and a half, but the core idea is still to be a collaborative story telling RPG that feels like a traditional RPG. The latest version of it is called Death of the Vele and the (lame) website is here It has a link to the latest rules. Wow, taking a look at the old rules, I see that I have streamlined the mechanics a LOT since last year. They are simpler, lighter weight, and more intuitive. There are also tools to promote more integrated and structured stories (spotlights, hitting aspects, etc.). Death of the Vele also adds a back story (which you can remove if you don't like, of course). I'm hoping to publish Death of the Vele within the next 12 months. In the mean time, the rules are out there for free, so anyone who wants to can use them. Here is the feature list from the latest copy of the rules: Collaborative, but feels like a traditional RPG Your characters are yours Supports campaign-length stories Game play ...
Read more