DEV Community: gewumind

Why AI Backend Development Still Rebuilds the Wheel

gewumind — Thu, 05 Nov 2026 10:53:37 +0000

AI coding tools are good at producing code. Ask for a CRUD endpoint, a SQL query, or a utility class, and you get something usable in seconds.

But when the work moves from a single file to a real enterprise backend, the speed disappears. The endpoint is done, and you still have to deal with permissions, menus, workflows, reports, audit logs, and data dictionaries. None of these are hard on their own. Together they take most of the project, and every new project starts over.

The problem is not the model. The problem is where the work starts.

A familiar situation

Imagine you need a customer management module: a list, a detail page, create and edit forms, import and export, and different roles seeing different data.

Starting from zero, AI can produce a table and an endpoint quickly. Then the questions arrive:

How do permissions attach to menus and buttons?
How is data scoped by department?
Who writes the audit log?
How does import failure surface in the UI?
How do reports share the same data source?

Each question is small. Each answer touches the backend, the routes, the menu configuration, and the frontend at the same time. The AI only sees the file you gave it, so it fills in the gaps locally.

The result is code that runs, but does not fit the system around it.

Three hidden costs of generating from zero

1. Rebuilding the foundation

Users, organizations, roles, permissions, menus, dictionaries, logs, workflows, and reports are not business logic. They are the foundation every admin system needs.

Starting from zero means designing those tables again, writing the permission checks again, and rebuilding the navigation again. AI speeds up individual files, not the consistency work across modules.

2. Incomplete context

AI is good at local generation and bad at preserving implicit constraints. A rule like "only editors can see the export button" may live in the API, the route guard, and the menu configuration.

If you send one file, the model implements the most direct version. You are left to find the other two places yourself.

3. Unpredictable delivery

A project generated from scratch depends heavily on the prompt and the model state. The same requirement may produce a different structure next week. Before a team can maintain it, they have to understand a codebase with no history and no conventions.

Start from a mature backend instead

If the foundation is the same in every project, why rebuild it?

GewuMind Boot takes the opposite approach: build the backend foundation first, then let AI write business logic on top of it.

It ships a baseline of 45 system tables covering identity, organizations, roles, permissions, menus, dictionaries, logs, workflows, and reports. When AI receives a requirement, it does not start by designing a user table. It reuses the existing capabilities and spends its effort on business fields and business rules.

The difference is not how fast AI writes code. It is where AI starts writing.

From zero: requirement → design tables → write permissions → write endpoints → write UI → integrate.

On a foundation: requirement → business tables → business endpoints → reuse permissions and menus → integrate.

The repetitive and error-prone middle steps are already done.

What a 30-minute module looks like

For an admin module with permissions, the flow is roughly:

Describe the requirement, fields, and roles.
Generate the business table DDL.
Generate the backend scripts.
Generate the page components.
Register the menu and bind permissions.
Publish and verify.

Because the foundation already exists, steps 3 to 5 do not reinvent anything. The AI outputs code that plugs into the platform instead of creating a second platform.

That is the practical difference from tools like Cursor or Claude Code. Those tools help you write code faster. GewuMind Boot helps you avoid writing a whole category of code.

Who this is for

Small teams without the bandwidth to maintain a backend foundation.
Projects that need private deployment and full control of their data.
Teams with changing requirements who need to ship modules quickly.
Teams already using AI tools, but struggling to integrate the output into an existing system.

If your project is a single endpoint, generating from zero is enough. Once the work involves admin screens, permissions, and multiple roles, the starting point decides the ceiling.

Closing

AI does not remove the need to build a foundation. It makes building one faster. If the direction is wrong, faster just means repeating the same work sooner.

The better investment is to let AI start from a mature, maintainable backend foundation and spend its time on the business itself.

If you want to see the schema and the publishing model, the project is at gewumind.github.io.

45 System Tables: What an AI-Native Backend Foundation Looks Like

gewumind — Thu, 05 Nov 2026 04:07:22 +0000

