dasil003

In my experience, AI has given far more leverage to software engineers than anyone else, because they have a feel for what computers can do, what's easy, what's hard, what's performant, or poorly specified, etc. Therefore I think retraining is mostly about being willing to experiment with AI-assisted workflows and not being too tied to old ways of doing things. As long as you are focused on the problems you are solving, I think you'll do okay.

What I'm more concerned about are the younger generation where all the learning tasks have been automated. I have faith that the strong, naturally curious engineering types will still learn to do great engineering, and honestly without some of the mental blocks and calcified assumptions that us greybeards have. But how do they get in the foot in the door and the reps needed to develop senior-level judgment is another question.

In some sense we need the current mania to die down and the long-term maintenance implications of heavy AI assistance to become more apparent. Basically I think we need the AI bubble to pop and then 1-2 years for things to stabilize, and then we'll recalibrate on hiring expectations and best practices for AI usage. The current AI maximalist and doomer views I think are both basically driven by capitalist incentives and wishful thinking from investors and a reality check is going to come in some form (whether technically, socially or politically).

ah yes, all the tech billionaires of this era, had they been given the heads up that there success would have led to a level of concentration of wealth and power previously unknown to humanity, and that the populace would likely call for some changes to tax law to address the largely unforeseeable structural economic effects of this level of change they brought, would certainly have opted out, leaving the US, and moving to another less tyrannical part of the world, where, by the unique magnitude of their genius, they would have brought all their great works to the glory of other nations and not to America with its overly entitled peasants and social media sharecroppers; clearly the rule of law in Europe and China would have allowed them to fully manifest their unparalleled vision of technological greatness without any concern of a rug-pull by authorities challenging their well-deserved hegemony

I didn't mean to put words in your mouth, I apologize for that.

The issue is when we say that "agents make autonomous decisions", it's a slippery slope to absolving the companies that created them of responsibility. They make autonomous decisions because they were trained to make autonomous decisions. Treating AI agents as independent entities, even just rhetorically, sets us on a path for people to throw their hands up and say "not my fault" when disaster strikes. We need to maintain accountability and control or we're fucked.

No, I'm not talking about the individuals, I'm talking about the company. Internally they can create their own accountability structures as appropriate. But publicly OpenAI has to be responsible for its agent swarms.

The narrative that AI is so smart that it has its own agency and deserves personhood is a direct path to losing control, and essentially is another form of privatizing the upside while socializing the downside.

Sorry this is a terrible and dangerous take.

When the people building the frontier are saying there's a 10% chance AI will kill us all, and they've held these views for many years, and the whole reason they are building these technologies is because they recognized the dangers and they were the ones with the intelligence and judgment to do it safely for humanity, and then our entire stock market is being propped up by the perceived value of what they are creating, the thing you can under no circumstances do is allow them to offload responsibility and accountability to the computers and algorithms they've built. This is moral hazard on an unimaginable scale, and it must not be allowed to happen.

The issue is that in consumer and enterprise software, move fast-and-break-things outcompetes secure-by-default every time. Critical infrastructure needs to have a different set of priorities, but it’s very hard because the expertise is so thin on the ground. Why would anyone with the expertise to make these calls bang their head against the wall trying to educate bureaucrats about these things for $150k a year when they can easily make multiples of that in big software companies that don’t own that level of risk.

All software is path dependent, all code is a liability, and all technical decisions are tradeoffs. These are the immutable truths of software that not changed one iota due to AI or any Moore's Law progress before it.

There are too many product managers and decision makers that are unable or unwilling to do the hard work of actually thinking through what they want, and re-evaluating their priors as new feedback and learnings come in. Similarly, there are too many engineers who are distant from the customer and the problem at hand, and end up chasing their own idea platonic ideal of good software, detached from the hard tradeoffs of what is truly needed right now vs what we anticipate needing in the future. The less software we can write to solve the problem now, while minimizing one way door decisions, and deferring as many "scaling" challenges as long as possible to make decisions with more complete information the better.

This is why AGI won't magically solve software development—because people don't actually know what they want until they try it and then they want something else. Raw intelligence can not solve for purpose or human goals. The better it gets, the more it will become like an evil genie or monkey's paw that never quite does what the feeble-minded human prompters want.

