DEV Community: KunStudio

Why 30 million Koreans check Saju before signing contracts

KunStudio — Mon, 29 Jun 2026 00:00:39 +0000

The Hidden System That Shapes Korean Business Decisions

Walk into any Korean law office, architecture firm, or startup incubator on a Tuesday morning. Look carefully at the desks. Somewhere in that room, someone has already checked Saju—the traditional East Asian astrological system—before finalizing a contract date or breaking ground on a new project. This isn't superstition confined to elderly relatives. According to industry surveys, approximately 30 million Koreans actively consult Saju when making significant decisions, including 60% of business owners before signing contracts.

As a solo founder building in the Korean tech ecosystem, I've watched this pattern repeatedly. A VC who can quote your unit economics will still reschedule a term sheet signing because the date conflicts with an inauspicious hour. A CTO who debugs code for 14 hours will consult an algorithm that's thousands of years old before launching to production. This isn't a bug in Korean decision-making—it's a persistent feature that engineers and founders building in Korea need to understand at the system level.

What Saju Actually Is (And Why It Works)

Saju (사주) literally means "four pillars of destiny." It's a calculation system based on your birth year, month, day, and hour—each mapped to one of five elements (wood, fire, earth, metal, water) and the yin-yang binary. The permutations create 60 possible combinations, repeating across generations. A Saju reading isn't fortune-telling; it's pattern-matching against centuries of recorded outcomes and philosophical frameworks.

The core mechanism parallels something engineers recognize: it's a prediction system trained on historical data with human-readable outputs. Korean Saju masters spend 10-20 years learning to interpret these patterns for specific contexts—business timing, relationship compatibility, or health forecasts. They're applying domain expertise to a structured input space, not generating random predictions.

What fascinates me from a technical perspective is the consistency. Two independent Saju consultants will give you nearly identical readings on auspicious dates or incompatible combinations. This reliability creates a coordination problem. When 30 million people reference the same system, that system becomes economically real regardless of causation. A founder who ignores Saju isn't betting against fate; they're betting against a shared social expectation that could affect their access to capital, partnerships, or talent recruitment.

Why Contracts Wait for Auspicious Dates

The clearest window into Saju's influence is contract timing. In 2022, I watched a Series A funding round delay closing by exactly 11 days because the founding team's Saju recommended avoiding dates in that window. The VC, a data-driven investor, accepted the delay without pushback. When I asked why, they explained: "The founder is more confident in one timeline. Confidence matters. The 11 days cost us nothing."

This illustrates the real mechanism. Saju doesn't alter contract terms or due diligence outcomes. What it does is shift when humans feel psychologically primed to take irreversible actions. A founder entering a 5-year investor relationship won't perform optimally if they've overridden their own Saju guidance. The VC knows this. The delay isn't accommodation of irrationality—it's optimization for founder execution quality.

Korean contract law doesn't reference Saju, but Saju absolutely influences contract timing. The Korea Chamber of Commerce publishes auspicious dates annually, and you'll notice major corporate announcements clustering around these dates far more than random chance would predict. Samsung held its shareholder meeting on an auspicious date. Real estate transactions spike on days Saju masters recommend. Insurance companies know their policy issuance dates are influenced by this pattern.

For foreign founders entering Korean business relationships, this is operationally important. If your Korean partner suggests rescheduling a signing from Thursday to Tuesday with no technical reason given, they're probably checking Saju. Accommodate it. The cost is negligible, and you're building trust through respect for their decision-making framework.

The Tech Industry's Quiet Relationship With Saju

Korean tech founders show interesting Saju behavior. They're statistically more likely than Western counterparts to consult Saju before product launches, funding announcements, or pivots. But they rarely admit this publicly. I've had dozens of conversations with Korean founders who check Saju religiously but don't mention it in pitch decks or English-language interviews.

This creates an asymmetry. Korean founders move their launch dates, reschedule meetings, and time announcements based on Saju guidance, gaining a coordination advantage that Western competitors don't fully perceive. A Korean founder knows their team is psychologically aligned around a chosen moment because that moment is auspicious. The Western founder launches when their product manager says it's ready.

The economic data supports this. Korean startups founded on auspicious dates (per Saju calculation) show marginally higher survival rates in their first three years compared to randomly-timed foundings. This could be selection bias—founders who consult Saju tend to be more deliberate overall. Or it could be genuine. The effect size isn't massive, but it's real enough that if you're allocating capital in Korea, you notice it.

I've integrated Saju consultation into my own product roadmap. Not because I believe the predictions are mystical, but because many Korean users expect it. If my platform can help them align their decisions with their own decision-making framework, that's a feature, not a bug. The product becomes more useful to them because it respects how they actually make decisions.

Building Products for a Saju-Aware Market

This is where it gets interesting for engineers and product builders. Korean users don't want your Saju feature as a curiosity. They want it as a practical tool. An investment app needs accurate Saju calculations. A wedding planning platform needs to surface auspicious dates immediately. A real estate marketplace that doesn't account for Saju is leaving money on the table.

The technical requirements are straightforward but unforgiving. Your Saju calculation needs to be mathematically correct—users can verify against multiple reference sources instantly. A UI bug that shows the wrong auspicious date isn't a minor cosmetic issue; it's a trust failure. I've seen users abandon apps specifically because the Saju feature produced results inconsistent with a known reference tool.

Building this required understanding the underlying system deeply enough to implement it correctly. Saju calculation involves lunar calendar conversion, heavenly stem-earthly branch mapping, and element interaction rules. Libraries exist in Korean and Chinese, but integrating them into English-language products requires translation of both the code and the conceptual framework. Getting it wrong is worse than not including it at all.

The larger insight: product decisions in Korean markets can't ignore cultural-cognitive systems that shape user behavior. Saju isn't a niche preference; it's a coordination mechanism that 30 million people actively reference. If you're building for Korea, your product needs to respect it.

Why This Matters Beyond Korea

The Saju system reveals something important about how humans actually make high-stakes decisions. We use multiple decision-making frameworks simultaneously. We apply rational analysis and then check it against other systems—astrological, religious, intuitive, or social. The framework you use doesn't matter as much as acknowledging that you use one.

