tunesmith

I think someone "writing like ai" is not really the same thing as the flaws we see from ai. "Writing like ai" might mean we adopt certain conventions in how we communicate or frame ideas, but the ai flaws are more along the lines of weasel words or bullshittery; avoiding incisive ideas in favor of fluffiness, or in favor of pithy-sounding phrases that communicate nothing. That's a problem that humans have had long before AI.

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 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.