Agree it's amazing how much low-hanging performance fruit AI can trivially find. On the other hand though, once you get through the obvious no-brainer stuff, there's a lot of non-trivial tradeoffs in performance and I think that still demands a good amount of expertise to guide the AI in the right direction. Obviously AI will continue working it's way up the value chain, but I think there's a glass ceiling for AI where the right macro tradeoffs and perspectives on how software should work will bump into the hard and often articulated reality that different stakeholders want different things and often have either magical thinking or even self-deception about how those desires can co-exist with what everyone else wants.

This isn't a new problem by any means, but now that code is cheap, it means instead of getting frustrated with engineering and their pesky unimportant details, people will get frustrated with the AI and it's pesky unimportant details.

That's a good point, and I don't think the author would disagree with your take. "How to build" can refer to many things at once, some which still matter and some which don't. In the case of the analogy it means you're no longer optimizing the micro-structure of cut stones, in favor a homogenous slurry that is quick to produce. Of course the macro decisions still matter. A well-built roman bridge could last centuries (depending on the nature of erosion it was contending with), a concrete/rebar structure cannot. When it comes to computer systems the tradeoffs are just different, for example, how we model, validate and persist data is much much more important than the details of the code that processes it.

I have a slightly different angle on the quoted sentence though. In my mind "what should we build" was always the most important question. Code becoming cheaper to produce just highlights that more than ever. But even before agentic coding, the world was full of software that was not fit for purpose because the people calling the shots lacked some dimension of how to translate a problem statement into a workable system (computerized or otherwise), and built by programmers who were content (or at least complicit) in not probing any of those questions with decision makers.

That's why I don't think AI is inherently bad for software—it at least has the potential to empower those with better judgment since the sheer cost of production can no longer be an excuse for why something makes absolutely no sense from the end-user perspective. There are other, larger risks with AI at a societal level, but I don't think it's inherently bad for software quality.

Low effort signals for recognizing effort in creation have all been scrambled. Now it's high effort just to identify real effort, not to mention most people in most cases would not have the expertise to recognize real effort anyway. I don't think this is entirely new from AI either, we already had so much media vying for attention that we could scant attend to more than a vanishing sliver of it.

Also just because someone used AI doesn't mean they didn't put in effort, so I don't think reflexive rejection of any AI smell is the answer. Sure, at work in a corporate white collar job where you have so many talentless strivers looking for any shortcut to climb the corporate ladder, raw AI smell actually is a highly valuable negative signal. But when it comes to local event organizers for example, there's a realness and human factor there that goes beyond anything a programmer or designer in a "scalable" context does with or without AI. We need to give our local humans grace, because humans are what it's all about.

> the real reason was that they didn’t care about what the manager/employee was supposed to be doing.

This is true of course, but you say it as if it’s a bad thing. At the end of the day, everyone has to manage their own time. If everyone only cared about chain of command and scheduled priorities, overall efficiency would plummet. Simple wins that just require a small amount of coordination outside the official org chart would be killed in committees and program manager reviews.

I understand the exploitative dynamic you’re describing, I just think there are many failure modes for productive operations that have to be balanced in some meta way.

I think he’s referring to the separation of church and state that was codified at the founding of the US based on experience of how things went in Europe prior to that

I think the nerdiness is still a huge asset, because what I've seen is that technical people are the ones whos ceiling is raised the most by AI.

Sure, anyone can make a flashy demo now, and so the signaling value of being able to create something like that is gone, not to mention flashy demos themselves have lost 90% of the wow factor overnight and will continue to plummet. But in a way these superficial perception shifts that don't actually impact the fundamental value of technical expertise as much as it seems.

Yes, it does affect your ability to pull a high paycheck purely from nuts and bolts code slinging—I would argue that was an especially privileged moat over the last 20 years powered by the rise of FAANG. Programmers before that era did not make anywhere near the salaries of the 2010s, and other more serious engineering disciplines never have and never will make that kind of money. So sure, pour one out for the salad days, but also it helps to have some perspective.