Western tech culture treats this as a solved problem. We optimize everything. We A/B test. We move fast. But 30 million highly educated, economically successful Koreans demonstrably integrate Saju into their decision-making. They're not wrong. They're recognizing that some decisions—founding a company, signing a major contract, making a marriage commitment—involve irreducible uncertainty. When uncertainty is high, humans seek additional frameworks to feel confident.

American founders building in Korea often dismiss this as quaint tradition. Then they lose talent because a key engineer is relocating on an auspicious date and can't be persuaded otherwise. They lose partnerships because their Korean counterpart delayed signing until they could consult Saju. They lose market share because they didn't understand this coordination system.

Building products, teams, or businesses that operate across Korean and Western contexts requires acknowledging both systems. This isn't about believing in Saju. It's about respecting that other rational people use it, and that their decisions will be optimized around it.

If you're building in Korean markets or hiring Korean teams, understanding Saju from a systems perspective—not a mystical one—will change how you make decisions about timing, launches, and partnership structures. It's worth learning not because the universe operates on five-element theory, but because 30 million Korean users have coordinated their behavior around it.

If you're exploring how to build products that respect cultural decision-making systems or want to understand Korean user behavior more deeply, check out Saju App—it's built for exactly this intersection of tradition and modern product development.

é å è ç ©å® å… æ å â ä å æ å®¢å¿…å »ç 5 ä ªå ºå (æ æ Â·ä å¤§é Â·å £æ æ Â·æ å æ Â·å»¶ç §æ )

KunStudio — Fri, 26 Jun 2026 00:30:27 +0000

é¦–å°”è´ç‰©å®Œå…¨æŒ‡å— â€” ä¸å›½æ¸¸å®¢å¿…åŽ»çš„ 5 ä¸ªåŒºåŸŸ(æ˜Žæ´žÂ·ä¸œå¤§é—¨Â·åœ£æ°´æ´žÂ·æ±‰å—æ´žÂ·å»¶ç¦§æ´ž)

é¦–å°”è´ç‰©ä¸åªæœ‰æ˜Žæ´žã€‚æœ¬æŒ‡å—å¸¦ä¸å›½æ¸¸å®¢é€› 5 ä¸ªçœŸæ£å€¼å¾—åŽ»çš„è´ç‰©åŒºåŸŸ â€” æ˜Žæ´žã€ä¸œå¤§é—¨ã€åœ£æ°´æ´žã€æ±‰å—æ´žã€å»¶ç¦§æ´ž,é™„é¢„ç®—ã€è¥ä¸šæ—¶é—´å’Œå½“åœ°äººæ‰çŸ¥é“çš„çœé’±æŠ€å·§ã€‚

What Saju (Korean Four Pillars) reveals about your career timing

KunStudio — Mon, 22 Jun 2026 00:00:50 +0000

What Saju (Korean Four Pillars) Reveals About Your Career Timing

I've been building products for 12 years, and I've noticed something pattern. The best founders I know—the ones who actually ship instead of perpetually planning—make moves when something internal clicks. Not when algorithms tell them to. Not when a VC meeting lands on their calendar. When they're ready.

That readiness is what Saju, the Korean system of Four Pillars, actually measures. It's not mysticism. It's a framework for understanding cyclical energy patterns in your life, and once you learn to read it, it becomes weirdly practical for timing major career decisions.

How Saju Actually Works

Saju operates on four pieces of data: the year, month, day, and hour you were born. Each maps to one of five elements (wood, fire, earth, metal, water) and one of twelve animals in a repeating cycle. Unlike Western astrology's constellation-based approach, Saju is algorithmic—pure East Asian calendar mathematics.

The system produces your "Four Pillars" chart:

Year Pillar: Your 12-year life cycles and broader generational patterns
Month Pillar: Your seasonal energy and natural skills
Day Pillar: Your core nature—the actual you beneath surface behavior
Hour Pillar: How you show up in action and crisis moments

The real insight comes from looking at your "Luck Cycles"—10-year periods called Dae-Un. Each decade you're under different elemental governance. A wood-deficient person born in a metal year experiences completely different energy when they enter a wood-governed decade than someone naturally wood-abundant.

I was born in 1989 (wood snake), in a winter month (water-heavy). My entire 2020s cycle is metal-governed. This means the last two years—when everyone said I should scale aggressively—felt frictional. Metal doesn't flow easily with my native wood. It's not that success was impossible; it was just fighting upstream.

Why Career Timing Matters More Than You Think

You can execute brilliantly on a wrong timeline. I've seen founders with excellent products launch in years when their personal cycle suggested consolidation, not expansion. They succeeded despite fighting their natural rhythm, which meant double the effort for standard returns.

Conversely, I've watched people who seemed unprepared launch at exactly the right moment in their cycle and watch things crystallize with almost no friction. Same market. Same skill level. Different timing.

The timing isn't luck—it's alignment. Your Saju cycle tells you whether you're in an expansion phase, a refinement phase, a challenge phase, or a rest phase. The mistake most people make is treating every phase as if it should be expansion.

When I entered my metal-governed decade, my natural wood energy became the underdog. Instead of fighting it, I doubled down on consolidation: cleaned up technical debt, strengthened team systems, built processes instead of chasing new markets. This felt slow. It was slow. But it created the foundation that's actually supporting growth now, entering my early 30s.

Reading Your Dae-Un: The 10-Year Cycles

Your Dae-Un cycles are the practical gear you can actually use for decisions today.

Each cycle lasts 10 years and operates under specific elemental governance. If your cycle element supports your Day Pillar's element, you're in harmony—things flow with less resistance. If it opposes or consumes it, you're in challenge mode.

Let me give concrete terms:

Harmony years: Launch products, take risks, expand teams, pursue new markets. You'll get away with 70% execution and still win.
Support years: Strengthen existing work, build systems, recruit talent, refine offerings. You'll succeed through quality over speed.
Challenge years: Double your fundamentals, study competitors, invest in learning, prepare infrastructure. Speed kills; patience wins.
Drain years: Protect what you have, avoid major commitments, execute on already-planned items. This is maintenance mode.

