super refreshing take! i think the "software engineering is solved" perspective forgets that one of the most core parts of the job is turning smaller unstructured messiness/goals into a candidate (but likely imperfect and iteratively improved) artifact that helps more complex goals get solved. writing code used to be part of this recipe, but the supervision of the artifact is definitely still the same with agents code generation throughout the years has always been about putting bigger and bigger "holes" in your spec and and having an automated solver try and fill it in (it's a feature not a bug!), and while we should definitely strive for Good Code™, what makes code "good" has always been contextual: not just whether an implementation works, but whether its tradeoffs make sense for the messy, evolving goals of the system it's meant to serve. benchmarking this will be a super fun thing to do :) more interestingly, the frontier of software engineering research might increasingly be about understanding how much ambiguity we can safely delegate. making the holes in specs bigger is only useful as long as we can have reasonible feedback loops that tell us whether the solver filled them correctly, and the hardest part is often that we don't even know what correctness means until we've built something and seen how it behaves.