[lelanthran]

> I am already going to spend the brain power on reviewing the code.

Very few devs are actually reviewing any generated code.

> Why not fast forward to that point and save 80% of the time

If you are saving 80% of time, you aren't actually reviewing the code.

[surgical_fire]

> Very few devs are actually reviewing any generated code.

Just because very few devs are qualified at doing their fucking job, it doesn't make someone trying to use AI properly wrong.

> If you are saving 80% of time, you aren't actually reviewing the code.

The idea is that if you spend time in specification ahead of time, reviewing and validating will be easier and less time consuming later.

I haven't tried it myself, but the idea rings true to me.

[lelanthran]

I've never seen a spec survive first contact with implementation. The spec is refined while writing the code.

Hell, you probably couldn't even build a simple bike shed from plans without having to revise them while building, so I am skeptical that without writing you are going to pinpoint the problems in the spec.

Reading only gets you a short way towards learning.

[surgical_fire]

> I've never seen a spec survive first contact with implementation. The spec is refined while writing the code.

Neither have I. This does not make the spec useless. I don't spec hoping that it will be the source of truth, I spec because planning more often than not allows me to spot inconsistencies and ambiguity ahead of time, not halfway through implementation.

> Hell, you probably couldn't even build a simple bike shed from plans without having to revise them while building, so I am skeptical that without writing you are going to pinpoint the problems in the spec.

I think you are using specification and design wrong.

It's not supposed to be a bible that implementation can't deviate from. It's a plan, not law. It's okay for the plan to be adjusted in contact with reality.

It's still useful to know ahead of time constraints, expected output, assumptions, premises, etc.

[lelanthran]

> It's not supposed to be a bible that implementation can't deviate from. It's a plan, not law. It's okay for the plan to be adjusted in contact with reality.

My point is that without writing, you can't surface the type of problems you usually surface. The AI isn't going to surface those problems for you.

It's rare when reviewing that you think "Oh shit, this approach is totally wrong, we need to throw it away", while it's common when writing code to have that reaction.

If you aren't writing, you aren't having that reaction, and you aren't going to get it from reviewing code that has thousands of green "passed" lines in the testsuite.

[surgical_fire]

> It's rare when reviewing that you think "Oh shit, this approach is totally wrong, we need to throw it away", while it's common when writing code to have that reaction.

That's not my experience. It is actually very common for specifications and design to be reviewed and improved.

[lelanthran]

> It is actually very common for specifications and design to be reviewed and improved.

I think there may be crossed wires here - specs and designs are reviewed, but I've never seen a code review result in a spec+design review, while I always see spec+desiogn review happen during the "writing code" phase.

In short, reading code does not result in a spec+design review, writing code does. If you are not writing code and only reading it is unlikely you will trigger a spec+design review.

[Stehfyn]

I use a multimodal approach to defining my spec: different layers of criteria for how the software looks, behaves, what it produces, and under what constraints.

For the literal code:

• A healthy cocktail of /WX + /Wall, plus clang-tidy with very few suppressions

• An extremely opinionated mix of clang-format and LLM-generated bespoke formatting that AST-based tools cant express

• Hungarian notation; all stack locals pre-hoisted, declared in order of appearance, and separated from subsequent assignments

• Enforced dataflow: all memory accesses are bounded independent of branch resolution, with only data-oblivious indexing

• Functions have a single point of return

In a C89 workflow, this pushes agents to produce code where wrong business/domain decisions are unmistakably obvious, while eliminating the vast majority of bug classes before I ever read it.

So yeah, Ill reassert 80%, if not more.