Also to work so hard, and even when you have good luck as well, to see the people around you adapting their expectations so fast that they're blasé about what feels like amazing luck and success to you, and to realize that you can never satisfy them, only inevitably let them down when you experience setbacks.
This is the AI companies' fantasy, to replace simple, efficient, deterministic computing with expensive LLM calls. It'll be bad for customers, bad for users, bad for the environment, bad for everybody except the companies selling it.
I'm a heavy AI user and haven't written code by hand in a long time (and probably won't until Advent of Code, honestly) but I'm already sick of people using AI to replace code at things that code excels at and AI is no better at, just slower and more expensive.
It isn't just driven by the AI companies, either. I've already seen it internally, with developers who need diagnostic tools creating Claude skills, and in the excitement of adopting AI, barely noticing that they're incredibly slow, expensive, unreliable, and even slow to create compared to the script or diagnostic endpoint they would created in the past. And they're surprised to learn that Claude skills suffer from bitrot and cross-repo dependencies just like traditional software: somebody's Claude skill fails because it wasn't updated to match changes elsewhere, and it takes much longer to realize that a conversation with Claude is going wrong than if a script or an endpoint returns an error.
When code is the best solution, by all means use AI to write it! But don't use AI instead when AI isn't fit for purpose.
I was forced to give up on commit messages long before AI, because other people were so bad at them that I happily agreed that all PRs should squash commits.
At least then the squashed messages were usually pretty decent. But then people started using AI (or AI started using people) to create absolutely massive commit messages that are impossible to skim in git blame and overall very bad for human consumption.
AI has made massive strides in virtually every other way. Why do they continue to write in a wasteful, human-hostile way?
I think we'd have to be be very naive not to suspect that this is intentional. AI companies have a stated goal of replacing humans in the software development process, and they're actively making the process itself inhospitable for humans.
They are injecting massive amounts of text into their customers' development process, which then becomes tokens that their customers will then pay them to process over and over again. It's like a CO2 scrubber that emits CO2.
I suspect there's a prompt one can add to improve the consumption of commit messages for humans, just that the default one is pretty bad. Kind of similar to the AI generated posters a few weeks back: https://news.ycombinator.com/item?id=49764791.
Apple built their entire brand around this ethos, and being willing and able to execute it better than any other brand. Letting it slip undermines the Apple brand, which is the entire company.
They built this brand for hardware, but, personally, I’ve never had this opinion of their software. I mean, being Unix based is better than Windows, but they’ve always been cooking weird UI refreshes or buggy software.
It’s crazy because they have (or had) something like $100bn in cash. Spending 0.5% of that per year on software (development, bug-fixing, performance, and QA) would help tremendously. They’d be insurmountable.
I know “they don’t have to”, but they don’t have to do a lot of things that they do on the hardware side. They choose to.
This is a little simplistic. Investing more in the quality component of the org - valuable.
TM3 is basically "if this is your approach to shipping sooner / more quickly, then you're going to have a bad time." It's not a solution for a delayed project. It's not "you shouldn't invest more in the infrastructure of a large project" (or at least not blindly).
It is valuable if you do it right, but it's difficult.
I've been promoting a specific aspect of performance quality recently, but it's mostly lead to other teams creating tests to monitor it that don't really make sense (along the lines of "if you use the computer it'll make the CPU % go up"), asking me to look at it, and then when I say it's probably fine I get a response along the lines of "it must be important because we already told all the executives about it."
That's just a classic software development book. What makes its lessons scientific fact?
Also, it's about a singular project that's late.
Not necessarily applicable to dozens of projects with understuffed teams. Adding people to such teams to help, and assigning new people to look and fix bugs nobody cares about now because they're overworked on some "flagship" new features, is a different case.
> An aggressive first principles approach often leads otherwise well-intentioned technologists into strategic / ideological dead-ends
First principles are an illusion. Good engineers make strategic choices of the supposed "first principles" they apply, and on a particularly difficult problem, they may iterate through multiple options before discovering the "first principles" that yield a good solution.
Engineers that take first principles seriously and try to use them to guide their decisions discover that correct-sounding first principles tend to work in some contexts and fail in others. Then they go one of two ways responding to these failures.
One way is to blame the context. My favorite example of this is a project where a consultant writing a Java web service struggled for months to get Hibernate to emit queries than ran efficiently on the company's Oracle database. Pressed by management to write the queries by hand, the consultant insisted that using Hibernate was a non-negotiable "best practice." Eventually the manager grepped the logs, identified twelve distinct queries that the service needed, and tasked the Oracle admin with optimizing them, which took less than an afternoon. The consultant still pushed back against using the hand-tweaked queries, saying that if the answer emitted by Hibernate didn't run efficiently, then the database schema was wrong and needed to be fixed. This was not the right response when the database in question was the beating heart of a hundred million dollar tech company and was optimized to handle massive transactional workloads, and the consultant was struggling to write a simple web service for internal users.
The second way is to push your first principles to higher and higher levels of abstraction to make them less context-dependent. They update "Use Hibernate for database access" to "Use whatever database library or framework makes it possible to achieve the best results with the least developer effort" and eventually resort to something like "do whatever achieves the best outcome measured by its impact on what is important to you at the time."
I think a better approach is to collect a toolkit of potentially helpful principles and develop understanding of when each principle tends to be helpful.
I don't like the idea of a big, widely used project with stable and polished UI concepts "pushing forward" design innovation. It risks falling victim to overconfident UX folks who think their ideas will succeed and be loved if people are just forced to use them for a while, and for me, it's a red flag that the article doesn't discuss where this innovation should happen. There are plenty of neophiles among open source users who would love to experience new UI ideas as they're being developed. But the focus seems to be on targeting people who don't want to be guinea pigs:
> The final, particularly strong, objection from the tech community is "don't touch my stuff". People get angry when they have worked hard to get their desktop environment just as they like it and something changes to disrupt that. "And I get that. As I said before, I don't want to change everything." But the world is changing, "and we need to grow our way gently into some new things."
Unproven innovation shouldn't be forced on people who don't want it. It should start by proving itself with people who have an appetite for novelty and opt into experimentation. Winning their interest will be a lower bar anyway, generating better constructive feedback on half-baked ideas, with less risk of backlash. Then, as ideas are improved and vetted, they can work their way into the mainstream.
The fact that they're not describing any such process, and instead announcing that they're coming straight for the "don't touch my stuff" crowd, makes me very wary that they think the hardest part of UI innovation is forcing people to use it against their will until they accept it.
AI output right now is like a final exam essay response from an anxious student. Instead of being edited for focus and clarity, it's anti-edited to cram in as many details as possible. Instead of worrying that the reader might get bored or confused, it assumes that the reader has no choice but to read the whole thing, even if they get a headache. It doesn't care about picking the most useful perspective on a problem; it cares about covering every possible angle that a grader might use to dock points from it.
It's basically the work you get from a smart, diligent person who is oblivious to any shared goal and approaches every assignment with a CYA attitude.
It's not a bad attitude given that I don't trust it did the work right, so the more details it can include, the more opportunities I have to spot errors, which invalidate the whole result - and conversely, if all details seem right and self-consistent, it gives me greater confidence the work is correct.
It's because so many of these models were trained on corporate content, which is the exact same vibe. "We're going to drone on for pages about how great we are for building the thing without explaining what it can do for you or how to use it, because spending real effort connecting with our customers isn't something we ever learned climbing the corporate ladder"
reply