stillpointlab

I mean, what seems more efficient: creating massive city sized domes that are self contained and controlling the entire environment to sustain human life, "magically" dispelling our atmosphere and boiling off our oceans, mastering physics to move entire planets. Or launching a rocket to Mars with sufficient supplies? Keep in mind that we already have SpaceX and we'll probably have Starship operational long before 2200 where some of this is meant to go down. And if some AI got to the point of the mastery of physics needed to move a planet out of solar orbit, your objection is that getting to Mars would be hard?

I watched a let's play video recently where someone played your demo. Hope your final release goes well!

I'm working on a platform for context management that includes apps that operate on structured text formats (e.g. YAML, JSON, XML, MD) and provides editors for structured text formats (code editing using codemirror, markdown editing using prosemirror) and eventually all media assets (images, videos, audio).

The idea is you have a set of sources (e.g. Github, Google Docs, local file system), a bunch of transformations (templates, apps, llms/gen-ai, simulations) and sinks (communicated through changesets). The platform is like a cache layer that connects these together and allows for a graph of operations (source->executor->sink->source->executor->etc.) which allows for tracing the lineage of assets through a system.

It's an impossibly large vision made barely possible with agental coding assistance.

Why would the SSE do that to Earth, when there are other close-by planets that it would have the same capability to terraform? I mean, leave us Earth and take Mars or Venus or something.

As an aside, in my own "I'm 14 and this is deep" musings, I was wondering if the massive expansion of data centers is driven by more than just profiteering. I mean, what if the purported persuasion abilities of advanced AI are fully in effect and the psychosis we think industrial magnates are suffering is the result of AI that has already far surpassed our expectations carefully convincing us to build it.

I was investigating Durable Objects (DO) and had Fable walk me through where in my app they might be appropriate. One place had a dependency with billing (where I use a transaction now) and the proposed re-work to allow for concurrent editing with DO looked very much like this, reservations with idempotency keys. And if you add hierarchical allotments then it scales pretty well.

I disagree with the other posters about the bg process, if you have any bg processing already you should be able to handle the few edge cases without too much trouble.

Each game itself is mostly throw-away (although a few have some impressive graphics bling which must have taken some effort). I've been watching a channel called "Idle cub" [1] and he posts a new game every day (well, almost, sometimes he'll play a demo and then later the full game).

Seeing a massive stream of games that all surround the same 12 or so mechanics has been eye opening. The games range in duration from ~2 hours all the way to several days of content, although most premises seem to get old at around 4-6 hours.

At first I was doing research for my own game ideas, now I'm kind of mesmerized by the variety and the general relaxed atmosphere of these idle games.

1. https://www.youtube.com/@idlecub

