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

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

blog.nilenso.com

Post reply on HN
Print view View original

101–110 of 127 posts

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

#101

Post by fragmede »

jnwatson wrote: post #94
citizenpaul wrote: post #71

Earlier quoted context omitted.

I've been downvoted before for saying my take on this but... Its because SE is a low class low power field. Its not respected by the people in charge at the overwhelming majority of companies. It has resisted standardizing like lawyers, doctors or even real estate agents. So there is little leverage a person in the field can push back with. Its mostly just seen as an annoyance to gaining/consolidating power for the p…

> "SE is a low class low power field" This is the difference with FAANGs. Software engineering is king. The inmates are running the asylum. Google is at least 4x as efficient as other large companies I've worked for. Nearly every internal process that can possibly be automated is.

I was there for three years and you're totally right that everything's been automated, but also there are a large number of product level decisions that just don't make sense. They make financial sense, sure, but then that means the engineer has drank the MBA cool aid (or not enough of it), things get killed off, and they are no longer to be trusted around things that need proper love and care put into them. Promo packets though, sure.

https://therussofirm.com/man-dies-after-following-google-map...

It's hard to read that as a human, though, and not want to build a system that lets people update bad map data? Which there used to be, but then yeah.

So yeah, the inmmates (engineers) used to run the asylum (Google), but then a group of fucking psychopaths (DoubleClick) got added to the asylum, got given meth (ad money) and shits fucking unhinged.

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

#102

Post by rjh29 »

OptionOfT wrote: post #38

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 p…

Don't spend energy on clever prompting and reviewing. Spend your energy on knowing when to use the LLM at all.

If you know what to write but it's tedious, LLMs are great, they'll just fill all that in for you. Anything more complex or open that needs checking could be quicker to just think through and write yourself. You can still use LLMs at the edges, e.g. what API methods should I use for this?

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

#103

Post by ath_ray »

danparsonson wrote: post #58

I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cas…

"Unit of work" here is the unit for software delivery, and it can be decoupled from how any individual developer plans and executes whatever software they are delivering.

Product requirements are a hypothesis for creating business value, and the only way to test that hypothesis is to actually demonstrate a slice of that value in a way that's legible to all stakeholders involved.

This post is a nice articulation of this: https://blog.nilenso.com/blog/2025/09/17/the-common-sense-un...

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

#104

Post by dragonwriter »

soraminazuki wrote: post #96
dragonwriter wrote: post #53

Earlier quoted context omitted.

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

I don't but that. In the same spirit, are you telling me that you solve math problems without using any mathematical notation because it doesn't offer any improvement over natural language?

> In the same spirit, are you telling me that you solve math problems without using any mathematical notation because it doesn't offer any improvement over natural language?

That’s not in the same spirit, and I didn’t say either that programming languages don’t solve any problem, or that there aren’t tools that do solve the problem it was suggested that programming language solve where it exists, which isn't (except maybe since the advent of LLMs) between human and computer.

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

#105

Post by discreteevent »

ath_ray wrote: post #103
danparsonson wrote: post #58

I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cas…

"Unit of work" here is the unit for software delivery, and it can be decoupled from how any individual developer plans and executes whatever software they are delivering. Product requirements are a hypothesis for creating business value, and the only way to test that hypothesis is to actually demonstrate a slice of that value in a way that's legible to all stakeholders involved. This post is a nice articulation of th…

That post seems to say that the unit of work must be something customer facing. It even qoutes Kent Beck talking about "Weekly delivery of customer-appreciated value".

There is so much great software in the world that wasn't delivered like that and couldn't be delivered like that: Unix, Microsoft Word, Postgres, AutoCAD, The JVM, Google search, Windows, AWS, Robotics, Calculators ....

The software industry seems to have been captured by contractors who used to deliver CRUD apps and now want to make the whole world in their image and likeness.

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

#106

Post by dragonwriter »

SkyBelow wrote: post #78
dragonwriter wrote: post #53

Earlier quoted context omitted.

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

