tunesmith

I'm always going to be furious at Apple about ceasing large-housing (flat-head) earbuds. My ear canals just don't take in-ear airpods, and there's nothing to be done about it. I've tried everything. What does work is large-housing buds with earclick technology, so they sit against the canal with a decent seal. I used to be able to have mobile ear listening in a way that integrated with apple tech, but there's nothing like airpods that do that anymore. It's just in-ear or big bulky on-ear or over-ear stuff. It's infuriating.

Let's say that tomorrow, due to an improved model or whatever, we realize that the most efficient form of code of an app - for an llm to understand and work with - is for it to be in one long spaghetti file.

Why wouldn't we do that? I think there's a point where this comes down to values instead of facts. If you want it to be human readable, that's fine and there are a bunch of therefores from that point. But if you don't necessarily want that for a particular codebase, why refactor if the LLMs can handle it?

For me, codex $100 mo/plan and a claude teams account at work (mostly sonnet, some opus), Claude basically feels about as effective as Codex did 4-5 months ago pre-5.6. Claude still has weird patterns of being confident in one answer while another chat with the same model is confident in another answer, where one answer is clearly wrong. Missed details, over-engineering in places, while still overall helpful and effective. Codex, however, just feels freaking rock solid on Sol high. I literally have zero complaints.

On the bet that layoffs will result in programmers ending up at 40% of the staffing level they are now, I will take the over.

Generally speaking, the pattern is that people are overestimating how much "work replacement" will happen, and underestimating how much "work shifting" will happen.

What is fascinating is how you can witness it at so many levels of organization. One example: Employer executive get enamored with moving from labor to capital. They believe that by using LLMs, they can replace a lot of workers. At my place of employment, we have people that are surprised they can't file a Jira ticket describing a product ask, and have it kick off an implementation. You can build the skill to attempt that, but invariably you'll get back questions like "what do you mean by <x>" and "what do you want to do in this case, a, b, or c?"; questions that a product person or an exec are not well suited to answer.

In the past, programmers did that kind of interpretation and judgment call. So then you're in a quandary; who should do that work? Work that previously, you never imagined was an inherent part of what the replaceable code monkeys do at your beck and call?

And then, how do you hire for that? How do you find the training for the people that are experienced enough with... something... to know what a cohesive error response is, or what kind of telemetry strategy is best for that particular product and organization, what collection of product asks are incredibly complicated for what they're asking and can deliver 95% of the benefits at 5% of the work if we just do this instead, and whether you want to aim more towards thick or thin clients?

Who are those people? Wait, those are programmers? Wait, there's this whole collection of inherently human skills that we devalued, by not appreciating they were always quietly doing that for us in the past?

That's just one example. There's a repeating pattern of discovering where the work truly is, work that was embedded in manual patterns we might not have to involve ourselves with anymore, but is yet still essential. So the nature of our jobs changes massively, but the overall level of employment does not.

At least, not in the medium to long term. There is a lot of painful churn we have to suffer through first.

All of our developers are now using agents. We're not hand-writing code at all anymore. And yet, some of our developers deliver stories in an hour, others deliver similar complexity stories in a week. Executives are surprised to discover they cannot simply turn over a product-authored jira story and have it yield a single agent-written PR. There is still significant work that happens between the point at which a story is written, and the point at which correct prompts are input that generate the code that fits the requirements. Very significant work. I think that when people say "code was never the hard part", they're only guilty of eliding the point that "code was never the only part" or "the hardest part", and that there's so much other stuff that programmers do at various levels of competency, and that... perhaps up to now it was easy for product folks and execs gloss over since they just put us all in one bucket of "people that write code".

"talking about your mental health" does not mean re-parroting your trauma. there's understanding, re-framing, forgiving, all kind of other things that go beyond the limited belief that talking just calcifies trauma.

and if you have a lot of bet opportunities.

Honestly I'd like to run it on a novel I've written and haven't released yet. I've been having conversations with Codex about how to write a story "compiler" that tracks static "states" of each character and then how plot events change those states, but haven't started anything yet.

I like the idea of using something like this as a writing aid, as if to "compile" a story to shake out what contradictions or open plot lines or implications are yet to resolve.

