> It's 2026 and the notion that you can get detailed enough requirements and specifications that you can one-shot a perfect solution needs to die.

It's 2026 and the idea that even with detailed-enough requirements you can one-shot even a workable (let alone perfect) solution also needs to die. Anthropic failed to build even something as simple as a workable C compiler, not only with a perfect spec (and reference implementations, both of which the model trained on) but even with thousands of tests painstakingly written over many person-years. Today's models are not yet capable enough to build non-trivial production software without close and careful human supervision, even with perfect specs and perfect tests. Without a perfect spec and a perfect human-written test suite the task is even harder. Maybe in 2027.

I completely agree. It's more than 40 years since I wrote my first program, and I've never seen software that was first specified and then written and all was good.

The most difficult part of any non-trivial engineering is understanding the problem, and the first versions of a piece of software are how you reach that understanding.

That's why I do not think that AI-powered "software factories" will ever work. It's waterfall development all over again. An architect writing UML diagrams and handing them off to the team of programmers to do the essentially mundane task of implementing... the wrong thing.

AI is, however, very good at helping you go fast from the wrong first version to the less wrong second one. But you need to remember that your main task is to understand the problem that you are trying to solve.

A previous iteration of my company had a CEO with a simple management idea that I believe worked really well: treat each product team as a mini startup.

That means EVERY role needed to develop the product was in that team. No separate corporate wide QA function, infrastructure and operations function, sales function, project management function, or domain expertise function. All the people performing those functions for that project were part of the project team.

Now this is somewhat hyperbole as if there is no sharing of resources whatsoever you don’t really have a single corporation.

But the idea is clarifying and helps to eliminate silos and tighten communication and feedback loops.

I miss that style of working. Although I try to break those barriers where I can as an individual contributor by just figuring out who needs to talk to who to make things happen and opening those channels of communication.

I don't agree.

I regularly get pieces of work someone product guy has thought up in an afternoon. They only care about the happy path, and sometimes only part of the happy path. I work for a global company that has to abide by rules and regulations in each country we operate in. The product guy thinks up some feature, we implement the feature, then we're told "actually, we legally aren't allowed to do this in 90% of the markets we operate in". Cool, so we add an ability to disable it in those markets. Then they come back "We can do this in some of those markets if it's implemented with [regulatory bureaucracy], so can you do that please".

Then we have to hack away at the solution because the deadline is right around the corner.

This is not software engineering! None of this is related to the software. The job of a software engineer is to take a list of requirements and figure out the way we accomplish those requirements. Requirements gathering is NOT a software engineering problem. Software is implementation, product is behaviour. That's the split. The behaviour of the thing we're building needs to be known before we even try to seriously build it.

If someone just held back for week and did their due diligence, we would been able to architect a solution that is scaleable, extensible, easy to maintain and can make the future easier.

This is also the part that AI speeds up the most for me, maybe 100x productivity.

I start with something like this prompt:

"This is a research project around <vague statement>. What do competitors, like <x>, <y>, <z> do around this, are there any blog posts or tech talks?

Are there any academic approaches or recent papers around the topic?

Can you survey any related open source projects? I know of <x> and <y>. Please include analysis of activity, github stars, number of downloads on npm/pypi/crates, and search the web for reviews or complaints or positive or negative blog posts from developers.

All claims should have links to the original sources, preferably with quoted text where appropriate.

We are going to write a research plan for how to produce this report.

The implementation of the plan will spawn subagents to survey breadth, then spawn subagents for each depth topic in detail"

Nailed it. I suspect the OP is a waterfall guy (despite the token references to agile). All the references to documentation is a big clue. When I see "documentation" and "development" running in parallel, as if that's an extraordinary thing, I mentally cross out "documentation" and replace it with "input from stakeholders", which, in an agile world is... YES!! Of course those run in parallel. That's the whole point of agile.

How do you translate "send an email to users" as a feature without a Document? ... also an incredibly waterfall thing. We Don't Do That Anymore. Thank goodness. Because it is incredibly inefficient (and not any less error-prone). And the chances that Some Guy who wrote the Document six months ago really understood the actual problem is...practically zero.

One of my favorite waterfall stories. A friend of mine who does contract programming for <big company>, who said that her projects were always delivered exactly on time, so you never had to apply the "double the estimates rule".

"So your projects always finish exactly on the delivery date original given?!" Incredulity!

"Oh no. They usually take twice as long, but the difference is that, first we deliver what they asked for (which arrives exactly on the original schedule date, but is completely unusable); and then we charge them 3 times as much to deliver what they actually wanted (which takes twice as long)."

Trying to figure out the best way to solve vague requirements is why I got into engineering.

If I got detailed specs, I’d just be a coding robot. I push that work off onto juniors.

I'm seeing decision-makers / people who write requirements starting to use AI as well in my day to day. As before, my job is to read, understand and test those requirements against the real world as I understand it. But same with code. Software engineering for the past (at least) 20 years has had a core focus of "don't trust anyone", this hasn't changed and this takes a lot of time and effort still.

> Now most of the friction comes from alignment and coordination with other teams.

Then I see a solution! Why don't we simply put the entire company on one big team?

Not to mention that ai lets the domain experts create and test proof of concept implementations themselves. This alone has been a revelation for us and saves a tremendous number of design cycles.

> we should reduce coordination overhead and empower individuals and teams to make decisions and execute on them.

Improved collaboration. Says every new CEO and manager. The notion that this is ever going to be solved especially with different experience, views, agendas etc needs to die too. AI is surely not going to help and with that roadblock iterating faster doesn’t help because then people want to try just for trying.

We will see smaller and smaller teams where all this overhead is minimized by handful of people, and more than ever we will see 2-5 people teams creating great software

Yeah I agree, such a fundamental aspect of software engineering is translating ambiguous “asks” into specific requirements. We now have a tool to convert those requirements directly into code.

And yes, architecture and how to actually implement the designs are also part of the requirements.

The code is just the implementation, the actual problem that needs solving is one abstraction level higher.

This is true, but funny thing is: it was also true before AI.

It's UML and outsourcing all over again: If only we can write the perfect UML diagrams representing the ideal class hierarchy, we can just put that in an email, send it to India, then we'll get back exactly the program we wanted, no mistakes!

> Trying to figure out what a vague, title only, feature request actually means.

> My take is that to accelerate processes we should reduce coordination overhead and empower individuals and teams to make decisions and execute on them.

This is funny because it's exactly what the agile/scrum training taught me 20 years ago.