Yeah this article is in a real uncanny valley for me where it has some insight, but it also throws out some wild ideas that don't pass the sniff test for me.

To me what AI is doing is changing the economics of human thought, but the change is happening way faster than individuals, let along organizations can absorb the implications. What I've seen is that AI magnifies the judgment of individuals who know how to use it, and so far it's mostly software engineers who have learned to use it most effectively because they are the ones able to develop an intuition about its limitations.

The idea of removing the human from the loop is nonsense. The question is more what loops matter, and how can AI speed them up. For instance, building more prototypes and one-off hacky tools is a great use of vibe coding, changing the core architecture of your critical business apps is not. AI has simultaneously increased my ability to call bullshit, while amplifying the amount of bullshit I have to sift through.

When the dust settles I don't really see that the value or importance of reading code has changed much. The whole reason agentic coding is successful is because code provides a precise specification that is both human and machine readable. The idea that we'll move from code to some new magical form of specification is just recycling the promise of COBOL, visual programming, Microsoft Access, ColdFusion, no-code tools, etc, to simplify programming. But actually the innovations that have moved the state of the art of professional programming forward, are the same ones that make agentic coding successful.

Man, as a young programmer coming up I really looked up to Paul Graham, but now as a seasoned vet in the industry, it's remarkable (and disappointing) to see him publish an article based on such a false equivalency. I mean this level of missing the forest-for-the-trees is the type of thing that routinely prevents senior engineers from getting promoted to staff because they're pedantically fixated on the wrong details. And that's on top of failing to read the room as to why people are even calling for a wealth tax in the first place.

The more obvious reason to not tax wealth is because it's hard to measure, and if you try to do it you will incentivize hiding it. Meanwhile, there are obvious obvious loopholes that the ultra-wealthy enjoy which could be reasonably closed. Namely, close the buy-borrow-die loophole, don't allow step-up basis for inherited wealth, and tax capital gains at least as much as income. Now people with a lot of money can afford to fund a lot of premium think tanks to come up with fancy economic reasoning why those ideas are Really Bad™, but at this point it's clear that's bullshit propaganda and the unintended consequences are exceedingly unlikely to be worse than the current unchecked consolidation of wealth and power enabled by the current loopholes.

I think this depends a lot on the task, the existing codebase, and the taste of the operator.

In general I tend to agree with you if you're talking a codebase you are deeply familiar with, the value-add from have agents write the code probably ranges from very small to negative in most cases.

On the other hand if you're trying to make changes in systems you are not familiar with, LLMs are a huge speed boost to folks with enough experience to sniff out what would be a bad path essentially via socratic method to the agent.

Obviously there are no silver bullets and no substitute for judgment. I will say though, I'll tradeoff ugly local code for good data models and interfaces any day of the week, and there is definitely an archetype of engineer that is very precious about code without good judgment on where it matters and where it doesn't.

In the age of AI you can't "undo the claims" for randos on the internet. I mean it was hard enough before, but at this point it's now a direct money -> speech pipeline. Reputation will matter more than ever before.

I vividly remember the moment this clicked for me. I had spent the better part of a decade being interested in programming and essentially learning recipes. It wasn't until I was a couple years into a CS degree and starting to work professionally as a web developer, that I finally had an epiphany of what software actually was, and the degrees of freedom that it actually has. It's very hard to put into words because it was an internal phenomenon, but I can describe at a more visceral understanding of what is meant by "the map is not the territory", and "all models are wrong but some are useful". It's like, you can build anything in software, it's up to you to decide how to do it and make it relevant for a real world use case.

Of course I was still super junior and had so much to learn, but from that point I could at least interrogate any pattern or best practice to understand why it existed and where it should or should not be applied.

I've had conversations with people who wanted to learn how to code. I found that teaching someone how to code is tedious experience. It's just a bunch of memorization and bafflement at how quickly someone else can do things at the keyboard. I've since come to realize that wanting to learn to code is NOT a good starting place. It's best to have a vision. What's the problem you are wanting to solve? If writing software is a way to solve that problem...well NOW we have something to learn around. We have a vision. We have a goal. And learning the syntax and cs concepts is no longer an end of itself, it's just an obstacle to get through to accomplish the vision. You bring enough of these visions to completion, you'll find you've cleared a LOT of obstacles and wow, you've gained a lot of software knowledge.

This is why you need sufficiently senior engineering leadership (both IC leadership and management). If you have engineers who meekly do whatever a non-technical stakeholder asks then you have a vacuum of responsibility, and sooner or later things will blow up catastrophically and whoever was least adept at CYA will get blamed.

On the other hand, almost any business problem can be solved in a reasonable way that doesn't send your system through any terrible one-way doors if you zoom out enough and ask enough whys. Of course not every place allows engineering to do that, but the ones that don't aren't able to retain senior folks because they will just go somewhere where their judgment is valued. Sometimes technical debt is the right thing for the business, but sufficiently senior engineers can set things up so there is always a way out. But what you can't do is uphold the purity of the system above the business problem. The systems are paid for by the business, so if you lose sight of that then you've lost the plot and the basis for your influence.

Yea, I think even a lot of decent devs are afraid to just say "no" to things. They don't even bargain to find a balanced solution that can be reasonably done in terms of architecture and time to production.

