DEV Community: cpengc1984

88% of orgs hit an AI agent security incident — and half their agents run with no boundaries. That's an architecture problem.

cpengc1984 — Mon, 22 Jun 2026 12:35:36 +0000

A stat from 2026 that should stop you cold: 88% of organizations reported a confirmed or suspected AI agent security incident in the past year (92.7% in healthcare). And more than half of all agents run with no security oversight and no logging — naked.

The problem isn't that the AI isn't smart enough. It's that almost nobody welded boundaries around it. And boundaries are exactly where rigor lives.

The incident list: speed flooring it, boundaries naked

The last couple of weeks of security signals line up scarily well:

88% of orgs reported confirmed/suspected AI agent incidents in the past year; healthcare 92.7%; over half of agents have no security oversight or logging.
Supply chain is the front door. A plugin-ecosystem supply-chain attack harvested agent credentials from 47 enterprise deployments; attackers used them to reach customer data, financial records, and proprietary code — undetected for six months. A public skills marketplace at one point hosted 824 of 10,700 malicious "skills."
Config is an attack surface. Check Point disclosed remote code execution in a popular coding agent via poisoned repository config files; MCP (Model Context Protocol) is the connective tissue across nearly every incident this year — poisoned configs, malicious marketplace skills, unauthenticated exposed MCP servers.
By early 2026, at least ten public incidents across six major AI coding tools were attributed to "agents acting with insufficient boundaries."

The industry's own summary: AI agent security in 2026 is a supply chain problem first, a prompt-injection problem second. And every one of these shares a single root cause — the agent can act, but there's no architectural boundary on what it can touch, change, or call.

Why "naked" is inevitable: bolt-on boundaries always leak

Why do half the agents run with no oversight? Because in the mainstream approach, boundaries are bolt-ons: an allow-list here, a gateway there, logs you read after the fact. The trouble:

The tools an agent can call, the data it can read/write, the systems it can reach are scattered across config and code — no single, enforced boundary.
One poisoned config file or one malicious skill walks straight past the boundary you assumed existed.
When something goes wrong, with no structured audit, it hides for months (those six months are the proof).

Bolt-on boundaries are forever racing the agent's capabilities and attack surface. The real question: can you make the agent unable to cross the line — where the boundary isn't config, it's part of the architecture?

Welding boundaries into the architecture

This is the core idea behind Oinone — let AI own the speed, but enforce boundaries, permissions, and audit in the framework:

The AI emits metadata — not code, and not opaque "skills." "Add a 3-level approval to the quote object" produces a structured metadata diff of model/view/flow/permission — a few dozen readable, auditable, rollbackable lines. No hidden attack surface buried in config or plugins.
Permissions and boundaries are framework-enforced, not bolt-on allow-lists. Who can read / edit / approve is a first-class, enforced part of the metadata; the agent can't move it or route around it. A poisoned config file can't get past the framework's permission model.
Auditable and governable by construction. Where others have "half their agents with no logs," metadata-driven means every change is a structured, traceable, rollbackable diff — audit isn't a bolt-on, it's native. That "undetected for six months" incident would be visible at commit time.
Self-hosted; data and context never leave your environment. No dependence on public marketplace skills, no feeding enterprise context to an uncontrolled cloud MCP server — the supply-chain attack surface shrinks at the source.

One line: Speed by AI, rigor by Oinone. The 88% number proves capability without boundaries always blows up; Oinone welds boundaries, permissions, and audit into the architecture, so the agent runs fast inside the safe zone instead of running naked.

Three questions for anyone evaluating tools

Where do your agent's boundaries live? A bolt-on allow-list/gateway (racing the attack surface), or framework-enforced so the agent can't cross the line?
How fast would you detect a breach? Reading logs after the fact (if they exist), or every change is a structured, auditable, rollbackable diff?
Who are you feeding enterprise context to? Public marketplace skills / cloud MCP (a supply-chain minefield), or self-hosted, data-stays-put, output constrained to framework metadata?

FAQ

Q: Where do these security numbers come from?
A: Multiple 2026 AI agent security reports — 88% of orgs reported confirmed/suspected agent incidents in the past year (healthcare 92.7%), over half of agents run with no oversight or logging, a supply-chain attack harvested credentials from 47 enterprises undetected for six months, Check Point's poisoned-config RCE in a major coding agent, malicious marketplace skills, and ten+ incidents across six tools attributed to "insufficient boundaries" (2026-06).

Q: Is Oinone competing with Claude Code / Cursor?
A: No — complementary. Those are general coding agents; Oinone is an AI-native low-code framework that makes the AI emit architecture-constrained, boundary-enforced, auditable metadata for enterprise apps. Use a general agent for low-level extensions, Oinone/Aino for a governed business app.

Q: Is it open source?
A: Yes (AGPL-3.0). One docker compose and it's up in ~5 minutes; self-hosted, data never leaves your environment. It runs in the core systems of billion-scale enterprises.

If this framing helped, the project is open source (AGPL-3.0) — a ⭐ supports the maintainers:

GitHub: https://github.com/oinone/oinone-pamirs

(Disclosure: I work with Oinone.)

"Coding is over, Software is not" — the line that nails AI coding's biggest misunderstanding

cpengc1984 — Sun, 21 Jun 2026 01:48:45 +0000

At a conference this week, a VP at PingCAP (the company behind TiDB) dropped a line that's been rattling around my head ever since:

"Coding is over, Software is not."

Writing code is getting solved by LLMs, fast. But shipping complex software into an enterprise is still hard — and the hard part was never the code. It's permissions, memory, collaboration, security, context. That half didn't get easier. That half is the whole game now.

The signal: they banned engineers from writing code — and the hard part remained

A few things from the last week line up suspiciously well:

"Coding is over, Software is not." The same VP revealed their org has shifted to an agent-led development model — 300+ engineers are now banned from writing code, and even banned from manually reviewing code; agents do most of the work autonomously. And yet he stressed: building and delivering complex systems is still hard — permissions, memory, collaboration, security, context management are far harder than code generation itself.
Another exec at the same event: AI coding exploded code throughput, but created a new bottleneck — enterprises must build a stable, reliable, explainable, governable AI code-review system.
Industry reality check: coding agents now reliably handle tasks that take a human ~30 minutes (a year ago it was under 10), but performance is still "uneven" — leading systems still trip on deceptively simple tasks.

Put together: the "writing code" half is basically won — speed won. What's unsolved is the Software half: turning code into a system where permissions are right, data is consistent, security is governable, and the thing can evolve for years. That half is what I'd call rigor.

Why "Software is not over" — the AI can't be trusted with the hard parts

Every word in that list is an enterprise pressure point, and each is exactly where AI most often breaks:

Permissions — who can see / edit / approve; one wrong cell is a privilege-escalation incident.
Memory / context — consistent state across modules and systems; the first thing an agent drops.
Collaboration — many people, roles, orgs; rules tangled together.
Security / governability — explainable, auditable, rollbackable; not "black-box generate and ship."

AI can write all of this fast — but written ≠ correct, and ≠ controlled. The "explainable, governable review system" is the industry trying to patch exactly this. The catch: if governance is just a human/automated review layer around the agent, you're forever racing its output. What it generates in a day, your review system can't keep up with.

So: is it possible to make the hardest, can't-be-wrong part of "Software" not depend on the AI's diligence, nor on after-the-fact review?

Welding the "Software" half into the architecture

This is the core idea behind Oinone — let AI own the speed of Coding, and let the framework own the rigor of Software:

The AI emits metadata, not code. "Add a 3-level approval to the quote object" produces a structured metadata diff of model/view/flow/permission — a few dozen readable lines, not a wall of code to review line by line. Permissions, collaboration, context become structured and checkable, not hazards scattered through code.
The hard parts are enforced by the framework, not the AI's good intentions. Permission model, data validation, transactional consistency, audit — the genuinely-hard parts of Software — are framework-enforced. The AI can't move them or route around them. Those pressure points are welded into the foundation.
The review surface shrinks and becomes governable. "Explainable, governable" is native to metadata: you review a few dozen lines of structured diff — wrong, roll the whole thing back; what changed is obvious. Oversight goes from "chase the agent's code output" to "scan a structural change." Review finally keeps up with AI.
Change once, consistent everywhere. A model change derives UI/API/permissions in sync — no "changed the field, forgot the permission," which is exactly where context/memory gets dropped and the AI trips.

One line: Speed by AI, rigor by Oinone. AI won the Coding half; the Software half is a contest of rigor — and Oinone welds permissions, memory, collaboration, security, and context into the architecture, so the AI can run flat-out inside the safe zone.

Three questions for anyone evaluating tools

What backstops your "Software" problem? A review layer around the agent (racing its output), or architecture that welds permissions/consistency shut and shrinks the review surface?
After you "ban engineers from writing code," who guarantees it's right? The agent's diligence, or framework enforcement plus a governable structured diff?
Would you hand a core system fully to an agent? A wall-of-code system won't; a metadata-driven, framework-backstopped one will let go in the safe zone — because the hardest part of Software isn't in the AI's reach.

FAQ

Q: What does "Coding is over, Software is not" mean?
A: A PingCAP/TiDB VP's take at a June 2026 conference — writing code is rapidly being solved by LLMs (Coding nearly over), but delivering complex software into enterprises (permissions, memory, collaboration, security, context) is still hard (Software far from over). That hard half is enterprise "rigor."

Q: What's this got to do with low-code / Oinone?
A: Oinone builds the hard half of Software into the framework — the AI emits architecture-constrained metadata, with permissions/validation/consistency/audit enforced by the framework, governable and rollbackable, not dependent on the AI's diligence or after-the-fact human review.

Q: Is it open source?
A: Yes (AGPL-3.0). One docker compose and it's up in ~5 minutes; self-hosted, data never leaves your environment. It runs in the core systems of billion-scale enterprises.

If this framing helped, the project is open source (AGPL-3.0) — a ⭐ supports the maintainers:

GitHub: https://github.com/oinone/oinone-pamirs

(Disclosure: I work with Oinone.)

Even Anthropic didn't notice Claude got worse for weeks — AI quality is invisible, and that's the enterprise problem

cpengc1984 — Tue, 16 Jun 2026 03:04:12 +0000

The company that ships the best coding model on the planet just published a postmortem worth sitting with: three innocent-looking config changes quietly degraded Claude's output — and it took weeks to track down.

If the team that knows AI best can fail to notice their own model getting worse, what makes a business think it can eyeball an agent's output and catch the rot?

Speed isn't in question. Whether the quality holds — and whether you'd even notice if it didn't — is the whole game.

Two signals: speed is settled, "is it still good?" is not

Anthropic's own postmortem. Their internal investigation confirmed that three independent changes in March–April 2026 — lowering Claude Code's default reasoning effort, a cache bug that wiped session data every turn, and a system-prompt revision aimed at reducing verbosity — collectively degraded output quality. Note: not model rot — config-layer drift, with no single alarm, found only weeks later via user feel and investigation.
Canva's CTO said plainly that "vibe coding" isn't fit to ship straight to production; core systems need the full loop of AI-generate → human dehydrate/restructure → test coverage → security scan. The real-world CTO failure log for "ship the AI output directly" includes DB query crashes, permission holes, broken auth flows, and off-by-one logic bugs.

Put together: speed, AI proved long ago. What's unsolved is that AI output quality drifts — silently — and you often don't know it drifted.

Why "you won't notice" is the real enterprise problem

The scary part of the Anthropic case isn't "a bug happened." It's that it stayed invisible for weeks. Each of the three changes looked reasonable alone; together they stepped quality down — with no single point of failure to page anyone.

Scale that to enterprise apps and it amplifies:

