![\"Blog](\"https://erudika.com/_astro/blogpost_media23.HcqdJrg-_Z1UOBNa.webp\")
Running a Q&A platform for your team is only half the job. Once people start using it, administrators need to understand what’s happening: Which questions are getting attention? Who are the most active users? Is engagement increasing? Which questions have been sitting unanswered for too long?
\nThat’s why we’re introducing a brand-new admin dashboard for Scoold and Scoold Pro.
\nThe dashboard gives administrators an at-a-glance view of what’s happening across their Scoold installation, with statistics, activity metrics, charts, trending content, user engagement and more.
\nAnd there’s another interesting story behind this release: we built most of it with an AI coding agent.
\nThe new dashboard is available from the /admin section of Scoold and is designed to give administrators a quick overview of the health and activity of their Q&A community.
Among other things, it provides information about:
\nOne of the most useful views for an administrator is identifying questions that have remained unanswered for a long time. These are often the questions that need attention from moderators or subject-matter experts.
\nThe dashboard also makes it easier to spot which parts of your knowledge base are getting the most attention and which users are contributing the most.
\n![\"Blog](\"https://erudika.com/_astro/dashboard1.DuSD8cAM_Z1jGdzd.webp\")
For this feature, I used OpenCode, an open-source AI coding agent, to do most of the implementation work.
\n![\"Blog](\"https://erudika.com/_astro/dashboard2.B54qPB3U_6OSQh.webp\")
I started by preparing a PRD.md describing the feature and providing screenshots showing the kind of dashboard UI we wanted. I then gave OpenCode a relatively simple initial instruction:
\nTake a look at the PRD and devise a plan for implementing the new feature. We need a new dashboard at
/admin.
The agent had access to the existing Scoold codebase and the design references.
\nFrom there, the work became an iterative collaboration between me and the coding agent.\nI still inspected the existing code myself and made the important architectural decisions. In particular, I had to explain some of the details of Scoold’s backend architecture and how its underlying Para data model works. The agent handled most of the implementation.
\nI spent four calendar days building this, and a total of ~150 million tokens, which is astounding to me.\nThe numbers are interesting:
\n| Metric | Result |
|---|---|
| Calendar time | 4 days |
| Active model time | ~4.5 hours |
| Prompts | 56 |
| Model steps | 781 |
| Tool calls | 807 |
| Files changed | 63 |
| Lines added | 2,432 |
| Lines removed | 228 |
| New files | 13 |
| Feature commits | 6 |
| Total token processing | 151.6 million |
| Total AI cost | $16.81 |
It used the shell extensively, inspected the existing Java code, searched through the project, edited files, ran the Maven build and tests, started and stopped the application and used Playwright to interact with the running application in a browser.
\nIn total, it made 153 browser calls during the session.
\nThat last part was particularly useful. The agent could actually look at the resulting dashboard rather than relying entirely on whether the code compiled.
\nI switched between a couple of models depending on what I needed:
\nI used GLM for the planning part. GPT Luna was used as the implementing agent and handled most of and implementation tasks.
\nThe total cost of the entire session was only ~$17. That’s a surprisingly small amount considering the amount of code that was produced.
\nThe session processed about 151.6 million tokens, but only 9.1 million were new input tokens. About 139.2 million tokens were served from the provider’s prompt cache, giving the session a 93.8% cache hit rate.
\nFor long-running coding-agent sessions, this makes a significant difference to the economics. The agent repeatedly needs a large amount of context about the project, but most of that context doesn’t need to be processed from scratch every time.
\nOne of the key takeaways from the project was that I didn’t “one-shot” the feature with instruction such as:
\n\n“Build the entire admin dashboard.”
Instead, I broke the work into smaller, verifiable pieces. I like to call it “micro waterfall”.
\n![\"Blog](\"https://erudika.com/_astro/waterfall.Dg7Piges_Z14K7s3.webp\")
I’d ask it to implement a particular dashboard panel or part of the functionality, let it make the changes, run the application and inspect the result, and then move on to the next piece.\nThat approach worked considerably better than trying to delegate the entire feature in one shot.\nThe agent stayed focused because each task had a relatively clear boundary and, importantly, a clear way to verify whether the result was correct.
\nEarly in the session, I had to explain how to start and stop the development services and provide additional information about Scoold’s backend architecture.
\nThere were also several cases where the agent reported that something was working, but a manual check showed that it wasn’t quite right.\nFor example, at one point a leaderboard displayed the wrong number of rows. In another case, a resource column displayed an object type instead of the actual object ID.
\nOne of the more interesting parts of the development was the way we handled traffic statistics.\nAn early implementation of the dashboard would read and iterate over hundreds of objects every time the dashboard loaded.\nThat worked, but it obviously wasn’t a good design for a production application.
\nDuring a code review, the agent identified the problem and suggested a different approach.\nInstead of repeatedly scanning hundreds of individual objects, Scoold now aggregates traffic information in memory and periodically flushes the aggregated data to storage.\nThe dashboard can then read a small amount of aggregated data rather than repeatedly processing hundreds of objects.
\nThis is a good example of where an AI coding agent can be useful beyond simply translating instructions into code. Once it understands enough of the surrounding architecture, it can also identify implementation problems and suggest improvements.
\nThe dashboard also introduced a new audit log.
\n![\"Blog](\"https://erudika.com/_astro/dashboard3._nKSdBsx_Z1w38xV.webp\")
This provides administrators with an audit-style view of activity taking place in their Scoold installation.\nFor this part of the implementation, I provided the agent with a written specification describing the events that needed to be tracked.\nThat turned out to be a very effective way of working.
\nRather than asking the agent to decide what should be logged, I gave it an explicit specification and asked it to map those requirements onto the existing controller code.\nThe result was roughly 50 new event types and around 30 new call sites across the application.\nThis change also greatly enhanced the webhooks API, where developers can now register to listen for much more events in Scoold.
\nThe feature was validated through a combination of automated and manual testing.\nThe project includes unit tests for the new dashboard service, while the agent also repeatedly built and ran the application during development.\nBut browser testing was equally important.
\nThe agent used Playwright to interact with the actual running application, while I manually inspected the dashboard and its data.\nThis helped catch problems that wouldn’t necessarily show up in a unit test or compiler error.\nThe final feature touches a significant portion of the application, including the admin controller, configuration, request interception, templates, JavaScript, styling, localization and the new dashboard service.
\nThe implementation ultimately landed across 63 changed files and was split into six feature commits.
\nThe biggest lesson wasn’t that AI can write a lot of code.\nWe already know that.\nThe more interesting lesson is that the quality of the result depends heavily on the quality of the feedback loop.
\nThe most effective workflow for this project was:
\nThe AI agent handled a lot of the mechanical work. I remained responsible for the product decisions, architecture and verification.\nGoing forward, this approach will increasingly become how we develop Scoold.
\nThe new dashboard gives Scoold administrators considerably more visibility into their communities, but it’s also a foundation we can build on.\nAs we collect feedback from users, we’ll continue improving the dashboard with additional metrics and administration tools.
\nScoold is designed to help companies build and maintain their own internal knowledge bases without handing their organization’s knowledge over to a third-party platform.\nNow administrators have better tools for understanding how that knowledge base is being used.
\nIf you liked this post, you can try out Scoold Pro today at cloud.scoold.com.
\nAbout the author
\n![\"Alexander](\"https://erudika.com/_astro/ab.D_BEgQ6X_Z8oAm5.webp\")
Alexander Bogdanovski
\nFounder & Indie Hacker
17+ years building backend infrastructure. Creator of Para and Scoold.
\n","headings":[{"level":1,"text":"The best free Q&A platform just got better - Scoold has a new admin dashboard!","id":"the-best-free-q-a-platform-just-got-better-scoold-has-a-new-admi"},{"level":2,"text":"A dashboard for your Q&A community","id":"a-dashboard-for-your-q-a-community"},{"level":2,"text":"Building the dashboard with OpenCode","id":"building-the-dashboard-with-opencode"},{"level":2,"text":"Four days, 56 prompts and 4.5 hours of AI work","id":"four-days-56-prompts-and-4-5-hours-of-ai-work"},{"level":2,"text":"The models","id":"the-models"},{"level":2,"text":"One-shot vs Micro-Waterfall","id":"one-shot-vs-micro-waterfall"},{"level":2,"text":"AI coding agents still need supervision","id":"ai-coding-agents-still-need-supervision"},{"level":2,"text":"The agent caught a hard-to-find performance issue","id":"the-agent-caught-a-hard-to-find-performance-issue"},{"level":2,"text":"Building the activity log","id":"building-the-activity-log"},{"level":2,"text":"Testing the result","id":"testing-the-result"},{"level":2,"text":"What we learned","id":"what-we-learned"},{"level":2,"text":"What’s next?","id":"what-s-next"}]}}