{"slug": "your-code-is-a-sacred-cow-bred-by-a-slop-machine-put-your-business-logic-in", "title": "Your Code is a Sacred Cow Bred by a Slop Machine. Put Your Business Logic in Postgres.", "summary": "In 2025, AI-generated code has made traditional software engineering practices like code reviews and testing ineffective, as AI can produce large volumes of superficially correct code that subtly violates business rules. The author recommends placing all critical business logic directly in PostgreSQL, where it is enforced by the database's immutable constraints and benefits from the compounding expertise of database administrators. This approach creates a \"last defensible fortress\" by separating disposable, AI-generated application code from the core business rules that must remain correct and stable.", "body_md": "\"In the era where AI velocity exceeds human review and you can't tell the ninja from the noise — own the last defensible fortress.\"\nEvery best practice in modern software engineering is a social contract pretending to be an engineering solution.\nCode review. PR checklists. Linting pipelines. Clean architecture. SOLID principles. Testing pyramids. These work beautifully in a fantasy team — small, senior-heavy, stable, everyone reads the architecture docs, everyone cares.\nThat team doesn't exist at scale. It never really did.\nAnd in 2025, it's completely, irreversibly dead.\nThe old control loop was: slow down output → review → gate → merge.\nThat loop had one assumption baked in: humans are the bottleneck on code production, so you gate humans.\nThat assumption is gone. The code is now infinite and free. Your junior dev with Cursor ships 10x what your senior shipped in 2019. Your contractor uses Claude Sonnet and delivers a feature in a day that used to take a sprint. Your intern doesn't even write code — they write prompts and review diffs they barely understand.\nAnd here's the part nobody's saying out loud:\nThe tests are AI-generated too. They test what the AI thought it was building.\nThe PR looks immaculate. Consistent style. Well-documented. Green CI. And the business rule is subtly, quietly wrong — because the agent didn't know about the edge case your senior learned from an incident three years ago that never made it into a spec.\nYou can't add enough reviewers. You can't make the checklist long enough. You cannot out-review the velocity.\nHere's the current reality of \"business logic in application code\":\nYour rules live in service classes, middleware, serializers, validators — spread across layers, replicated across services, enforced by convention and prayer.\nEvery new dev who joins — bootcamp grad, offshore contractor, AI-assisted intern — touches that code. Every PR is a potential bypass. Every \"quick fix\" is a load-bearing card in a house of cards.\nAnd now the code itself is generated by a machine that has no memory of why the rule exists, no context for the incident that created it, and no skin in the game if it gets it wrong.\nYou have perfect version control over slop. Git tells you exactly which commit introduced the wrong behavior. Congratulations. The audit trail of your own mistakes is immaculate.\nMeanwhile, you're doing standup, sprint planning, architecture reviews, and PR approvals — all of it cope. Elaborate institutional cope to manage the entropy of logic that was never safe outside a controlled environment.\nAsk yourself honestly: which role churns faster at your company?\nThe JavaScript developer — framework-hopping, chasing the ecosystem, mentally rewriting their stack every 18 months. React → hooks → RSC. REST → GraphQL → tRPC. Webpack → Vite → whatever drops next Tuesday. Their knowledge doesn't compound. It rotates.\nOr the bearded guy with the SQL wand.\nThe senior DBA who's been writing joins since before your current frontend framework was a GitHub repo. Whose CTEs from 2015 still run. Whose understanding of indexes, vacuuming, and query planning compounds year over year. Postgres 17 still respects everything he wrote in Postgres 10.\nYou also cannot fake SQL mastery in an interview. Run EXPLAIN ANALYZE\non the query. No leetcode theater. No rehearsed system design answers. Either the query plan shows 3ms with an index-only scan, or it shows a sequential scan on 2 million rows and you're done. The database is the interviewer, and it has no unconscious bias and cannot be charmed.\nMeanwhile your JS interview pipeline is a gymnasium for people who memorized 50 leetcode patterns for 3 weeks. They pass. They join. You find out 6 months later.\nHere's the reframe:\nThere are now two zones in your system.\nAbove the line: AI territory. Generate freely. Redeploy in minutes. Let the contractors, the juniors, the agents write it. Move fast. Break things. The BFF, the frontend, the API adapters — disposable by design. This is where velocity lives and chaos is acceptable.\nBelow the line: The fortress. Slow. Deliberate. Council-gated. Changes are rare and ritualistic. This is where correctness lives and velocity is the enemy.\nThe line is the database boundary.\nAnd the crucial insight: you cannot prompt your way into changing a trigger. The AI can generate a million BFF variations. Every single one hits the same wall. The invariant holds not because anyone checked the PR, but because the system enforces it at a layer where velocity doesn't operate.\nThe PostgreSQL-centric architecture — sometimes called Planetary Architecture — inverts the conventional stack:\nREVOKE ALL\nfrom everyone including the application user. Superadmin only.The application user — the one your PostgREST or Django connects with — can see metadata on raw tables but never read a row directly. The BFF consumes views and calls functions. It has no idea what the underlying schema looks like.\nA junior dev, an AI agent, an offshore contractor — they work on the BFF. They literally cannot bypass business logic because there is no surface to touch. The database rejects it at the query level.\nThis architecture changes what \"senior\" means.\nIn a conventional stack, seniors spend their leverage on reviews, mentoring, and trying to slow down the entropy of a dozen people touching business logic simultaneously. They're playing defense constantly.\nIn the Postgres temple, the senior writes the fortress once, correctly. Encodes the rules into trigger functions, RLS policies, view contracts. Then steps back.\nThe chaos above the line doesn't require their supervision anymore — because the architecture does the supervision. One council of SQL wardens can safely oversee an arbitrarily large BFF team of agents, juniors, and contractors. The blast radius of any mistake above the line is hard-bounded by what PostgREST exposes, which is bounded by what views exist, which is bounded by what the senior built.\nThe more junior and AI-heavy your above-the-line becomes, the more valuable the below-the-line fortress gets. The chaos above justifies the rigidity below.\nThe Oracle shops of the 90s had this right. Business logic in stored procedures. Schema changes as rituals. DBAs as priests. Nobody pushed to production without the warden's blessing.\nWe abandoned it because startups needed to move faster than that culture allowed, and Rails made it feel unnecessary. We traded correctness guarantees for velocity, and it worked — when humans were still the velocity bottleneck.\nThat trade no longer makes sense. The velocity problem is solved. The correctness problem is now existential.\nThe bearded SQL warden who stays 10 years, whose fortress gets stronger over time, whose knowledge doesn't deprecate — that person is now the most strategically valuable engineer in your organization.\nNot because SQL is magic. Because owning the one layer that AI cannot slop is now the entire game.\nYour code is a sacred cow bred by a slop machine, kept alive by PR prayers and best-practice inhalers.\nPut your sacred cow in Postgres, where the DB is the priest, and no agent, no junior, no tired tech lead reviewing his 40th PR of the week can accidentally sacrifice it on a Friday deploy.\nThe fortress holds. The orbit burns. That's the architecture.\nInspired by PostgreSQL centric - Planetary Architecture by Ryo Suwito.\nTags: #postgres #architecture #systemdesign #webdev #programming", "url": "https://wpnews.pro/news/your-code-is-a-sacred-cow-bred-by-a-slop-machine-put-your-business-logic-in", "canonical_source": "https://dev.to/ryo_suwito/your-code-is-a-sacred-cow-bred-by-a-slop-machine-put-your-business-logic-in-postgres-4923", "published_at": "2026-05-18 21:25:42+00:00", "updated_at": "2026-05-18 22:04:06.864967+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "developer-tools", "data", "enterprise-software"], "entities": ["Cursor", "Claude Sonnet", "React", "GraphQL", "tRPC", "Webpack", "Vite", "Postgres"], "alternates": {"html": "https://wpnews.pro/news/your-code-is-a-sacred-cow-bred-by-a-slop-machine-put-your-business-logic-in", "markdown": "https://wpnews.pro/news/your-code-is-a-sacred-cow-bred-by-a-slop-machine-put-your-business-logic-in.md", "text": "https://wpnews.pro/news/your-code-is-a-sacred-cow-bred-by-a-slop-machine-put-your-business-logic-in.txt", "jsonld": "https://wpnews.pro/news/your-code-is-a-sacred-cow-bred-by-a-slop-machine-put-your-business-logic-in.jsonld"}}