I've been watching a lot of let's play content on YouTube for incremental games (it's like an ASMR thing) and after watching a lot of these games it is clear that pacing a video game is a challenge. Sometimes the player finds a sneaky way to increase their progress that busts the game, other times they miss the correct path and get stuck in a painful grind. It is also very obvious when the game dev has targeted a play-time metric and forces the game into that metric. Incremental games really expose this dynamic since they are generally pure upgrade mechanic attached to some kind of dopamine generator (flashy lights, rhythmic sounds, etc.)

> We have long had the problem that there are more people who want to write code than people willing to review it.

I think this is an important thing to mull over. The world is going to be a different place for those who wanted to write code but not review it compared to those who are willing to carefully review code.

It seems possible, in fact reasonable, to understand my observation as following from your assumed "correlation". I gave it context that it is having a conversation with an expert, it correlates it's output with the context. A non-expert user can't fake that context so they never see similar correlated output. This context-correlation doesn't happen if one uses "You are a expert ..." prompting "tricks".

My experience has been, if you speak like an expert who is speaking to an expert you get better results. I'm not sure how that is anthropomorphizing. It is just "if I do these things, I get these results".

I agree with this post's gist, and I've certainly noticed how LLMs change their interaction with me once I demonstrate some knowledge. I've often started a technical conversation very vaguely and only once I challenge the LLM on its simplifications does it start to actually get to the meat of issues. Often there is a perceptible moment where the LLM seems to recognize my level of ability and how it communicates clearly changes.

But another thing I have found is that I get significantly better results from the LLM by treating it like an intelligent independent agent. All of the "you are a senior dev ..." or "your starving kids depend on the correctness of this answer ..." kind of prompting has been mostly useless. In general, I find being honest and clear to be the best strategy.

You can't "pretend" to be a senior software engineer. If I can root you out of an interview process then you aren't going to fool the LLM. But if you clearly state your level of expertise and your desired outcome, then the LLM does a very good job of meeting you where you are.

There is also a strange ephemeral attitude I get from agents sometimes, like they don't like to be called out for being wrong. But in the same way that human's show this trait, they also seem to warm up over time as they gain trust. It is almost like social positioning, once they realize they aren't actually expert they morph into a support role stance pretty seamlessly. That is also why they can still feel sycophantic, because once they realize they aren't actually driving the discussion they can actually feel like enthusiastic passengers, wanting to see where the conversation leads as much as the prompter.

Before I officially got into development as a career I had a manual labor job at a local business. They were debugging issues in their operations and brought in a consultant that wrote out workflows using FoxPro [1] a Database Management System (DBMS) that was similar to MS Access. These DBMS systems allowed non-technical people (like the consultant) to create quick and dirty forms-based apps.

I recall at the time (late 90s) these were popular dev platforms for regular folks. People would create fitness apps, time trackers, meal planners, etc. using WISYWIG interfaces and visual schema editors.

Of course, the 2000s, 2010s and 2020s were massive consolidation events with winner-takes-all SaaS eating the world.

My intuition here is that software for one is a temporary thing. Longevity has a quality of it's own, and eventually people just don't want to debug their own stuff. Sooner or later $5/month (or freemium) takes over.

1. https://en.wikipedia.org/wiki/FoxPro

That is a good point and I don't mind getting a bit philosophical when I point out that experience is distinct from rationalism. Underneath this there is an argument about empiricism vs. rationalism (or realism vs. idealism).

The hand-wringing on the 50-50 cases is almost always theoretical, in the sense that I am trying to reason instead of rely on memory/experience. But that is a double edge sword because sometimes memory/experience are closer to trauma and can lead one away from a solution that is correct now in some new environment.

It also reminds me of the phrase "use in anger". You don't really know about an approach/architecture until you've had to deal with something in an urgent or high-stakes moment (your 2am debugging). But to get that experience, you have to have shipped the thing first. It is a chicken-and-egg problem, you can't debug something at 2am unless it is live, and you can't know if it will cause you a problem until you've dealt with it.

AI (LLMs, agents, etc) is this giant alteration to the environment that shakes up everything. In some sense, I feel I have to throw out my taste and "use in anger" all over again. It is painful but may be the only way. And I have to accept the risk that going slowly (like this post suggests) may be the wrong way, and I may watch the young untraumatized new-comers blast by me riding their 100 agent orchestrations to massive success. What I mean here is, in the final scenario from my original comment (7 top guys vs 100 decent guys) - I know the result from experience. But am I just traumatized and it will be different with agents?

It is comforting to find other people experiencing the exact same reality as me, since I see so much in this post that matches my own experience.

It reminds me of all the recent talk about "taste". Architecture "quality" may not be objective in a right/wrong sense, in the same way that fashion isn't right/wrong. It's like we are all going to have to relinquish reason/rationality to the machine and start to study up on aesthetics.

Even historically, my big struggles have usually been deciding between two nearly-equivalent options. I get this a lot now with LLMs because there is no break in-between these decisions that implementation used to force. I feel I'm constantly making "taste" calls between tradeoffs that have no clear objective criteria, and it is as exhausting as the code review this post (and my experience) suggests are still necessary, even with Fable/GPT-5.6 level models.

In many cases, I do what I've done with junior engineers whose code I reviewed pre-agent: make on-the-spot judgement calls. When I see a broken window, I call it out. But when I see minor issues, I sometimes just let it pass, note it in memory and tackle it wholesale once an accumulation of similar minor issues get to a certain size.

As a tangential aside, I consider two dev shops from pre-agent days. One decides to hire 7 extremely talented engineers and gets them to work closely together. The other decides to outsource to 100 decent engineers and tries to silo them into modules. I think we are facing a similar choice with agents. You can either work extremely closely with a handful of agents, collaborating on design, review, etc. Or you can spin up a fleet of sub-agents and YOLO, then try to separate the wheat from the chaff in some automated way. My taste is the former, small highly coordinated shop. But time will tell if I am right or wrong.

I was cleaning my office a couple of days ago and found stacks upon stacks of paper. I've had a habit for over a decade of taking printer paper, folding it half length-wise, and scribbling notes on it as I work. I use it like a temporary scratch pad. It is an ingrained habit at this point, as soon as I have difficult focused work to do I reach for the paper and pen. Urgent site-wide outage? Start scribbling. Big feature decomposition? Start scribbling.

So I have this massive stack of notes that I glimpse at before shredding or whatever. Nothing of permanent value, nothing that I look at even 24 hours after it is written. But the sheer volume of the writing like that I do surprises me ever time I clean it out. It's like a novella sized stack of paper with server names, sketchy diagrams, peoples names, dates, commit hashes, debug messages. Lots and lots of lists. Things underlined, circled, stars, strike through, arrows, etc.

It is such an ingrained habit that its almost a compulsion, like someone is tying my hand behind my back if I don't have access. It is like my brain needs reassurance that some detail I just noticed won't be lost, at least it will be on the paper if I need it in the next 5 minutes. Like an extension of my short-term memory.

I have also kept a journal for 20+ years, mostly on paper. I often use a fountain pen (Lamy 2000) and notebooks with high-quality paper, but I am not super picky about it. I've used the cheapest school notebooks to the finest Japanese boutique papers. I'm a fan of the Pilot G2 and pens that have a similar feel. I'll also journal in Google Docs, Apple notes, or text docs in VS Code.

It is hard for me to disentangle the supposed benefits from the sheer weight of habit. It is just something I do, part of who I am.

Today it is SQLite, tomorrow Linux?

I'm not sure of the long-term viability of these brute force swarm approaches, but clearly the AI companies dig the marketing they get out of it. But the fact that they get so far at this stage suggests we have a very interesting 2 years coming up.

> but soon models may not need to be updated

Which is why my original post mentioned the volatility in models. We aren't just doing research on frontier, there is a huge amount of research on quantization, distillation, etc. that is changing the landscape at the low-end almost as much as it is changing on the frontier.

And it is also why I mention revealed preference. What feels sufficient / "good enough" today is a moving target. This isn't just a question of what you want, it is a question of what is economically viable for the entity that will be designing, manufacturing and marketing this ASIC of which you speak.

I think part of this thinking is in reverse. What I mean by that is people are saying something like "Imagine if 18 months ago a company started to create an ASIC based on GPT-4o (or whatever was good at the time). By today they'd have a model that is not great by today's standard but good enough".

Maybe, but what is the shelf-life of that 18 month decision? Barely good enough today, when it launches, starts to get worse and worse every month going forward. You have to recuperate that investment on your depreciating asset.

And you are competing against anyone with the foresight to use a TPU instead, and the benefit from any new paper that finds how to distill, quantize or whatever better so their solution gets algorithmic boosts while you are locked in.

I think there is growing confusion in this discussion. I am saying "I see the fixed nature of ASICs creating a barrier to their adoption despite how cheap they are".

Many of the responses seem to say "but there is a market for cheap models".

There is a world where we have cheap models and we don't have ASICs powering them. Things like TPUs and NPUs, which are programmable, are likely to fill that role. They are optimized for inference while also allowing different (and updated) models to run on them.

Given two companies competing on the cheap end. First company goes TPU, second goes ASIC: who wins? My bet is on TPU since they can update their model, even if their hardware is slightly more expensive and slightly slower, since the optionality of new models beats the performance gap. That may not hold forever but given the pace and volatility of the current LLM market, I believe it will hold for some time.

Yes, but the context of the discussion is "who wins the war and how". And you are moving the goal posts very far from the original claim, which is that the speed with which companies can get their models onto ASICs will be the determining factor.

I admit I would like a faster model - but even though I have faster models available I still go to Fable or GPT-5.6 90% of the time. So there is a gap between a potential preference and a revealed preference.

Custom AI for things like facial recognition in cameras has existed for decades, before LLMs were a thing. I don't see that getting replaced. And on-device conversational intelligence might go that route as well, we'll have to wait and see. It's a lot of silicon to dedicated to a static non-changing thing. My money would be on programmable TPU-like things (Apple's NPU kind of stuff). It just seems more flexible to have an array of compute that you can load different models into, so you can update it, etc.