This is very naive and reductive thinking. Experiments have a cost, you really have to think carefully about what you are trying to learn. Even when code is cheap, traffic and time are still huge constraints, and you better make sure your hypothesis actually makes sense for your goals, because AI is more than happy to fill in the blanks with a plausible but completely wrong proposal.

More broadly, it's well understood that experiments are not a replacement for design and UX. Google is famously great at the former and terrible at the latter. Sure the AI maxxers will say the machines are coming for all creative endeavours as well, but I'm going to need more evidence. So far, everything good I've seen come from AI still had a human at the wheel, and I don't see that changing any time soon.

Even writing code the good old way, of course we experiment. I remember the old rule "Plan to throw away the first one. You will anyway." But then there's the "second system effect" where the second system is supposedly always overengineered and trying to take every possibility into account.

And then there's the times when the quick sloppy poc you planned to throw away gets forced into production and is still impossible to change ten years down the road.

AI makes all these problems so much less painful.

I worked at a company which had a huge monolithic ERP system (their product, to be clear) with no good separation between the GUI layer and presentation layer. The GUI was also dependent on an ancient version of the Borland C++ compiler. They put in a humongous effort to move to a slightly more modern UI library, and a client server architecture.

However, someone had decided that messages in xml or json were too inefficient, they already had performance issues. So they went with a binary message protocol of their own design - with no features for protocol update. Everything communicating with the server had to be on exactly the same version, or it would throw an error. So of course they very, very rarely updated the protocol.

I think the best help of AI will be to clean up such real life messes of soul-crushing architectural regrets. Will it do it perfectly, certainly not, but I wouldn't do it perfectly myself either if I was forced to do it - and I'd take a hell of a lot more time to do it.

I think you and 7e are both right. Being able to iterate some N orders of magnitude quicker is a big deal. This doesn’t eliminate design and UX. Rather, it merges it with high iteration speed to produce a form of “play”.

“Play” is what produced at least two (likely more) generations of attentive (and therefore competent) programmers. The hype around LLMs is painful, yes, but attentive human minds will ultimately bust through it.

I agree with you, so far what I see is that AI amplifies an individuals output in many domains, but the value of that is 100% contingent on their judgment. It changes the economics of many tasks, but fundamentally it can't really help you if you don't actually know what you want—which is sort of a shocking number of people in the corporate world where most people are there for a paycheck, and perhaps to pursue some social marker of "success".

I'm under no illusions about the goals of AI company execs to justify their valuations (and expenses!) by capturing a huge chunk of global employment value, and the CEOs of many big companies whose financials are getting squeezed for all sorts of reasons and are all too happy to jump on the efficiency narrative of AI to justify layoffs that would have been necessary anyway. Also, AI will keep getting better and it could certainly will move up the food chain—it's already replaced a lot of what I did and I assume capabilities will continue improving for a while even after model capabilities plateau as we improve harnessing, tooling and practice.

So yeah, it can replace a lot of what we do, but I'm not running scared because every step of the way I've seen software people are the ones who actually get the most out of LLMs. Sure it can write all the code so the job changes, but even our workflows completely change, it's giving us more of an edge (if we're open to it) than it does to anyone non-technical. At this stage it still feels empowering on an individual level.

Now I do worry about the consolidation of power and wealth in a tech oligarchy, but that's an issue we need to deal with at a societal and government policy level. Essentially, I can see AI as having radically different outcome potential based on how it's governed. In one way it can be very empowering to small teams, and reduce coordination costs, and increase competition by allowing smaller groups of people to make more scalable companies. But it could also lead to unprecedented concentration of wealth and power if a small set of AI companies are allowed to capture all the economic gains. I don't think there are any easy answers, but I do feel hopeful that we can figure something out as a society—it certainly seems to be creating some unified sentiment across political lines that have been so polarized and divisive over the last decade.

It amplifies by 1000x is the problem for our jobs. However, I do agree that developers with experience are needed to actually harness these tools. I’ve been able to do wonders with them, but I can’t see a junior dev doing 10% of the work that I can with them.

It's a strategy problem, and the current version of the US is spectacularly bad at strategy.

Once upon a time the US had visionaries steering DARPA and making useful bets on the future.

Now strategy is defined by stonks-go-up, quarterly returns, democracy bad, and CEO narcissism, and that's a potently catastrophic combination.

I get that working in the corporate world is often alienating, and also that one might have to accept a bullshit job in order to put food on the table, so on some level I say do what you gotta do.

But beyond that, man this is such a depressing way to live. I've worked a lot of jobs I don't like and put in varying degrees of effort based on how I feel about the people and the situation. But generally one value I live by is that if I'm paid to do something I'm going to try to do a good job at it. That doesn't mean burning myself out or going above and beyond for a boss or company that doesn't deserve it. But for my own integrity and self-worth I have to at least put in a baseline professional effort. If I can't stomach even doing that then it's a clear sign I need to be planning my exit, anything less is disrespectful to my basic self.

Kudos on the analysis, the conclusion is right. I would go further and say even if the metric was completely fair and unbiased it would still not tell you anything useful, and any manager or executive that used it as part of any kind of headcount decision (firings, layoffs, which team to grow, etc) is a moron who probably should be facing tough questions from their own management chain.

AI is a tool, everything it does is attributable to the person who prompted it. Anything else is no different from the long-understood fallacy of counting lines of code.

so, what you're saying is that we can definitely expect this metric to be used to make hiring / firing decisions then