Live data from Hacker News

Software Engineering fundamentals matter more

rhonabwy.com

191–200 of 266 posts

Re: Software Engineering fundamentals matter more

#191
post #9
post #2

> In the past year, agent harnesses crossed the “can it be done” rubicon. Brother, I'm still in "Can you get it right?"-mode. What am I doing wrong? (Rhetorical, but advice welcomed).

Tell it to use red/green TDD and start things off with an already configured test suite, maybe with a single test that asserts 1+1==2. Make sure it know how to run the tests before it starts writing any additional code. Then set it a clear goal.

> Make sure it know how to run the tests before it starts writing any additional code.

Thank you for this advice. I can absolutely see how such advice could be helpful, and considering I have created environments (containerized) where that is not always possible, then that might explain some of my past results. XD

Do you have any advice on how to make LLMs actually follow instructions and how to prevent them 80/20-ing every task?

By the way, I appreciate you taking the time to reply. Thank you for you current and past contributions, I had a lot of fun with Django when I was in college.

Re: Software Engineering fundamentals matter more

#192
post #58

Earlier quoted context omitted.

Ikea cabinet is pleasant to look at, and its design makes sense.

But how many times can you take a piece of Ikea furniture apart and put it back together again? I have friends who have moved apartments with the same Billy bookshelf 2-3 times and if they tried it one more time the thing would collapse. Not to belabor the metaphor as heavily as my friend's Billy, but there's a maintenance corellary to be made here. Most Ikea furniture can be put together once, in one place, and left…

You pick cheapest most replaceable item from all there is in IKEA and make it an example?

Re: Software Engineering fundamentals matter more

#193
post #2

> In the past year, agent harnesses crossed the “can it be done” rubicon. Brother, I'm still in "Can you get it right?"-mode. What am I doing wrong? (Rhetorical, but advice welcomed).

I’ve found some success is small projects, with limited scope, in a greenfield. I’m terrified to attempt agentic anything in the repo my job actually cares about. I triggered it once by accident, when the agent was first rolled out and enabled by default… it broke everything. Now I just use ask mode, and even that is wrong half the time, and once it goes wrong it just keeps getting worse. I saw a post from Dave Plumb…

I concur with your first sentence. I have found success creating some sort of MVP, but I have had virtually no success with taking something from initiation to completion.

My employer won't even provide LLMs for us, let alone allow us to use agentic coding on our repos. All our code is still USDA certified, organic, free-range code.

> He said his spec document for the AI was 107 pages long.

Absolutely not. My ADHD forbids such temptations of the dark arts. I'll feed any LLM a 107 page spec list, but I won't be writing nor reading that spec list.

Re: Software Engineering fundamentals matter more

#194
post #20
post #2

> In the past year, agent harnesses crossed the “can it be done” rubicon. Brother, I'm still in "Can you get it right?"-mode. What am I doing wrong? (Rhetorical, but advice welcomed).

You're appealing to ambiguity. All you've said is you have failed—how is anyone supposed to know what went wrong?

I suppose they aren't, but I am perfectly fine with reading what has worked for others should they feel inclined to share.

Re: Software Engineering fundamentals matter more

#195

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

I've never found these discussions to be all that useful, because it's hard to define what conditions are sufficient to say something is "thinking" or "reasoning". It just ends up being circular and metaphysical arguments.

That being said, current generation LLMs do have issue, it's more productive to talk about those and their impact on real tasks (long term memory, continual learning, tokenization, context rot, reversal curse, etc)

Re: Software Engineering fundamentals matter more

#196

Earlier quoted context omitted.

Back in the day artisans took care of horses and new have cheapened ourselves to use stinky cars. Back in the day we built computers with relays by hand, now we have cheapened ourselves to use weird semiconductors and use inefficient python code instead of highly optimized hand crafted assembly. Maybe we should go back to hunting and gathering?

Typical sentiment I see that completely lacks any nuance. For one car vs IKEA are two completely different beasts entirely. A car opened up new avenues that a human could never do before its invention. This itself makes it a far more worthy invention than most. IKEA cheapened stuff and gave low quality cookie cutter furniture to everyone. Was this really a great thing, that propelled humanity forward? It’s also not l…

