There have always been young people who can quickly hack something together with whatever new tools are available. That way of working never lasts, but the tools do last.

When tools prove their worth, they get taken into to normal way software is produced. Older people start using them, because they see the benefit.

The key thing about software production is that it is a discussion among humans. The computer is there to help. During a review, nobody is going to look at what assembly a compiler produces (with some exceptions of course).

When new tools arrive, we have to be able to blindly trust them to be correct. They have to produce reproducible output. And when they do, the input to those tools can become part of the conversation among humans.

(I'm ignoring editors and IDEs here for the moment, because they don't have much effect on design, they just make coding a bit easier).

In the past, some tools have been introduced, got hyped, and faded into obscurity again. Not all tools are successful, time will tell.

This reminds of talking to my nephew at Thanksgiving years ago. He was studying for an exam after the holidays and I was looking at his screen open to a Google Doc which looked like his study notes except - they were being edited as I was watching - by someone else. I asked about it and he goes “we have a single Google Doc where all students collaborate on the study notes.” My mind was blown, I was also using Google Docs but not in a millions years would it cross my mind its utility for such a thing he and his classmates were using it for. Can’t wait to see what new blood “Juniors” brings to the table!

I definitely agree with this. Older folks have to deal with the double whammy of being familiar with what they already know, plus there is a good bit of research that learning and absorbing new things just gets harder past mid-40s or so.

That said, I don't think this negates what TFA is trying to say. The difficulty with software has always been around focusing on the details while still keeping the overall system in mind, and that's just a hard thing to do. AI may certainly make some steps go faster but it doesn't change that much about what makes software hard in the first place. For example, even before AI, I would get really frustrated with product managers a lot. Some rare gems were absolutely awesome and worth their weight in gold, but many of them just never were willing to go to the details and minutiae that's really necessary to get the product right. With software engineers, if you don't focus on the details the software often just flat out doesn't work, so it forces you to go to that level (and I find that non-detail oriented programmers tend to leave the profession pretty quickly). But I've seen more that a few situations where product managers manage to skate by without getting to the depth necessary.

... and the biggest problem is that the people who _do_ know how hard it is to build software are the ones whose input on the matter is most likely to be discounted as "sour grapes"/"fear of obsolescence".

Valknut is pretty good at forcing agents to build more maintainable codebases. It helps them dry out code, separate concerns cohesively and organize complexity. https://github.com/sibyllinesoft/valknut

> We ultimately need optimized DSLs and aggressive use of stateless sub-modules/abstractions that can be implemented in isolation to minimize the amount of context required for any one LLM invocation.

Containment of state also happens to benefit human developers too, and keep complexity from exploding.

> accrue massive technical debt

The primary difference between a programmer and an engineer.

>If you largely accept their edits unchanged, your codebase will accrue massive technical debt over time and ultimately slow you down vs semi-automatic LLM use.

Worse, as its planning the next change, it's reading all this bad code that it wrote before, but now that bad code is blessed input. It writes more of it, and instructions to use a better approach are outweighed by the "evidence".

Also, it's not tech debt: https://news.ycombinator.com/item?id=27990979#28010192

I'm not sure.

Think of the Game hits from the 90's. A room full of people made games which shaped a generation. Maybe it was orders of magnitude harder then, but today, it's multiple orders of magnitude more people required to make them.

Same is true for websites. Sure, the websites were dingy with poor UX and oodles of bugs... but the size of the team required to make them was absolutely tiny compared to today.

Things are simultaneously the best they've ever been, and the worst they've ever been, it's a weird situation to be in for sure.

But truthfully; orders of magnitude more powerful hardware was the real unlock.

Why is slack and discord popular? Because it's possible to use multiple gigabytes of ram for a chat client.

25 years ago? Multiple gigabytes of ram put your machine firmly in the "I have unlimited money and am probably a server doing millions of things" class.

Modern Java is vastly more complicated than early Java. So I'm not sure I follow your reasoning. Programming nowadays is absurdly complicated. I have 20 years of experience and I can't imagine how new developer could learn it all.

I don't really know if AI makes programming easier or harder. At one side, you can explore any topic with AI. This is super powerful ability when it comes to learning. At another side, the temptation to offload your work to AI is big and if you do that, you'll learn nothing. So it comes down to a person type, I guess. Some people will use AI to learn and some people will use AI to avoid learning, both behaviours are empowered.

