DEV Community: Christian Smith

The Honest Machine

Christian Smith — Tue, 30 Jun 2026 00:00:00 +0000

After a full day of grinding out connections, deploying the machine, setting the model, tweaking the UI, one question was left standing: did it work?

Not function. Function is the floor: a user asks, the thing answers, the lights come on. I was after something deeper. I wanted it to hand back something real and curated, pulled from what I'd actually written; not the same flat response played back every time the same question came in.

So I asked it the foundation question. What is squish? Not once. Not twice. Three times, watching each answer for the thing I was testing: a unique reply every pass, built from my own words, never a recording on loop. It answered the way I'd hoped, but answering was only half the standard.

The other half was the denial. So I asked it something I'd never written a word about, something I knew it had no business knowing, and waited to see what it would do with a question it couldn't honestly take. The refusal came back clean: The corpus has knowledge, but the information you seek will not be found here.

That was it. Not function — Work. It didn't just respond; it knew the edge of what it could honestly say, and it stopped there. The standard was set. The corpus was operational.

What it actually is

Here's what it is, before how it works. Ask the Corpus is a question box for everything I've published. You type a question about my work; it answers, in plain language, using only what I've actually written. Not the whole internet's take on a subject. Not a model's best guess at what I probably think. Just my own published words, found and handed back to you.

How it answers

So how does it actually answer? Less magic than it looks, and better for it.

When you ask a question, the machine doesn't go reach into some vague cloud of everything-it-knows. It does something narrower and more honest. First it takes your question and finds the passages in my writing that sit closest to it: not by keyword matching, but by meaning, so "what makes software feel alive?" can surface the squish essay even if it never says the word meaning. That's retrieval. It pulls the handful of pieces most likely to hold the answer.

Then, and only then, the model gets to work. It reads those passages and writes an answer from them, in plain language, and tells you which of my pieces it drew from. The retrieval decides what's on the table; the model just speaks from what's there. It never gets to improvise past the edge of what I've written, because the only thing in front of it is the handful of passages retrieval handed over.

That's the whole engine. Find the closest real writing, answer only from it, name the source. Nothing reaches outside the corpus, because nothing is allowed to.

The part that matters

Now the part that matters. Everything I just described, the retrieval, the answering, the citing, is the function. It's the floor. Any competent build does that much. The thing I actually set out to make wasn't an assistant that answers; it was an assistant that refuses.

Think about what every other AI you've used does when it hits the edge of what it knows. It keeps talking. It fills the gap with something plausible, something shaped like an answer, and hands it over with total confidence. The machine never says I don't have this. It would rather be wrong than be silent , because sounding helpful is the thing it was tuned to do.

I built mine to do the opposite. When the answer isn't in my work, it doesn't reach for the next-best guess. It stops. The corpus has knowledge, but the information you seek will not be found here. That line isn't an error message; it's the whole point. It's the machine refusing to pretend, declining to launder a guess into something that looks like fact.

That refusal was the design goal, not a side effect. Anyone can build a thing that answers. The hard part, the human part, was deciding it should sometimes say no, and then making the no real. Grounded, or nothing. The machine makes it run; I make it honest.

The temptation to fill in

Here's the temptation, and it's real. It would be easy to let it fill in the gaps with fabricated information. Retrieval comes back thin on some question, the model clearly knows the general answer from its own training, and you're one line of code away from letting it just... help. Answer anyway. Sound smarter. Never leave a visitor empty-handed. Every instinct in the AI era pushes that direction: more capability, more coverage, more yes.

I built the walls instead. The refusal that stops it at the edge of my work. The caps that keep each answer lean. The limits that say this is a demo, not an open tap. None of those are things the machine wanted; they're things I decided. A tool without guardrails isn't more powerful, it's just less trustworthy.

The same restraint shows up in a quieter place: the model itself. The reflex is to reach for the biggest, smartest one available, because it's there and it's impressive. I didn't. I chose the smaller, cheaper one, because the job didn't need a genius; it needed something fast and honest to speak from passages I'd already handed it. Matching the tool to the work instead of grabbing the most powerful thing on the shelf is the same move as the refusal: taking only what the task asks for, and no more.

What the machine can't choose

The corpus runs quietly now. People ask it things; it answers from my work, or it tells them it can't. That's the tell that it's working: honesty is invisible when it holds, the way you never notice good squish, you just feel the thing is alive.