IKEA allowed people to afford decent quality furniture who otherwise couldn’t afford it. That’s a huge benefit in my view. Your “spend a bit more” is actually a huge amount for artisanal quality furniture.

That’s how commodization has always worked. Something is suddenly available for the masses with maybe some loss of quality.

Look at Excel. A lot of elitists look down on people doing complex stuff with it but in reality it has enabled many people to do stuff they would otherwise have to pay a ton of money for.

Back to furniture. You are free to buy artisanal furniture but for a lot of people worldwide it would be a huge loss if Ikea didn’t exist.

Re: Software Engineering fundamentals matter more

#197
Scenario: an AI lab develops ASI for software development internally. The ASI produces bug-free software and human-readable specs. It's so reliable the company can guarantee the code matches the spec.

Rather than provide tokens to developers, they instead sell finished software to the companies: specs in, software out.

Companies no longer need to employ software developers. Instead, they buy bespoke, bug free, guaranteed quality software from the AI lab.

Seems plausible to me.

Re: Software Engineering fundamentals matter more

#198
post #70

I have an open question for software engineers out there: As someone that has never studied CS but has written basic code most of my life (accelerated now with AI), where is the best place to learn software engineering fundamentals?

I don't think you can learn without doing the actual work where normal constraints apply so you can test and see the pros and cons of different approaches to different aspects of the problem(s).

You need a limited budget, limited timeline, limited capabilities in team and software tools+systems, and you need to be on the hook for support, maintenance and long term extensibility.

Software engineering is an optimization problem balancing all of the above and much more. There is no one answer to any problem, but more of a general sweet-ish spot (or more like region than spot) of balancing the competing priorities.

Re: Software Engineering fundamentals matter more

#199

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…

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

As always it's a usage problem, specifically you aren't pre-feeding it a large enough sample of reference code that it can use for context. I have a custom functional DSL that I prefeed the BNF + about few thousand lines of code and it has no problem writing it, in almost the same style as the reference. Literally point your model to a reference repo as say "read this entire repo and replicate the codestyle + directory structure exactly".

Re: Software Engineering fundamentals matter more

#200
post #2

> In the past year, agent harnesses crossed the “can it be done” rubicon. Brother, I'm still in "Can you get it right?"-mode. What am I doing wrong? (Rhetorical, but advice welcomed).

What is “it” specifically and what languages are you using?

"It" is a lot of things.

Languages:

- C#/.NET: Sufficient sometimes, but not how I'd write things. Most results at least compile, but I have noticed plenty of defiance towards particular instructions, e.g, "Do not use , use " -> code contains and not .

- C#/Godot: I have noticed the greatest amounts of defiance here. Not to mention most results are an 80/20 implementation of what I asked for. And no, I am not trying to one-shot a full game or anything.

- AArch64 and x86: great results surprisingly, though only small amounts were produced. Mainly, assistance with RE-ing and cracking some binaries from https://crackmes.one or where ever.

- The Lord's Language (Swift): Maybe the LLMs are better at SwiftUI/Swift, but I have had some rough results going down the opposite direction of the software stack. I have on/off been working on a personal, FOSS "productivity" tool for macOS, e.g., mouseless navigation, window management, GUI automation, etc.. This type of development requires a significant amount work with C APIs like CoreGraphics, Accessibility, CoreFoundation, etc.. The code isn't the problem for me, it's the lack of useful debugging. LLMs, last I have tried (around Opus 4.6 times), seemed to really struggle with things like CoreGraphics Y-axis coordinates being inverted compared AppKit's and other stuff like that.

- Applescript (GUI automation): Do not even waste your time trying (I fault no LLMs for this either).

- elisp: the code is usually sufficient, though package config can be a little dicey.

- Shell scripts (Zsh, Bash, Powershell): great results.

- Python: I try to avoid this language unless necessary, but the results have been great.

These days, I use the plain Web chat interfaces for about 95% of my usage compared to the CLI harnesses. Sometime ago, I realized I get better results that way. With the web chat, I would say my results have been outstanding.

Post reply on HN