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

> You are absolutely building the kitchen, the living room, the bathroom as you put in the foundation, framing, the plumbing, the electrical work, etc

OK, the kitchen and the bathroom are special cases due to the plumbing and so on, so my analogy breaks down a bit there, but the rest of the rooms? They don't crystalise their function until the occupants move in. Maybe I as a builder might assume a certain room will be the living room, and designate another as the master bedroom, but until the owner puts in funiture, they're more or less just empty boxes with power and windows. Most of the 'features' or user stories of the house arise at the end out of the combination of built elements and final decoration. Software is actually a lot like this - take a trivial example user story of creating an invoice. What do you need for that? UI, data storage, comms maybe, some domain logic. Each of those things can (and in my opinion should) be expressed independently, but if you're developing that user story as a single deliverable, then you need to create bits of all of them. And that's what I'm saying - we're building things that naturally decompose into 'horizontal' layers (units of infrastructure), but doing it in 'vertical' slices (user stories), which, to torture my analogy even further, results in uneven flooring, mismatched walls, and untidy structures that get more and more difficult to change over time as requirements change and more builders try to add other slices of building that were not anticipated.

If you want to sleep in the lounge from now on instead of the bedroom, and entertain your guests in the back bedroom, you can just move the furniture. That's a lot more agile in my opinion than the software we commonly build.

OK, it's just an analogy, to make a broad point about the approach to design and construction. But you absolutely can design software in that way - I do it, and it works very well. It's not easy, but as I said in another comment, it delivers robust solutions that are nonetheless adaptable to change and easy to maintain. By contrast the 'agile' projects I've worked on were either a tangled mess, or else failed spectacularly.

> This isn't how writing code works

Maybe that's not how you write code, but there are many different ways to paint that particular fence, no? I've been coding for a long time and for me, this is the approach that I've landed on that's the best I've found so far. To me, the idea of feature-led development is, to put it mildly, nonsensical.

> But... reviewing code is harder than writing code.

For me it's very clearly the opposite. I wonder if it's a professional background, or personality or neurotype issue or something, but when I'm faced with a problem I often get somewhat paralyzed, spending a long time thinking about a good approach, but when I delegate to someone or ask an AI to tackle it, even if I get back something half-shitty, it removes my paralysis and then reviewing and improving what they did is significantly easier (or at least more motivating) for me than doing it from scratch. And even if they ended up giving me something that's entirely in the wrong direction, and I need to throw out all of it, I still usually feel that it removes that paralysis and gives me a better understanding of the problem space.

I wonder if this difference between people accounts for a significant different between those who benefit from AI and those who don't.

Slicing a cake across layers is about prioritising value and mitigating the risk of building the wrong thing. Most product and feature requirements are hypothesis for creating value, unless that hypothesis has already been validated.

> It's very convenient for the stakeholders to see progress mapped out like that It's important for the business to validate product value. This is not just progress anxiety.

Crafting software to perfection is ultimately a waste if it doesn't provide value to the business or customer. If we are sure we're building the right thing, we can risk more, and spend more of our time building the thing better. Build scrappy first, build confidence in value, and then craft to perfection.

The slices of cake aren't built in isolation. Every time a slice is being worked on, it is integrated back. The cake analogy falls apart here, because cakes (and houses) aren't nearly as malleable as software. We have opportunities to refactor it every step along the way, and change its shape. Yes, sometimes we refactor independent of business value, and I think that's essential too. I don't think the idea that's presented is to have absolutely every slice be vertical, and business / customer facing.

> do you finish working on one leg first before you move onto some other part?

Depends on the physical process. Are you carving, casting, bolting or welding or using 3d modelling and printing … ?

> trying to stick them together just results in a fragile mess

If it's a physical cake.

If it's software we seamlessly add functionality to each layer as needed.