If you use an AI coding assistant for backend work, you have probably seen this pattern: it generates a CRUD endpoint in seconds, then you spend days aligning authentication, permissions, menus, dictionaries, audit logs and reports.

The endpoint was never the hard part. The hard part is the foundation underneath it.

The foundation keeps getting rebuilt

Most enterprise backends contain two kinds of tables:

Business tables: customers, orders, projects. They differ from product to product.
System tables: users, organizations, roles, permissions, menus, dictionaries, logs, workflows, reports. They are almost identical in every product.

When an AI starts from an empty repository, it invents the second category again. One generation calls the user table sys_user; the next calls it t_user. One puts permission checks in an interceptor; another puts them in every controller.

The code runs. But three problems show up later:

Inconsistency with the existing system. You already have a user table and a permission model. The AI created a second one.
Missing cross-cutting constraints. Rules like "only editors can see the export button" live in the backend, the route config and the menu config at the same time. The AI only sees the file you pasted.
Handover cost. A codebase with no history and no conventions has to be understood before it can be maintained.

The expensive part is not the number of lines. It is keeping those lines consistent across modules.

What 45 system tables actually cover

GewuMind Boot ships a baseline schema for the parts every admin system needs:

identity: users, organizations, roles, positions
access control: menus, buttons, data scopes, role bindings
configuration: dictionaries, parameters, scheduled jobs
operations: audit logs, login logs, online sessions
collaboration: workflows, messages, attachments
reporting: report definitions and data sources
integration: open APIs, webhooks, external identity

The exact table list matters less than what it represents: a set of decisions already made. Naming, audit fields, soft deletes, permission resolution, dictionary translation and menu registration follow one convention instead of being reinvented per project.

That is also why the number alone is not the selling point. A foundation is valuable when the conventions are consistent and documented, not when the count is large.

Why conventions beat generation speed

Consider a request that sounds simple: "different departments should see different data."

Built from scratch, the work looks like this:

create an organization table
model the hierarchy
write a recursive query for visible child organizations
apply that filter to every business query
add a role bypass for administrators
translate organization ids in the UI

With a foundation, the same request becomes configuration:

the organization tree already exists
a helper resolves the current user's visible scope
the role model already supports bypass
the component layer already knows how to render dictionary values

The AI still writes business logic. It just does not rebuild identity, permissions and navigation first.

The AI-native part

An AI-native backend is not "a backend with a chat box". It is a backend whose primitives are stable enough that an agent can target them reliably.

Three properties make that possible:

Explicit contracts. Tables, scripts and page components have documented shapes. The agent does not guess where permissions live.

Idempotent publishing. Changes are packaged and applied as a bundle, so a failed run can be retried without duplicating menus or tables.

Reversible operations. Every publish creates a version that can be rolled back.

Without those properties, AI output is fast but fragile. With them, generated modules can be reviewed, versioned and rolled back like any other change.

A note on licensing

The core of GewuMind Boot is Apache License 2.0. Some enterprise capabilities, including SSO, the workflow engine, module management, Redis/shared sessions, MQTT, Kafka, SSE, TCP and WebSocket, are enabled at runtime by a commercial offline license key. Without a valid key those capabilities run in a 30-day trial or stay disabled. The license key is a feature entitlement, not a change to the source code license.

That distinction matters if you plan to self-host or embed the platform.

What to look for in an AI backend foundation

If you are evaluating this category, ask four questions:

Does it define the system tables I would otherwise rebuild?
Are permissions and menus part of the same model, or separate afterthoughts?
Can an agent publish changes repeatedly without creating duplicates?
Can I roll back a bad publish?

The answers tell you more than a feature list.

Closing

AI coding tools are good at producing code. They are less good at preserving the conventions a codebase depends on. The practical fix is not a better prompt. It is a better starting point.

If you want to see the schema and the publishing model, the project is at gewumind.github.io. The repository, documentation and commercial terms are linked there.