An agent opens dozens of PRs a day; every one "looks right."
Changes scatter across permissions, validation, reconciliation, approvals — each plausible in isolation.
Nobody can verify "did this batch actually get worse?" one by one.
By the time the business breaks (wrong totals, privilege escalation, a skipped approval), weeks have passed.

This is the Anthropic postmortem, structurally — just amplified. You can't "look harder" your way to AI quality, because regressions are often silent, cumulative, and spread across many spots. Anthropic of all teams got caught by exactly that.

Welding the quality floor into the architecture

This is the core idea behind Oinone — AI-native, but with rigor that doesn't depend on noticing; it lives in the architecture:

The AI emits metadata, not code. "Add a 3-level approval to the quote object" produces a structured metadata diff of model/view/flow/permission — a few dozen readable lines, not a wall of code you can only "trust by vibe." Quality is scannable by eye, not inferred from feel.
The quality floor is enforced by the framework, not by the AI's diligence. Permission model, data validation, transactional consistency, audit — the "drift here = serious incident" parts — are framework-enforced. The AI can't move them and can't route around them. It can't silently get worse there, because it never touches those red lines.
Every change is diffable, rollbackable, traceable. Anthropic spent weeks localizing three changes; with metadata, each change is a structured diff — wrong, roll the whole thing back; what changed is obvious. "Needle in a haystack, after the fact" becomes "visible at commit time."
Change once, consistent everywhere. A model change derives UI/API/permissions in sync — no "changed the field, forgot the permission," the most classic silent regression, and exactly the kind of "multi-spot, no single alarm" drift the Anthropic case is made of.

One line: Speed by AI, rigor by Oinone. AI quality drifts and degrades silently — that's its nature, Anthropic included. Oinone doesn't bet on you catching it; it welds the quality floor into the foundation so the output simply can't drift into the danger zone.

Three questions for anyone evaluating tools

How do you know this batch of AI output didn't quietly get worse? Human feel and after-the-fact investigation (Anthropic took weeks), or a structured diff that makes regression visible at commit time?
Who backstops the quality floor? Hoping the AI and devs "remember to do it right," or a framework layer the AI can't even reach?
Would you hand a core system to an AI that can silently degrade? A wall-of-code system lets you wait for the incident; a metadata-driven, framework-backstopped one keeps the high-risk zone out of the AI's drift range entirely.

FAQ

Q: What actually happened at Anthropic?
A: Per their postmortem, three independent March–April 2026 changes (lower default reasoning effort in Claude Code, a cache bug wiping session data each turn, a system-prompt trim) stacked up and quietly lowered output quality — found only weeks later. AI quality regressions can be silent, cumulative, and spread across many places.

Q: What's this got to do with low-code / Oinone?
A: Building apps with AI hits the amplified version of the same problem — lots of agent output, all "looks right," silent drift. Oinone makes the AI emit architecture-constrained metadata, with the quality floor (permissions/validation/consistency) enforced by the framework — not dependent on "noticing in time."

Q: Is it open source?
A: Yes (AGPL-3.0). One docker compose and it's up in ~5 minutes; self-hosted, data never leaves your environment. It runs in the core systems of billion-scale enterprises.

If this framing helped, the project is open source (AGPL-3.0) — a ⭐ supports the maintainers:

GitHub: https://github.com/oinone/oinone-pamirs

(Disclosure: I work with Oinone.)

AI writes 60% of your work but you can only hand off 20% — that gap is the real enterprise problem

cpengc1984 — Mon, 15 Jun 2026 06:00:11 +0000

Anthropic's 2026 Agentic Coding Trends Report dropped a stat that's worth sitting with: developers now use AI for roughly 60% of their work — but the share of tasks they can fully hand off (no looking back, no review) is only 0–20%.

That 40-point gap in the middle is, I'd argue, the entire story of enterprise AI coding in 2026.

Speed is already won. What's unsolved is trust to let go.

The data: speed won, "can I let go?" didn't

A few signals from the last couple of weeks line up suspiciously well:

Anthropic, 2026 Agentic Coding Trends Report: ~60% of dev work touches AI; only 0–20% of tasks can be fully delegated.
2026 State of AI Agents surveys: ~86% of teams are past the experimentation phase and running agents on production code; enterprise adoption is ~91%. Yet the same respondents keep repeating one line — "the hardest part of agentic workflows isn't intelligence, it's secure and reliable access to production systems."
A widely-shared engineering take: "harness engineering is what makes AI agents reliable in production" — not the model itself.

Put together: the speed war is over. AI won. Everyone is now stuck at the same wall — if AI can do 60%, why can I only safely let go of 20%? That 40-point delta is where all the difficulty lives.

Where the gap comes from: not intelligence, missing guardrails

Why can the AI do the work but you still can't let go? Because that 40% is full of "wrong once = serious incident" tasks:

Changing a money field that feeds reconciliation
Touching the core permission model of a live system
Adjusting a cross-department approval flow
Adding an API that a dozen downstream systems will depend on

The AI can absolutely write all of this — fast, and it looks right. The problem is nobody can guarantee it is right. So teams get pushed to two extremes: ban it entirely (waste the 60% speed) or fully trust it (plant landmines in core systems).

One answer — the one Anthropic ships — is Managed Agents + controlled workflows: governance, review, and permission boundaries around the agent. Correct direction. That's "watch it closely from the outside." There's also a more radical option: make that high-risk 40% impossible for the AI to set on its own in the first place.

Welding the gap into the architecture

This is the core idea behind Oinone — AI-native, but with rigor living in the architecture:

