Live data from Hacker News

They lied to you. Building software is hard

blog.nordcraft.com

51–60 of 119 posts

Re: They lied to you. Building software is hard

#51
LLMs have clearly accelerated development for the most skilled developers.

Particularly when the human acts as the router/architect.

However, I've found Claude Code and Co only really work well for bootstrapping projects.

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.

It will probably change once the approach to large scale design gets more formalized and structured.

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.

Yes, AI will one shot crappy static sites. And you can vibe code up to some level of complexity before it falls apart or slows dramatically.

Re: They lied to you. Building software is hard

#52
There is a point in there, long-range analysis and debugging without AI is much harder, AI spots lots of non-obvious stuff very fast. If we consider "spotting non-obvious flaws" a skill, this will atrophy as beginners will learn to use AI to scan code for flaws,it is effective but doesn't teach anything, reading long blocks of code and mentally simulating it is a incredibly valuable skill and it will find stuff AI misses(something that is too complex, e.g. nested/recursive control flow,async and co-routines/threads interacting,etc), AI goes for obvious stuff first and has to be manually pointed to "identify flaws, focusing on X".

Re: They lied to you. Building software is hard

#53
Fred Brooks, from "No Silver Bullet" (1986)

> All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivity have come from removing artificial barriers that have made the accidental tasks inordinately hard, such as severe hardware constraints, awkward programming languages, lack of machine time. How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.

AI, the silver bullet. We just never learn, do we?

Re: They lied to you. Building software is hard

#54
> With no-code tools you often reach a hard limit where the tool simply does not make sense to use anymore.

No-code is the same trend that has abstracted out all the generic stuff into infrastructure layers, letting the developers to focus on Lambda functions, while everything in the lower levels is config-driven. This was happening all the time, pushing the developer to easier higher layers and absorbing all complexity and algorithmic work into config-driven layers.

Runtime cost of a Lambda function might far exceed that of a fully hand-coded application hosted on your local server. But there could be other factors to consider.

Same with AI. You get a jump-start with full speed, and then you can take the wheel.

Re: They lied to you. Building software is hard

#55
post #22
post #15

Perhaps this is a bit OT, since the article focuses more on self-development ("When training a muscle, you only get stronger with resistance"), but I wonder about the subtitle: > Every week there seems to be a new tool that promises to let anyone build applications 10x faster. The promise is always the same and so is the outcome. Is the second sentence true? Regardless of AI, I think that programming (game developmen…

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. Thin…

> it's multiple orders of magnitude more people required to make them.

That's something that seems to eat up AAA games, each person they add adds less of a person due to communication effects and inefficiencies. That and massive amounts of created artwork/images/stories.

There are a lot of indie game studios that make games much more complicated than what was in the 90s, and have a lot less people than AAA teams.

And ya, tons of memory has unlocked tons of capability.

Re: They lied to you. Building software is hard

#56

This article includes a graph with a negative slope, claiming that AI tools are useful for beginners, but less and less useful the more coding expertise you develop. That doesn't match my experience. I think AI tools have their own skill curve, independent of the skill curve of "reading/writing good code." If you figure out how to use the AI tools well, you'll get even more value out of them with expertise. Use AI to…

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…

I’ve seen otherwise intelligent and capable people get so addicted to the convenience and potential of LLMs, that they start to lose their ability to slowly go through problems step by step. it’s sad.

Re: They lied to you. Building software is hard

#57
Software is the hardest thing on planet earth. That's why there's this concept of bootcamps. No other profession has this concept of "bootcamps".

Building a plane is easier than building software. That's why they don't have bootcamps for building planes or becoming a rocket engineer. Building rockets or planes as an engineer is a breeze so there's no point in making a bootcamp.

That's the awesome thing about being a swe, it's so hard that it's beyond getting a university degree, beyond requiring higher math to learn. Basically the only way to digest the concept of software is to look at these "tutorials" on the internet or have AI vibe code the whole thing (which shows how incredibly hard it is, just ask chatGPT).

My friend became a rocket engineer and he had to learn calculus, physics and all that easy stuff which university just transferred into his brain in a snap. He didn't have to go through an internet tutorial or bootcamp.

Re: They lied to you. Building software is hard

#58

Something that's been on my mind recently - what if gen AI coding tools are ultimately attention casinos in the same way social media is? You burn through tons of tokens and you pay per token, it feels productive and engaging, but ultimately the more you try and fail, the more money the vendor makes. Their expressed (though perhaps not stated) economic goal may be to keep you in the "goldilocks zone" of making enough…

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.

Re: They lied to you. Building software is hard

#59
post #53

Fred Brooks, from "No Silver Bullet" (1986) > All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints. Most of the big past gains in software productivit…

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.

Re: They lied to you. Building software is hard

#60

LLMs have clearly accelerated development for the most skilled developers. Particularly when the human acts as the router/architect. However, I've found Claude Code and Co only really work well for bootstrapping projects. 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. It will probably change once the appro…

> 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.

Post reply on HN