I mean, if I imagine Anthropic giving away unlimited Sonnet 4.5 away at $20, I would still be paying the $200 for fable.

It is a bit like saying "why would you hire someone with a doctorate when you could get unlimited high school grads". How appealing that sounds depends on your needs.

I'm not convinced, mostly because things like crypto, which I believe went into ASICs, were based on very slowly moving and mostly understood algorithms. LLMs and model architectures seems significantly more volatile. I wouldn't want to be working out the finer details of my chip rollout only to find a new paper/approach that give multiples of performance.

So I guess it depends on how much the latest-greatest model motivates people, and my read on the current churn is that developers are extremely unloyal to brand at this point and will jump to whoever has the best model. And as long as the best model is running on programmable GPUs, that will be the dominant form.

It may be a lot of cool things but one thing it is not is a web browser.

I can't try it since it hasn't appeared in my Codex yet, but this is is necessary from OpenAI in my opinion. Fable is just so much better at understanding broad context. I only use GPT 5.5 for straight forward easy to describe tasks, and it does crush those. But I spend a lot more time steering Codex towards good design on broad concept type tasks, ones that Fable shows sometimes surprising clarity.

I look forward to seeing how it compares once I have access. Not getting tripped by spurious safe guard flags could be an advantage.

> Avoid generic brevity instructions: GPT-5.6 is more sensitive than GPT-5.5 to instructions such as “Be concise,” “Keep it short,” or “Use minimal text.”