But every refusal is a small, real event. A machine declining to make something up. In an age where confident nonsense is the house style, mine does the rare thing: it knows where it ends, and it stops there.

That was never the hard part to be proud of. Retrieval was harder to wire; deployment took longer to land. The refusal was one decision and a handful of lines. But it's the part with my name on it, because it's the part no model would have chosen for me. Everything else, the machine could do. Knowing when to stay silent, somebody had to want.

Confident nonsense is costly; an honest no is priceless.

Next: why the code was never the job; only where the thinking showed.

Christian Smith (RNVizion) is a Python developer, AR/VR Sales & Support Specialist at Meta, and a self-described modern-day Renaissance man. He builds desktop tools, writes fiction, makes art, and is figuring out the rest as he goes. Find his work at rnvizion.dev.

Lazy in the Right Way Is Leverage

Christian Smith — Mon, 22 Jun 2026 00:00:00 +0000

I told a machine to publish a post, and it refused.

Not an error. Not a crash. A decision. I sent a post; it came back and told me, in plain words, the post was missing what it needed and it wouldn’t ship something broken. I sat with that, a bit longer than I’d like to admit. I built that refusal myself, that same afternoon; it still caught me off guard to watch it hold the line.

Let me back up.

I publish to my own site by hand, and publishing is more steps than it sounds. Write the post. Generate the little card that shows it on the index. Check that the post carries the right tags in its head, the ones the feed reads to know the thing exists. Insert the card at the top of the list, newest first. Push. None of that is hard; what it is, is the kind of repetitive that doesn’t tax you so much as wear you, the same trivial moves every time, each a quiet chance to fat-finger something and not notice for a week.

Here’s the part I want to sit on. There are two ways to be lazy about a repetitive chore.

The first is to keep doing it by hand, because it’s “only a few minutes,” and a few minutes never feels worth fixing. That’s the lazy that wins today and loses every day after; you save one afternoon and pay the few minutes forever.

The second is to spend the time building the thing that does the process for you, turning lost time into margin. That’s lazy too; I’m not dressing it up as discipline. It’s just laziness aimed at the future instead of the present: maximum economy of effort, measured across every post I’ll ever publish instead of only the next one.

I built the second kind.

Both share the same drive: do less. The difference is direction. Aimed at right now, “do less” keeps you stuck with the chore. Aimed at the future, “do less” is the engine behind every tool anyone has ever made. Same instinct, opposite fruit.

And here’s what wasn’t true a few years ago: the future-facing kind of lazy just got cheap. What I built in an afternoon would have been a week of work not long ago, easily more. The slow, one-time investment that buys you out of the fast, repetitive forever, the trade that used to be too expensive to bother with, now costs an afternoon. Speed didn’t cut my work; it cut the price of ending the chore for good.

That’s the leverage. Not the machine doing my thinking. The machine letting me do my thinking once and keep the result.

Which brings me back to the post it refused.

I didn’t teach it to publish so much as to judge. I taught it what a good post needs, and to refuse anything short of it: does this have its tags, its card, its place in the list, and if something’s missing, don’t ship it. One time, with a clear head. Now it runs that judgment on every post, including the ones I’d wave through past midnight, tired and just wanting the thing live. The refusal isn’t the machine overruling me. It’s me, from a better moment — standing watch over me at a weaker one.

I did the slow work once; it does the fast work forever, carefully.

That’s the whole trick, and it has nothing to do with working hard. Lazy in the right way is leverage.

Next: an assistant that earns trust by knowing when to say “I don’t know.”

Squish: The Soul That Speed Can't Generate

Christian Smith — Tue, 16 Jun 2026 04:20:00 +0000

I learned one of the most important words in my craft in a college classroom, and it wasn't in the syllabus.

My game programming professor, Dave, pulled up a montage one afternoon: decades of games stitched together, frame by frame, all to explain a single idea. Why do people love Mario? Not respect it. Not remember it. Love it. The answer he gave us had a name: squish.

Squish is the feel of a thing. The weight, the response, the texture of an interaction; the part you don't see in a screenshot but feel in your thumbs. It's the difference between a button that does something and a button that feels good to press. Once Dave gave me the word, I realized I had been feeling it my whole life without being able to point at it.