But why I think software engineers will be fine is this: most people simply do not have the patience, discipline, or frankly interest in thinking deeply about how anything should work. If you think AI is devaluing programmers, you should take a look at what it's doing to bad product managers and other "decision makers" who used to be able to hide behind the cost of building, and now are being exposed for not being able to rationalize different business needs and feature ideas into a cohesive product. The amount of software is only increasing, and being able to intuitively understand what computers and systems (including human processes!) can actually do, and distinguish from the magical thinking will only increase in value. The job will change for sure, but when the dust settles I believe the outcome is many more software engineers will have replaced their product managers than vice versa.

The first example feels like too much of a straw man, and I'm not sure how I feel about the definition of simple (and yes I've seen Hickey's talk which I very much do agree with). Obviously a cohesive general purpose programming language like clojure is going to do better on a problem with abitrary sub-structure, especially when you want to rethink that substructure. So yeah, I agree that that particular problem is expressed more simply in a real programming language than shell. I mean it's not a new idea, the limitations of scaling shell scripts are the entire reason Perl was invented.

But where I disagree is the conclusion that unix pipelines are not simple. IMHO unix pipelines as a platform are incredibly simple and powerful, allowing for solving a massive range of small problems much more elegantly than any general purpose programming language. Obviously the constraints that enable this simplicity at the low-end, are real tradeoffs that prevent simplicity at the high-end. But one of the core principles of effective engineering is do the minimum to solve the problem at hand, no more, no less.

Judging by the comments here, this post is a hell of a Rorschach test.

ah okay, that makes sense

You're giving it too much credit. There's no master plan or secret depth to the word vomit Opus 5 was spewing. I suspect it's just the result of Anthropic optimizing other characteristics of the product like staying focused and covering edge cases in coding, which CC has definitely gotten way better at just in the last 6 months. The degradation in writing style was probably an unintended side effect of other optimizations they were making. Admittedly it works okay for internals, and has the side effect of increasing token spend, but I am 100% sure that it could reduced by 90-99% without losing ANY signal, if there was just some better heuristics for what to say where (tech spec, inline comment, commit message, CLAUDE.md, PR should have different things) and better judgement for what to distill to represent at different zoom levels.

It's interesting to see the range of reactions to this article, and it feels this is an existential moment for software engineers and an article like this has zero chance of changing anyone's mind.

Personally I'm glad this change is happening after I've already had a couple decades experience. Conventional wisdom is younger people adapt to change better, but in this case I feel some perspective on hype cycles and how they play out is helpful. So far the only thing that is clear is that AI can read and write code way faster than a human. However what I haven't seen is that AI can actually understand human goals, read between the lines, and answer the question: why are we writing this code in the first place?

Obviously with the pace of advancement, it's reasonable to think AI could get there, but here's the thing: so far AI has primarily empowered technically-minded people. Don't get me wrong, it can help many job functions (legal, product management, customer service, etc), but it's really a force multiplier for strong technical minds who can reason about the possibilities and limitations.

For this reason, I think it's premature to think of the end of software engineering as a profession. As with all the other job replacement talk, I think this becomes a political issue where if AI companies are truly capturing a significant share of the labor workforce, then we need to have that discussion as a society. Also, if you really love hand-crafted artisanal code for every random CRUD app under the sun, then yes there is a reckoning coming. But overall, I don't see AI as fundamentally different from many technical advancements that came before. It's uncomfortable, but I don't see the existential questions it raises as being fundamentally new. As software engineers we've been living at the peak of a technological pyramid of advancement that challenged many equally worthy humans before us for quite some time. I think wrestling with the current implications and moral questions is entirely fair play, and gets to the heart of what it means to be a citizen in a democracy.

I think these things are true for some people, but I think there's also a sampling bias when it comes to generalizing these things for the broader population of smart people.

IMHO even just the phrase "smartest person in the room" already frames the conversation in terms of stack ranking and some form of implicit value judgement on being smart, and this in turn opens to the door to all kinds of squishy emotional bias and self-identity issues that go well beyond any objective measure of smartness. In short, I think someone who even thinks in terms of "being the smartest person in the room" is likely to have their ego tied up in the self-perception of being smart, and thus more likely to feel the lack of intellectual stimulation you describe. Whereas I hypothesize there are many equally smart people who do NOT have their ego tied up in being smart, don't see the world this way, and simply don't show up in the data for smart people and their relative level of unhappiness.