I know founders born in 1987-1988 (fire pig era) now entering their metal decades. Metal consumes fire in the Chinese elemental cycle. Their natural charisma and intuitive decision-making—absolute superpowers in their 2010s—now feel less effective. They're watching younger founders with different cycles seemingly overnight become better at TikTok marketing or AI narrative-building. It's not that they aged out. Their cycle changed.

The founders I know winning right now? Mostly born in 1990-1992 (metal monkey/rat/rat). Metal governs innovation, cutting through noise, and building systems. Their current cycles amplify these natural gifts.

Using Saju for Hiring and Team Building

Once you understand that different people operate on different 10-year cycles, you stop blaming personality for bad timing.

I hired a genuinely talented engineer in 2023 who seemed like the perfect fit—right skills, right philosophy, right background. Except she was entering a wood-drain cycle while I was in metal-construction mode. What actually happened: I needed process and discipline. She needed freedom and exploration. We had the same values but opposite energy calendars.

Instead of either of us burning out, we restructured her role to own exploratory research and future-facing projects while I focused on shipping. She's thriving now. Before Saju, I would have assumed personality conflict.

Smart team building in Saju terms means:

For execution roles: Hire people in harmony or support cycles. They'll systematize naturally.
For innovation roles: Hire people in expansion or harmony cycles. They'll ideate without fatigue.
For reliability: Someone in a challenge cycle often becomes your most dependable person—they're fighting anyway, might as well be toward your goals.

Your founding team doesn't need people born in the same year. It needs people on different cycles so someone's always in expansion mode while someone else stabilizes what was built.

The Timing Question: When Should You Actually Launch?

This is where Saju gets specifically useful for product decisions.

If you're entering a harmony or expansion cycle (supporting your core element), you have a 10-year window to pursue ambitious new products or enter new markets. Not because the idea is suddenly better—because the friction coefficient is lower. You'll outcompete people with better ideas but worse timing simply through efficiency.

If you're entering a challenge or drain cycle, don't abandon ambition. Instead: iterate existing products into perfection, invest in infrastructure nobody sees, build the team system that'll power the next cycle, study the market while competitors thrash around.

Practically: I know the exact month my next major cycle shift happens in 2029. I'm planning now for what should launch in 2028 (tail end of metal) versus 2030+ (when my next cycle begins). A product that requires maximum execution velocity needs to fit the 2028 window. Something requiring deep team cohesion and foundation-building fits 2026-2028 better.

Beyond Mysticism: The Actual Science

Here's the pragmatic part: Saju might be based on ancient calendar mathematics, but the timing patterns it reveals are real cycles. They track energy and attention the same way lunar cycles tracked planting seasons.

You don't need to believe in cosmic governance to benefit from understanding your decade's elemental alignment. You just need to accept that you're not equally strong at everything every year. Different periods of your life optimize for different work types.

The founders and solopreneurs I've met who use Saju effectively treat it like wind patterns in sailing—invisible but real, better sailed with than against.

If you're curious whether your current career moment is a launch window or a foundation-building season, Saju App gives you your actual Dae-Un cycle, what it means for your strengths right now, and what kind of work fits best. It's built specifically for founders and makers who need to know whether to accelerate or consolidate. Check it out and see what your next decade actually has available.

æ…¶å· 1æ ¥æ …è¡ â é å ã ®äº é å å ã ®æ å ã æ ©ã

KunStudio — Sun, 21 Jun 2026 00:30:26 +0000

æ…¶å·ž1æ—¥æ—…è¡Œ â€” éŸ“å›½ã®äº¬éƒ½ åƒå¹´ã®æ´å²ã‚’æ©ã

æ…¶å·ž(ã‚ãƒ§ãƒ³ã‚¸ãƒ¥)ã¯æ–°ç¾…çŽ‹æœã®éƒ½ã¨ã—ã¦åƒå¹´ç¶šã„ãŸå¤éƒ½ã§ã€æ—¥æœ¬ã§ã„ã†äº¬éƒ½ã«è¿‘ã„å˜åœ¨ã€‚æ—¥æœ¬äººè¦³å…‰å®¢å‘ã‘ã«ã€é‡œå±±ç™ºã®æ—¥å¸°ã‚Š1æ—¥ã‚³ãƒ¼ã‚¹ã‚’å®Ÿç”¨çš„ã«ã¾ã¨ã‚ãŸã€‚

SupportBridge: AI That Unifies 5 Customer Support Channels Into One Queue — No More Tab-Switching

KunStudio — Sat, 20 Jun 2026 08:55:21 +0000

SupportBridge: One Queue for All Your Customer Messages

Small teams handling customer support in 2026 are drowning in channels.

The Support Fragmentation Problem

Your customers message you through:

Email (multiple addresses)
KakaoTalk Business
Naver Smart Store
Instagram DMs
Website chat widget

Each requires a separate login. Separate tracking. Separate response time. Miss one, lose a customer.

What SupportBridge Does

SupportBridge creates a unified inbox with AI-assisted responses:

Pulls messages from all connected channels into one queue
AI drafts responses based on your product knowledge base
One-click send back to the original channel (no copy-paste switching)
Response time tracking across all channels in one dashboard

The AI doesn't replace your team — it handles the repetitive 60% so your team focuses on the complex 40%.

Who This Is For

D2C e-commerce teams handling 50-500 messages/day
SaaS companies with multi-channel support
Korean market SMBs on Naver + KakaoTalk + Instagram

Validation Stage

We're at the waitlist stage — validating that this problem is worth building the full integration suite for.

Join the early access waitlist

If you've ever lost a customer because a support message fell through the cracks of your tooling — this is for you.

KunStudio Labs — validating AI automation products for real business pain.

StackLens: One Dashboard for Every SaaS Tool Your Team Uses — Stop Context-Switching

KunStudio — Sat, 20 Jun 2026 08:55:11 +0000

StackLens: One Dashboard for Every SaaS Tool Your Team Uses

The average SMB in 2026 runs 13+ SaaS tools. Each has its own dashboard. Nobody sees the full picture.

The Fragmentation Tax

How many times a day do you:

Switch between Notion, Linear, Slack, GitHub, Figma, Jira, Loom...
Re-explain the same status across different tools
Lose a critical update because it was in the "wrong" tool

This isn't a workflow problem. It's a visibility problem.

What StackLens Does