I have simple and useless answer how to solve that. Throw it all out. Start from the scratch. Start with simple CPU. Start with simple OS. Start with simple protocols. Do not write frameworks. Make the number of layers between your code and hardware as small as possible. So it's actually possible to understand it all. Right now the number of abstraction layers is too big. Of course nobody's going to do that, people will put more abstraction layers and it'll work, it always works. But that sucks. Software stack was much simpler 20-30 years ago. We didn't even had source control, I was the young developer who introduced subversion into our company, but we still delivered useful software.

Short answer: No, things have not gotten easier. The toolchain is insanely huge. A computer science graduate is woefully underprepared for the tool tsnuami that will completely swamp their careers. Many of these tools are worse than no tool at all.

Causes: Bubble economics, perverse incentives, lack of objectivity, and more.

The good news is that huge competitive advantages are available to those who refuse to accept norms without careful evaluation.

Having learned programming in the 80s (as a teen), I would say it was much easier back then. Programmers have made things vastly more complicated these days.

> programming is easier than ever

Or does it just seem that way because you've had a whole lifetime to digest it one little bit at a time so that it all seems intuitive now? If "easy to understand and get started with" were the bar for programming capability, we'd have stopped with COBOL.

> Compare modern languages like Go & Rust to C & C++, simply for their ease-of-compilation and execution.

Except that at least for game development, C and C++ are still the go-to tools?

I think as many other people who replied to you have said, it's a mixed bag. It's better in some sense, with abstractions and frameworks that sand down sharp edges, and libraries that can do everything. But it's also crushingly more complex. Back in the day you had to know and care about memory allocation and ASM, but all the knowledge you needed was in a manual or two that you owned and could actually know the contents of.

Maybe the outcome they had in mind was "it helps, but nowhere near 10x"?

Also, I'm not sure anyone was making 10x claims about the tools you cite.

I think it is about as hard as it ever was. The tricky part is learning to think through problems in a certain way, when you have that it doesn't matter much whether you're reading hexdumps and slinging low-level code on a 68k chip or clicking about in Godot and watching videos about clicking.

Crapping out code that does the thing was never the hard part, the hard part is reading the crap someone did and changing it. There are tradeoffs here, perhaps you might invest in modeling up front and use more or less formal methods, or you're just great at executing code over and over very fast with small adjustments and interpreting the result. Either way you'll eventually produce something robust that someone else can change reasonably fast when needed.

The additions to Java and C# are a lot about functional programming concepts, and we've had those since forever way back in the sixties. Map/reduce/filter are old concepts, and every loop is just recursion with some degree of veiling, it's not a big thing whether you piece it together in assembly or Scheme, typing it out isn't where you'll spend most of your time. That'll be reading it once it's no longer yesterday that you wrote it.

If I were to invent a 10x-meganinja-dev-superpower-tool it would be focused on static and execution analysis, with strong extendability in a simple DSL or programming language, and decent visualisation API:s. It would not be 'type here to spin the wheels and see what code drops out', that part is solved many times over already, in Wordpress, JAXB oriented CRM and so on. The ability to confidently implement change in a large, complex system is enabled by deterministic immediate analysis and visualisation.

Then there are the soft skills. While you're doing it you need to keep bosses and "stakeholders" happy and make sure they do not start worrying about the things you do. So you need to communicate reliably and clearly, in a language they understand, which is commonly pictures with simple words they use a lot every day and little arrows that bring the message together. Whether you use this or that mainstream programming language will not matter at all in this.

You missed the word "anyone". Of course tools for programmers have seen huge improvements. The "promise" referred to here is that you don't need to learn programming skills to be an effective programmer.

As with anything, there's also too much of a good thing though.

In my own career I switched role to get more time on a area where I felt I needed more growth an practice. Turns out I never got really very good at it, and basically was just in a role I wasn't great at for 6 years. It was miserable. My lesson is "if you know you are bad at something, don't make it load-bearer in your life or career".

There are mixed views here. Some are making the claim relevant to the Silver Bullet observation, than LLMs are cutting down time spent on non-essential work. But the view that's really driving hype is that the machine can do essential work, design the system for you, and implement it, explore the possibility space and make judgments about the tradeoffs, and make decisions.

Now, can it actually do those things? Not in my estimation. But from the perspective of a less experienced developer it can sure look like it does. It is, after all, primarily a plausibility engine.

I'm all for investing in integrating these generative tools into workflows, but as of yet they should not be given agency, or even the aesthetic appearance of agency. It's too tempting to the human brain to shut down when it looks like someone or something else is driving and you're just navigating and correcting.

