| hey yall, try writing a few specs at the component/module/package level. define the api contract, types/interfaces, dependencies, package behavior. effectively do the same work you do writing code, but with a layer of "behavior statements" instead of code blocks. define observable behaviors, let codegen workout most of the rest by implementing the contract. decompose specs into proper units (a hundred lines or so), not god-awful, unreadable, vibe-coded, frankenstein documents. follow the software engineering best practices you've honed for the last 25 years. you end up slowing down, sitting in the problem, figuring out "the right problem to solve", all the benefits of writing the code. but now you have a spec to iterate on, and the behavior statements in the spec generate code and tests from a single source of truth (each statement a provable assertion). as bugs arise, trace back to the spec. changes often end up being a single line of text in the spec which cascades into an easy to review diff plus tests. spec prose allows writing "why" and "how" together without code comments which go stale. and lean on your type system to leverage opportunities to be terse, creating a spec which has fewer words, yet still produces strong correctness guarantees (aka, the spec can be shorter than the code, and still be readable). bonus: versioning a spec is easy, so now you have a change signal when reviewing your peer's code changes. be more careful with major/minor bumps, skim patch bumps. while many of my peers are taking the giant-ass sdd approach, shipping fast, and losing touch with the actual system behavior, ive been taking the approach outlined above with a modest 2x speedup in feature delivery (their speedup appears much larger), without losing touch with the underlying system. i am working on large, complex, overgrown, legacy code, so i dont have the luxury of floating in a vibe coding cloud, miles above the scary jungle and tigers and lava and spike traps that i call home. ive found this approach to be a brilliant balance of speed, incremental AI opt-in, hands-on to avoid context loss, and most importantly to me: maintainability. i suspect a subset of "proper" ai-codegen software engineer tooling and flows will settle in this vicinity. encourage folks to swiftly vibe-code prototypes, but then from there, let software engineers do what we do best: engineer software, and transform the protoypes into something maintainable. |