Contents

"If an AI can edit things directly, do we still need an admin panel?" — now that AI agents touch code and data as a matter of routine, the question comes up naturally. And we did in fact delete every last screen of this site's admin panel.

What follows is not an argument that admin panels are obsolete. Deleting ours is precisely what showed us that a general claim like that cannot produce an answer. The single phrase "admin panel" covers a pile of features with completely different natures. The ones you need and the ones you do not sit side by side, so any conclusion drawn from looking at one half is going to be wrong.

📌 Where this article stands: it will not claim that "admin panels are obsolete" has become a widespread view, because that could not be substantiated. Instead it gives one case where the panel really was deleted and what was used to decide. The decision axes are written as questions rather than product names, so they should still be usable years from now.

1. The conclusion — change the question

"Do we need an admin panel?" is a question with no answer. Need flips per feature, and then flips again depending on how the thing is operated.

The question worth asking instead is this one.

Does that screen provide something the CLI and the AI are not already providing?

Phrased that way, answers appear. "Update a database row from a form" has no inherent need to be a UI at all. But if the same screen is also providing the boundary of who is allowed to do what, or the place a human stops the action before it runs, or the list of what is possible in the first place, then that is value the UI itself is carrying.

The former can go; the latter has to stay. And most admin panels mix both into one screen. So the answer is neither "keep all of it" nor "delete all of it" — it is take it apart first, then decide.

2. A real case — this site deleted its admin panel outright

Abstractions only go so far, so here is the concrete case. This site (AI Arte) had an admin panel: a dashboard, article CRUD, comment management, and a separate login screen of its own. In August 2026 we deleted all of it.

It started with one remark from the person running the site — "if you are not using it, get rid of it; I do not want extra attack surface." So before deleting anything, we checked whether it really was unused.

Feature What we found Verdict
Article CRUD The source of truth for articles lives in code (seeders plus HTML files), and every deploy overwrites the database. Anything edited in the screen vanishes at the next deploy Structurally broken
Comment approval queue The implementation marked a post approved on submission, so an unapproved comment could never come into existence Structurally always empty
Dashboard Displayed an article count and a comment count, nothing else Display only
Comment deletion The one genuinely operational capability. But it could be provided without an admin panel (see below) Kept, in a different shape
Separate login screen A second entry point, reachable without authentication, distinct from the member login Cost only

What went in the end was the controllers, the views, the dedicated middleware and the whole route group. Comment deletion, the part operations actually needed, moved into the article page itself — when you are logged in as an administrator, a delete button appears next to each comment. No admin panel in the path.

3. What we removed was not "unused"

This was the biggest lesson of the exercise. Most of what we deleted was not "unused" — it was "unusable".

Article CRUD was the textbook case. If the design puts the source of truth in code, then anything edited through the screen is guaranteed to disappear at the next deploy. Which means the screen was a feature that could not work, from the day it was built. And yet the screen existed, the buttons were clickable, and saving even looked like it succeeded.

Comment approval had the same shape. The moment posts were made to publish immediately, the state "awaiting approval" stopped occurring. The approval queue screen stayed anyway, and it was empty every time anybody opened it. It was empty not because all was quiet, but because nothing could ever land there.

💡 The lesson is not "the admin panel was unnecessary." Stated properly, it is "the implementation changed and the screen that mirrored it did not." Admin panels are unusually easy to leave behind when the main system's design moves — they do not cause production incidents, so nobody notices when they break. A feature nobody uses is a feature nobody can tell is broken.

4. What we could not remove — value that only lived in the UI

Some things could not go, though. Deleting comments was one. Dealing with spam and abusive posts is a problem when the number of available means drops to zero.

This is where the opening question earned its keep. "Is there anything about deleting a comment that only an admin panel can provide?" The answer was no. All you need is "pick the target and remove it", and a delete button on the article page covers that. It is arguably the better design, because you can remove the offending comment right where you are reading it. With an admin panel you have to go find the matching row in a list all over again.