I use it for lilypond for notation. I always considered it superior to Finale and Sibelius anyway. Not sure how it stacks up against the more modern commercial notation apps. But I love having a real trackable version history of my pieces.

What's also cool is the more advanced llms know lilypond and music theory too, so they can do things like... I don't know, check for counterpoint errors. I've used it with limited success to expand my jazz lead sheets into two-hand piano arrangements just for practice exercises.

I just had Sol Ultra read the proof and create a graph of it using Concludia (my side project) so you can explore it visually/graphically. I certainly don't understand it though so I have no idea if it's helpful. :)

https://concludia.org/graph/g_2ecb8083-52ec-3448-8c30-2f9bc7...

I think it doesn't prove much that it hasn't happened yet. Companies might just be moving slower than you think, and are still planning on doing it. And, in many corners, "don't manually write code" is being joined by "don't manually read code" as an attractive principle.

How do you mean OpenAI lets you use your own harness? I'm under the impression that a custom harness requires the OpenAI SDK, which requires api tokens rather than plus/pro accounts.

Wow, didn't know this existed until today. Thanks!

It's interesting to think about how difficult it is to define "fair" with the current system. If a state's population is 60/40 and there are ten districts, do you want them each to be representative at 60/40, and thus 10-0? Or do you want six districts one way and four the other way? In other words, there's a real tension between "competitive districts" and "representative outcomes".

I experience the same with OpenAI, on the $100/month plan. GPT-5.4 is something I still have to challenge: it can bullshit me with bad implementation and add a lot of cruft that costs more time later. GPT-5.5-xhigh is something I have almost complete faith and trust in, it's just smooth. And yet I know the actual token cost of that fully utilized is exorbitant, like as much as an entire salary for a senior developer.

So maybe our CEOs are responding with a lot of foresight and inside information and know that that level of quality is going to be cheap really soon. But barring that, they're going to experience either sticker shock or a slowdown.

I think the real endgame is probably more accurate "models of models" (model routers) that know exactly how to split prompts between expensive frontier and cheap/free local models.

I'm building a website that allows friends to write branching fiction novels together, and another website that allows people to argue and conclude together using first-principles thinking. I've abandoned a project that allows people to register percentage certainty of sports outcomes to improve their calibration - it wasn't fun enough for the users. A few other things besides. I recently wrote a gpl TUI to edit dags here: https://github.com/tunesmith/dagim - that one as something of an experiment since it's in a language I don't know, that one took 3-4 days of steady prompting.

I feel like I must have plateued and don't know what to do next to level up. I'm currently on the $100/month codex plan and it seems fine using 5.5-xhigh all the time. I think of what to do next, have a chat session to determine exactly what to ask for up to the point of being ready to implement, and then codex churns on a commit-sized task whereupon I briefly check it on my local dev server. If necessary I ask for a change. Then I ask it to commit and recommend the next step based off the spec. Oftentimes I have to "approve" an out-of-sandbox request anyway.

I haven't found anything that requires running all night. I could tell it to one-shot a big plan but given how often I realize I want an intermediary thing to be slightly different it seems like a waste of effort.

