Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Software Engineering fundamentals matter more

rhonabwy.com

Post reply on HN
Print view View original

31–40 of 266 posts

Re: Software Engineering fundamentals matter more

#31

Post by user43928 »

The article says what many here like to hear, but in my opinion the core arguments are false.

> Making software debuggable, maintainable, layered, and composable – that’s still quite a trick

Not really. I have been working on a mobile app for months, and I stopped even glancing at the code about two months ago.

150k LOC, around half of that in tests, and the AI still has no problem maintaining the code on my behalf.

Debuggable? It can add extensive instrumentation in seconds.

None of this requires expertise, prompting, or mention of TDD. It's the default.

Frankly I do not believe the author tried developing a large codebase fully agentic and without reviewing the code. I believe many here look at the code produced, deem it substandard, and go hands on.

> They’re foundationally incapable of always and consistently preventing prompt injection attacks

From Anthropic's article about the Auto mode:

> We commissioned an evaluation from a third party, Trajectory Labs, who tested different models within the latest publicly available versions of Claude Code and Codex as of July 17th 2026.1 They tested 72 indirect prompt injection scenarios held out from Anthropic

> In this evaluation, none of the 720 attack attempts succeeded against Claude Fable 5, Opus 5, or Sonnet 5 running auto mode. On the other hand, 5.83% of the attacks succeeded against GPT-5.6 Sol running Codex's Auto-review mode. Notably, this is greater than the 0.09% average attack success rate against our latest models running in bypassPermissions mode without additional safeguards. The tests showed a 19.03% attack success rate against GPT-5.6 Sol when running in Full Access mode

I'm sure someone is going to reply with how they do not trust Antrophic's research, but lacking other data, prompt injection appears to be largely solved already.

Re: Software Engineering fundamentals matter more

#32

Post by necovek »

danielbln wrote: post #26
slopinthebag wrote: post #23

Earlier quoted context omitted.

Where is the reasoning in linear regression?

Where is the reasoning in synaptic transmission?

There isn't, which is exactly the point: we do not yet understand the fundamentals behind reasoning.

Re: Software Engineering fundamentals matter more

#33

Post by hbcdbff »

user43928 wrote: post #31

The article says what many here like to hear, but in my opinion the core arguments are false. > Making software debuggable, maintainable, layered, and composable – that’s still quite a trick Not really. I have been working on a mobile app for months, and I stopped even glancing at the code about two months ago. 150k LOC, around half of that in tests, and the AI still has no problem maintaining the code on my behalf.…

How do you expect us to take your views on LLM code quality and durability seriously when a) you don’t even look at the code and b) you’ve only been doing this for two months?

Re: Software Engineering fundamentals matter more

#34

Post by hbcdbff »

slopinthebag wrote: post #12
theteapot wrote: post #8

> It helps to know that LLMs don’t “reason”. They predict .. Semantics. Prediction is the training objective. The ability to reason can be, and very arguably is, an emergent property of that.

Why would "reasoning" be an emergent property of prediction?

Why wouldn’t it?

Re: Software Engineering fundamentals matter more

#35

Post by siva7 »

slopinthebag wrote: post #7
mortalapeman wrote: post #5

With generated code, the directory structure, interface design and general state management is usually a haphazard mess. Even with the best frontier models. But what really gets me is the model often tries to make assumptions for me that I didn't specify in the prompt. Subtle things like which error states are "oh shit we need to bail" vs "this isn't a deal breaker." Sometimes it will ask, but more often than not it…

They're RLHF'ed to an inch of their lives to be able to one-shot complete tasks, since requiring human input defeats the purpose of being able to replace the labor force. But once the insanity ends LLMs will be packaged as tools for developers to use to boost their productivity, and we'll consider them as we do IDE's and debuggers and stuff. But we have to get through this hype cycle first.

wake up, slopinthebag. wake up..

Re: Software Engineering fundamentals matter more

#36

Post by szundi »

bluegatty wrote: post #15
mortalapeman wrote: post #5

With generated code, the directory structure, interface design and general state management is usually a haphazard mess. Even with the best frontier models. But what really gets me is the model often tries to make assumptions for me that I didn't specify in the prompt. Subtle things like which error states are "oh shit we need to bail" vs "this isn't a deal breaker." Sometimes it will ask, but more often than not it…

The generated code is fine at the functional level, the directory structure is usually the standard pattern for the given type of project. The error types and codes, it will produce to spec. If you type 'make me that thingy' - yes, it's probably not going to do what you want, but if you give it spec and guidance, it usually will. The 'interface design' ... not very good though.

[dead]

Re: Software Engineering fundamentals matter more

#37

Post by anon48293 »

necovek wrote: post #32
danielbln wrote: post #26

Earlier quoted context omitted.

Where is the reasoning in synaptic transmission?

There isn't, which is exactly the point: we do not yet understand the fundamentals behind reasoning.

Don’t we? We can build something which has all the output associated with reasoning.

I’d say we’ve figured out the fundamentals behind reasoning.

Re: Software Engineering fundamentals matter more

#38

Post by Alien1Being »

AI generated code is like IKEA furniture.

IKEA furniture embodies many elements of good cabinet making but skips many nonessential elements. And does this more consistently than cabinet makers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day.

In the future AI code inevitably will embody most good software engineering practices. And will do this more consistently than software engineers who can be bored, incompetent, depressed, burnt out, resentful, tired, having a bad day.

Just look at the messages on HN or around you at your colleagues to see how mediocre the average software engineer is..

Today's IKEA is good enough for most people.

Tomorrow's AI coding will be good enough for most corporations.

Good enough to vastly reduce the need for fine craftsmen and women / software engineers.

Good enough to deskill those who call themselves cabinet makers / senior software engineers. These days the cabinet makers I personally know just do contract kitchens for project builders.

But IKEA is and AI will be, bad enough that at the high end with special requirements / taste / money / an inflated sense of self worth, some furniture makers still exist and thrive.

Perhaps 1% percent of current software engineers of today will be needed in the future when AI code inevitably has the ability to follow good software engineering practice.......

And as usual it will mainly be the mediocrities that remain ( so there is hope for you too ), with occasional islands of excellence.

Re: Software Engineering fundamentals matter more

#39

Post by TheWrongGuy »

theteapot wrote: post #8

> It helps to know that LLMs don’t “reason”. They predict .. Semantics. Prediction is the training objective. The ability to reason can be, and very arguably is, an emergent property of that.

By that standard, human brains don't either. Our externalizations of concepts like language or symbolic structure allow us to do so. In the parlance of our times, we built our own reasoning harnesses because our intuition lead us to do so.

Re: Software Engineering fundamentals matter more

#40

Post by user43928 »

hbcdbff wrote: post #33
user43928 wrote: post #31

The article says what many here like to hear, but in my opinion the core arguments are false. > Making software debuggable, maintainable, layered, and composable – that’s still quite a trick Not really. I have been working on a mobile app for months, and I stopped even glancing at the code about two months ago. 150k LOC, around half of that in tests, and the AI still has no problem maintaining the code on my behalf.…

How do you expect us to take your views on LLM code quality and durability seriously when a) you don’t even look at the code and b) you’ve only been doing this for two months?

I've been working on the app for four months, and I am clearly not talking about code quality.

I am talking about product quality and maintainability. Both are more than adequate.

I know this because I have worked on it for an estimated 300 hours. Has the author practiced a similar approach for even a week? I doubt it.

Post reply on HN