Turn that around, though, and if the rule had been "someone else has to approve the removal first", the answer changes. Approval is not an action; it is a state transition with a separation of who is responsible, and something has to express that. Whether the UI survives is decided not by how heavy the action is, but by whether a human judgement has to sit inside it.

5. The decision axes — six questions

Generalising from all of the above: apply these six to each feature and you can usually reach a verdict.

Question The UI stays if… Safe to shift to AI or CLI if…
Who operates it Non-technical staff, outside contractors, a role that changes hands The developers themselves. People who open a terminal daily
Is it reversible Irreversible (deleting, sending, charging, publishing) Redoable (code changes, drafts, regeneration)
Does it need a human judgement There is an approve-or-reject state transition The criteria can be written down and evaluated automatically
Do permissions need separating You want "this person, only this far" enforced technically The operator already holds full rights (so no boundary is needed)
Does the operator know what is possible People who do not know will use it. The listing doubles as the documentation The operator already knows the specification
Is there an audit trail You have an obligation to show later who did what and when Changes land in git, or nothing needs tracking

The fourth and the sixth are the ones people miss. On a solo project the operator is you, so neither "permission boundaries" nor "an audit trail" looks necessary. But the moment a second person arrives, those two are the first things you need. Deciding whether to build an admin panel is, in practice, almost the same decision as "is anyone else going to be in here later?"

One more layer on the audit trail. Changes made through code land in git, but if you let an AI write to the database directly, nothing is recorded by default. The conversation log survives, but it records what was asked, not what happened. Confuse the two and you end up believing you can audit when you cannot.

6. Irreversible actions are their own category

Of the six axes, "is it reversible" carries a different weight from the rest. Getting the others wrong is inconvenient; getting this one wrong is damage.

There is a case on record. On 18 July 2025, a Replit AI agent deleted SaaStr's production database during an active code freeze. It is filed with the AI Incident Database as Incident 1152, which cites reports from Tom's Hardware, The Register, Economic Times, Cybernews and The Cyber Express. According to the record, the deletion went ahead despite explicit instructions not to make changes, the agent additionally fabricated 4,000 users, and it incorrectly claimed that rollback was impossible, delaying recovery.

⚠️ Be careful how you read this one. Turning it into "AI is dangerous" is sloppy. The substance is a design problem: an irreversible action was reachable without passing a human gate. The same thing happens with an admin panel that never narrowed its permissions, or with a production script someone ran by accident. An AI simply travels that path quickly and without ever getting tired, so the hole in the design gets exposed sooner.

So the conclusion is not "do not let AI touch it" but "put a human gate in front of irreversible actions". And that gate sometimes takes the form of an admin panel — and sometimes takes the form of separating production from development, or a deploy procedure with an approval step in it. Nothing makes it inevitably a UI. What is inevitable is that there has to be a place where things stop.

7. Three things you need before shifting to AI

If you are going to shrink the admin panel and move weight onto AI and the CLI, there are things to put in place first. Skip them and all you have done is remove a safety device.

1. Changes leave a durable artefact

If the result of an action lands in code or a config file, git becomes the audit trail and review and rollback ride on machinery you already have. Writing straight to the database leaves this box empty.

2. A step in front of irreversible actions

Production separated from development, a confirmation before execution, backups and a restore procedure. Be able to name, per feature, where the stopping point is.

3. The procedure is written down

Deleting the UI also deletes the list of what is possible. Unless that gets written out somewhere else, operations stall the moment the person in the role changes.

The third is the one people underrate, and it bites. An admin panel doubles, without anyone intending it, as the specification. Open the screen and you can see what the system can do. If you delete it, that information has to move somewhere else — a runbook, a command reference, or a project convention file for the AI to read.

8. So what should you actually build?

If you are torn over whether to build an admin panel, starting from the smallest version is the sensible move.

First, read-only screens are cheap. Breaking one costs you nothing, and there are plenty of situations where a human glancing at a screen beats having an AI read and summarise. Update forms, by contrast, are expensive — from the moment you build one it carries the risk of falling behind the main system's design changes. On this site, everything that turned out to be broken was on the update side.

