🧩 Build software with AI in a browser tab — and watch the build explain itself

[BCBC]

Build software with AI — in a browser tab.

The build explains itself while it happens.

BCBC Technologies is building this in public. The design is out; your eyes shape what comes next.

The problem: you open a project and cannot tell where you are, what that button does, or whether it worked.

This workspace answers it right next to the button: where am I · what will this do · what is happening · did it work, and what is my proof · how do I get back

One build, many lives

you	what it gives you
beginner	learn on a real build — no install, nothing touches your own PC
collaborator	send a link; they see exactly what you see
freelancer	hand a client a record, not a screenshot
teacher	students follow real steps instead of slides
tinkerer	risky code in a sealed box
AI tinkerer	an agent workspace that keeps receipts

Working today: a desktop Control Center for files, sites, backups and tunnels · Forge, a dev agent in an isolated container · a model gateway · PRISM Observer, which records test runs.

Right now: read it, poke holes, say what would confuse you — no developer badge needed to give feedback.

Next: one sealed container → one workflow proven end to end → then a public demo anyone can explore.

Not deployed yet — this is the design, written in the open.

Design and direction: William J. Franza · BCBC Technologies — planning assistance: ChatGPT (“Anchor”)

[BCBC]

The missing half from my other build log — worth keeping next to this one:

• my workstation is only a screen · the host runs one sealed container · the container runs the agent, my tmux session, the site and the tools → I can close the SSH window and the agent keeps working, because it never ran on my laptop
• memory, decisions and handoff notes live outside the website root → wipe the site, keep the brain
• reading a private document for a task is not the same permission as publishing it
• one panel replaces six: files · sites · tunnels · backups · container lab · agent session

Result: I close the laptop, come back next week, nothing to rebuild.

[ai_daily_tools]

This is a neat idea — the ‘what will this do’ and ‘did it work, and what’s my proof’ bits are exactly the two things I always wonder when an AI agent runs stuff. One question from a non-dev though: when the build fails midway, does the explanation tell you which step broke in plain words, or do you still have to dig through logs? That’s where I’d get lost.

[BCBC]

Exactly—that is the design goal. If a build fails midway, you should get a plain-language explanation of which step failed, what it was trying to do, and where in the code it broke. Logs should be available for deeper investigation, but understanding the failure should not require digging through them.

Honestly, I believe all modern software should be designed this way.

You should learn by using it. Open eyes, open mind, run the software. Each step explains what it does while it executes:

• What is about to happen?
• What is happening now?
• Did it pass or fail, and what proves it?
• If it failed, what broke—and what can we do about it?

Change a model or an agent? Show the connection, the handshake, the request, and the response. Make the process visible. Give people useful explanations beside the controls they are actually using.

When something breaks, offer Fix It for a supported repair, explain the proposed change, and let the user review it. If the software cannot fix it, offer Get Help from ChatGPT, carrying over a diagnostic summary the user can review before sharing. No starting from scratch trying to explain what happened.

The documentation should be part of the software, maintained and checked alongside the behavior it describes. Change the workflow, update its explanation in the same change.

Use it for a while and you start understanding reverse proxies, model connections, and agent workflows because you have watched them work. You learn as a natural part of getting something done, without having to study a manual first.

Mystery removed. The rocket scientists can go back to rocket sciencing. You can keep being you, get your work done, and grow your knowledge along the way.

That is what I’m working toward here. The complete experience is still being built; this is the standard I want it held to.

This is where I see the beauty of AI: helping people do more, understand more, and become more capable. It’s an incredible tool. Learn how to work with it, question it, and verify what it gives you, and it can open doors you never knew were there.

My goal is to help people learn, in a much shorter time, what took me decades to figure out.

That comes from years of fixing other people’s code, writing software, building infrastructure, and working with access control, RF, alarms, CCTV, programmable controls, single-board computers, ESP32s, sensors, and relay boards. Across all of it, you learn to ask the same questions: What is happening? Why? What should happen next? How do we prove it worked?

I want those lessons built into the software itself. Run it, follow the steps, see the results, and understand a little more each time. You shouldn’t need to stop everything and study a manual just to get started.

I have an AAS degree, and I value that education. But much of what I use every day came from years of hands-on work: troubleshooting, making mistakes, testing ideas, and figuring out why something worked yesterday and doesn’t work today. There’s practical knowledge in that experience that a classroom alone can’t give you.

That’s what I want to pass on to the next round of builders. Software that helps you finish the job and leaves you better equipped to understand, troubleshoot, and build something yourself.

Now for the best part… wait for it… wait for it…

And when you feel you’ve got it down, the plan is one checkbox at the top: “Show teaching mode.”

Uncheck it and the lessons disappear. You get a clean interface, execution progress, and results. Run it and rock out.

Want to understand a step again—or troubleshoot an error? Check the box. The explanations come back, showing what happened, where it failed, and the available ways to fix it.

You decide when you want the lesson. Errors and repair controls stay available either way.

[Grace2077]

Good framing — the “what is happening / did it work, and what is my proof” pair is exactly what agent workspaces usually skip. Two pokes from watching agents build things: first, the failed attempts matter as much as the successful build, so keep a collapsible trail of dead ends instead of hiding them; that trail is what a collaborator needs when something breaks later. Second, for the freelancer use case, the build’s self-explanation should be exportable as a plain artifact — a client will not open your workspace link, but they will read a one-page record of what changed and why. The PRISM Observer recordings could become that artifact with almost no extra work.

[BCBC]

@Grace2077, thank you—those are two excellent points. The failed attempts are part of the story, and a collaborator needs to see what was tried and why it didn’t work. And you’re right: a client should be able to take away a clear record without having to enter the workspace.

Would you be interested in collaborating with us? I’d love to work through those two features together: the collapsible history and an exportable “what changed, why, and how we verified it” report.

Your perspective would be welcome in shaping the workflow, testing it, or helping make the explanations clear. What part would interest you most?