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?
I'd argue the things that make a codebase more human-readable is also what makes it more agent-readable though. Agents are trained on human data, after all.
The position in the article is reasonable because what would end up happening otherwise is:
- Agents increase complexity, humans can't read it anymore
- Agent unable to keep making updates without looping forever (the complexity of the code exceeds the agent's context length). Human doesn't understand either so can't fix.
This isn't hypothetical either, it's basically what ends up happening to most vibe-coded software if the person doing the vibe coding doesn't know how to review the outputs being produced.
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.
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.
I agree with you in the broad strokes, but replacement by LLMs isn't the only way the level of employment can be reduced. If LLMs can make it so that two programmers can do the work that used to require five, that can result in a very large reduction in employment, even while having (some) programmers is still essential.
What sources do you think are good for this data for the recent past? My brief initial search is turning up a lot of contradictory data, probably because the sources are defining "programmers" differently from each other.
Only if there is no further additional demand created by the now lower cost of doing the work. Take lighting as an example. As it has progressed from burning expensive candles to now leds, our demand for lighting has continued to increase.
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.
Yes, me. I suffered some serious depression that I cured through therapy and medication. Discussing it openly with my family and friends certainly helped.
As the saying goes, recognizing that you have a problem is the first step to being able to solve it.
venting is a form of talking about mental health. there are other forms that the problem statement doesn't apply to, like your examples. but the statement does apply to my example, therefore we can't say that talking about mental health is exclusively a positive behaviour.
Can you think of anything you can do that is exclusively a positive behavior? Drinking water in excess kills you, excess breathing kills you, excess exercise kills you, I think the logic here can be used to sow the seeds of uncertainty in nearly anything, honestly.
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.
That's right! The system quickly updates the plot chart as new chapters are released, and the author doesn't have to create and maintain the wiki themselves.
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’d be very interested in running a private pilot on your novel. Since it is unpublished, the result would remain private and I would not use or share the manuscript without your permission. You can reach me at aldor@synaptale.com or through the contact link on the site.
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've considered using Lilypond, but I really like the autoplay feature in Musescore, as well as the lack of delay between placing notes and seeing the result.
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. :)