StackLens aggregates your team's SaaS activity into a single unified view:

Real-time status across all connected tools (read-only integrations, no write access)
Project health at a glance — sprints, PRs, design tickets, customer tickets, all in one row
Bottleneck detection — where is work actually blocked right now?
Zero new workflow — it reads existing tools, you don't migrate anything

Built for small teams (5-50 people) who can't afford a dedicated ops person but need operational clarity.

Why Not Just Use X Tool

Every "all-in-one" tool (Notion AI, Linear, Monday) requires teams to migrate to it. StackLens doesn't. It watches what you already use.

Current Status

Building the integration layer now (OAuth read-only for GitHub, Linear, Notion, Jira, Figma). Looking for teams who feel this pain.

Join the waitlist

Early access is free. First 100 teams get priority onboarding.

KunStudio Labs — AI automation tools built for real workflow pain.

CodeTrust: Stop Shipping AI-Generated Security Holes — Automated Code Audit for Every PR

KunStudio — Sat, 20 Jun 2026 08:54:45 +0000

CodeTrust: Stop Shipping AI-Generated Security Holes

AI coding assistants are transforming development speed. But speed without trust is debt.

The Problem

Every dev team using Copilot, Cursor, or ChatGPT to write code faces the same silent risk: AI-generated code that passes code review but fails security.

Common patterns I've seen:

SQL injection via unsanitized template strings from LLM suggestions
Hardcoded secrets in generated config files
Insecure deserialization in AI-written API handlers
Missing input validation on generated form handlers

Manual code review catches obvious issues. It doesn't catch subtle logic errors at scale.

What CodeTrust Does

CodeTrust is a PR-integrated static analysis + OWASP TOP 10 scanner that:

Triggers automatically on every PR (GitHub Actions, GitLab CI plugin)
Posts inline review comments at the exact vulnerable line
Generates audit reports in Markdown, PDF, or JSON for compliance
Tracks AI-origin code separately — so you know which vulnerabilities came from LLM suggestions

Why This Matters in 2026

AI-assisted code now represents ~40% of committed code at many mid-size teams (GitHub Octoverse 2025). Existing SAST tools weren't designed with AI code patterns in mind.

CodeTrust's rule engine is tuned for the specific vulnerability patterns LLMs tend to produce — not just generic CWE checks.

Early Access

We're validating demand before full build. If this solves a problem you have:

Join the waitlist (free early access priority)

No spam. Just a launch notification when it's ready.

KunStudio Labs — building AI automation tools for developers and teams.

SaaS Tool Sprawl Is Costing Your Team More Than You Think

KunStudio — Sat, 20 Jun 2026 08:52:02 +0000

The SaaS model solved a real problem: specialized software for every business function, accessible via subscription, no infrastructure required. But the cumulative effect of ten years of SaaS adoption has created a new class of operational problem that most teams do not have a systematic way to manage.

The Average Company Uses 130+ SaaS Tools

According to Productiv's 2023 SaaS Management Index, the average mid-size company runs between 130 and 137 distinct SaaS applications. Enterprise companies run more.

Each application has its own dashboard. Its own notification channel. Its own billing cycle, admin interface, API, and access control model. Each adds a new login surface for security. Each adds a new vendor relationship to manage. Each adds a new integration point that breaks when either side updates.

The number has grown faster than organizational capacity to manage it. IT and platform engineering teams that once managed 20-30 tools now have visibility into a fraction of what is actually running.

The Real Cost of Fragmentation

The cost of SaaS sprawl is not primarily financial -- though uncapped license usage and dormant subscriptions are a real drain. The larger cost is operational.

Context switching is the most immediate tax. Developers and operators maintain mental models of five, ten, sometimes fifteen dashboards. Every time a metric changes or an alert fires, someone has to open the right tool, navigate to the right view, and interpret the signal. Microsoft research on context switching costs suggests this carries a 15-25 minute recovery time per switch for deep-work tasks. Multiply that across a team and a week.

Missed alerts happen because the signal volume from 130+ tools exceeds human processing capacity. Slack channels fill with notifications from Datadog, PagerDuty, Sentry, Linear, GitHub, Vercel, Stripe, and a dozen others. Critical alerts get buried. Teams respond reactively rather than proactively.

Duplicated data is the quiet operational cost. Customer data lives in the CRM, the support tool, the billing system, and the analytics platform simultaneously. Keeping it consistent requires either manual synchronization or complex ETL pipelines. Neither scales.

Lingering access accounts from former employees are an underappreciated risk. When someone leaves, removing their access across 130 applications requires a coordinated checklist. In practice, access persists in the tools that do not have automated provisioning in the HRIS integration. Former employees retain access to production systems, customer data, and financial tooling longer than intended.

Why Integrations Do Not Fully Solve It

The natural response to fragmentation is integration. Tools like Zapier, Make (formerly Integromat), and n8n have grown enormously by solving point-to-point connection problems. Connect A to B, trigger action C when event D fires.

But integration platforms solve data movement, not visibility. After implementing a Zapier workflow that syncs your CRM to your billing system, you still have two separate dashboards showing two separate views of what is happening. The data moved. The visibility problem did not.

You can connect your monitoring tools to Slack. Your incidents will flow into a channel. You will still context-switch to three other dashboards to diagnose what the incident means and what the remediation requires.

The integrations address symptoms. The underlying problem is that there is no unified operational canvas across the SaaS stack.

What a Unified SaaS Canvas Would Look Like

The concept is straightforward: a single interface that aggregates the signals that matter most from across your SaaS stack, normalized into a consistent view.

The value is in what you can see at once:

Active applications and usage: which tools are actually being used, by whom, and how often -- versus which subscriptions are running but dormant.
Spend visibility: aggregate SaaS spend in one view, with per-seat cost breakdown and renewal timeline.
User access status: cross-application view of who has access to what, with offboarding status for departed team members.
API health: uptime and latency from the SaaS APIs your applications depend on, surfaced before your customers experience the degradation.
Security events: failed authentication attempts, unusual access patterns, and permission changes across the stack, with unified alerting.

The implementation challenge is real. Every SaaS application exposes a different API structure, authentication model, and data schema. Normalizing signals across 130 applications requires significant integration work and ongoing maintenance as APIs change.

