stillpointlab

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.

It does, but I have to direct it and review it. That means I have to think about it, research it, consider how the new feature or system fits in with the existing feature or system. I have to make decisions on libraries/dependencies. I have to consider how the project will evolve in the next week, month, quarter. I communicate all of that to Claude in an interactive planning session and it outputs a detailed spec, ready for implementation.

All of that thinking, planning, rewriting, etc. takes almost as long as it takes Claude to actually deliver the feature. The big features Claude writes take ~30-45min of uninterrupted coding to deliver (I just checked the last feature was 39m 41s for +1,610/-26). To write that same code would have taken me probably 2 days.

One thesis I am developing is that LLMs have given us a new kind of tradeoff. We can use the intelligence and tremendous speed up that mechanically pumping out basic CRUD code has given and we can either deliver more features or deliver higher quality.

What that means to me is that there is a balance. My belief is that we have to take some of the new power and put it towards quality rather than spend it all on speed.

Yes, I review every PR (which is part of the bottleneck) and give strict feedback (as I mentioned, averaging 2 to 3 fixes per task).

What I'm saying is that there are some higher-level loops (as described in this article) that are outside of the bottlenecks I mentioned (spec creation and PR review).

For example, I may have 3 written and ready to go specs that are totally unrelated (don't touch the same files, each can go to PR stage with no conflict) but it isn't easy to keep the agent moving on them unless I do so manually. Having an outer-layer orchestrator that can move that along makes a lot of sense.

But when there are dependencies between tasks, it has to wait for my PR. And once I run out of good specs, it has to wait for me to write them.

My experience is that I am bottle-necked on specs. The agent loop is less of a thing for me now.

If I can get a clear understanding of what I want to build, communicate that to Claude Code in planning mode with the goal to write an actionable spec (not code, plan to write the spec) then I tend to get very good results once the agent goes to implement.

But this strategy, while effective, puts a big load on me to write the specs. The agent tends to knock each one out of the park (usually 2 to 3 follow ups based on code review) but then I'm back at the stage that requires the spec.

Another issue for me is that when I step away, if the agent finishes a task and could technically start on an existing spec (no overlap on files so no conflict possible) it doesn't know it can just create a new branch and start. Before I go to bed I'll often say "do task X and once done and pushed start on task Y". But I haven't had luck beyond that. Often I find that it starts on Y and has a question and then the agent is idle the rest of the time.

The final issue is dependency coupled with the above. For example, today I was writing a background job processor. Obviously, the jobs that are in subsequent tasks require the system. That happens with some frequency. Even the specs need to be refreshed after the implementation to take any details that were resolved at coding time into account.

But I am just on the cusp of wanting the outer loop. The gate is almost entirely on spec creation and PR review. In places where those gates don't matter, I want the agent to keep chugging away.

As an aside, I strongly believe we need to start using tools that are better for LLMs even if they are worse for us. For example, Rust is annoying because the compiler is so strict. Bad for me, great for LLMs.

I came across the following yesterday: "The Great Way is not difficult for those who have no preferences," a famous Zen teaching from the Hsin Hsin Ming by Sengstan

As we move from tailors to big box stores I think we have to get used to getting what we get, rather than feeling we can nitpick every single detail.

I'd also be more interested in how his 3rd, 4th or 5th vibe coded app goes.

One thing that comes to mind, more of a first reaction than a considered opinion, is the complexity of V8 getting in the way. JavaScript and Typescript present a challenge to language implementors.

There is something to be said about giving AIs a clean foundation on which to build their own language. This allows evolution of such systems to go all the way into the compiler, beyond tooling.

I'm old, so I remember when Skyrim came out. At the time, people were howling about how "dumbed down" the RPG had become compared to previous versions. They had simplified so many systems. Seemed to work out for them overall.

I understand the article writers frustration. He liked a thing about a product he uses and they changed the product. He is feeling angry and he is expressing that anger and others are sharing in that.

And I'm part of another group of people. I would notice the files being searched without too much interest. Since I pay a monthly rate, I don't care about optimizing tokens. I only care about the quality of the final output.

I think the larger issue is that programmers are feeling like we are losing control. At first we're like, I'll let it auto-complete but no more. Then it was, I'll let it scaffold a project but not more. Each step we are ceding ground. It is strange to watch someone finally break on "They removed the names of the files the agent was operating on". Of all of the lost points of control this one seems so trivial. But every camels back has a breaking point and we can't judge the straw that does it.

> We all know that the industry has taken a step back in terms of code quality by at least a decade. Hardly anyone tests anymore.

I see pseudo-scientific claims from both sides of this debate but this is a bit too far for me personally. "We all know" sounds like Eternal September [1] kind of reasoning. I've been in the industry about as long as the article author and I think he might be looking with rose-tinted glasses on the past. Every aging generation looks down at the new cohort as if they didn't go through the same growing pains.

But in defense of this polemic, and laying out my cards as an AI maximalist and massive proponent of AI coding, I've been wondering the same. I see articles all the time about people writing this and that software using these new tools and it so often is the case they never actually share what they built. I mean, I can understand if someone is heads-down cranking out amazing software using 10 Claude Code instances and raking in that cash. But not even to see one open source project that embraces this and demonstrates it is a bit suspicious.

I mean, where is: "I rewrote Redis from scratch using Claude Code and here is the repo"?

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

I want to consider the higher-level claims in the article. In between the historical context helpfully provided by the article there is also some speculation about Merkaba, Platonic solids, Flower of Life and other sacred geometry.

There is a premise hidden in those speculations that there is some strong connection between the structure of the universe itself and the structures humans find pleasing when listening to music. And I detect a suggestion that studying the output of our most genius musicians might reveal some kind of hidden information about the universe, specifically related to some kind of "spirituality".

This was a sentiment shared, in some sense, by the deists of the enlightenment. They rejected the scriptures and instead believed that studying the physical universe might reveal the "mind of God".

If we are looking for correspondences between these things - why limit ourselves to Euclidean geometry? Modern physics leans on Riemannian geometry, symmetry, and topology. It appears the topology of the universe, under a wide array of experiments, is way more complicated than the old geometric ideas. Most physicists talk about Lie Groups, fiber bundles, etc.

If you take "as above, so below" seriously and you want to find connections between cosmology and music, I believe you have to use modern mathematical tools. I think we need to expand beyond geometry and embrace topology. Can we think of the chromatic scale tones as a Group? What operators would we need? etc.

It's interesting to try to get into the head of a guy like Coltrane and his mathematical approach, but perhaps we could be pushing new boundaries based on new understanding.

According to the spec, yes a grammar checker would be subject to disclosure:

> ai-modified Indicates AI was used to assist with or modify content primarily created by humans. The source material was not AI-generated. Examples include AI-based grammar checking, style suggestions, or generating highlights or summaries of human-written text.

My experience is: AI written prompts are overly long and overly specific. I prefer to write the instructions myself and then direct the LLM to ask clarifying questions or provide an implementation plan. Depending on the size of change I go 1-3 rounds of clarifications until Claude indicates it is ready and provides a plan that I can review.

I do this in a task_descrtiption.md file and I include the clarifications in its own section (the files follow a task.template.md format).

I'm still calibrating myself on the size of task that I can get Claude Code to do before I have to intervene.

I call this problem the "goldilocks" problem. The task has to be large enough that it outweighs the time necessary to write out a sufficiently detailed specification AND to review and fix the output. It has to be small enough that Claude doesn't get overwhelmed.

The issue with this is, writing a "sufficiently detailed specification" is task dependent. Sometimes a single sentence is enough, other times a paragraph or two, sometimes a couple of pages is necessary. And the "review and fix" phase again is totally dependent and completely unknown. I can usually estimate the spec time but the review and fix phase is a dice roll dependent on the output of the agent.

And the "overwhelming" metric is again not clear. Sometimes Claude Code can crush significant tasks in one shot. Other times it can get stuck or lost. I haven't fully developed an intuition for this yet, how to differentiate these.

What I can say, this is an entirely new skill. It isn't like architecting large systems for human development. It isn't like programming. It is its own thing.

I think ghostty is a popular enough project that it attracts a lot of attention, and that means it certainly attracts a larger than normal amount of interlopers. There are all kinds of bothersome people in this world, but some of the most bothersome you will find are well meaning people who are trying to be helpful.

I would guess that many (if not most) of the people attempting to contribute AI generated code are legitimately trying to help.

People who are genuinely trying to be helpful can often become deeply offended if you reject their help, especially if you admonish them. They will feel like the reprimand is unwarranted, considering the public shaming to be an injury to their reputation and pride. This is most especially the case when they feel they have followed the rules.

For this reason, if one is to accept help, the rules must be clearly laid out from the beginning. If the ghostty team wants to call out "slop", then it must make it clear that contributing "slop" may result in a reprimand. Then the bothersome want-to-be helpful contributors cannot claim injury.

This appears to me to be good governance.

One thing I've noticed with all the LLMs that I use (Gemini, GPT, Claude) is a ubiquitous: "You aren't just doing <X> you are doing <Y>"

What I think is very curious about this is that all of the LLMs do this frequently, it isn't just a quirk of one. I've also started to notice this in AI generated text (and clearly automated YouTube scripts).

It's one of those things that once you see it, you can't un-see it.

I agree with you and I have seen this take a few times now in articles on HN, which amounts to the classic: "We've tried nothing and we're all out of ideas" Simpson's joke.

I read these articles and I feel like I am taking crazy pills sometimes. The person, enticed by the hype, makes a transparently half-hearted effort for just long enough to confirm their blatantly obvious bias. They then act like the now have ultimate authority on the subject to proclaim their pre-conceived notions were definitely true beyond any doubt.

Not all problems yield well to LLM coding agents. Not all people will be able or willing to use them effectively.

But I guess "I gave it a try and it is not for me" is a much less interesting article compared to "I gave it a try and I have proved it is as terrible as you fear".

The amount I have to say on this topic would be inappropriate for a Hacker News comment. But some brief and unstructured thoughts I can offer.

For collaboration I believe that _lineage_ is important. Not just a one-shot output artifact but a series of outputs connected in some kind of connected graph. It is the difference between a single intervention/change vs. a _process_. This provides a record which can act as an audit trail. In this "lineage" as I would call it, there are conversations with LLMs (prompts + context) and there are outputs.

Let's imagine the original topic, audio, with the understanding that the abstract idea could apply to anything (including mental health). I have a conversation with an LLM about some melodic ideas and the output is a score. I take the score and add it as context to a new conversation with an LLM and the output is a demo. I take the demo and the score then add it to a new conversation with an LLM and the output is a rhythm section. etc.

What we are describing here is an evolving _process_ of collaboration. We change our view from "I did this one thing, here is the result" to "I am _doing_ this set of things over time".

The output of that "doing" is literally a graph. You have multiple inputs to each node (conversation/context) which can be traced back to initial "seed" elements.

From a collaborative perspective, each node in this graph is somewhat independent. One person can create the score. Another person can take the score and create a demo. etc.

I have seriously considered going to the local court and just watching. I did it once as a kid, and we went to city hall a few times too.

I asked it to create a story that described the modes of the major scale with a cartoon treble clef as the main character.

It created a 10 page story that stuck to the topic and was overall coherent. The main character changed color and style on every page, so no consistency there. The overall page layouts and animation style were reasonably consistent.

The metaphor it used was the character climbing a mountain and encountering other characters that represented each mode. Each supporting character was reasonably unique, although note motif was present on 3 or 4. The mountain also changed significantly and the character was frequently back at the bottom. However, in the end, he does reach the summit.

I can't say I am overly impressed but it does mostly do what they claim.

One analogy I have been thinking about lately is GPUs. You might say "The amount of time it takes me to fill memory with the data I want, copy from RAM to the GPU, let the GPU do it's thing, then copy it back to RAM, I might as well have just done the task on the CPU!"

I hope when I state it that way you start to realize the error in your thinking process. You don't send trivial tasks to the GPU because the overhead is too high.

You have to experiment and gain experience with agent coding. Just imagine that there are tasks where the overhead of explaining what to do and reviewing the output are dwarfed by the actual implementation. You have to calibrate yourself so you can recognize those tasks and offload them to the agent.

I haven't used the virtual drummer feature of GarageBand recently, but my experience with it was pretty disappointing. The output sounds very midi or like the most basic loops.

I believe there is massive room for improvement over what is currently available.

However, my larger point isn't "I want to do this one particular thing" and rather: I wish the music model companies would divert some attention away from "prompt a complete song in one shot" and towards "provide tools to iteratively improve songs in collaboration with a musician/producer".

> I don't buy argument from people who are saying they are excited to live in this age

What argument is required for excitement? Excitement is a feeling not a rational act. It comes from optimism and imagination. There is no argument for optimism. There is often little reason in imagination.

> How to even find the value in living given all of that?

You might have heard of the Bhagavad Gita, a 2000+ year old spiritual text. It details a conversation between a warrior prince and a manifestation of God. The warrior prince is facing a very difficult battle and he is having doubts justifying any action in the face of the decisions he has to make. He is begging this manifestation of God to give him good reasons to act, good reasons not just to throw his weapons down, give away all his possessions and sit in a cave somewhere.

There are no definite answers in the text, just meditations on the question. Why should we act when the result is ultimately pointless, we will all die, people will forget you, situations will be resolved with or without you, etc.

This isn't some new question that LLMs are forcing us to confront. LLMs are just providing us a new reason to ask the same age-old questions we have been facing for as long as writing has existed.

I really hope we move on from these boil-the-ocean models. I want something more collaborative and even iterative.

I was having a conversation with a former bandmate. He was talking about a bunch of songs he is working on. He can play guitar, a bit of bass and can sing. That leaves drums. He wants a model where he can upload a demo and it either returns a stem for a drum track or just combines his demo with some drums.

Right now these models are more like slot machines than tools. If you have the money and the time/patience, perhaps you can do something with it. But I am looking forward to when we start getting collaborative, interactive and iterative models.

Also https://cookbook.openai.com/articles/openai-harmony is referenced 3 times in the README but it is 404

I hade a comment section on a blog in the early 2000s. It was a spam nightmare. Never again. I would not have one even with the products that claim to handle that spam for you.

As for the "I thought about this problem for 10s let me tell you all the things wrong with it" - yeah. Engineers do that. I'm constantly pointing it out in relation to LLM coding agents.

Lately I've been stuck in YouTube court cases recommendations. There are live trials and many archives for all sorts of real court cases at every stage. I have grown an appreciation for what a judge does. A judge listens and makes sure all information has been provided before making a judgement/ruling/order. The patience those folks show is significant. I can only imagine how tiring that amount of active listening must be. I have found it personally inspiring and educational.

I'm usually the one defending AIs in the comments, but this article hits home for me. I find myself zoning out when I read long tracts written by AI. I absolutely hate filler and many LLMs just fill up space with text.

In my own usage, that has meant that even when I use LLMs to help with prose, I write the text and use the LLM to review and provide feedback. In some cases I will copy a sentence if the LLM version is better but generally I just ask for opinions. I explicitly request the AI _not_ to write. When it re-writes entire paragraphs of my prose I actually experience a deep cringe feeling.

I think this is a strawman argument that is conflating uses for AI. I posted a video not long ago where Andrew Ng makes the claim to the AI Startup school that in testing they are seeing ~10x improvement for greenfield prototypes and 30%-50% improvement in existing production code bases.

So two groups are talking past one another. Someone has a completely new idea, starts with nothing and vibe codes a barely working MVP. They claim they were able to go from 0 to MVP ~10x faster than if they had written the code themselves.

Then some seasoned programmer hears that claim, scoffs and takes the agent into a legacy code base. They run `/init` and make 0 changes to the auto-generated CLAUDE.md. They add no additional context files or rules about the project. They ask completely unstructured questions and prompt the first thing that comes into their minds. After 1 or 2 days of getting terrible results they don't change their usage or try to find a better way, they instead write a long blog post claiming AI hype is unfounded.

What they ignore is that even the maximalists are stating: 30%-50% improvement on legacy code bases. And that is if you use the tool well.

This author gets terrible results and then says: "Dark warnings that if I didn't start using AI now I'd be hopelessly behind proved unfounded. Using AI to code is not hard to learn." How sure is the author that they actually learned to use it? "A competent engineer will figure this stuff out in less than a week of moderate AI usage." One of the most interesting things about learning are those things that are easy to learn and hard to master. You can teach a child chess, it is easy to learn but it is hard to master.

Mailing list is on the roadmap but doesn't exist just yet.

What you could do: sign in using one of the OAuth methods, go to the user page and then go to the feedback section. Let me know in a message your email and I'll ping you once the blog is setup.

Sorry it is primitive at this stage but I'm prioritizing MVP before marketing.

I'm currently in build mode. In some sense, my project is the most over complicated blog engine in the history of personal blog engines. I'm literally working on integrating a markdown editor to the project.

Once I have the MVP working, I will be working on publishing as a means to dogfood the tool. So, check back soon!