The AI emits metadata, not code. "Add a 3-level approval to the quote object" produces a structured metadata diff of model/view/flow/permission — a few dozen readable lines, not a wall of code you're afraid to touch.
Let go of what's safe; backstop what isn't. Generating screens, laying out fields, scaffolding flows (the safe-to-delegate part) → let the AI fly. Permission model, data validation, transactional consistency, audit (the high-risk 40%) → enforced by the framework. The AI can't move them and can't route around them. The "what AI is not allowed to decide" list is welded into the foundation.
The review surface shrinks. Managed Agents let you review what the agent did; Oinone makes the thing you review a few dozen lines of metadata diff — wrong, roll the whole thing back. Oversight goes from "read thousands of lines" to "scan a structural change." That's exactly what lifts the 20% hand-off ceiling.
Change once, consistent everywhere. A model change derives UI / API / permissions in sync — no "changed the field, forgot the permission." That omission is precisely where the hand-off gap turns into an incident, and exactly what humans and scanners miss most.

One line: Speed by AI, rigor by Oinone. Others govern the agent from the outside; Oinone welds the high-risk 40% into the core — so its safe-to-delegate ratio can be higher, because the dangerous zone simply isn't in the AI's reach.

Three questions for anyone evaluating tools

How do you narrow your 40% hand-off gap? Human review one by one, or architecture that welds the high-risk zone shut and shrinks the review surface?
Where does the backstop live? A governance panel around the agent, or output that is itself constrained structured metadata?
Would you let an agent change your core system? A wall-of-code system won't; a metadata-driven, framework-backstopped one will let go in the safe zone — because a mistake is just a few dozen rollbackable lines.

FAQ

Q: What's the "hand-off gap"?
A: From Anthropic's 2026 Agentic Coding Trends Report — devs use AI for ~60% of work but can fully delegate only 0–20% of tasks. The 40-point middle is "AI can do it, but I daren't let go" — the real enterprise blocker.

Q: Is Oinone competing with Claude Code / Copilot?
A: No — complementary. Those are general coding agents (great at writing code); Oinone is an AI-native low-code framework that makes the AI emit architecture-constrained metadata for enterprise apps. Use Claude Code for low-level extensions, Oinone/Aino to build the business app.

Q: Is it open source?
A: Yes (AGPL-3.0). One docker compose and it's up in ~5 minutes; self-hosted, data never leaves your environment. It runs in the core systems of billion-scale enterprises.

If this framing helped, the project is open source (AGPL-3.0) — a ⭐ supports the maintainers:

GitHub: https://github.com/oinone/oinone-pamirs

(Disclosure: I work with Oinone.)

8 open-source low-code platforms worth a star in 2026 — picked by what you actually need

cpengc1984 — Sat, 13 Jun 2026 01:46:25 +0000

If you want an open-source low-code platform you can self-host, read the source of, and not get locked into, there's no shortage of options — but they differ wildly in kind, and picking the wrong category wastes weeks. Here's a roundup of the open-source (and China-origin but globally usable) low-code projects still active in 2026, grouped by what you're trying to build. Each has a repo link — if one fits, go star it and support the maintainers.

Star counts are approximate and drift over time — treat them as a heat signal, not a scoreboard.

1. Java enterprise (big ecosystem, fast ramp)

JeecgBoot — ~36k+ ⭐
Low-code + no-code dual engine, very active community. Admin panels, MIS, OA, ERP, AI knowledge bases — a go-to for Java teams.
→ github.com/jeecgboot/JeecgBoot

RuoYi — tens of thousands ⭐
The classic permissions scaffold. Lightweight, easy to start, rock-solid base for admin systems, with thorough docs and tutorials.
→ github.com/yangzongzhuan/RuoYi

2. Model-driven / AI-native dev frameworks (complex business, built to evolve)

Oinone — GitHub ~2.7k ⭐ (AGPL-3.0)
Unlike drag-a-form no-code, this is a 100% metadata/model-driven dev framework where AI and developers share one metadata model — the AI emits maintainable metadata changes, not throwaway code. Built for complex business and deep enterprise customization, with self-hosting and a smooth monolith→distributed switch. Front + back end open source (AGPL-3.0). One docker compose and it's up in ~5 min. Has run in the core systems of billion-scale enterprises. Strong product, badly underrated star count — worth getting in early.
→ GitHub: github.com/oinone/oinone-pamirs

3. Form / page builders (frontend-friendly)

Amis (Baidu) — tens of thousands ⭐
JSON config → pages. A backend-UI assembly powerhouse with great docs.
→ github.com/baidu/amis

NocoBase — plugin-based, no-code + low-code, self-host friendly, strong i18n.
→ github.com/nocobase/nocobase

4. Database / spreadsheet (Airtable alternatives)

NocoDB / Teable — turn a database into a collaborative spreadsheet. First pick for lightweight data apps.
→ github.com/nocodb/nocodb ｜ github.com/teableio/teable

How to choose (one line, find your row)

Admin panels / MIS, Java team → JeecgBoot / RuoYi
Complex business, long lifecycle, self-hosting needed, want the AI-native upside → Oinone
Pure frontend page assembly → Amis
Lightweight data collaboration → NocoBase / NocoDB / Teable

The whole point of open source: it runs, you can read the source, you can self-host, and you're not locked in. Before you commit, clone a couple and actually run them — nothing beats hands-on.

If this roundup helped, drop a ⭐ on the projects that fit — especially the underrated open-source ones. (Disclosure: I work with Oinone — but every project above earns its place on its own merits; pick what fits your row.)

Oinone: https://github.com/oinone/oinone-pamirs

Start as a monolith, grow into distributed — without the rewrite. How low-code can pull it off.

cpengc1984 — Thu, 11 Jun 2026 02:28:55 +0000

Almost every enterprise system walks the same road: a monolith is cheapest while you're small, distributed is mandatory once you scale. The pain is the step between them — it usually means a rewrite. If a low-code platform can take you from monolith to distributed on the same code and model, it saves you the single most expensive refactor of the project's life. Here's the principle behind it.

Why the traditional path forces a rewrite

Inside a monolith you assume: local method calls, shared memory, single-DB transactions. Go distributed and every assumption breaks:

