I read it as after requirements and before code. This is how I would expect it to work too. It reads the existing codebase, which also makes sense for non greenfield projects as in the example.
The Eisenhower quote comes to mind: "Plans are worthless, but planning is everything."
If you don't start with approximately the right destination, you're definitely never going to end up there, even if you have to take some detours and compromise on some choices.
It gets really frustrating reviewing people's designs at times, when it's crystal clear they're a) working backwards and b) haven't really considered the customer experience at all.
One of my favourite tell tale signs of a) is when the chosen option 100% fits the specifications, doubly so if there's no cons associated with the pros. Sometimes it's genuine, but very rarely.
I slightly disagree. Plans are really useful for enhancements. If we stick to original plans & patterns as we extend & add new features, we can slow down the decay process.
Re:AWS launches Kiro, its Cursor clone
by danbeaulieu on Monday July 14, 2025 @09:44PM
(#44567106)
Kiro takes the requirements and the existing code to create a spec.
Otherwise the spec may cover requirements that are already met in the existing code and needs to understand integration points it needs to include in the spec.
Having used Kiro myself I think it does what you expect.
This is nice for documentation but really having a design document after-the-fact doesn't really help much. Designing is a decision-making process before the code is written.