Mario is made of squish

Watch what happens when Mario jumps. He doesn't just move up and come down. There's a wind-up; a crouch before the launch. At the peak there's a moment of hang, a held breath, and then the fall comes in heavier than the rise. You can feel gravity grab him. Add the double jump and the timing tightens into something your hands learn before your brain does.

None of that is necessary. A character could ascend and descend in a straight functional line and the game would still technically work, but it wouldn't be Mario. It wouldn't be the thing that millions of people carry in their bodies decades later. The weight in that fall is not decoration; it is the soul of the whole experience.

That's what squish does: it turns function into love. A game that works gets played once. A game with squish gets felt, and felt things get returned to.

I have spent years chasing that feeling in software that has nothing to do with games. The hover state that responds just right. The animation that has weight instead of just motion. The little moment of resistance before a thing snaps into place. I build desktop tools, not platformers; the realms are completely different, but the question is identical every time: does this feel alive, or does it just function?

Then speed showed up

Here is the part nobody was ready for.

I can build faster now than I ever could before. Things that would have taken me years as a solo developer are achievable in months, sometimes weeks. AI handles the scaffolding, the boilerplate, the thousand small functional decisions that used to eat my nights. I'm not romantic about this; it is genuinely the most powerful leverage a builder has ever held.

But speed has a cost that almost no one is naming yet.

When you can generate a working app in a weekend, something gets skipped, and the thing that gets skipped is almost always the squish; because squish is slow. Squish is the part that doesn't show up in the demo, doesn't pass a unit test, doesn't make the deadline shorter. Speed optimizes for done. Squish lives in everything that comes after done.

The dead software

You have used the result. We all have, more and more lately.

An app with a clean UI and nothing underneath it. It works. The buttons respond. The layout is fine, and somehow it feels like standing in a model home: every surface correct, every room staged, and not a single sign that a person actually lives there.

There is no defining feature. No reason to come back. No reason to tell a friend. You couldn't pick it out of a lineup of ten others built the same rushed way.

It is, and I mean this precisely as someone who writes horror: uncanny. Everything is right and the whole thing feels wrong. The deadness isn't in any one detail; it's in the absence of a decision. Nobody chose how it should feel, so it doesn't feel like anything. It has no identity because no human ever insisted it have one.

That is what software without squish actually is. Not broken — Hollow.

What speed can’t generate

Here is the line I keep coming back to. AI can generate function. It cannot generate the decision to give a thing a soul.

Squish doesn't come from capability; it comes from caring. From a human being looking at something that already works and saying this should feel like something, and then spending the slow, unglamorous time to make it true. The weight in Mario's fall existed because someone decided players should feel gravity in their hands. No model proposes that on its own. It is a choice, and the choice is human.

So the danger of the AI era was never that the machines would build badly. It's that they build adequately, instantly, at infinite scale. Adequate is the most seductive enemy soul has ever faced. Why spend three more days on feel when the thing already works? Because the thing that already works is the thing no one will remember.

Speed and soul are not enemies

I want to be clear, because the easy version of this essay is anti-AI, and I don't believe the easy version.

AI didn't take my squish away. It gave me time for it.

Every functional decision I hand to the machine is an hour I get back for the human part; the feel, the weight, the identity, the thing that makes someone return. Used with intention, speed is not the enemy of soul. It is the budget you spend buying more of it.

The builders who win this era won't be the ones who ship the fastest. They'll be the ones who use the speed to afford the squish everyone else skipped.

Dave gave me a word for a feeling in a dark classroom years ago. I've spent every project since trying to earn it. Now, with more power at my fingertips than that version of me could have dreamed, the question hasn't changed at all; it's only gotten louder.

Anyone can make it work. Squish is the part you have to think and feel.

This is the first in a series on building with a soul in a fast age. Next: why the job of a developer was never really the code; it was the thinking.

I Lacked the Tools, So I Built Them: How Constraint Created a Software Suite

Christian Smith — Fri, 22 May 2026 00:00:53 +0000

How constraint created a software suite: the story behind the RNVizion toolkit.