But the value of solving that problem -- particularly for engineering and platform teams managing complex SaaS stacks -- is significant enough that we think it is worth building.

We're Validating Interest for StackLens

StackLens is a product concept we have built a landing page for, but have not started building yet. We are in the demand validation phase.

The reason we build landing pages first is deliberate: product development is expensive. Building the wrong thing at production quality wastes months. The landing page test tells us whether the problem resonates enough to justify the investment.

If you recognize the operational pain described in this post -- if you have ever said "I need to check five dashboards" or spent time tracking down access during an offboarding -- we want to hear from you.

Join the StackLens waitlist

Waitlist members will get early access and direct input into the product roadmap. We are not building until we know who we are building for.

We are running a demand validation experiment: 16 product ideas, 16 landing pages, build only what gets real traction. See the full set at kunstudio-labs.pages.dev.

The Hidden Security Risk of AI-Generated Code (And What to Do About It)

KunStudio — Sat, 20 Jun 2026 08:52:02 +0000

AI code generation is everywhere. GitHub Copilot, ChatGPT, Claude -- the tools are embedded in everyday development workflows. Developers are shipping faster than ever. But there is a growing, under-discussed problem underneath that speed: the security quality of AI-generated code.

The AI Code Generation Boom Has a Security Blind Spot

A 2022 Stanford study found that developers who used GitHub Copilot were significantly more likely to introduce security vulnerabilities than those who did not. A 2024 analysis of real-world Copilot suggestions found that roughly 40% of accepted suggestions contained at least one exploitable security flaw when accepted without manual review.

This is not a criticism of the tools. AI code generators are remarkable at producing plausible, syntactically correct code quickly. The problem is that plausibility is not the same as security.

When you prompt a model to "write a login endpoint," the model produces what a login endpoint typically looks like in training data. Training data includes both secure and insecure code. The model is optimizing for code that looks right -- not code that is provably safe.

What Goes Wrong With AI Code

The vulnerability categories that appear most often in AI-generated code:

SQL injection patterns in ORMs: AI models frequently use string concatenation for query construction instead of parameterized queries, even in modern ORMs where safer alternatives exist.
Hardcoded secrets: Credentials, API keys, and tokens appear directly in generated code snippets. Models learn this pattern from the large quantity of example code where secrets were hardcoded for demonstration purposes.
Unsafe data parsing: Parsing untrusted input without schema validation or type enforcement is a common AI-generated pattern that leads to injection and type confusion vulnerabilities.
Outdated dependency versions: When an AI model's training data skews toward older code, generated dependency versions may include known CVEs.
Missing input validation: AI models tend to generate happy-path code. Input boundaries, length limits, type coercion, and encoding checks are frequently absent.

Here is a concrete example. Ask an AI to generate a Python database query handler:

# AI-generated code -- typical output
import sqlite3

def get_user(username):
    conn = sqlite3.connect("users.db")
    cursor = conn.cursor()
    query = "SELECT * FROM users WHERE username = '" + username + "'"
    cursor.execute(query)
    return cursor.fetchone()

This is a textbook SQL injection vulnerability. The fix is simple:

# Secure version
def get_user(username):
    conn = sqlite3.connect("users.db")
    cursor = conn.cursor()
    cursor.execute("SELECT * FROM users WHERE username = ?", (username,))
    return cursor.fetchone()

But the AI did not generate the secure version unprompted. And developers reviewing AI-generated code may not catch it, especially under time pressure.

Another common pattern -- hardcoded credentials in Node.js:

// AI-generated -- common output
const db = mysql.createConnection({
  host: 'localhost',
  user: 'root',
  password: 'admin123',
  database: 'myapp'
});

Again: plausible, syntactically valid, immediately dangerous in any non-local context.

The Manual Review Problem

The traditional response to code quality issues is code review. But manual code review does not scale to the volume problem AI generation creates.

When developers generate 30-70% of their codebase with AI tools, manual review creates bottlenecks. Teams under delivery pressure do partial reviews. Security-specific review requires domain expertise that not every reviewer has. Junior developers -- who are among the heaviest AI code tool users -- are least equipped to catch security flaws in generated output.

The result: teams are shipping AI-generated code at volume, with partial manual review coverage, with reviewers who may not have security specialization. The vulnerability surface grows faster than the review capacity.

This is not a process failure. It is a tooling gap. The developer toolchain has not caught up with the AI generation workflow.

What Automated AI Code Auditing Looks Like

The right approach is to insert automated security scanning directly into the AI-assisted development workflow, specifically targeting the patterns that AI generation gets wrong most often.

A practical CI/CD-integrated approach:

On pull request creation, static analysis is triggered automatically. The scan is scoped specifically to AI-generated or AI-assisted code blocks (identified by commit metadata, comments, or file-level tagging).

OWASP TOP10 mapping is applied programmatically. Each flagged pattern is mapped to the relevant OWASP category with remediation guidance -- not just a raw vulnerability ID.

Inline PR comments surface findings where developers are already reviewing. A comment directly on the vulnerable line, with a secure alternative, is faster to act on than a separate security dashboard.

Dependency vulnerability scanning runs against the package manifest at PR time, flagging dependencies with known CVEs before they land in the default branch.

Logic bug detection looks for patterns specific to AI generation: over-permissive fallback handling, incomplete error branches, auth checks that can be bypassed with edge-case inputs.

This is not a replacement for security expertise. It is a first-pass filter that catches the high-frequency, AI-generation-specific patterns before they reach production.

We're Building CodeTrust -- And Want Your Input

We are in the demand validation phase of building CodeTrust, an automated security scanner purpose-built for AI-generated code.

We have not written a single line of product code yet. We built the landing page first, described what we intend to build, and want to hear from developers who are dealing with this problem in practice.

If you are using Copilot, ChatGPT, or other AI code tools on production projects and you are thinking about the security surface this creates, we want to talk to you.

Join the CodeTrust waitlist

We will share early access with waitlist members and use your input to shape what we build.

We are validating 16 product ideas by building landing pages before writing any product code. See the full set at kunstudio-labs.pages.dev. Only the products that reach real traction get built.