I'm guessing the next thing I should probably look into is some sort of machine vm I can tunnel my codex-gui requests to so I don't have to deal with the sandbox approvals (I don't want to give it "dangerous" access to my entire mac).

I don't understand what people are doing with their side projects that is leading them to churn through tokens so quickly, to the point of requiring two $200/month subscriptions and a bunch of token charges besides.

I went through the dotcom crisis and never heard of GFC until today. I've always seen it as the finsys crash.

compared to almond farms? You phrase that as if almond farms use a reasonable amount of water.

as opposed to what, though? You don't get a 3% discount for using cash.

It was the "honest" stuff that hit my radar, but maybe Claude is just ruining that word for "honest" usage.

That's not what OP was saying, they were saying they experienced multiple instances of LLM handling some tricky problem. But just because it can solve Tuesday's problem doesn't mean it can solve Thursday's.

And this:

>the number of people in that role can be reduced in proportion to the amount of work automated.

Components of humans are not fungible. If one fifth of my job is easier but the other 4/5ths require my specialized human judgment, you can't remove one person out of five and pretend everything will be okay. That's what I mean by the two-step; you just did it yourself.

> How do you determine that this will incorrectly lead to a reduction in the workforce?

This gets back into Theory of Constraints. Identify the constraint. Alleviate the constraint, not the symptom. If you're in a factory, and transmogrifiers are building so many widgets that your whatchamaflorpits starts falling behind, you don't scuttle 20% of your transmogrifiers, you buy more watchamaflorpits!

Instead people are like, "oh gosh, my developers are idle, guess we have to lay them off."

In practice, it's more like companies want to spend money on AI because they believe it will save money somewhere else. If instead they see extra cost, then they get all confused. They can't bring themselves to believe that in their particular case maybe the benefit isn't worth the cost; they're axiomatically conditioned to believe they have to keep using it, and so therefore they have to make cuts somewhere else. It's insane.

I went through this personally. I had a glut of project ideas I wanted to get through. I signed up for the $200/month thing. I caught up. My agent sat idle. It was hard to decide to cut my plan. I felt initial pressure to search and hunt for other ideas to code, ideas that were pretty stupid. I finally downscaled my plan; I got hold of myself. But that's easier to do for an individual than it is for a company.

In normal economic theory it's easier to understand. You're at a particular scale. You have the opportunity to automate, but does it make sense for you? I could go out and buy a riding mower right now, but my lawn is less than a quarter acre. The riding mower lets me scale up, but I don't have something that can benefit from it.

I think there's something else psychological going on. What you describe is a rational approach based off of bad values. But I think I'm also seeing something weirdly irrational.

It's like an (emotional) depression or something. Scarcity thinking, the inability to think expansively. People are so sure that everything around them is shrinking that they feel an instinct to hunker down, shrink, and cut as well. Like it doesn't occur to them that they don't have to feel that way. The execs I work with, none of them strike me as spreadsheet-driven greedy people. They seem more freaked out than that.

> I've had multiple instances now where AI left to it's own devices has solved a tricky problem that I honestly didn't think it was capable of.

Who cares that you've had multiple instances? Everyone has had multiple instances. The question is whether that happens in EVERY instance. Because when someone's laid off, that's what the exec believes, that the person isn't needed at all.

I'm not arguing that AI won't replace jobs - it's clear that jobs are already disappearing "because of AI". I'm not even arguing that it is immoral (even though it is). I'm arguing that it is short-sighted and unwise.

Unfortunately it will take longer for our bosses to walk it back. I feel like I'm fighting the battle daily, telling execs what kind of work LLMs do not replace... it's very slippery, they keep on doing the rhetorical texas two-step - I don't think they even realize they're doing it. We communicate that LLM is amplifying, they hear it can replace. "No, we need humans to help with specs" "But AI can help with that." "But only help, they can't come up with the idea." "Sure they can, we can just ask them."

It's also amazing how hidden some of these realities were before. Like, you assign a ticket to a developer - in the past they just wanted to know the developer was working on it and didn't care so much which work was what. They'd probably be so surprised to find out that a large percentage of implementation was deriving exactly what was meant by the jira ticket or the specification or the product person's intent. Which is all the stuff you have to work on before you can type in a prompt to an LLM. But now there's this pressure to believe that the developers only do the implementation part that the LLMs do, so they can pretend there will be major efficiency improvements. And it's really hard to explain to them what it is that developers even do.

I know I'm not saying anything new here, but at least where I'm working all of these matters feel much more present than they did months ago.

There should be class action lawsuits just from widespread recognition of corporate wrongdoing.

I think there's a way to define it without it either side feeling personally attacked. One of the things I like about using agents for programming is that if the spec is detailed enough, I can implement it in a number of different languages and still get the thing I intended. That means that the "art" is in the spec, not the implementation.

I think the question with AI in music is when it gets to that point. What's the musical spec? What's the implementation? If the spec is supposed to be the pure distillation of my intent, then shouldn't that mean each time I engage AI to "implement" the spec, the musical output of the AI should be the same?

At that point I'm all in favor of using AI for music. But when AI is used to replace a specific intent with vague intent, that's where I feel like something is lost in the human experience of human-created music.