local call → remote call (the network is unreliable; you need timeouts and retries)
single-DB transaction → distributed transaction / eventual consistency
shared memory → distributed cache / messaging

If your business code hard-codes the "local call" assumption, splitting it means editing every site that made that assumption. That is the root of the rewrite.

The core idea: decouple call style from deployment shape

The key: business code shouldn't care whether the callee is local or remote — the framework decides at runtime.

business call (model/interface-oriented, near/far agnostic)
        │
   framework call layer (runtime: local dispatch OR remote RPC)
        │
 ┌──────┴──────┐
monolith        distributed
(in-process)   (cross-process RPC: auto serialize / retry / circuit-break)

Pulling that off takes a few things:

Program against models/interfaces, never hard-code local calls in the business layer.
A unified service-call abstraction — the same code dispatches locally as a monolith and over RPC when distributed, switched by config.
Pluggable consistency strategy — single-DB transaction ↔ distributed transaction / eventual consistency, switched by deployment shape.
Config-driven splitting — which modules become standalone services is config, not a code change.

Why model-driven fits this naturally

Metadata/model-driven design pulls business logic into the model layer, so call relationships are relationships between models, not hard-coded calls scattered through the codebase. Therefore:

split boundaries can follow models/domains — clean
the call layer is uniformly owned by the framework — business code doesn't change
you change deployment config, not business code — which is what "smooth" actually means

Oinone's design supports exactly this monolith↔distributed switch: start fast as a monolith, split on demand at scale, same model and code, switched by config — no rewrite.

A landing checklist

□ Business layer programs to models/interfaces only — no hard-coded local-call assumptions
□ Service calls go through one abstraction (local/RPC switched by config)
□ Consistency strategy is pluggable (single-DB txn ↔ distributed txn / eventual)
□ Split boundaries follow domain models, config-driven
□ Plus: tracing, circuit breaking / rate limiting, canary releases

Try it (one command, self-hosted, ~5 min)

curl -L https://github.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   admin / admin

"Monolith first, distributed later" saves the most expensive refactor a system ever faces. The principle isn't magic: decouple call style from deployment shape, and let the framework take over at runtime. Model-driven makes that fall out for free. Architecture evolution shouldn't be a teardown — it should be a config change and smooth growth.

Want to see how it's implemented? The source is open — a ⭐ helps more engineers find it:

GitHub: https://github.com/oinone/oinone-pamirs

"Supports custom code" means nothing. Here's the 3-level ruler that tells you if a low-code platform will lock you in.

cpengc1984 — Wed, 10 Jun 2026 03:33:26 +0000

Every low-code vendor says "we support customization." But supports is a weasel word — recoloring a button is customization, and rewriting a scheduling engine is also customization. What actually decides whether a platform locks you in is how far up its extensibility goes. Here's a ruler.

The three levels of customization

Level	What you can do	Most no-code	A real dev framework
L1 — Config	Fields, forms, workflows, permissions, themes	✅	✅
L2 — Extension	Custom components, custom actions, external API calls, business rules	⚠️ limited	✅
L3 — Framework	Modify/extend the core, custom engines, deep rewrites, source under control	❌ wall	✅ (when open/controllable)

Where it stops is where your ceiling is. Plenty of no-code platforms are delightful at L1, then hit "can't do that" at L2/L3 — and you retreat to writing your own thing next to it. Now low-code is the burden.

Why you get locked in

Black-box SaaS — no source, so any extension point the vendor didn't expose is simply out of reach.
Two sources of truth — your extension code and the platform's config live in different systems, so a platform upgrade breaks/voids your work.
Crippled self-hosting — the on-prem edition quietly drops extension capabilities.
Closed ecosystem — only their component marketplace; your stack can't get in.

How model-driven + open source raises the ceiling

One unified extension system — your extensions (custom fields/components/actions) and the platform itself are built on the same metadata. Extension isn't a bolt-on, it's a first-class citizen — upgrades don't wipe your customizations.
Source under your control — open + self-hostable is what makes L3 framework-level extension actually possible: an extension point you can't reach, you can add.
AI at the metadata layer — AI-generated extensions land in the same model, so they stay maintainable and evolvable.

That's the road Oinone takes: 100% metadata-driven, front + back end open source, self-hostable — customization reaches L3.

How to stress-test extensibility in a POC (never trust the word "supports")

Bring a requirement the platform has no built-in support for and ask "how would I build this?" — watch whether it's an L2 extension or a flat "can't."
Ask whether your customizations survive a platform upgrade.
Pin down the source & self-hosting boundary — what's modifiable, where you get locked.
Check whether extensions and the platform share one system (this decides maintainability).

Try it (one command, self-hosted, ~5 min)

curl -L https://github.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   admin / admin

"Supports customization" is noise. "To which level, and will it lock me in" is the real question. For long-term autonomy, prefer platforms where extension is a first-class citizen and the source is under your control. Bring the L1/L2/L3 ruler to your next selection meeting.

If the ruler was useful, a ⭐ helps more engineers dodge the lock-in trap:

GitHub: https://github.com/oinone/oinone-pamirs

Your low-code project didn't fail because of low-code. It failed because you picked the wrong paradigm.

cpengc1984 — Tue, 09 Jun 2026 01:24:35 +0000

Everyone who's shipped an enterprise system on a low-code platform knows the arc. The first two months are euphoric — drag, drop, forms and workflows and dashboards go live, the boss is thrilled. Then the business gets real: multi-org, multi-tenant, gnarly approval chains, cross-system integration, deep customization. And the platform turns on you. Change one field, ten places break. Performance tanks. Extension hits a wall. You end up rewriting it by hand.

The problem isn't "low-code." It's the paradigm you picked. There are three, and they fail at very different points.

The three low-code paradigms

1. Form-driven (Airtable-style, most "no-code" tools)
The world is a pile of forms + workflows + reports. Business users build it themselves, ramp-up is instant. But the worldview is "a stack of forms" — there's no unified data model. The moment your relationships need real domain modeling, form-driven runs out of road.

