---
title: "Is software engineering still needed in the AI era? Clean Code determines the ceiling of AI's capability."
description: "As the AI era arrives, do we still need to read code? This article delves into human-machine collaboration and code quality optimization in AI software engineering, explaining why testing systems and architectural refactoring are key to reducing maintenance costs and cognitive risks."
canonical_url: "https://blog.markkulab.net/en/post/clean-code-determines-ai-ceiling"
author: "Mark Ku"
author_url: "https://blog.markkulab.net/en/author/mark-ku"
site: "Mark Ku's Tech Notes"
date_published: "2026-08-01 19:24:14 +0800"
category: "AI"
language: "en"
license: "CC BY 4.0"
license_url: "https://creativecommons.org/licenses/by/4.0/"
attribution: "when reusing or quoting, credit the author and link back to the original"
---

# Is software engineering still needed in the AI era? Clean Code determines the ceiling of AI's capability.

## Foreword: AI Makes Coding Faster, So Why Have Maintenance Costs Skyrocketed 4x?

In today's era of rapid development in generative AI and AI agents, many developers have experienced unprecedented development speed. With just a few prompts, AI can generate hundreds of lines of code in seconds, seemingly boosting development speed by 4x [10]. However, as project scale grows, we're starting to observe a worrying phenomenon: the system's "Comprehension Debt" is quietly accumulating [10].

Many teams are finding that while coding is faster on day one, by the second year, system maintenance costs have soared to four times the original amount [10]. This forces us to pause and ask: In the age of AI, do we still need software engineering? As engineers, do we still need to read and review code ourselves?

From our experience, AI has not yet reached the stage where "a single sentence can perfectly complete all complex tasks." Human-computer collaboration will remain the norm for a long time. If we feed bad code directly to AI, it will only produce more unmaintainable garbage code based on the existing chaos. As the industry says, "consistency" makes AI assistants a force multiplier, while "inconsistency" turns them into a chaos amplifier [10].