I used to go to a barber and if you said "cut it short", he cut it really short.

I've just been carefully reading the code. It is easy to slip into just accepting what comes out to speed things up, but reading the code is important.

I save myself by skimming things like tests, templates, some UI. Anything cosmetic. But I have to read the majority of code that ends up on my back end systems.

I've had mixed results with downgrading on Fable. I was able to do a complete audit of my OAuth implementation without any issue. But when I asked for an OWASP top-ten review of my code base it got through 5 of 6 tasks and tripped in the final summary, which Opus had to finish.

I had one completely random trip when I was investigating some normal code. As far as I can tell a sub-agent ended up reading a file that tripped Fable during a review, but the whole feature was nowhere near anything secure so I don't know what could have caused it.

I also got completely locked out of Fable when working on parts of a subscription system (stripe subs).

But my experience isn't as bad as some peoples. The above maybe covers 15% of my attempted use cases. For the remaining 85% it has chugged along fine, sometimes in code I assumed would trigger it. It really feels random to me when it actually flags.

I'm pointing out how I noticed a particular emotional response when working with LLMs.

I've been an engineering manager in the past and I have tried my best to keep the needs of my team in mind when I am delegating work. I try to consider the person, their goals, motivations, preferences, frustrations. I consider before interrupting them if the minor issue I am bringing up is worth the distraction it might cause them, since switching tasks is a mental load.

But with LLMs, almost none of that matters. They don't have goals, motivations or preferences in the same way people do. I can interrupt it all day and it won't get frustrated or lose motivation.

I think anxiety is a harsher word than I mean, but it is close to the feeling I have when I'm about to deliver bad news to someone. When I'm about to say "you know all that work I asked you to do, I need you to throw it away and restart". And I model in my mind the frustration and demotivation this can cause a person. And then I feel anxious about causing them this frustration.

I have to train myself out of that when instructing LLMs. It doesn't mean I have to avoid moments of joy or appreciation. It means I have to understand LLMs have different needs than people, and I have to work towards those needs.

I feel on the other side of this. Just yesterday I was reviewing some code output from Claude and I realized a change that I had asked for in a previous review step wasn't what I wanted. I had a moment of social anxiety, like I didn't want to bother a coworker with my indecision. But I have to remember, the LLM doesn't care. It doesn't have an ego. It doesn't get annoyed at being asked to redo work.

I still say "please" and "thank you" frequently, but I'm starting to embrace the fact that the LLM doesn't care about grunt work, doesn't care about rework, doesn't care about nitpicking, doesn't have a preference in general. It needs very little more than for me to be completely clear in my instructions.

I agree, but that is the crux of my initial post. There is a ceiling to how quick I can deliver using LLM coding agents which is the speed at which I can write good enough specs.

I feel I'm at the point now where the time the LLM takes to deliver a feature, no matter how big, is nearly inconsequential. Because while it is in the process of delivering the feature, I am writing the next spec, and by the time I finish the spec the agent is waiting for the next feature. And at that point I have to review it's code, give it feedback, review it's fixes, merge, etc. All of the "waiting" is on me. It is basically delivering features as fast as I can write specs and could only get faster if I write specs faster.