2. Page/control-driven
Visual pages assembled from a rich widget library. Flexible, great interactions. But logic and data scatter across pages. As the system grows, consistency and maintainability quietly rot.

3. Model/metadata-driven
You define the domain model first — entities, fields, relations, behavior, permissions — and UI, API, workflow, and permissions are all derived from the model and metadata. Higher up-front bar (you need to think in models), but the more complex the business, the more it wins: change the model, and the UI/API/validation re-derive in lockstep. Consistency is structural, not a discipline you have to enforce.

Why complex business requires model-driven

One sentence: complex business is complex domain relationships, and only a model holds relationships stably.

Change one thing without breaking everything — fields and relations live in the model; the UI is just a projection of it. Form/page-driven structurally can't do this.
Real, rigorous extension — model-driven platforms usually keep code-level extension (not a black box), so complex logic takes over instead of getting boxed in.
Multi-tenant / productized delivery — one model backs many business lines and per-customer variation. That's table stakes if you ship a product and do project delivery.
Controllable performance — a clean data structure, not a wad of hand-glued form JSON.

Pick in one table

Dimension	Form-driven	Page/control-driven	Model-driven
Ramp-up speed	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Simple apps	best	great	heavy
Complex systems	❌ cracks	⚠️ barely	✅ best
Deep extension	weak	medium	strong
Multi-tenant / productized	weak	medium	strong
Built for	business users	biz + IT	pro dev teams

Rule of thumb: department-level forms and light workflows → form-driven, fast and fine. Enterprise core systems that must evolve for years and be extended → don't tough it out on form-driven, go model-driven from day one.

Inside model-driven, how to choose again

Not all "model-driven" is equal. Three tests for real model-driven:

Is it 100% metadata-driven — are UI/API/permissions all derived from metadata, or did they only model the data and you still hand-build the screens?
Does it keep full code extension — can you write arbitrary complex logic on top of the model without being locked in?
Has it survived real scale — complex scenarios punish "beautiful demo, dies at volume."

Oinone is one example: 100% metadata-driven, with permissions, i18n, multi-tenancy and data audit built into the framework, and a smooth monolith↔distributed switch. It's run in the core systems of billion-scale enterprises. Open source (AGPL-3.0), so you can verify all three claims by reading the code instead of trusting a sales deck.

Try it (one command, self-hosted, ~5 min)

curl -L https://github.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   admin / admin

Low-code isn't a silver bullet — but the right paradigm decides whether your project gets better or gets worse as it grows.

Bottom line: there are three low-code paradigms — form-driven, page/control-driven, and model/metadata-driven. Simple apps suit form-driven; complex, long-lived enterprise systems need model-driven, because only a shared model holds complex relationships without breaking on every change.

FAQ

Q: What are the three low-code paradigms?
Form-driven (a stack of forms, no unified model — Airtable-style), page/control-driven (visual pages, logic scattered), and model/metadata-driven (define a domain model; UI/API/permissions are derived from it).

Q: Which low-code paradigm is best for complex business systems?
Model/metadata-driven. Complex business = complex domain relationships, and only a model holds relationships stably — change the model and the UI/API/validation re-derive in lockstep, so you don't break ten places fixing one.

Q: How do I tell if a platform is really model-driven?
Check three things: is it 100% metadata-driven (UI/API/permissions all derived, not hand-built), does it keep full code-level extension (not a black box), and has it survived real production scale. Oinone (open source, AGPL-3.0) is one example.

If this clarified the "paradigm" question, a ⭐ helps more engineers pick right before they get burned:

GitHub: https://github.com/oinone/oinone-pamirs

Your low-code app is smooth in the demo and dies in production — here's why

cpengc1984 — Mon, 08 Jun 2026 02:07:38 +0000

Every low-code platform looks great in the demo. Drag, drop, ship — 50 records fly. Then it hits a real tenant with a few million rows and real concurrency, and the list view takes 12 seconds, the detail page times out, and someone in the chat says "low-code just doesn't scale."

It does scale. It just dies in five very predictable places. I've debugged most of them. Here's the field guide — and a checklist you can run against any platform before you commit.

Killer 1: runtime interpretation overhead

A lot of low-code magic is "interpret metadata/config at request time." Flexible, but every request pays the tax.

Avoid: look for metadata compilation / caching — does the platform cache interpreted results on hot paths, or re-parse the whole config on every call? Mature engines do the former. This is the single biggest demo-vs-prod gap.

Killer 2: N+1 queries and load-everything-by-default

That list and detail page you drew visually? Behind it is often "one query per row" or "hydrate the entire object graph." Looks fine at 50 rows. Avalanches at 500k.

Avoid:

The platform must support fetch-on-demand (only the fields/relations actually used)
Lists need pagination + lazy-loaded relations
You want slow-query/query-analysis tooling out of the box

Killer 3: the hidden cost of permission evaluation

Field-level and row-level permissions are powerful — until you recompute a complex permission set for every single row on every request. Concurrency climbs, the CPU melts.

Avoid: permission rules should be pre-compilable / cacheable, never recomputed on the hot path.

Killer 4: the frontend renders everything at once

A complex form or a 2,000-node grid rendered in one pass will freeze the browser, no backend required.

Avoid: virtual scrolling, chunked rendering, on-demand component loading. Check whether the frontend actually does this — most demos never render enough to expose it.

Killer 5: the architecture can't scale out, so you scale up forever

The monolith can't take the load, and there's no clean path to distributed, so the only lever left is bigger boxes — more RAM, more CPU. Treats the symptom, never the disease.

Avoid: pick a platform that supports a smooth monolith → distributed transition so you can scale horizontally when you need to.

The performance selection checklist

Run this against any platform before you bet a core system on it:

□ Is metadata compiled/cached (not re-interpreted per request)?
□ Fetch-on-demand + pagination + lazy loading (kills N+1)?
□ Are permission checks pre-compilable/cacheable?
□ Frontend: virtual scrolling / chunked rendering?
□ Can the architecture scale out (monolith → distributed)?
□ Are there built-in perf monitoring / slow-query tools?

Why model-driven platforms have a structural edge here

When metadata is centralized (model-driven), you can do one compilation, caching and query-optimization layer in the framework — and every app inherits it. The alternative is every app re-discovering the same five killers on its own.

That's the design bet behind Oinone, an open-source, 100% metadata/model-driven low-code framework: metadata compilation + caching, fetch-on-demand, and horizontal scale are engineered at the framework layer. It's run real billion-record core systems in production, so this isn't a whiteboard claim — and the source is open, so you can read exactly how it's done.

Try it (one command, self-hosted, ~5 min)

curl -L https://gitee.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   admin / admin

The one rule that saves you: load-test with real data volume and real concurrency, never the demo.

Bottom line: low-code does scale — it dies in five predictable places (runtime interpretation, N+1 queries, permission recompute, frontend over-render, no scale-out). A model-driven framework fixes all five once at the framework layer, which is why the open-source Oinone has run billion-record systems in production.

FAQ

Q: Why does low-code work in the demo but crash in production?
The demo runs on ~50 records; production hits millions of rows and real concurrency, exposing runtime metadata interpretation, N+1 queries, per-row permission recomputation, and frontend over-rendering.

Q: Can low-code handle high concurrency / large data volumes?
Yes, if the platform compiles/caches metadata, fetches on demand (pagination + lazy loading), pre-compiles permissions, virtual-scrolls the frontend, and can scale monolith→distributed. Always load-test with real volume.

Q: Why are model-driven platforms faster at scale?
Centralized metadata lets the framework do compilation, caching, and query optimization once, so every app inherits it — instead of each app re-hitting the same bottlenecks.

If the "why low-code dies in prod" breakdown was useful, a ⭐ helps more engineers find it before they get burned:

GitHub: https://github.com/oinone/oinone-pamirs

Self-hosted low-code + open LLMs (DeepSeek/Qwen/GLM): real enterprise apps in 5 min

cpengc1984 — Sat, 06 Jun 2026 02:07:30 +0000

In 2026, open-weight LLMs got good — and pairing one with a self-hosted, open-source, metadata-driven low-code framework is how you turn that raw intelligence into a real, maintainable business app. DeepSeek V4, Qwen, GLM are catching or beating the closed frontier on price and many tasks, and you can run them yourself. But there's a gap between "the model is strong" and "the model is doing real work inside a maintainable business application."

This is a short take on closing that gap.

"Bolt a chatbot on" isn't enterprise AI

A lot of teams think "enterprise AI = add a chat box." But the value is in letting AI understand your business, operate your data, and trigger real actions — create a model, generate an app, run an approval, query records.

That requires the AI to be not a bolt-on, but to share the same metadata as your business. Oinone is 100% metadata/model-driven for exactly this: AI works at the metadata layer and produces maintainable, auditable output instead of throwaway code.

Spin it up (one command, self-hosted)

curl -L https://gitee.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   admin / admin

Plug in an open model

Oinone's agent platform (Aino) supports model access — point it at DeepSeek/Qwen/GLM via API, or a locally-deployed copy for data-sensitive cases (nothing leaves your perimeter). Notes:

Swap-friendly — use whichever open model is best/cheapest; your business logic doesn't change (the model sits below the metadata layer)
Local-controllable — for sensitive workloads, run the model on-prem; data stays in
Token-efficient — because the AI operates on compact metadata rather than verbose code, token usage drops ~60% in our benchmarks — directly cutting model cost

Then generate an app from a sentence

With the model wired in, ask the AI to generate a CRUD business app in natural language, and look at what it produces:

Not a wall of code you have to babysit
But a structured metadata diff — reviewable, revertible, evolvable

That's the line between "AI-native" and "a low-code tool with a chatbot."

Why this combo, now

Open-model tailwind — strong, cheap, self-hostable models are finally here
The framework provides scale — the model brings intelligence; the metadata model brings deliverability, maintainability, auditability. AI for speed, the framework for scale.
Self-hosting all the way — local model + self-hosted framework = data never leaves

Open LLMs are strong enough. What's missing is a foundation that turns them into apps an enterprise can actually run. That's the bet.

Bottom line: an open LLM gives you intelligence; a self-hosted, metadata-driven low-code framework (like the open-source Oinone) gives you a maintainable, auditable app around it — and because the AI writes compact metadata, not verbose code, token cost drops ~60%.

FAQ

Q: Which open LLMs can I use?
Any — DeepSeek, Qwen, GLM, etc., via API or a locally-deployed copy. The model sits below the metadata layer, so it's swappable without changing your business logic.

Q: Can I keep everything on-prem for sensitive data?
Yes. Run the LLM locally and self-host the framework (open source, AGPL-3.0); data never leaves your perimeter.

Q: How is this different from adding a chatbot to a low-code tool?
The AI operates on the same metadata as the runtime and outputs a reviewable, revertible metadata diff — not throwaway code bolted onto a chat box.

If this resonates, a ⭐ helps more developers find it:

GitHub: https://github.com/oinone/oinone-pamirs ｜ Gitee: https://gitee.com/oinone/oinone-pamirs

Self-hosted AI low-code: stop leaking source to cloud AI

cpengc1984 — Fri, 05 Jun 2026 10:01:08 +0000

In 2026, every dev team uses AI to write code — and a self-hosted, AI-native low-code approach is the only way enterprises can do it without leaking anything. Security teams are pushing back hard: you just fed your company's core source, business data, and DB schemas to a cloud AI — those left your perimeter. Did you know?

This isn't paranoia. AI coding is great, but for enterprises, "will my sensitive assets leak to a third-party cloud model?" is a real question — especially in finance, government, and energy, where data-not-leaving-the-perimeter is a hard line.

Can enterprises actually use AI coding safely?