I think of myself as a modern-day Renaissance man: someone who's never been content to do just one thing. I'm a developer, a creative, a designer, and a philosopher who craves knowledge, truth, and understanding. I'm building out my own fiction book universe on the side, with real-world artifacts planned to accompany the stories (masks I'm learning to make myself), among other things, I'll save for later. I keep a notebook of research papers and inventions I want to pursue; theoretical for now, real later. I make my own art assets, not because I can't find an affordable artist, but because I enjoy the process of pulling exactly what's in my head into something other people can see. I've carved raw gemstones, done wire wrapping, played trumpet, piano, flute, electric bass (trumpet is still my favorite), and back in my university days, I wrote lyrics, produced beats, and put out real tracks; some solo, some collaborations with other musicians. Some of those tracks are still floating around in the wild on Apple Music, Spotify, and SoundCloud, for anyone curious enough to dig. I'm a poet at heart, but the music phase was real work, not a hobby attempt. The vizion never lost sight. It just got upgraded. And I'm deeply invested in fitness and helping others make healthier choices, both physically and mentally.

These feel like vastly different fields from the outside, but in my head, they're all connecting to make one big picture: RNV, a life and a brand built around helping people (myself included) level up across the board.

The catch is that being a Renaissance man without resources is a particular kind of hard. I've learned firsthand that resources are the enemy of imagination: not because imagination needs them, but because the lack of them is what most often stops imagination from becoming real.

For most of my life, that's been the wall. I could see what I wanted to build. I have the ideas, the plans, the skills; What I didn't have was the gear, the software licenses, or the budget to make every vision tangible the moment I had it.

For a long time, that's where things stalled.

The shift in framing

At some point, I stopped looking at my situation as "I can't do this." I started looking at it as "what can I do, right now, with what I have?"

The answer was: more than I thought.

