Artist Dashboard

The Experiment

The rule was simple: I don’t write any code. I don’t edit any files. Everything gets built through a prompt.

Not as a gimmick. As a deliberate research question: what quality of software can you actually build through an AI, if you treat it seriously?

This was mid-2024. Claude Code didn’t exist. Multi-agent frameworks were academic papers. Context windows were small. Tool calling had just started showing up but nobody was really talking about it — no playbooks, no community knowledge, no best practices. You interacted with models by copying and pasting, one session at a time, hoping the context held.

Artist Dashboard was the project I built inside those constraints.

Why This Project

Two threads converged at once.

The first was personal. My artistic side had been creeping back into my life — painting, making things, showing up in the creative community. And as a developer, I kept seeing the same problem: artists are not operations people. Managing social media across platforms, distributing work, finding an audience — it’s a second job on top of the actual job of making art. There needed to be better tools, and I was in a position to build them.

The second was professional. At Juniper, I’d been deep in RAG projects and chatbot work, trying to find where AI could actually land inside large engineering teams. That work wound down as LLM fluency spread across the org. So I started focusing somewhere else: tool calling. At the time it was out there, but nobody was really using it. I started digging into what you could actually do when a model could take actions — not just generate text, but do things.

That dropped me directly into what we now call agentic software development. The question became: can I build a real production application this way?

Artist Dashboard was the answer to both questions at once.

What It Actually Was

Not a demo. Not a portfolio piece. A real company.

I launched a website. I took on subscribers. I ran a production deployment on Digital Ocean’s Kubernetes environment — globally distributable, cloud-hosted, the real thing. At peak I had seven or eight users testing it, real accounts, real content, real feedback.

The platform itself was a centralized social media management tool for artists and creators. The core function: one place to manage and post your work across every platform your audience lives on. Upload once, publish everywhere. Schedule posts, track performance, manage your media library from any device.

The integrations were the hard part. Not a mock. Not a tutorial CRUD app. Real OAuth client integrations with every major platform I could get a working client on — Bluesky, Imgur, Reddit, and the long fight to get Meta working.

The backend was Python and FastAPI handling async OAuth flows, job queues, and media processing pipelines. The frontend was React and TypeScript. The whole thing ran on Kubernetes. Built, deployed, and operated without a single line of code written by human hands.

How You Actually Build Software Through a Model

This is what the project was really about.

Early days, it was slow. Context windows were small enough that you could lose work mid-session. Tool calling was unpredictable — the model would sometimes use a tool correctly, sometimes not at all, sometimes in ways that broke things downstream. There was no planning layer. No persistent memory. You’d get blockers and have to figure out how to talk the model around them, how to redirect toward a different approach, how to get unstuck without starting over.

What I learned: the models weren’t the constraint. The practices were.

Software engineering best practices don’t change just because an AI is doing the implementation. If anything they matter more. When I was precise about architecture, clear about interfaces, explicit about what a function should and shouldn’t do — the work went better. When I was loose, when I moved fast and let things slide, I’d end up with something that worked once and broke the second time.

The discipline that makes good software makes good AI-assisted software. That was the lesson, and it wasn’t obvious going in.

Why It Failed

Two reasons, in order of impact.

Meta. Instagram is where artists live. From day one I knew getting Meta integrations would be complicated — their API access policies are restrictive and their approval process is designed for companies with lawyers. I tried working around it, building on other platforms first. But every artist I talked to wanted Instagram specifically. Eventually I went through the full process: proper business accounts, proper applications, the right descriptions of what the company does.

Meta approved the setup, then read the description of what Artist Dashboard actually did, and shut down every account I’d created. Multiple times. Every path I tried. Once they understood the use case — a third-party tool for managing and publishing content at scale — they blocked it, and there was no appealing that decision.

Without Instagram, the target market wasn’t interested enough to sustain the business.

Platform API instability. Bluesky, Imgur, Reddit — every integration I built had consistency problems that weren’t Artist Dashboard’s fault. Calls would succeed, then fail with the same request an hour later. Behavior changed between API versions with no notice. Building anything reliable on top of that was its own ongoing battle, and it consumed time that should have gone to product development.

The K8s bill running $400/month was a symptom, not the cause. I made the call to shut down rather than keep funding infrastructure for a product that couldn’t clear the platform access problem.

The Insight That Changed How I Work

The biggest thing I learned had nothing to do with code.

When I talked to the model like an engineer — precise, structured, commanding — I got compliant but brittle results. The model would do exactly what I said, including the parts I hadn’t thought through. It would succeed narrowly and fail badly.

When I switched to talking like a manager — guiding it through a situation, giving it context and goals instead of instructions, letting it reason about the path — the work got better. Not just the output. The process. It would surface things I hadn’t considered. It would push back when something didn’t make sense. It felt less like operating a tool and more like running a project.

That’s not a soft observation. It’s a practical methodology shift: stop thinking like an engineer when you’re directing an AI, and start thinking like someone managing a capable but inexperienced colleague who needs the full picture, not just the next task.

That insight — and all the hard lessons about where it breaks down — is what I carried into Root Cause.

What It Built

Artist Dashboard was the proving ground for most of what I now know about agentic development.

I gave multiple presentations on the project at AIMUG — the Austin AI/ML User Group — talking through what was working, what wasn’t, and what I was learning about building production software with AI assistance. Some of those demos worked. Some didn’t. The demo gods were not always cooperative. But the conversations were good, and the community was building the same intuitions I was.

What came out of it:

• A real picture of what agentic AI development can and can’t do with the tools that existed in 2024
• Clarity on where the leverage actually is (architecture, not implementation)
• Hard-won knowledge about production social platform integrations and why they’re brutal
• Confidence that you can build serious software through a model if you bring serious engineering discipline to the process

The product didn’t survive. The methodology did. It’s how I work now.

What Came Next

Eighteen months later I ran the same experiment in the hardest conditions I could design: an unfamiliar domain (video games), an unfamiliar language (Rust + Bevy), a more complex system (local multi-agent AI, infrastructure simulation, narrative engine). The result was Root Cause.

It went further. It went smoother. The tools had improved, but so had the practice. Artist Dashboard is where I figured out what the practice had to be.

Private repository — demonstration available on request.