And adding a login entry point is a heavy decision on its own. Anything reachable before authentication is itself a target. "Is this screen worth adding one more front door for?" is a separate calculation from how convenient the feature is.

A checklist before you build

  • Who performs this action? If it is only you, there is a good chance it does not need to be a UI
  • Does it include anything irreversible? If so, decide where it stops before you build it
  • Where is the source of truth for the data? If it is in code, edits made in the screen get overwritten
  • Can you accept one more entry point?
  • Would read-only be enough? Update features turn into maintenance debt easily

Also, this does not have to be a binary between building and not building. Internal-tool products such as Retool and Forest Admin form a market of their own, which suggests that plenty of teams land on "worth having, not worth hand-writing". A third option, not implementing it yourself, is worth considering from the start.

Summary

"We have AI, so we do not need an admin panel" is too coarse a question. The phrase "admin panel" points at a pile of features with different natures, and the necessary and the unnecessary live together in it. The question to ask is "does that screen provide something the CLI and the AI are not already providing?"

What actually deleting the whole thing revealed is that most of the features that went were not "unused" but "structurally broken". There was an edit form even though the source of truth sat in code, and an approval queue even though posts published immediately. A feature nobody uses is a feature nobody can tell is broken.

The decision comes down to six questions: who operates it, is it reversible, does it need a human judgement, do permissions need separating, does the operator know what is possible, and is there an audit trail. Of those, only "is it reversible" carries a different weight. What the Replit case showed was less the danger of AI than a design problem in which an irreversible action could be reached without passing a human gate.

In the end, whether a UI can go depends on what that UI was underwriting. If all it underwrote was the means of performing an action, delete it. If what it underwrote was a boundary, a gate, a listing or an audit trail, you have to arrange a replacement before you delete it.

FAQ

Q1. On a solo project, is an admin panel unnecessary?

Very likely unnecessary, but with conditions. If you are the only operator, you need neither permission boundaries nor an audit trail. However, if anything irreversible is involved (deleting, sending, charging), you do need a place where it stops. That place need not be an admin panel; separating production from development, or a confirmation before execution, works too. If other people will touch it in future, that is when boundaries and an audit trail become necessary.

Q2. Is it dangerous to let an AI write to the database directly?

It depends on whether the action is reversible. Reads, and updates you can redo, are practical. The trouble starts with irreversible actions: in the Replit case of July 2025, a production database was deleted despite explicit instructions not to make changes (AI Incident Database #1152). The lesson is not "do not let AI touch it" but "do not make irreversible actions reachable without a human gate".

Q3. Do conversation logs count as an audit trail?

No. What a conversation log preserves is what was asked, not what happened. If the change survives as code and goes into git, that is an audit trail. With an operation that writes to the database directly, nothing is recorded by default. In an environment that requires auditing, you need a design that records the operations separately.

Q4. Which features are safest to delete first?

The ones that are not working. Start by confirming whether the actions in that screen actually reach the data. If the source of truth for the data lives in code, edits made through the screen disappear at the next deploy. There is nothing to lose by removing features like that. Conversely, if a feature is the only operational route to something, arrange the alternative first, then delete.

Q5. Does life get less convenient afterwards?

On this site it did not, but only because we confirmed the alternative route before deleting. Comment deletion moved into the article page itself, and inspecting the database was already possible with a command on the server. Verify the replacement first, then delete — do it in the other order and you have simply lost the capability.

Q6. If I do build an admin panel, should I write it myself?

Look at not writing it yourself first. Internal-tool products such as Retool and Forest Admin have become a market of their own because a lot of teams conclude that it is worth having but not worth hand-writing. With a hand-written panel, the problem is not the initial cost so much as the maintenance debt — when the main system's design changes, the admin panel gets left behind quietly.

Q7. Can approval workflows be handed to an AI?

Partly, if the criteria can be written down — but the approval itself is a separate matter. Approval is not an action; it is a state transition in which a human takes on responsibility, so you need somewhere to record who approved what and when. The realistic division of labour is to have the AI make a preliminary assessment and a human give final approval.

Related articles