Comment by liampulles | Hacker News Reader

Comment by liampulles | Hacker News Reader

Parent Full thread

I know many programmers for whom "developing domain understanding" is an abstract concept (if indeed, it is a concept for them at all). But in the age of big AI, I see more need for this, not less.

At least this is my observation: when my colleagues have been wholesale chucking stuff over to Claude, they've then been confronted with classic XY-Problem shit, poor user experiences, and over-complex solutions (which will mount future problems regardless of whether a person or an agent iterates on that code). Much of this can be solved by actually sitting down and thinking about it, and I mean at a code design level, not just a speccing level.

Many people don't realize that there are more useful outputs to solving a problem than just a mere solution. Obviously if one has a contractor mindset (you don't care about the after effects of a system) then this is of no relevance to you. Some companies promote that mindset, certainly ones that have no broader aspirations then getting acquired soon. That's fine - but many companies actually are about sustainability, and understanding in these places is paramount.

Agree 100%, especially with your second paragraph. The majority of domain experts I've interfaced with in my own domain, along with things I am not an expert in, are typically experts not because of the solutions they build, but because of the things they _don't_ build. It is the cliche "a clever person solves a problem, a wise person avoids it" paraphrase.

But I think what is lost is the value in (a) person(s) who intuitively spots and avoids these problems. My hypothetical example that I have seen play out: The domain expert spots one of these problems and succinctly explains that the problem doesn't need to be solved. Maybe it's a byproduct of bad design elsewhere, or there is a much better solution that avoids it altogether. Once the rest of the team/the lead catches on, either hindsight bias or outcome bias, or a combo, takes over and they don't recognize that all the value all along was in the person being able to spot this situation. They throw that in claude and claude does it's sycophant thing (after expressing that the previous situation was flawless for however long), and they are off to the races right back to automation bias with zero pause for thought...

To me, "domain knowledge" seems to resemble a primitive form of "slop filter" to use the modern parlance. In any field, the majority of possible ideas are slop. This has always been the case. People somehow learn to navigate through the slop, to find things that are worth working on.

Even before the AI era, we were flooded with a veritable DDOS attack of slop, in our in-boxes, meetings, etc. Managers believed that innovation was held back by quantity of ideas, or by the domain experts being "resistant to change." This led to day-long group brainstorming sessions that yielded nothing. Part of the transition from student to junior to senior is learning to filter your own ideas, and to guide others in the search for ideas that are likely to be fruitful.

The criteria for slop filtering have always been subjective, arbitrary, or driven by institutional culture. That's what we've got. Any means of generating ideas produces slop in the absence of filtering.

What will slop filtering look like when the AI can generate tera-proofs per second? What does it look like already for our e-mail inboxes? We are asymptotically trending towards slop filters that look more and more like "ignore everything." I already read none of the business memoranda that I receive. I don't answer my phone. The number of workers needed to read and assess business memoranda is zero.

The slop filter still functions in math. Problems are pre-filtered for being of interest. Somebody expressed enough interest in the Navier-Stokes problem to give it a name and attach a prize to it. There are still plenty of "prize problems." Here are some:

* Quantum gravity

* Improvement of superconductors that don't need helium

* Practical generation of power from fusion

hmmmm. Good points. esp:

> Part of the transition from student to junior to senior is learning to filter your own ideas, and to guide others in the search for ideas that are likely to be fruitful.

I wonder how that'll change over time now. I think it's pretty important to have a few instances of thinking hard to come up with ideas and being totally convinced they are correct, only to have someone else trounce them with one or two succinct thoughts of their own. Those were very big personal development moments for me. And equitable, I still have folks with a lot less exp/time come out of left field with maybe not as formulated, but amazing ideas.

Domain knowledge... Not with the culture of software engineers leaving the company after 1 year

I had an agent (SOTA models, xhigh reasoning, etc.) write and optimize some CUDA code recently. They've gotten a lot better at this stuff. And yet, they couldn't (self-)realize the obvious issue with their code: it was written as if for a typical multicore CPU. What the heck was a (serial) queue doing there? "Work efficiency" as a tradeoff for stalling 20k threads. Its later proposed optimizations were all about "can we get the queue faster" rather than "maybe we should actually parallelize the work for our very-parallel processor".

Funny stuff, as if it were hell-bent on writing a paper rather than actual software.

Sometimes a session just goes bad and is best abandoned or rolled back to before it went off the rails. I've also been using agents to write and optimize CUDA (and the C++ app code) recently and didn't run into anything so braindead. But, I had one session recently where the LLM started making duplicated tool calls and just couldn't stop doing it. Had to generate a handoff and start again in another session and haven't run into that specific problem again. I don't remember specifics at this point but once and I while I have to rollback a session a half dozen turns when its clear the agent had gone completely off the rails.

Reply on news.ycombinator.com