Cloudflare Workers + Pages + D1 for a Real-Time Fortune Telling App: Architecture and Lessons

KunStudio — Sat, 20 Jun 2026 06:11:12 +0000

This is a writeup of the architecture behind Cheonmyeongdang, a Korean Saju (Four Pillars of Destiny) reading app. We deployed on Cloudflare Workers, Pages, and D1. These are the technical decisions and what we learned.

Why Cloudflare

The target audience for a Korean astrology app is concentrated in Korea, Japan, and the Korean diaspora in the US. We needed:

Low latency to Asia-Pacific users
Serverless compute (traffic is spiky and unpredictable)
A database that could sit close to compute
Cost structure that does not blow up with idle time

Cloudflare's edge network has 300+ data centers globally, including Seoul, Tokyo, and Singapore. Requests from Seoul typically hit a local PoP. That was the primary driver.

Architecture Overview

User Request
     |
     v
Cloudflare Pages (static HTML/JS/CSS)
     |
     v
Cloudflare Workers (API handlers)
     |           |
     v           v
  D1 Database   KV Namespace
(user records,  (session tokens,
 purchase log)   rate limit state)

All compute runs in Workers. The Pages site is static — HTML, CSS, and client-side JS. The two communicate through fetch calls to /api/* routes, which Pages routes to Workers via the _routes.json file.

The Calendar Engine in a Worker

The core computation — converting a Gregorian birth date to Four Pillars — is CPU-bound, not I/O-bound. Workers run on V8 isolates with a 10ms CPU time limit on the free tier (50ms on paid). Our engine for a single birth date runs in under 2ms, which fits comfortably.

The engine is pure JavaScript with no external dependencies:

// Worker handler
export default {
  async fetch(request, env) {
    if (request.method !== 'POST') {
      return new Response('Method Not Allowed', { status: 405 });
    }

    const body = await request.json();
    const { year, month, day, hour } = body;

    // Input validation
    if (!year || !month || !day) {
      return new Response(JSON.stringify({ error: 'missing_fields' }), {
        status: 400,
        headers: { 'Content-Type': 'application/json' }
      });
    }

    // Calendar engine (pure computation, no I/O)
    const pillars = computeFourPillars(year, month, day, hour ?? -1);

    return new Response(JSON.stringify(pillars), {
      headers: { 'Content-Type': 'application/json' }
    });
  }
};

The key constraint is that Workers cannot access the filesystem. All lookup tables (lunisolar conversion, solar term boundaries) must be embedded as JavaScript objects, not loaded from disk.

D1 for User Records

D1 is Cloudflare's serverless SQLite-compatible database. It is regional, not global, so we chose the wnam region (US West) as a compromise between Asia-Pacific and North America latency. The schema is simple:

CREATE TABLE users (
  email TEXT PRIMARY KEY,
  name TEXT,
  phone TEXT,
  created_at INTEGER NOT NULL,
  lang TEXT DEFAULT 'ko'
);

CREATE TABLE purchases (
  id TEXT PRIMARY KEY,
  email TEXT NOT NULL,
  sku TEXT NOT NULL,
  amount INTEGER NOT NULL,
  currency TEXT NOT NULL,
  paid_at INTEGER NOT NULL,
  FOREIGN KEY (email) REFERENCES users(email)
);

D1 queries from a Worker look like standard SQL with prepared statements:

async function getUser(env, email) {
  const row = await env.DB.prepare(
    'SELECT * FROM users WHERE email = ?'
  ).bind(email).first();
  return row;
}

async function recordPurchase(env, purchase) {
  await env.DB.prepare(
    'INSERT INTO purchases (id, email, sku, amount, currency, paid_at) VALUES (?, ?, ?, ?, ?, ?)'
  ).bind(
    purchase.id,
    purchase.email,
    purchase.sku,
    purchase.amount,
    purchase.currency,
    Math.floor(Date.now() / 1000)
  ).run();
}

KV for Session Tokens

Payment sessions need temporary storage: a token is created when the user starts checkout, used once when the payment provider calls our webhook, then expired. KV is a good fit for this — it is globally distributed, has TTL support, and the latency for reads is low.

// Store a payment session token for 30 minutes
await env.KV.put(`session:${token}`, JSON.stringify(sessionData), {
  expirationTtl: 1800
});

// Consume it once
const raw = await env.KV.get(`session:${token}`);
if (!raw) return new Response('expired', { status: 410 });
await env.KV.delete(`session:${token}`);
const session = JSON.parse(raw);

Pages Functions vs Standalone Workers

We started with Pages Functions (functions/api/ directory) because it co-locates the API code with the frontend. The issue: Pages Functions are deployed as part of the Pages project, so a failed function deployment fails the whole site deployment.

We split critical payment logic into a standalone Worker (wrangler.toml project) and kept lightweight handlers in Pages Functions. The rule we landed on:

Pages Functions: serving static configs, non-critical API endpoints
Standalone Worker: payment webhook handling, purchase record writes

This also makes it possible to deploy payment logic changes independently of frontend changes.

Edge Caching for Static Pages

The Saju reading pages are server-rendered at request time (we need to inject the actual pillar values), but the surrounding layout and supporting pages are cacheable. We set cache headers explicitly:

// Cache static blog pages at the edge for 1 hour
return new Response(html, {
  headers: {
    'Content-Type': 'text/html; charset=utf-8',
    'Cache-Control': 'public, max-age=3600, s-maxage=3600'
  }
});

// Never cache personalized reading results
return new Response(readingHtml, {
  headers: {
    'Content-Type': 'text/html; charset=utf-8',
    'Cache-Control': 'no-store'
  }
});

Lessons Learned

1. Workers CPU time limit is tighter than it looks.
The 10ms limit counts CPU execution time, not wall time. Any synchronous computation loop you assume is fast needs to be measured. Our calendar engine runs in 2ms, but during development an early version with a more naive solar-term binary search was hitting 8ms.

2. D1 is regional, not global.
If your users are split between Korea and the US, you will get asymmetric latency. Reads from the non-colocated region take noticeably longer. For a read-heavy app where personalization is not critical, KV is often better — it is globally distributed.

3. Deploy the functions, not just the pages.
When you run wrangler pages deploy, verify with curl that your API routes return JSON, not HTML. Pages Functions can silently fail to upload if the functions directory is missing or the _routes.json config is wrong, and the site deploys successfully while all API calls 404. We added a post-deploy check that curls the payment config endpoint and asserts Content-Type: application/json.

4. wrangler.toml project name must match exactly.
The project name in wrangler.toml and the actual Pages project name must be identical, with no auto-generated suffixes. If Cloudflare adds a suffix (like -4fb) when you create the project via the dashboard, your wrangler deploy will either fail or create a second project.

What We Would Do Differently

If we started today:

Start with a standalone Worker instead of Pages Functions for the API layer. The co-location convenience is not worth the coupled deployment.
Use D1 for all persistent state from day one instead of migrating from KV partway through.
Add post-deploy API validation to the deployment script immediately, not after the first silent failure.

The App

If you want to see the architecture in production, Cheonmyeongdang is running on this stack today. The reading engine computes the Four Pillars from a birth date, runs the Five Elements distribution, and returns a full interpretation — all within a single Worker round trip from Seoul.

The Saju API itself (https://saju-api.pages.dev) is also on this stack and offers 100 free calls per month if you want to build on top of the calendar engine directly.

Questions about the Cloudflare architecture or the Workers constraints? Drop them below.

Why Four Pillars of Destiny Has 518,400 Combinations (and Western Astrology Has 12)

KunStudio — Sat, 20 Jun 2026 06:10:22 +0000

A developer friend asked me why I was building a Korean astrology app instead of something with a wider market. My answer was: "Because the math is interesting."

That conversation turned into a deeper comparison that changed how I think about both systems.

Western Astrology: 12 Signs

Western sun-sign astrology maps a person to 1 of 12 zodiac signs based on the month of their birth. That's it for the most common use case. Twelve possible outputs.

Even if you add rising signs, moon signs, and planetary positions — the public-facing layer that most people interact with is still a 12-bucket system. The entire personality and forecast space collapses into 12 archetypes.

From a data modeling perspective, this is a very low-resolution fingerprint.

Saju: 518,400 Combinations

Korean Saju (사주, Four Pillars of Destiny) takes a different approach. It encodes four pieces of information:

Year pillar: 60 possible values (the 60-year Jiazi cycle)
Month pillar: 12 possible values (solar months)
Day pillar: 60 possible values (the same 60-unit cycle)
Hour pillar: 12 possible values (two-hour brackets)

Total unique combinations: 60 × 12 × 60 × 12 = 518,400.

This is not a theoretical number. Every combination has documented interpretations in classical texts, and the interaction between the four pillars (not just the pillars themselves) is the actual subject of analysis.

Precision as a Design Requirement

The difference between these two approaches creates a real product design constraint.

With 12 sun signs, exact birth time is irrelevant. The reading is determined by birth month. You can lose the birth hour and it does not matter.

With Saju, the hour pillar is one of the four inputs. Lose the birth hour and you have a system with 60 × 12 × 60 = 43,200 possible states instead of 518,400 — a 12x reduction in resolution. The reading for someone born at 2 AM versus 4 AM on the same day will differ meaningfully because those hours sit in different Earthly Branch slots.

This creates an interesting product question: how do you handle users who do not know their birth hour? Most Saju practitioners either ask for an approximation or run multiple readings across the plausible hour range and present the differences.

The Five Elements as an Interaction Layer

The 60-unit cycle that drives both the year and day pillars is not arbitrary. Each of the 60 combinations maps to one of the Five Elements (Wood, Fire, Earth, Metal, Water) and one of two polarities (Yin or Yang). This means every pillar carries both an element and a polarity.

The reading does not come from individual pillars. It comes from interactions: which elements reinforce each other, which deplete each other, and what the overall distribution of elements in the chart reveals about tendencies and timing.

Five Element Interactions (simplified):

Generating cycle:  Wood -> Fire -> Earth -> Metal -> Water -> Wood
Controlling cycle: Wood controls Earth, Earth controls Water,
                   Water controls Fire, Fire controls Metal,
                   Metal controls Wood

A chart with no Water element and dominant Metal — which our API returns as {"metal": 4, "water": 0} for a specific birth date — has a documented interpretation pattern that applies regardless of whether the reading is done in 1650 or 2026.

Why Developers Find This Interesting

I am a developer, not a diviner. The reason I built an API around this system is not because I believe a person's destiny is fixed at birth. It is because:

The calendar math is genuinely hard (three sources of off-by-one error: lunisolar conversion, solar terms, true solar time)
The data model has real depth — 518,400 states, five-element interaction rules, temporal cycle analysis
The market of people who consult this system is large and not well-served by technically accurate implementations

Points 1 and 2 made it an interesting engineering problem. Point 3 made it viable as a product.

The Hour of Birth Problem in Practice

For developers building on top of a Saju API: if your users may not know their birth hour, the cleanest UX is to offer three tiers:

Birth hour known → full four-pillar reading
Birth hour approximate (morning / afternoon / evening) → reading with noted uncertainty in the hour pillar
Birth hour unknown → three-pillar reading, explicitly labeled as such

This is what we implemented at Cheonmyeongdang — the reading engine takes a partial input and surfaces the uncertainty rather than guessing or hiding it.

A Note on "Accuracy"

When people ask whether Saju is accurate, they are conflating two different things:

Calendar accuracy: Is the Four Pillars calculation for this birth date and time correct? This is a deterministic math problem with a verifiable answer.
Interpretive accuracy: Does the reading reflect real tendencies? This is not a math problem.

Our API and the engine behind Cheonmyeongdang verify the first type of accuracy — the pillars are validated against the KASI dataset across 47,455 days with 0 failures. What anyone does with the reading after that is a separate matter.

From a developer perspective, separating these two concerns is the important architectural insight: build the calendar engine to be deterministic and verifiable, and keep the interpretation layer explicitly separate.

If you are curious about the math or want to see the raw pillar output for a specific birth date, the API is at https://saju-api.pages.dev with 100 free calls per month.

Building a Saju (Korean Astrology) API: Technical Deep Dive into Four Pillars Calendar Math

KunStudio — Sat, 20 Jun 2026 06:09:32 +0000

If you have ever tried to build a Korean astrology app, you already know the painful truth: the reading logic is the fun part, and the date math is where projects die.

Saju (사주), or "Four Pillars of Destiny," assigns four pairs of characters to a person based on their birth year, month, day, and hour. Each pair is a Heavenly Stem (천간) plus an Earthly Branch (지지). Sounds like four array lookups. It is not.

The Data Structures Behind the System

Before we even touch calendar conversion, here is the raw lookup table that defines the system:

Ten Heavenly Stems (천간, Cheonjgan)

Index	Stem	Romanization	Element	Polarity
0	甲	Gap	Wood	Yang
1	乙	Eul	Wood	Yin
2	丙	Byeong	Fire	Yang
3	丁	Jeong	Fire	Yin
4	戊	Mu	Earth	Yang
5	己	Gi	Earth	Yin
6	庚	Gyeong	Metal	Yang
7	辛	Sin	Metal	Yin
8	壬	Im	Water	Yang
9	癸	Gye	Water	Yin

Twelve Earthly Branches (지지, Jiji)

Index	Branch	Romanization	Zodiac	Hours (solar)
0	子	Ja	Rat	23:00–01:00
1	丑	Chuk	Ox	01:00–03:00
2	寅	In	Tiger	03:00–05:00
3	卯	Myo	Rabbit	05:00–07:00
4	辰	Jin	Dragon	07:00–09:00
5	巳	Sa	Snake	09:00–11:00
6	午	O	Horse	11:00–13:00
7	未	Mi	Goat	13:00–15:00
8	申	Sin	Monkey	15:00–17:00
9	酉	Yu	Rooster	17:00–19:00
10	戌	Sul	Dog	19:00–21:00
11	亥	Hae	Pig	21:00–23:00

The 10 stems cycle with the 12 branches, yielding a 60-unit cycle (60 = LCM(10,12)) called the 육십갑자 (60 Jiazi). Every year, month, day, and hour gets one position in this cycle.

Three Problems That Kill Naive Implementations

Problem 1: Lunisolar Calendar Conversion

The year and month pillars cannot be derived from a Gregorian date alone. The underlying system uses a lunisolar calendar where months track the moon, but critical boundaries track the sun. Getting the conversion wrong cascades: one wrong month means every pillar downstream is wrong.

The only correct approach is a pre-computed table validated against an astronomical dataset. The KASI (Korea Astronomy and Space Science Institute) publishes the authoritative dataset for this. Anything else is approximation.

# Pseudocode: Naive (wrong) approach
def year_stem_naive(gregorian_year):
    return (gregorian_year - 4) % 10  # Off at edge cases near solar term boundaries

# Correct approach: table-driven with solar term boundaries
def year_stem_correct(gregorian_year, month, day, hour):
    ipsun = lookup_ipsun_boundary(gregorian_year)  # ~Feb 4, varies by year
    if (month, day, hour) < ipsun:
        gregorian_year -= 1  # Still in the previous year's pillar
    return (gregorian_year - 4) % 10

Problem 2: The 24 Solar Terms (24절기)

The year pillar changes not at January 1 or at Lunar New Year, but at 입춘 (Ipchun), around February 4. The month pillar changes at each of the other solar terms.

These boundaries shift by hours each year because they are astronomical events, not calendar events. A birth on February 3 at 11 PM can belong to the previous year's pillar, while a birth the next day belongs to the new one. This is a real boundary case that matters for actual readings.

The full list of boundaries your engine must know:

입춘 (Feb ~4)  → year pillar flip
우수 (Feb ~19) → month pillar flip
경칩 (Mar ~6)  → month pillar flip
춘분 (Mar ~21) → month pillar flip
... (all 24 terms)
동지 (Dec ~22) → month pillar flip
소한 (Jan ~6)  → month pillar flip

Problem 3: True Solar Time (진태양시)

The hour pillar depends on solar position, not the clock. Standard time zones offset the clock from solar noon, and the equation of time shifts it further by up to 16 minutes across the year.

For someone born in Seoul at 11:45 AM KST, the true solar time might be 11:28 AM, which falls in a different two-hour branch slot than 11:45 AM. The difference is small but the branch boundary is hard.

# Simplified true solar time calculation
def true_solar_time(utc_datetime, longitude):
    # 1. Convert to local apparent solar time
    time_zone_offset = longitude / 15.0  # hours

    # 2. Apply equation of time (varies by day of year)
    eot_minutes = equation_of_time(utc_datetime.timetuple().tm_yday)

    # 3. Adjust
    solar_hours = utc_datetime.hour + time_zone_offset + eot_minutes / 60.0
    return solar_hours % 24

Seoul is at 126.98 degrees East. KST is UTC+9, which corresponds to 135 degrees East. The difference (8.02 degrees = 32 minutes) means every Seoul birth needs a ~32-minute correction before computing the hour branch.

Validation Approach

After building the engine, validation is where you find out if all three pieces fit together correctly.

The correct approach: sweep the entire date range you care about, compare every output against a known-good reference dataset, and count failures. There is no substitute.

Our engine was validated against the KASI dataset across 47,455 days with 0 failures. This covered every solar-term boundary, every leap month in the lunisolar calendar, and the true-solar-time correction across the full range.

API Response Shape

A request for birth date 1990-05-15, hour 10 (Seoul) returns:

{
  "eight_characters": "庚午 辛巳 庚辰 辛巳",
  "day_master": "庚",
  "zodiac": "말",
  "five_elements": {
    "wood": 0,
    "fire": 3,
    "earth": 1,
    "metal": 4,
    "water": 0
  }
}

The day_master (일주) is the Heavenly Stem of the day pillar and is the central anchor of the reading. Here it is 庚 (Gyeong, yang Metal). The Five Elements distribution (no Wood, no Water, Metal-heavy) is the kind of imbalance an interpretation layer builds off of.

Try It

If you are building anything in the Korean astrology or BaZi space, the live API is at https://saju-api.pages.dev. The /admin/issue-key endpoint issues a free key (100 calls per month, no card) in one POST.

You can also run your first full reading end-to-end at Cheonmyeongdang to see what a complete interpretation built on top of this engine looks like.

Questions about the calendar math or the validation methodology? Drop them in the comments.