alt Hacker NewsCan't upvote you enough. This is the way. You aren't vibe coding slop you have built an engineering process that works even if the tools aren't always reliable. This is the same way you build out a functioning and highly effective team of humans.
The only obvious bit you didn't cover was extensive documentation including historical records of various investigations, debug sessions and technical decisions.
Replies
Building a fancy looking process doesnt mean output isnt slop. Vibecoders on reddit have even more insane "engineering" process. parent comment has all these
Architecture & Design Principles • Single Responsibility Principle (SRP) • CQRS (Command Query Responsibility Segregation) • Domain Segregation • Domain-Driven Naming Conventions • Clear function/variable naming standards • Architectural constraint definition • Scope definition • Escalation criteria design • Completion criteria definition
⸻
Planning & Process • Formal upfront planning • Constraint-based design • Defined scope management • Escalation protocols • Completion criteria tracking • Maintenance sprints (technical debt paydown) • Frequent code audits
⸻
AI / Agentic Development Practices • Agent-assisted code audits • Agent-based feedback loops (e.g., reading .feature files pre-build) • Agent-driven reasoning optimization (code clarity for AI) • Continuous automated review cycles
⸻
Code Review & Static Analysis • Code review bots: • Sourcery • CodeRabbit • CodeScene • Automated detection of: • Anti-patterns • Contract violations • UX concerns • Architectural flaws
⸻
Linting & Code Quality Enforcement • Strict linting rules • Custom lint rules • Enforcement of lint compliance via bots • Detection of lint rule subversion
⸻
Testing Strategies
Core Testing • Unit Testing • BDD (Behavior-Driven Development) • .feature file validation before build
Advanced Testing • Property-based testing • Snapshot testing • End-to-end (E2E) testing • With MITM (man-in-the-middle) proxies
Formal / Heavyweight Testing • Model checking • Bounded proofs • Unbounded proofs • Undefined behavior testing
Emerging / Exploratory • Mutation testing • Fuzzing
⸻
Code Quality & Auditing • Code duplication detection • Redundancy analysis • Assumption validation • Architectural compliance checks • Domain boundary validation • TOCTOU (Time-of-check to time-of-use) vulnerability analysis
⸻
Development Workflow Enhancements • Continuous audit cycles • Debt-first maintenance phases • Feedback-driven iteration • Pre-build validation workflows
⸻
Security & Reliability Considerations • TOCTOU vulnerability detection • MITM-based E2E testing • Undefined behavior analysis • Fuzz testing (planned)
Documentation is only useful if it is read. I have found it impossiple to get many humans to read the documentation i write.