Product proposal 001
WordPress, but AI-first.
The CMS stops being a fixed dashboard with AI bolted onto the side. It becomes software that understands its own architecture, can propose and implement changes to itself, and keeps every rewrite inspectable, testable, permissioned, and reversible.
The thesis
The website becomes a living software system
Most AI features inside content management systems operate on a text field. They write a paragraph, suggest a title, or generate an image. An AI-first platform works at the level of the whole system: code, content structure, interface, permissions, plugins, performance, accessibility, analytics, and deployment.
Ask for an outcome, not a plugin.
“Create a multilingual member publication with regional editors, paid research, an accessible reading mode, and a weekly briefing” becomes an architectural proposal the system can build, test, explain, and maintain.
Core shift
From configuring software to negotiating with software that can change itself.
The operating loop
Self-rewriting without silent autonomy
The product only earns the right to modify itself by making the process legible. A rewrite is a governed software release, not an unlogged agent action.
Understand
The system maintains a live model of its code, content types, theme, plugins, permissions, traffic, failures, and editorial behavior.
Explain
Before changing anything, it explains the relevant architecture, dependencies, risks, and the reason a change could help.
Propose
The AI turns an intent into a visible plan with interface previews, database changes, code diffs, tests, and a rollback path.
Rewrite
Approved work is generated on an isolated branch or staging environment, never as an invisible mutation of production.
Verify
Automated checks cover behavior, accessibility, performance, security, content integrity, and compatibility before release.
Release or reverse
A human controls deployment. Every change is attributable, observable after release, and reversible from an immutable history.
Product capabilities
What AI-first changes
The proposal is not a more conversational version of the existing admin. It changes what the platform is capable of becoming for each organization.
Interface
An admin that can redesign itself
Describe the workflow you need and the system can propose a new dashboard, editorial flow, approval state, or role-specific interface instead of making everyone adapt to a fixed control panel.
Architecture
Content models generated from intent
A publication, shop, archive, membership system, or multilingual knowledge base can become a tested content architecture rather than a pile of manually assembled fields and plugins.
Code
Native software changes, not prompt-shaped patches
The agent can create or revise themes, plugins, blocks, APIs, migrations, and tests while respecting the conventions and constraints of the existing system.
Operations
Continuous maintenance with evidence
The product can detect outdated dependencies, broken journeys, accessibility failures, layout shifts, dead content, and security risks, then propose fixes with proof.
Compatibility
A bridge from the existing WordPress world
The practical version begins as a compatibility layer for current sites, themes, plugins, hosts, and editorial teams rather than demanding a clean-room migration.
Memory
A site-specific operating model
It learns the publication's vocabulary, design system, business rules, risk tolerance, and approval habits without turning those decisions into an opaque black box.
Safety architecture
The ability to rewrite itself must be designed as a permission system
A useful self-modifying CMS needs stricter controls than ordinary no-code software because its output can affect identity, revenue, public information, personal data, and the integrity of an entire site.
Scoped authority
Separate permissions for reading, proposing, generating, testing, merging, deploying, editing data, and changing user access.
Evidence before release
Every proposal carries diffs, previews, test results, migration impact, security checks, and explicit unresolved risks.
Memory with accountability
Decisions, approvals, exceptions, and rollbacks remain attributable. The system can learn from them without erasing the record.
Non-negotiable boundary
The system never receives invisible, permanent production authority. High-impact changes remain staged, reviewable, and reversible by design.
The first wedge
Begin with existing WordPress sites
The fastest route is not replacing the ecosystem. It is adding an AI-native control layer that can understand a real site's accumulated themes, plugins, content, integrations, and operational constraints.
Entry product
A self-healing WordPress operator
Connect a site, build a system map, surface risks and friction, then generate reviewed fixes in staging.
Expansion
An intent-driven publishing platform
Move from maintaining inherited sites to generating and evolving complete publishing systems from organizational goals.
Long-term position
Not a page builder. An operating system for websites.
WordPress made publishing software extensible through themes and plugins. This proposal asks what happens when extensibility becomes conversational, agentic, testable, and native to the platform itself.
The final product is software that can become the software an organization actually needs, while keeping humans in control of what it is allowed to become.
Independent concept by HAAM. This proposal is not affiliated with or endorsed by the WordPress project or its trademark holders.