←back to thread

The quality of AI-assisted software depends on unit of work management

(blog.nilenso.com)
170 points mogambo1 | 1 comments | 18 Sep 25 13:06 UTC | HN request time: 0.208s | source
Show context
OptionOfT ◴[18 Sep 25 15:22 UTC] No.45290784[source]▶
And the value of AI as pushed to us by these companies is in doing larger units of work.

But... reviewing code is harder than writing code. Expressing how I want something to be done in natural language is incredibly hard.

So over time I'm spending a lot of energy in those things, and only getting it 80% right.

Not to mention I'm constantly in this highly suspicious mode, trying to pierce through the veil of my own prompt and the code generated, because it's the edge cases that make work hard.

The end result is exhaustion. There is no recharge. Plans are front-loaded, and then you switch to auditing mode.

Whereas with code you front-load a good amount of design, but you can make changes as you go, and since you know your own code the effort to make those are much lower.

replies(5): >>45291216 #>>45291738 #>>45291762 #>>45298898 #>>45301645 #
nicce ◴[18 Sep 25 16:35 UTC] No.45291738[source]▶
> Expressing how I want something to be done in natural language is incredibly hard

Surprise, surprise… that is why programming languages were created.

replies(2): >>45291806 #>>45297471 #
dragonwriter ◴[18 Sep 25 16:40 UTC] No.45291806[source]▶
Programming languages don’t solve that problem, since someone still has to explain what needs to be done in natural language unless the end customer is also the programmer.

Programming languages were created because of the different problem of “its very hard to get computers to understand natural language even if you know how to express what you want in it”.

replies(4): >>45291960 #>>45294677 #>>45295928 #>>45297725 #
1. derefr ◴[18 Sep 25 22:44 UTC] No.45295928[source]▶
> someone still has to explain what needs to be done in natural language unless the end customer is also the programmer

You're conflating requirement analysis with design. The customer only needs to describe the problem — a set of constraints on what comprises a valid solution. The software engineer is then free to design and develop a particular valid solution (and show it to the customer, which will result in more feedback, which will feed back into design, and so on.)

Formalizing this split is the premise behind Domain Driven Design (DDD): you can sit with the customer and pin down a problem description (= set of design requirements) together with them, expressed in exactly the natural language the customer-as-problem-domain-expert uses, without any reference to any particular potential design's solution-space domain. You can then turn around and reuse that set of natural-language statements as the skeleton of a test suite, that "enforces" the customer's expectations upon any potential design you create.

It's a lot like an artist sitting with a customer who's commissioning them, with the artist sketching something the customer is describing; and then the artist going away to actually illustrate/paint/craft/design/etc the thing, constrained by that sketch.