And eventually, with a few more breakthroughs in architecture maybe this tech actually will make digital people who can do all the programming work, and we can all retire (if we're still alive). Until then, we need to defend against sleepwalking into a future run by dumb plausibility-generators being used as accountability sinks.

I think software was indeed 9/10 accidental activities before AI. Probably still mostly accidental activities with the current LLM.

The essence: query all the users within a certain area and do it as fast as possible

The accident: spending an hour to survey spatial tree library, another hour debating whether to make our own, one more hour reading the algorithm, a few hours to code it, a few days to test and debug it

Many people seem to believe implementing the algorithm is "the essence" of software development so they think the essence is the majority. I strongly disagree. Knowing and writing the specific algorithm is purely accidental in my opinion.

Shipping is easy, shipping stable functional (lets lump in scalable) software on the other hand.

I understand the “8 year old niece” is hyperbole, but really? Everyone can build apps?

“Build me a recipe app”, sure.

Building anything substantial has consistently failed for me unless you take claude or codex by the hand and guide them through it step by step.

Not to mention selling it

But who are you shipping it to if everyone is building it?

If you were given a copy of the entire software stack that runs YouTube I would bet $1000000 you can't take all of YouTube's customers. Businesses are more than just the software.

The point of the article is that the jump start that AI gives you is not the same as the one that well thought frameworks give you. What AI writes falls apart and leaves you with the ruins.

That sounds exhausting.

I'd rather spend my time thinking about the problem and solving it, than thinking about how to get some software to stochasticaly select language that appears like it is thinking about the problem to then implement a solution I'm going to have to check carefully.

Much of the LLM hype cycle breaks down into "anyone can create software now", which TFA makes a convincing argument for being a lie, and "experts are now going to be so much more productive", which TFA - and several studies posted here in recent months - show is not actually the case.

Your walk-through is the reason why. You've not got magic for free, you've got something kinda cool that needs operational management and constant verification.

Absolutely true. Especially so with poorly abstracted software design.

This is why so many new teams' first order of business is invariably a suggestion to "rewrite everything".

They're not going to do a better job or get a better product, it's just the only way they're going to get a software stack that does what they want.

People don't develop the ability to solve algebraic equations when they see a professor solving it on the whiteboard. That's just the introduction to the methodology. The way people develop problem solving is by solving problems themselves.

This is why everyone's thirsty for senior/staff engineers who are AI powered right now, because their entire work experience was the typical SWE experience.

I cannot wait for the industry to have a highly skilled SWE drought in the next 5 years, so I can sweep in and become the AI powered engineer who saves the day because other junior-mid SWE's outsourced their problem solving way too early, either due to falling for the "don't be left behind" narrative (which is absurd because what about people who will get into CS in 6 years from now? Do they miss some metaphorical train?) or because their manager forced them to adopt the tools.

What comes to mind is Java vs assembly. Claude is just a really really high level language compiler. I work with senior Java devs who have never written assembly.

On the learning front, I spend the weekend asking Claude questions about Rust, and then getting it to write code that achieved the result I wanted. I also now have a much better understanding of the different options because I've gotten three different working examples and gotten to tinker with them. It's a lot faster to learn how an engine works when you have a working engine on a dyno than when you have no engine. Claude built me a diesel, a gasoline and an electric engine and then I took them apart.

Well, the first time i got really excited about an LlM was when it told me “yes, if you give me your game ideas and we iterate together, i can handle 100% of the coding.” lies, pure lies.

What is the hard evidence?

Edit: What I mean by this is there may be some circumstantial evidence (less hiring for juniors, more AI companies getting VC funding). We currently have no _hard_ evidence that programming has had a substantial speed increase/deskilling from LLMs yet. Any actual __science__ on this has yet to show this. But please, if you have _hard_ evidence on this topic I would love to see it.

If you think of building software as just writing the code then sure AI makes things a lot easier. But if software engineering also includes security, setting up and maintaining infrastructure, choosing the right tradeoffs, understanding how to deal with evolving requirements without ballooning code complexity, etc., then AI struggles with that at the moment.

> but the speed tradeoff

If you only care about a single metric you can convince yourself to make all kinds of bad decisions.

> Nobody is lying.

Nobody is being honest either. That happens all the time.

do you make money with it? like monthly subscription? because that's my achilles heel, how to synch the mysql backend with apple's payment system so it knows when user ordered or cancelled