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

71–80 of 127 posts

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

#71

Post by citizenpaul »

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…

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 power brokers on their way up the ladder.

That really is what computers/software are. Huge engines for orchestrating power that kings of old couldn't dream of.

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

#72

Post by Jensson »

citizenpaul wrote: post #71
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…

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…

> It has resisted standardizing like lawyers, doctors or even real estate agents.

You can't standardize a field that changes so fast, it takes decades to standardize a field and there has never been a point in time of software where two decades didn't completely changes the job.

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

#74

Post by gizmo686 »

nemomarx wrote: post #60
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…

They make more sense if you think about adding to an existing house. "I want to open up this wall to serve X function" kinda work they're very well adapted to legacy enterprise work

Even there, "open up this wall" is not a unit of work. You need to:

* Evaluate what, if any, structural implications removing the wall has * Tear down the existing wall * Redo any plumbing, ductwork, wiring, etc that was hiding in the wall * Remediate structural concerns from removing the wall. * Redo the flooring * Repair and repaint any damage done to remaining drywall

If this is part of a larger renovation, you will likely schedule work so the above tasks happen at the same time as other similar tasks.

E.g. A meaningful unit of work might be "electrical roughing", which would include both moving wires that were previously in the wall, and running a new circuit to the garage for a car charger. No user story covers those to tasks, but the nature of renovating a house means that it makes sense to do them together.

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

#75

Post by citizenpaul »

Jensson wrote: post #72
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…

> It has resisted standardizing like lawyers, doctors or even real estate agents. You can't standardize a field that changes so fast, it takes decades to standardize a field and there has never been a point in time of software where two decades didn't completely changes the job.

There is almost nothing new in CS since the 1970's. Even LLM's were invented at least theoretically back then.

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

#76

Post by magicalist »

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…

I don't think the analogies are that helpful. You are absolutely building the kitchen, the living room, the bathroom as you put in the foundation, framing, the plumbing, the electrical work, etc, or you will get either an unusable house or a very expensive gutting and remodel. User stories are figured out for the house long before any construction begins. House building is well on the waterfall side of development anyways, but at this point, what insight is this analogy yielding?

Call user stories a grouping of work, sure, but I guess I don't see why the distinction matters. Most possible "units of work" will have many cases worth breaking down further regardless of choice of unit.

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

#77

Post by bryanlarsen »

smw wrote: post #44
tedggh wrote: post #35

I found out that summarizing a completed task and feeding it to a new context works better than staying on the same context for multiple tasks. So let’s say I have a sprint with tasks 1, 2 and 3. I start by creating a project with general information including the spec, git issues, code base, folder trees, etc then work on Task 1. When done I ask for a summary using a template, which gives me a txt file describing wh…

Hell, claude even makes that part of the standard workflow, with /compact; cleverly using the llm itself to summarize the previous context

Once you see that message it's time to finish the task without AI because Claude will start crapping over your codebase if you let it continue.

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

#78

Post by SkyBelow »

dragonwriter wrote: post #53
nicce wrote: post #50

Earlier quoted context omitted.

> Expressing how I want something to be done in natural language is incredibly hard Surprise, surprise… that is why programming languages were created.

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 then comment on what was missed, which can then better be captured in the formal language. This continues until we get close enough that further effort to refine isn't justified.

This isn't the only reason programming languages were created, much as rarely anything has a single reason it was created. They were created as a way to get computers to do what we wanted without needing to modify the hardware, and then higher level languages were created so we can write more specification faster while losing a bit of the lowest level exactness.

Also why we have many different programming languages, as they try to fit into different levels of trade off between the different reasons for a programming language to exist. Well, one of the reasons we have many different programming languages....

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

#79

Post by jmcodes »

angusturner wrote: post #15
liszper wrote: post #3

most SWE folks still have no idea how big the difference is between the coding agents they tried a year ago and declared as useless and chatgpt 5 paired with Codex or Cursor today thanks for the article, it's a good one

I think most SWEs do have a good idea where I work. They know that its a significant, but not revolutionary improvement. If you supervise and manage your agents closely on well scoped (small) tasks they are pretty handy. If you need a prototype and don't care about code quality or maintenance, they are great. Anyone claiming 2x, 5x, 10x etc is absolutely kidding themselves for any non-trivial software.

I've found a pretty good speed up just letting Claude Code run with a custom prompt to gather the context (relevant files, types, etc..) for the task then having it put together a document with that context.

It takes all of five minutes to have it run and at the end I can review it, if it's small ask it to execute, and if it actually requires me to work it myself well now I have a reference with line numbers, some comments on how the system appears to work, what the intent is, areas of interest, etc..

I also rely heavily on the sequential thinking MCP server to give it more structure.

Edit:

I will say because I think it's important I've been a senior dev for a while now, a lot of my job _is_ reviewing other people's pull requests. I don't find it hard or tedious at all.

Honestly it's a lot easier to review a few small "PRs" as the agent works than some of the giant PRs I'd get from team members before.

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

#80

Post by bubblyworld »

bluefirebrand wrote: post #47
bubblyworld wrote: post #37

Earlier quoted context omitted.

Lol, what is up with everyone assuming there's no learning curve to these things? If you applied this argument to literally any other tool you would be laughed at, for good reason.

Probably because "there's no learning curve they are just magic tools" is how they are marketed and how our managers are expecting them to work

Sure, but people are allowed to have their own opinions too.
Post reply on HN