>Programming languages don’t solve that problem The idea is that a programmer will work with natural language dynamically to create enough of an understanding to create a formalized specification within the programming language (eh, we technically need to include the entire ecosystem needed to run the code, but rarely is that an issue). Often it won't be perfect, but then a demo can occur where natural language can t…

> The idea is that a programmer will work with natural language dynamically to create enough of an understanding to create a formalized specification within the programming language

I don't disagree that that is some people’s idea of the idealized process (though there are others, too.)

I disagree, though, that it is the purpose for which programming languages, as a category of tools, were invented. In fact, there were a whole bunch of tools for solving the problem of clarity of communicating expectations of sysstem behavior between humans in unconstrainted natural language invented, and that it was until fairly recently (well into the period of dominance of Agile, or at least “Agile”, methodss) the usual expectation in non-trivial programming projects that some combination of those would be used to solve that problem, and then the programmers, understanding the intent through those tools, would use programming languages to solve the problem that languages that are ideal for communicating between humans are not ideal for source languages for practical compilers or interpreters in computers.

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

#107

Post by RealityVoid »

rjh29 wrote: post #102
OptionOfT wrote: post #38

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 p…

Don't spend energy on clever prompting and reviewing. Spend your energy on knowing when to use the LLM at all. If you know what to write but it's tedious, LLMs are great, they'll just fill all that in for you. Anything more complex or open that needs checking could be quicker to just think through and write yourself. You can still use LLMs at the edges, e.g. what API methods should I use for this?

I like using LLM's for exploration of a new codebase, seeing what other options already exist for solving a solution I might not be aware of and planning a bit how to change stuff, since it sometimes sees thing I did not think of.

Another thing it's good at is writing tests - a lot of times I won't bother, but with AI I can do it cheaply. And it's very good at keeping documentation and a codebase consistent, believe it or not. If I change a part that is mentioned somewhere else and it has it in the context window, it will update both parts, whereas I might omit it.

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

#108

Post by trash_cat »

>> "Turns out the major bottleneck is not intelligence, but rather providing the correct context."

But this has more or less always been the case for LLMs. The challenge becomes context capure. Which in my opinion is the real challenge with LLM adoption. Without the right contex, some tasks just cannot be reliably completed.

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

#109

Post by danparsonson »

galbar wrote: post #61
danparsonson wrote: post #58

I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cas…

My take on this is that, from a SW development POV, user stories are not the right unit of work. Instead, I treat user stories as "Epics". Stake holders can track that Epic for progress, as the unit of work from their POV. Internally, the team splits Epics into "Spikes" (figure out what to do) and "Tasks" (executing on the things we need to do). - Spikes are scoped to up to 3 days and their outcome is usually a doc a…

Well OK, but that's just the same thing with extra steps.

The point I'm making is that there are large cross-cutting concerns that shouldn't be sliced up by feature, but rather that the features should arise out of the composition of the cross-cutting concerns.

A single user story commonly requires the holy trinity of UI, 'business logic' and data storage, and my contention is that it's more efficient and robust to build those three layers out holistically rather than try to assemble them from the fragments required for all the user stories.

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

#110

Post by danparsonson »

ath_ray wrote: post #103
danparsonson wrote: post #58

I seem to be in a minority but I find user stories or features to be really awkward and unnatural units of work for building software. Sure these things help to define the expected result but they shouldn't directly drive the development process. Imagine building a house that way - you don't build the living room, then the kitchen, then the bathroom etc.; you build floors, walls, the roof... The 'features' or use cas…

"Unit of work" here is the unit for software delivery, and it can be decoupled from how any individual developer plans and executes whatever software they are delivering. Product requirements are a hypothesis for creating business value, and the only way to test that hypothesis is to actually demonstrate a slice of that value in a way that's legible to all stakeholders involved. This post is a nice articulation of th…

That's the point though, thinking of delivery in terms of slices of business value naturally leads one to break application development along those lines. It's very convenient for the stakeholders to see progress mapped out like that, but it tends to lead to fragile and poorly-architected systems that are difficult to change in the future (and therefore not lower-case A agile).
Post reply on HN