I have a computer science background (game programming and development: specifically C++ and C# for formal training, Python for lightweight tooling). I have certifications. I have experience with Unity and Unreal (Unity being my main engine of choice). I have an old Lenovo Y-70 Touch from 2015 that could technically run my heavier creative software: Photoshop, Illustrator, Unity builds, and limited enough that I'd lose flow waiting for things to load and render; It could absolutely run Python and PyQt6 just fine, and I have time.

So I made a decision: I wouldn't try to break through the ceiling above me. I'd build a foundation, brick by brick, that kept rising. If you keep building up, there's no ceiling because there's nowhere to fall.

That's the framing that changed everything for me. I started sectioning my ambitions into two piles: projects I can do now with what I have, and projects I need to document and plan for when I have better resources. The roadmap to the Renaissance, you could call it.

The software suite came out of the first pile.

How brand identity work led to a color picker

I was building out my brand, RNVizion: Logos, slogans, video content, documentation. As I got deeper into it, I needed to choose colors that represented what RNV was about, and choosing colors, well, is harder than it sounds.

I was doing it the messy way at first: taking screenshots, snapping photos of things I liked, writing hex codes in a notebook; My camera roll filled up with ambiguous color swatches, I'd forget the context a few weeks later ("What was this from? Why did I save this?")

I needed a real color picker, one that could grab colors from images or directly from my screen, with a magnifier for accuracy, and built-in tools for checking contrast and generating harmonies.

I couldn't find one I liked that didn't cost money or come bundled with a design suite I couldn't afford. So I built RNV Color Picker.

See a need, fill a need, build a need.

The picker led to the palette manager

Once I started making real color decisions, the next problem revealed itself: I needed to save these palettes and use them across other projects.

RNV plans to produce merch eventually; I can't make the merch yet, that's a future-pile project, but I can plan it. I was building color palettes for hypothetical t-shirts, hoodies, packaging, and every palette deserved a name, a story, a way to be recalled with full context months later.

That meant exporting to every format I might eventually need: Adobe ASE files for Illustrator workflows, ACO for Photoshop, JSON for web work, CSS variables for sites, GIMP palettes for the open-source route, plain hex text for quick reference.

RNV Color Palette Manager was the answer. 16+ export formats, 7 mixing algorithms, built-in WCAG accessibility tools so I could check contrast as I designed.

No more screenshots of forgotten colors; every palette has a name, a purpose, and a file.

Then I wanted to actually mix paint

I was on a roll, I started thinking about real-world color; what colors look like when you mix actual paint, not when you average RGB values. Most digital color mixers fake it: they blend pixels, which isn't how pigment works at all.

I wanted to experiment with paint combinations without buying paint. Paint is another resource I didn't have to burn through.

So I went deep on Kubelka-Munk theory, the physics of how light scatters and absorbs through layers of pigment; it's the math behind how real paint actually mixes. Most "color mixers" online are just averaging RGB. I wanted mine to simulate the real thing.

RNV Color Mixer came out of that research. It's an oddly specific tool, but it does what it's supposed to do, and now I can experiment with color combinations that would otherwise cost me $30+ in paint and a Saturday.

Documentation work led to the text transformer

By this point, I was making a lot of content: documentation, scripts, product descriptions, captions, etc, constantly reformatting text for different contexts.

The editors I was using didn't have the text manipulation tools I needed natively. Simple things (converting case, applying regex transformations, batch processing files) took longer than they needed to.

I'm a lazy worker, but I mean that in the best way; Lazy doesn't mean suboptimal, Lazy means I'd rather spend two hours building a tool that saves me five minutes a day, every day, for the rest of my life, than keep doing the five-minute thing forever.

RNV Text Transformer is that tool. 11 transformation modes, 9+ file formats, regex builder, folder watching, full CLI; the thing I always wanted every text utility to be.

The icon builder closed the loop

Throughout building the apps themselves, I learned that proper desktop applications need multi-resolution ICO files. Not just a PNG renamed to .ico, actual multi-resolution icon files with several embedded sizes.

You'd think this would be an easily solved problem; It's not, ICO files feel like old tech that nobody updates tooling for anymore. The free options are sparse and outdated. The one good open-source option I found was command-line only, powerful, but with a learning curve.

I could've taken the time to learn it, or I could build a simpler GUI version I wished existed, the kind that someone like me (wanting a clean, efficient, no-friction tool) would actually use.

I built it, RNV Icon Builder: Multi-resolution ICO creation from PNG, SVG, and ICO sources (Cross-platform exports for Android, iOS, and favicons). A full CLI for power users who want it, a full GUI for everyone else.

What I didn't expect

Five apps in, I realized I hadn't been building isolated tools: I'd been building an interconnected creative suite, apps sharing a design language, talking to each other through compatible export formats, running on the same Python/PyQt6 foundation, and solving problems that naturally flowed into one another.

I never set out to make a suite. The need was a suite. You can't build a desktop app without icons. You can't design a brand without colors. You can't manage colors without organizing them. You can't write content without transforming it.

The suite emerged because the problems were always connected; I just needed to see the connections.

What this taught me

A few things, in no particular order:

Constraint is a creative engine. I built more, learned more, and shipped more under "can't afford it" than I ever did when having broader access. The constraint forced clarity about what I actually needed versus what I thought I needed.

Time is a real resource, maybe the most valuable one. When you can't throw money at problems, you have to think harder about which problems are worth solving. That filter is brutally useful. Half the projects I would've started if money were no object would've been wasted effort.

Build the foundation, brick by brick. Don't fight the ceiling. Build past it. Every brick I laid, every app I shipped, every lesson I documented, every plan I wrote down for a future-pile project raised the floor. There's no ceiling above someone who keeps building up.

Lazy in the right way is a feature, not a bug. I built tools to save myself effort across thousands of future moments. That's not typical laziness. That's leverage.

Plan what you can't yet build. The projects that need better hardware, more time, or resources I don't have yet, I write those down. The roadmap keeps moving even when I can't execute on every part of it.

Where it goes from here

The five apps live at rnvizion.dev, with full source on GitHub. They're open source. They have CLIs, multi-theme UIs, cross-platform CI, and real test coverage. If they're useful to you, take them.

The roadmap keeps going; more tools are coming. Games are coming (Unity is my main engine); I'll build properly once I have hardware that lets me iterate at the speed the work deserves. The fitness side of RNV is coming when the foundation is high enough to support it.

I'm not breaking the ceiling. I'm building past it.

If you're sitting on ideas, waiting until you can afford the right tools, consider that maybe you already have the only tools that matter.

Time. Curiosity. And the willingness to start with what's in front of you.

Christian Smith (RNVizion) is a Python developer, AR/VR Sales & Support Specialist at Meta, and a self-described modern-day Renaissance man. He builds desktop tools, writes fiction, makes art, and is figuring out the rest as he goes. Find his work at rnvizion.dev.