We've also reflected on this phenomenon in depth from a practical standpoint in [Some Tips for Vibe Coding: AI is an Amplifier, Don't Let It Amplify Your Tech Debt](https://blog.markkulab.net/post/beyond-vibe-coding-ai-amplifier).

## Why "4x Faster" Never Shows Up in the Delivery Cycle

AI really does make implementation faster. But for a feature to go from idea to production, implementation was never the only cost. The real time sinks are requirement clarification up front and verification plus review at the back, and AI has barely reduced either of them. Verification has actually become more expensive.

The front half didn't get faster because AI can only execute what you have already articulated. The moment requirements are vague, AI simply produces off-target code faster, and you spend more time steering it back. The back half got more expensive because the code isn't yours: you have to read every line before you dare merge it, and AI produces far more code per pass than a human would, so the review burden scales up proportionally.

Based on how it feels on our own projects, the rough proportions look like this:

```mermaid
---
title: Relative effort from idea to production (bars = hand-written, line = AI-assisted)
---
xychart-beta
    x-axis ["Requirements", "Design", "Implementation", "Verify & Review", "Rework"]
    y-axis "Relative effort" 0 --> 45
    bar [20, 15, 40, 20, 5]
    line [20, 15, 10, 30, 10]
```

The bars are hand-written development, the line is with AI assistance. Implementation drops by three quarters, yet total effort falls by only a bit over ten percent, because most of what you save gets eaten by verification and rework. That is why so many teams feel that "AI is fast" while their delivery cycle barely moves.

Reading that chart tells you where the leverage actually is. What can be compressed is not typing speed, it is **writing requirements and constraints in a form AI can read**, and **automating verification** so that reviewers only look at what genuinely needs human judgement. Those two are exactly what the later sections on the "Context Constitution" and the "test guardrails" are about.


## Core Pain Points: "Comprehension Debt" and Security Risks in the AI Era

Many people mistakenly believe that with tools like Copilot or Claude Code, code quality no longer matters. Some even think, "If I don't understand it, I'll just have the AI rewrite it." However, according to research from security and software institutes, this blind trust is creating huge risks:

*   **4x Faster, 10x Riskier**: Studies show that up to 62% of AI-generated code contains design flaws or known vulnerabilities, and projects using AI assistants have a 40% higher rate of secret (key) leakage [10]. Even more alarmingly, 20% of packages recommended by AI don't even exist, which can easily lead to security crises like malicious package hijacking (Slopsquatting) [10].
*   **Token Waste and Soaring Costs**: When the codebase is chaotic and lacks optimization, the AI must read large amounts of useless code to understand the context, causing token consumption to skyrocket and development costs to soar [10].
*   **Elongated Communication Chains, Low Efficiency**: When code structure lacks cohesion and logic is scattered, the AI can't get the full context. You then have to spend more time explaining to the AI "why it needs to be written this way," drastically reducing human-computer communication efficiency [10].
*   **Vulnerability Replication at Scale**: A human developer might manually introduce a single security vulnerability, but an AI assistant can replicate that insecure design pattern across dozens of files at astonishing speed [10].

In the software development lifecycle, **Operations Costs > Maintenance Costs > Development Costs**. If we don't organize the architecture, the system will become completely unmanageable within three months. Currently, to modify any feature, engineers must have a sufficient understanding of the system to correctly guide the AI. This is why we mentioned in [A Deep Dive into the Limitations of Vibe Coding](https://blog.markkulab.net/post/vibe-coding-limitations) that development without an architectural mindset will eventually hit a bottleneck.


## Technical Solution: An AI-Friendly Architecture Centered on "Digital Asset Cohesion"

Faced with these challenges, we've found that "architecture" hasn't become obsolete with the advent of AI. On the contrary, architecture has become a **context compression mechanism** for AI [10]. A good architecture helps AI filter out noise, significantly reducing its reasoning overhead [10].

### 1. Modular Monoliths Outperform Microservices
In AI collaboration scenarios, a microservices architecture can easily lead to "Context Fragmentation" [10]. This is because microservices force an AI agent to understand multiple repositories, service boundaries, asynchronous messages, API contracts, and eventual consistency, which is extremely costly for AI to reason about [10].

In contrast, the **modular monolith** has a significant advantage. It concentrates highly cohesive business logic within a single project with clear boundaries, allowing AI to grasp the project's overall structure more quickly, reducing context fragmentation, and making transactional reasoning easier [10].

#### AI-Friendly Architecture Comparison Diagram

```text
【高度碎片化的微服務架構】
┌──────────────┐   ┌──────────────┐   ┌──────────────┐
│  服務 A (Repo)│   │  服務 B (Repo)│   │  服務 C (Repo)│
└──────┬───────┘   └──────┬───────┘   └──────┬───────┘
       │                  │                  │
       └───────────► 異步訊息 / API ◄────────┘
  ⚠️ AI 必須理解多個 Repository、服務邊界、API 契約與最終一致性
  ❌ 缺點：Context 嚴重碎片化、Token 消耗極大、推理錯誤率高

【高內聚的模組化單體架構 (Modular Monolith)】
┌────────────────────────────────────────────────────┐
│ 單一 Repository (共享 Context 邊界)                 │
│  ┌──────────────┐   ┌──────────────┐   ┌─────────┐ │
│  │  模組 A (Domain)│ ◄─│  模組 B (Domain)│ ◄─│CLAUDE.md│ │
│  └──────────────┘   └──────────────┘   └─────────┘ │
└────────────────────────────────────────────────────┘
  ✅ 優點：AI 載入單一專案即可取得完整脈絡、邊界清晰、交易推理簡單
```

### 2. Clean Code Guidelines as AI "Performance Settings"
In the age of AI, code quality is no longer just an engineer's aesthetic preference; it directly determines the ceiling of an AI's effectiveness [10]. To enable AI to get code changes right in one or two attempts, we recommend implementing the following standards in your project [10]:

*   **Strictly Limit Complexity**: Set the maximum Cyclomatic Complexity for a single function to 12 and the maximum file length to 400 lines [10]. Long files distract the AI.
*   **Forbid Vague Naming**: Strictly prohibit generic and ambiguous names like `utils`, `helpers`, and `common` [10]. Such names prevent the AI from quickly determining responsibilities, leading to misplaced code.
*   **Strong Typing Constraints**: Disable the `any` type in TypeScript projects [10]. Complete type definitions are the best navigation guide for an AI.

### 3. How Does the Industry Actually Enforce Coding Standards? Turning Standards from "Documents" into "Toolchains"

After decades of promoting coding standards, the industry has distilled its consensus into a single sentence: **a standard that only lives in a wiki doesn't exist**. Standards that rely on personal discipline are always the first thing sacrificed under schedule pressure; the standards that survive are the ones baked into the toolchain and enforced automatically, an approach commonly known as "Standards as Code." Mainstream teams organize this into six layers:

| Layer | Mainstream Tools | What It Catches |
| --- | --- | --- |
| Style Guides | Google Style Guides, Airbnb JavaScript, PEP 8, .NET Conventions | A shared language for naming and idioms |
| Formatter | Prettier, Black, gofmt | Every argument about indentation, quotes, and line breaks |
| Linter | ESLint, Ruff, Roslyn Analyzers | Excessive complexity, vague naming, dangerous syntax |
| Type Checking | TypeScript `strict`, mypy | Type errors, implicit `any` |
| Architecture Guards | dependency-cruiser, ArchUnit, NetArchTest | Illegal cross-module dependencies, circular dependencies |
| Gatekeeping | husky + lint-staged, CI Quality Gate (SonarQube) | Substandard code never reaches commit / merge |

A few practical takeaways:

*   **Adopt public style guides instead of inventing your own**: Google, Airbnb, and PEP 8 have been battle-tested by thousands of teams; adopting them directly saves endless style debates. There's also a hidden bonus for AI collaboration: these guides are heavily represented in the models' training data, so following mainstream conventions means "speaking the language the AI knows best," and the generated code will match your expectations more closely.
*   **Let the formatter end format debates**: The value of opinionated formatters like Prettier is precisely that "there's nothing to argue about"; formatting issues disappear from code review forever.
*   **The rules from the previous section must become linter rules**: Cyclomatic complexity of 12, 400 lines per file, no `any`, no vague naming. These can't just live in a document; let the tools enforce them:

```javascript
// eslint.config.js: turning Clean Code standards into executable rules
export default [
  {
    rules: {
      complexity: ['error', { max: 12 }], // cyclomatic complexity cap of 12
      'max-lines': ['error', { max: 400 }], // 400-line cap per file
      '@typescript-eslint/no-explicit-any': 'error', // no `any`
      'id-denylist': ['error', 'utils', 'helpers', 'common'], // no vague naming
    },
  },
]
```

*   **Architecture boundaries can be tests too**: Principles like "the Domain layer must never depend on the Infrastructure layer" can be written as automated tests with dependency-cruiser (JS/TS), ArchUnit (Java), or NetArchTest (.NET); any violation turns CI red.
*   **Set up two gates**: Locally, husky + lint-staged intercepts before every commit; then CI applies a Quality Gate (e.g., SonarQube thresholds on new-code duplication, coverage, and vulnerabilities) as the second gate. Substandard PRs never reach the mainline.

For AI collaboration, this toolchain has an amplifying effect: **linter error messages are real-time feedback the AI can read**. After an AI agent edits code, one lint run returns violations as explicit error messages the AI can immediately self-correct against, a correction loop that a wiki-bound standard can never provide.


## Implementation Steps: Building a "Context Infrastructure" and Human-AI Collaboration Workflow

To make AI a true productivity tool, we must proactively build the project's "Context Infrastructure" [10]. Here are our recommended implementation steps:

### Step 1: Create a "Context Constitution" Document
Create a `CLAUDE.md` or a dedicated context file in the project's root directory. This document serves as the "project manual" for the AI agent, clearly defining architectural principles, the tech stack, and development standards.

According to an analysis report by Anthropic, teams that maintain good context documents see a 40% reduction in AI errors and a 55% increase in task completion speed [10].

#### A Standard `CLAUDE.md` Template

Below is a `CLAUDE.md` template suitable for a TypeScript project, which you can place directly in your project's root directory:

```markdown
# CLAUDE.md - 專案開發憲法

## 專案簡介
本專案為一個基於 Node.js / TypeScript 的電子商務後端系統，採用模組化單體（Modular Monolith）架構。

## 技術堆疊
- 執行環境：Node.js v20+
- 語言：TypeScript v5+
- 框架：NestJS
- 資料庫：PostgreSQL (Prisma ORM)

## 常用指令
- 安裝依賴：`npm install`
- 啟動開發伺服器：`npm run start:dev`
- 執行單元測試：`npm run test`
- 執行整合測試：`npm run test:integration`
- 程式碼格式化：`npm run format`

## 程式碼風格與架構約束
- **架構模式**：嚴格遵循 Domain-Driven Design (DDD) 與高內聚原則。
- **命名規範**：
  - 禁止使用 `utils`、`helpers`、`common` 等模糊命名，請依業務邏輯命名（例如：`PaymentCalculator`、`EmailNotifier`）。
- **類型系統**：
  - 嚴格禁用 `any` 類型，所有變數與函式必須有明確的型別定義。
- **複雜度限制**：
  - 單一函式複雜度（Cyclomatic Complexity）上限為 12。
  - 單一檔案程式碼長度上限為 400 行。超過時必須進行模組化拆分。
- **錯誤處理**：
  - 統一使用自定義的 `AppError` 類別，禁止直接拋出未捕獲的 Generic Error。
```

### Step 2: Use the `.claude/` Folder to Upgrade Standards into AI Behavioral Constraints

`CLAUDE.md` is only the entry point. Claude Code's `.claude/` folder provides a whole set of mechanisms that upgrade team standards from "reference documents" into "behavioral constraints". Since these files live in version control, the entire team (humans and AI alike) shares the same standard:

| Mechanism | Location | When It Loads | What Belongs There |
| --- | --- | --- | --- |
| Rules | `.claude/rules/*.md` | Automatically, every conversation | Non-negotiable team laws |
| Custom Commands | `.claude/commands/*.md` | When the user types `/command` | Standardized, repeatable workflows |
| Skills | `.claude/skills/*` | When the AI deems the task relevant | Domain-specific playbooks |
| Hooks | `.claude/hooks/` + `settings.json` | Before/after tool calls (shell level) | Hard interception the AI cannot bypass |

The **constraint strength of these four layers is increasing**. Using my own blog project's actual setup as an example:

1.  **Rules (soft constraints)**: Rules placed in `.claude/rules/` enter the AI's context in every conversation. My project includes `spec-before-code.md` (a spec document must be created and confirmed before touching code) and `cache-versioning.md` (every AI-generated static asset URL must carry a version query for cache-busting). The AI actively follows them, but at heart they are still "reminders."
2.  **Commands / Skills (workflow standardization)**: Multi-step workflows like "write an article," "create a spec," or "deploy" become commands and skills such as `/write-blog`, `/create-spec`, and `/deploy`, so everyone, including the AI itself, executes exactly the same steps, eliminating the chaos of "everyone does it differently." Skills have the added benefit of loading on demand: the AI reads them only when the task is relevant, wasting no context.
3.  **Hooks (hard constraints)**: This is the critical layer. Hooks are shell-level scripts that can intercept and inspect **before** the AI invokes tools like Edit/Write. For example, my project has a `PreToolUse` hook: when `docs/specs/pending/` contains no spec document, it outright blocks the AI from modifying code files and returns a "please create a spec first" message. This is the same philosophy as linters blocking human commits: **standards are enforced by interception, not by self-discipline**.

In other words, the `.claude/` folder is the extension of "Standards as Code" into the age of AI collaboration: linters constrain the code humans write, `.claude/` constrains the AI's behavior, and only together do they form a complete safety net.

### Step 3: Implement Automated Testing as a "Guardrail"
Code generated by AI must have an objective verification mechanism. Unit and integration tests are the best "guardrails." Before a comprehensive automated testing system is in place, we strongly recommend that human engineers perform manual testing and final checks. Never let the AI deploy on its own.

This echoes what we mentioned in [AI is Diligent, But It Doesn't Understand What You're Doing: Practical Reflections from Multi-Agent to Vibe Coding](https://blog.markkulab.net/post/multi-agent-vibe-coding-practical-reflection): AI development without testing guardrails is like bungee jumping without a safety cord.

### Step 4: Establish Risk-Based Code Review Guidelines
Even if AI writes most of our code, human reading and review remains indispensable. But review shouldn't be an all-or-nothing choice between "read everything" and "read nothing"; **review depth should be proportional to the cost of being wrong**. In practice, start by asking yourself three questions:

1.  If this code is wrong, what's the cost? (Financial loss, a data breach, or just a broken layout?)
2.  Can a failure be rolled back quickly? (One-click revert, or is the data already corrupted beyond recovery?)
3.  Will this code be continuously extended and maintained? (The longer code lives, the more quality compounds.)

Based on the answers, handle AI-generated code according to three risk tiers:

| Risk Tier | Typical Scope | Review Approach |
| --- | --- | --- |
| **High Risk** | Security, payments, access control, personal data handling, data migration and deletion, external API contracts | Line-by-line review, with a second reviewer when necessary; never merge directly |
| **Medium Risk** | Core business logic, system architecture and module boundaries, code that will be extended and maintained long-term | Focus the review on whether the design and boundaries are correct; let tests guard the implementation details |
| **Low Risk** | One-off scripts, internal tools, UI style tweaks, proof-of-concepts | Let automated tests and linters do the gatekeeping, with occasional human spot checks |


## Precautions and Risks

When introducing AI collaboration, we need to pay special attention to the following points:

*   **Cognitive Risk**: If engineers "don't know the 'why' behind their work" and just blindly copy-paste AI-generated code, they will gradually lose control over the system. When an unexpected error occurs, humans will be completely unable to debug it.
*   **Inaction is the Biggest Risk**: Although AI introduces the risk of technical debt, refusing to adopt AI tools or refactor old systems for fear of making mistakes often leads to a greater risk of being outcompeted in this era of rapid technological iteration.
*   **The Trap of Over-Delegation**: Currently, AI can only be fully delegated 0% to 20% of simple tasks. The remaining 80% of the work still requires human engineers for context management and system design [10]. Never treat AI as a panacea that allows you to completely wash your hands of responsibility.


## Conclusion: Efficiency = Human Architectural Thinking + AI Execution Power

Returning to the initial question: Do we still need software engineering in the age of AI?

The answer is: **More than ever before.**

The more cohesive your digital assets, the more power AI can unleash [10]. Conversely, a chaotic architecture will only turn AI into a technical debt accelerator. Software engineering hasn't disappeared; it has transformed into "how to prepare clean context and architecture for AI" [10].

When we can guide AI with a clear architecture, standardize it with `CLAUDE.md`, and constrain it with automated tests, only then can we truly unlock AI's potential and achieve an efficient and secure development model. On this topic, I recommend reading [Rethinking the Value of Software Engineering in the AI Era](https://blog.markkulab.net/post/ai-product-mindset-internal-external-growth), which has more discussion on transforming development mindsets.

**Next Step**: Add a `CLAUDE.md` to your project today, encode your Clean Code standards into your linter config and `.claude/rules/`, and try refactoring those chaotic modules that frequently cause AI to make mistakes!


## References

*   [Clean Code for AI Agents: Make Your Codebase Agent-Ready](https://aidailycheck.com/learn/clean-code-for-ai-agents) [10]
*   [Structuring Your Codebase for AI Tools: 2025 Developer Guide (Propel Code)](https://www.propelcode.ai/blog/structuring-codebases-for-ai-tools-2025-guide) [10]
*   [Anthropic 2026 Agentic Coding Trends Report (Hivetrail analysis)](https://hivetrail.com/blog/anthropic-2026-agentic-coding-report/) [10]
*   [What Is the Claude.md File and Why Does It Matter? (MindStudio)](https://www.mindstudio.ai/blog/what-is-claude-md-file-ai-agents) [10]
*   [Codified Context: Infrastructure for AI Agents (arXiv)](https://arxiv.org/html/2602.20478v1) [10]
*   [Does Code Quality Still Matter in the Age of AI? (Mark Heath)](https://markheath.net/post/2026/3/30/does-code-quality-still-matter) [10]
*   [Keeping AI Agents In Line With Clean Architecture (NimblePros)](https://blog.nimblepros.com/blogs/ai-agents-clean-architecture/) [10]
*   [How to Standardize AI Code Generation (IBM Think)](https://www.ibm.com/think/insights/standardize-ai-code-generation-across-your-development-team) [10]
*   [Code Quality Foundations for AI-assisted Codebases (Nick Tune)](https://medium.com/nick-tune-tech-strategy-blog/code-quality-foundations-for-ai-assisted-codebases-4880f5948394) [10]
*   [AI Coding Assistants in 2026: 4x Faster, 10x Riskier (Kusari)](https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost) [10]
*   [The 80% Problem: AI Ships Fast But Creates Hidden Debt (Augment Code)](https://www.augmentcode.com/guides/the-80-percent-problem-ai-agents-technical-debt) [10]
*   [The AI Technical Debt Crisis (RocketDevs)](https://rocketdevs.com/blog/AI-Technical-Debt-Crisis) [10]
*   [Software Architecture Considerations with AI-Assisted Coding (Heemeng Foo)](https://heemeng.medium.com/software-architecture-considerations-with-ai-assisted-coding-b4f5139e100a) [10]
*   [Do AI Agents Reason Better in Modular Monoliths? (Vishal Mysore)](https://medium.com/@visrow/do-ai-coding-agents-reason-better-in-modular-monoliths-than-microservices-b2549e1c1ab3) [10]
*   [Context Engineering for Developers (Faros)](https://www.faros.ai/blog/context-engineering-for-developers) [10]
*   [Google Style Guides](https://google.github.io/styleguide/)
*   [Airbnb JavaScript Style Guide](https://github.com/airbnb/javascript)
*   [Claude Code Docs: Memory (CLAUDE.md & Rules)](https://code.claude.com/docs/en/memory)
*   [Claude Code Docs: Hooks](https://code.claude.com/docs/en/hooks)

---

## About this article and its author

Originally published on [Mark Ku's Tech Notes](https://blog.markkulab.net/en/post/clean-code-determines-ai-ceiling)

License: [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) — when reusing or quoting, credit the author and link back to the original

### About the author

**[Mark Ku](https://blog.markkulab.net/en/author/mark-ku)** — Software Solution Provider

- 10+ years senior software engineer, now an AI Builder
- Focused on large-platform architecture — North-American e-commerce, AI SaaS subscription billing
- Combining AI Agents and automation to build evolvable product foundations

### Free tools built by the author

All of these are free to use:

- [Free PDF Sign Tool](https://blog.markkulab.net/en/tools/pdf-sign): Online PDF sign tool — draw, type, or upload a signature, then drag, resize, and download. Everything runs in your browser; nothing is uploaded.
- [VS Code Refactory](https://blog.markkulab.net/en/tools/refactory): Refactory is a VS Code refactoring extension: 34 actions plus a 37-rule code-smell inspection layer with a Code Health dashboard, across 18 languages, backed by 534 tests. It learns your repo's conventions: where interfaces live, where DI is registered, whether 'use client' belongs. It ranks files by git churn × complexity so you know what to fix first, and hands any smell to the Claude Code already on your machine. Free to use, and your source never leaves your computer.
- [DB-Kit Database Manager](https://blog.markkulab.net/en/tools/db-kit): DB-Kit is a lightweight, cross-platform database manager built with Tauri + Rust + React. Manage MySQL, MariaDB, PostgreSQL, SQL Server, Oracle, SQLite, MongoDB, Redis, Kafka, Elasticsearch and RabbitMQ from one consistent interface: passwords encrypted in the OS keychain, SSH tunnels, full CRUD, a visual query builder, stacked multi-statement result sets, cross-connection data transfer and compare/sync, Excel / CSV import & export, visualized execution plans, ER diagrams, scheduled backups, SQL stress testing with p50–p99 latency percentiles, a 15-rule SQL review engine, Kafka message browsing with monitoring & alerts, a bilingual UI (Traditional Chinese / English), a built-in AI assistant (natural-language SQL, AI review and tuning advice) and the dbk CLI. Free and open source (MIT), with installers for Windows, macOS and Linux.
- [VS Code Super Mermaid](https://blog.markkulab.net/en/tools/super-mermaid): Super Mermaid is a VS Code extension for beautiful Mermaid diagrams out of the box: auto-colored live preview, mouse pan & zoom, high-res PNG / SVG export, 21 templates and multiple themes. Free and open source (MIT).
- [React Super Mermaid](https://blog.markkulab.net/en/tools/react-super-mermaid): react-super-mermaid is an open-source React component library: render beautiful Mermaid diagrams with a single <MermaidViewer>, with built-in colorful / sketch themes, pan & zoom, in-diagram search, and high-res SVG / PNG export. Lightweight, SSR-safe, fully typed. Free and open source (MIT).
- [Jira / Confluence Super Mermaid](https://blog.markkulab.net/en/tools/jira-super-mermaid): An Atlassian Forge app: write Mermaid syntax directly inside a Jira issue or a Confluence page and get flowcharts, sequence diagrams, state machines and Gantt charts. 11 diagram types, SVG / PNG export, light and dark themes, full CJK support. Runs on Atlassian: your diagrams live in your own site and the app calls no third-party service. Free, coming soon to the Atlassian Marketplace.
- [Mermaid Live Preview](https://blog.markkulab.net/en/tools/mermaid-preview): Write Mermaid in your browser, see it render instantly, and share the whole diagram as a single link. No sign-up, nothing uploaded to a server, and mermaid.live share links work as-is.
- [React Intl Phone Number](https://blog.markkulab.net/en/tools/react-intl-phone-number): react-intl-phone-number is an open-source React component: framework-agnostic and antd-free, with E.164 in/out, a searchable flag / country-code dropdown, configurable validation levels (strict / mobile-strict / loose), themeable CSS, and i18n — phone logic powered by google-libphonenumber. Lightweight and fully typed. Free and open source (MIT).
- [Uptime Kuma Cluster](https://blog.markkulab.net/en/tools/uptime-kuma-cluster): Turn single-node Uptime Kuma into a highly available cluster: OpenResty + Lua smart load balancing, shared MariaDB state, health checks and automatic failover, plus cluster-management REST APIs. One Docker Compose command to start. Free and open source (MIT).
- [Special Education](https://blog.markkulab.net/en/education): Learning materials crafted for special education students

### Daily podcasts

- [Tech News](https://blog.markkulab.net/en/category/tech-news): Daily curated AI and tech trends. Catch the latest developments via audio summaries — covering AI applications, software architecture, DevOps, and engineering practice. — RSS: https://blog.markkulab.net/feed.xml
- [AI Stock Chat](https://blog.markkulab.net/en/category/ai-stock-chat): Every trading day, an AI-analyzed take on the Taiwan stock market, delivered as a two-host conversation covering the session and the next-day outlook. — RSS: https://blog.markkulab.net/ai-stock-chat/feed.xml

### Newsletter

[Subscribe to the newsletter](https://blog.markkulab.net/en/subscribe) — Be the first to know about new posts. No spam, unsubscribe anytime.