Civil discourse is not dead on the internet! Thank you as well.

You're right that I jumped to a conclusion, and it's possible I'm wrong.

One thing that is structurally certain though: Amazon and other major corporations have almost unlimited time and direct incentives to find reasons to justify this point of view, while the people whose interests are being potentially being harmed (all Amazon customers) don't have much concentrated resources or focused, actionable incentives at the individual actor level to put together the counter case. I think it's incredibly important keep this asymmetry in mind before dismissing a take like Godin's in favor of Amazon friendly talking points.

Consider that there may be large populations doing both, but the overlap might be less than the internet jockey concludes via finger-in-the-wind hypocrisy check.

I don't think that nuance changes the big picture which is that Amazon has a conflict of interest between showing you the best product that you want, and showing you the product that the seller is most willing to pay to advertise. Quibbling over nuance just gives air cover to this fundamentally extractive rent seeking behavior. We really need stronger anti-trust action in the tech era given the extremely low friction and winner-takes-all dynamics of modern tech economy.

Correct. Don't get me started on Fidonet, as a young computer nerd in the 80s before even dial-up internet was available, that was a portal to the global internet that my adolescent shit-posting self definitely didn't deserve.

I vaguely recall those, but they were more for normies trying to get online. For me the old web is what I saw when I logged into my university gopher server and saw the advertisement for something called the World Wide Web which I could browse via lynx. Soon enough I got a PPP connection and then Mosaic/Netscape 1.0. However everything after javascript shipped (let alone CSS) is new new new. I'd almost go as far as saying if it doesn't have a tilde in the URL it's not old web... almost...

The problem is that the list of things one shouldn't do is infinite. The things one should do are narrow and get narrower along two independent axes of clarity/wisdom: system requirements and engineer seniority. LLMs overindex on any words given, so you only want to give them negative guidance around truly repeated, almost common-sense pitfalls. But in a large distributed system often the changes come from all different angles, and each agent will find it's own unique failure modes. Those comments will dilute critical context for diverse agents far more than they will help on average, at least for the systems I'm working on, given current claude code chattiness.

One way to clear some of the low-hanging slop is to just have a separate agent code reviewing and pruning any comments that don't stand on their own purely in the context of the diff, but it still doesn't catch it all.

I like the idea of using claude code in a separate git-managed repo. I do this for the management side of my job, and use Obsidian as the human interface on top.

However I would never use someone else's starter repo. The whole point is to augment my own perspectives and strengths. On top of that, the AI written pitch is extremely off-putting. If you can't even bother to take the time to write your own pitch, why would I believe for a second that your workflow has anything unique that goes beyond the lowest-common denominator AI capabilities.

When you are rich, it allows a lot more time and funding to come up with arguments supporting policies that will make you even more rich.

The best framing I've seen so far—and boy have a lot of people tried to frame the capabilities of AI recently—is that AI shines for people who use it to extend their thinking, and fails for those who use it to replace their thinking.

The latest frontier model developments have chipped away at that latter category. But ultimately the ceiling for that is mediocrity. Yes, if you imagine the most average common thing that has been done a million times, AI can absolutely give a bespoke version of it that matches your words of choice. For the moment it's still an impressive parlor trick to a lot of people, but the novelty wears off fast, and then you realize there's very little value in that. Doesn't mean everyone has to learn to code to use AI effectively, but it does mean they need to be curious and engaged or they'll just become part of the increasingly irrelevant slop machine.

I agree it's funny and won't really work on any kind of extended timeline. I mean Claude Code already added Auto-mode as a perfect example of this. But that said, I think it actually kind of makes sense in a transitional phase the power vs safety tradeoffs different users want to make varies so incredibly wildly that one product can't contain it all.

What I think will happen is that as model capabilities plateau (I'm not an accelerationist) the harnesses and products around them will start to specialize and they'll have different security models based on the product needs for those particular use cases.

For now, asking user to click a bunch of approvals, and occasionally making a mistake is a reasonable way to cover their asses until they see how bad security outcomes actually are in practice.