About Me
Hello, my name is Bryan.
Yeah, I know… a little cheesy. That’s fine.
I’ve been around computers, networks, and systems long enough that I don’t really feel the need to dress it up too much. This isn’t a pitch. It’s just what I do and how I think about it.
I wrote my first program sometime around 1985, copying it out of a magazine onto a Commodore VIC-20 and saving it to tape. If you got one character wrong, it didn’t work. So you learned pretty quickly to slow down, pay attention, and understand what you were typing.
That part stuck.
The long road to here
Over the years, that turned into a career in PC, IT, and telecom systems.
Not in a theoretical sense, but in the real-world sense where things break, customers notice, and you have to figure out why. Watching logs, tracing behavior, understanding how systems actually move data, where they fail, and how to fix them.
You start to see patterns.
You realize that no matter how big the system gets, underneath it all, it’s still just decisions being made:
if this, then that
Over and over again. Faster, more distributed, more complex… but still the same idea.
That foundation never really goes away.
Why this exists
This site started because it’s fun.
For me at least.
After all these years of building, troubleshooting, and wiring systems together piece by piece, suddenly there’s a tool that lets you move at a completely different speed.
Things that used to take days now start forming in minutes.
That part is new.
But the interesting part isn’t that it’s fast. It’s what happens when you take that speed and put it inside a system that still has structure, boundaries, and control.
What I’m actually doing here
This isn’t an AI showcase.
It’s a controlled system that happens to use AI.
The listings are intentionally strange. That’s the surface. Underneath that, everything is structured, predictable, and very deliberate.
AI can generate just about anything now. Code, text, structure… even entire systems if you let it run.
But it doesn’t understand what it’s doing.
It’s predicting what should come next based on patterns. Sometimes that lines up with reality. Sometimes it doesn’t. It won’t tell you which is which.
So the responsibility stays on the person using it.
In this case, that’s me.
My workflow
When I sit down to work on this, I’m not starting from scratch.
The system is already there. The generator, the data, the structure, the environment. That part took time to build. Now it just sits there ready.
Because of that, the work isn’t about assembling things anymore. It’s about shaping, refining, and deciding what moves forward.
Most of the time I’m in VS Code working directly in the codebase. The generator, the frontend, the modes, all of it lives there.
AI is part of the workflow, but it’s not driving it.
I use it to refactor code, fix bugs, and speed up repetitive work. But I watch everything it does. Nothing just gets accepted and moved on.
If something looks off, I stop and figure it out. That might mean reading through the code, stepping through it, or backing it out entirely.
The goal isn’t to go as fast as possible. It’s to go fast without losing track of what’s actually happening.
Fallback path
There’s also a fallback built into how I work.
Most of the time I’m using the API because it’s faster and more consistent for text generation. But if for some reason I lose access to it, the system doesn’t stop.
I can run local models.
I’ve got that path worked out using tools like Ollama for text and ComfyUI for images.
That comes with tradeoffs. You don’t get the same depth or consistency as the API, and you have to manage resources more carefully.
VRAM becomes a real constraint, so I’ll shift things around depending on what I need. Sometimes that means unloading one system to give the other more room.
But it works. I can still generate listings, still produce images, still run the system end to end completely local if I need to.
It’s not the primary path, but it’s there.
The system it runs on
Everything happens on my local workstation.
This isn’t a typical dev box. It’s built around a Threadripper system with a lot of cores, a lot of memory, and fast NVMe storage.
When it was built, it was honestly overkill.
Now it fits.
When I run a build and it spins up dozens of workers to render pages, it’s actually using the machine.
Nothing is waiting in line.
- build processes run in parallel
- AI calls don’t block other work
- datasets stay in memory
- image generation has room to run
End to end, I can go from change → build → push → live in about three minutes.
Not because anything is skipped, but because nothing in the chain is slowing anything else down.
The flow
The workflow itself is simple, but very intentional.
Everything starts locally.
I make changes, run the site in development mode, and verify the output.
Underneath that, the generator is structured.
- YAML modes define behavior
- prompts are assembled programmatically
- AI runs in multiple passes
- raw responses are captured
- output is structured
Images are generated locally. No external dependencies.
At the end of that process, I have a complete artifact.
Nothing goes out until I’ve seen it working.
Publishing
When I’m satisfied, I build the site.
Publishing is a separate step. I run a script that pushes everything out.
That happens over a WireGuard tunnel. That’s the only path between local and remote systems.
Nothing is exposed directly.
Once it’s published, the site runs independently.
I can shut everything down locally and nothing breaks.
Where this goes beyond this site
This is a sandbox.
Everything I learn here feeds back into a much larger system at work.
There, AI is used just enough to add value, not as a dependency.
The rest is handled by systems like OpenSearch, SQL, and structured caching layers.
AI becomes one component, not the center.
Why it works
This works because it’s controlled.
- generation is local
- validation is manual
- publishing is gated
- serving is separate
Nothing is left completely open-ended.
Final thought
The speed is new.
The control is not.
AI lets me move faster, but only because I still understand what’s underneath it.
I let it help me move faster, but I make sure I can still explain everything it touches.