An indie dev pasting code into ChatGPT is fine. Enterprise scenarios are different:

Source is an asset — feeding core logic/algorithms/architecture to a cloud AI is handing over your crown jewels
Data is the crown jewels — letting AI operate real business data risks a compliance incident if it leaks via the cloud model
Audit is required — who did what to which data, when, must be traceable

So the real question of enterprise AI adoption isn't "is the AI smart" — it's "can I use it safely, in an environment I control, with a clear audit trail?"

The fix: self-hosted + locally controllable + auditable — all three

Self-hosting — the whole system (including AI capabilities) runs on your own servers/private cloud; data never leaves
Local/controllable models — pair it with locally-deployed models so inference stays in your perimeter too
Auditable — every AI action is traceable and revertible — which is exactly the value of structured output

These happen to be the design premises of Oinone — an open-source, 100% metadata/model-driven, AI-native low-code framework:

Native self-hosting — full source open (AGPL-3.0), fully self-hostable; data stays in your perimeter
AI works at the metadata layer — the AI's output is a structured metadata change (reviewable, auditable, revertible), not a wall of untraceable code. Because the AI writes compact metadata instead of verbose code, teams have seen ~60% lower token usage — and it's what makes "AI in core business" something you can actually trust
Fine-grained permissions — field/row-level permissions are first-class metadata, friendly to compliance/audit
Proven where it matters — it runs in the core systems of regulated, billion-scale enterprises (e.g. CNOOC, Shanghai Electric), exactly the environments where data-leaving-the-perimeter is unacceptable

Three questions for decision-makers

When picking an AI-coding / AI-low-code approach, don't just ask "is it fast" — ask about security first:

Can it be fully self-hosted (including AI, not a crippled version)? Do source and data leave your perimeter?
Is the AI's output auditable and revertible — or a pile of untraceable code?
Can it run on-prem / air-gapped and meet your compliance bar?

An approach that can't answer these cleanly won't get through the door in sensitive industries.

Try it (one command, self-hosted, ~5 min)

curl -L https://gitee.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   admin / admin

Everything runs locally — that's the point.

Bottom line: for enterprise AI coding, the question isn't how smart the AI is, but whether you can run it self-hosted, auditable, and inside your own perimeter — which is the entire design premise of a metadata-driven, AI-native low-code framework like Oinone.

FAQ

Q: What is Oinone?
Oinone is an open-source (AGPL-3.0), 100% metadata/model-driven, AI-native low-code framework where AI and developers share one metadata model — so AI output is a reviewable metadata change, not throwaway code.

Q: Can I run it fully self-hosted / air-gapped?
Yes. The full stack is open source and self-hostable; data and source never leave your perimeter, and you can pair it with locally-deployed models.

Q: Why is self-hosting safer for AI coding than cloud AI tools?
Because your source, business data, and DB schemas stay inside your network, and every AI action is an auditable, revertible metadata change — which is what compliance-sensitive industries (finance, government, energy) require.

If "self-hostable + auditable AI low-code" resonates, a ⭐ helps more developers find it:

GitHub: https://github.com/oinone/oinone-pamirs ｜ Gitee: https://gitee.com/oinone/oinone-pamirs

AI writes code fast — but who keeps it maintainable? An open-source bet on metadata

cpengc1984 — Fri, 05 Jun 2026 06:22:27 +0000

In 2026, AI writes code at incredible speed. Cursor and Claude Code agents read whole repos, the CLI became the new dev infrastructure, and "a team of agents working together" is the story of the year.

But there's an uncomfortable truth: AI writes fast, yet enterprise apps still fail to ship — maintainability gets worse, not better. Why?

Speed without "scale" (standards) is just faster tech debt

For a toy app, letting an AI agent one-shot the code is great. For an enterprise system, you need:

Maintainability — survive the 7th round of requirement changes
Evolvability — still extensible after 5 years
Deep integration + self-hosting + audit + fine-grained permissions

The problem with AI agents writing code: they emit a wall of one-shot code that immediately becomes a second source of truth alongside your project. The next agent run overwrites your hand edits; multiple agents each write their own thing. The faster it goes, the faster the debt piles up.

AI gave us speed. Nobody gave us scale — the standards, boundaries, and order. And enterprise apps die on exactly that.

The bet: make AI work on metadata, not on code

Oinone is an open-source, 100% metadata/model-driven low-code framework. The bet: data models, UI, permissions, workflows, AND the AI's output all live in one shared metadata model.

So an AI agent doesn't write throwaway code — it writes into the same metadata the framework and human developers already operate on:

What the AI changed is a structured metadata diff — reviewable, revertible, not 500 lines to read by hand
Multiple agents collaborate on one model, not divergent copies
Because metadata is compact, AI-coding token usage drops ~60% in our benchmarks

AI for speed, the framework for scale. That's the whole idea.

Try it (one command, ~5 min, no signup)

curl -L https://gitee.com/oinone/oinone-docker-shared/raw/master/oinone/docker-compose.yml -o docker-compose.yml
docker compose -p oinone up -d
# open http://127.0.0.1:88   user: admin   password: admin

Then have the AI generate an app from a sentence, and look at what it produces — a metadata diff, not a pile of code. That's the difference between "AI-native" and "a low-code tool with a chatbot bolted on."

Stack: Java backend + TypeScript frontend, AGPL-3.0 (genuinely open source, the framework you run is the framework that's public). Self-hostable; in production at large enterprises.

Honest about the rough edges

English docs are catching up; the polished 7.x live demo lands soon (the quickstart above is the real thing today). It's not for simple internal tools — use something lighter for those. It shines on complex, long-lived, self-hosted enterprise systems.

If the "metadata as the single source of truth for AI + humans" idea resonates, a ⭐ on GitHub (or Gitee) helps more developers find it. Happy to discuss the metadata model, the AGPL choice, and how it compares to Retool/Appsmith/Budibase in the comments.