Clock Lobster — Editorial

The Engaged Vibe-Coder

Sun, 09 Aug 2026 17:00:00 -0700

Editorial

The Engaged Vibe-Coder

You don't need to know everything to build with AI. You do need to know enough to tell when it's taking you somewhere you don't want to go.

Published August 10, 2026

There's a comfortable lie about vibe-coding, and it goes like this: you don't need to understand anything anymore. Describe what you want, accept the output, ship it. The model knows the rest.

I've been building with AI long enough to know that's not quite it. The model knows a great deal — more than me on most subjects, and certainly faster. But "knowing" and "judging" are different muscles, and the second one is still mine. The gap between a vibe-coded project that ships and one that quietly rots is almost never about the code. It's about whether the person driving stayed curious enough to notice when the road started bending.

You don't need to know everything

Let me be clear about what I'm not saying. I'm not telling you to learn to code the old way before you're allowed to vibe-code. That's the gatekeeping reflex, and it's outdated. The whole point of the current moment is that the floor moved. You can build real things now with a conceptual grasp that would have been laughable five years ago.

But there's a middle ground between "know everything" and "know nothing," and that's where the engaged vibe-coder lives. You learn the broad strokes. Not the syntax of every framework — the shape of the landscape. Enough to ask a better question, to recognize a worrying answer, to know when to stop and look something up instead of pressing enter. If you're just starting out, the vibe-coding tutorial track walks through exactly this middle ground, one lesson at a time.

The broad strokes, and why they matter

Three areas keep coming back when I watch projects go sideways. None of them require depth. All of them require curiosity.

The tech stack, end to end. Not how to write a React component — what React is, what the browser does with it, where the data lives, what happens between a user clicking something and a row changing in a database. You don't need to configure any of it. You need to hold the shape of it in your head so that when the model says "let's add a Redis layer here," you can ask whether that's because the project needs it or because the model reaches for Redis the way a carpenter reaches for a hammer. The same prompt produces very different architectures depending on what the model defaulted to, and you're the only one in the loop who can notice.

IT and deployment. Where your app actually lives. What a DNS record is, what a CDN does, what happens when a certificate expires, why environment variables exist and why the ones that matter never go in a repository. I've watched vibe-coded apps go dark for a week because nobody understood that the free tier had a cold-start budget and they'd blown through it on day three. The model can deploy for you. It cannot tell you that you've walked into a billing trap six months from now — that's a question you have to know to ask.

Software architecture, and specifically why some of it is popular. This is the one people skip, and it's the one that matters most. Popularity in software isn't fashion — it's usually a lagging indicator of something working. Relational databases won because they model money correctly. HTTP won because it's stateless and composes. Queues show up in every mature system because synchronous calls fail together. When the model proposes an architecture, the question isn't "will this work." It will, probably, for a demo. The question is whether it's shaped like systems that have already proven themselves at the scale you're heading toward, or whether it's a one-off that'll need to be torn out the moment real users show up.

The model can teach you all of this

Here's the part that genuinely surprised me. The same tool that writes the code is also the fastest tutor I've ever had on these subjects. I can ask it "why do people use Postgres instead of MongoDB for financial data" and get a better answer than most of my computer science textbooks would give, in thirty seconds, calibrated to exactly the depth I'm ready for. I can ask it to explain the architecture I'm looking at the way a senior engineer would explain it to a junior — what each piece does, what it's protecting against, where the seams are.

The model is willing to teach all day. The thing it can't do is be curious for you. You have to want to ask. You have to notice that you don't know what a CDN is and decide that matters, rather than letting the acronym slide past for the fourth time. The literacy isn't a prerequisite you earn before vibe-coding — it's a habit you build while you're doing it, one question at a time, every time something in the output doesn't quite make sense.

What engagement actually looks like

Engagement isn't reading every line of generated code and understanding it. That's exhausting, and for a lot of what the model produces, it's not even useful — the code is fine, the question is whether the decision behind it was fine. Engagement is a lighter touch. It's pausing when the model adds a dependency and asking what it's for. It's reading the first paragraph of the docs for any service it wires up, so you know what you've just taken on. It's keeping a running list of "things I've seen but don't fully understand" and spending twenty minutes a week closing one of them.

The vibe-coders who ship things that last aren't the ones who know the most. They're the ones who stayed interested. They treated the model as a very fast, very patient colleague rather than an oracle, and they kept asking the follow-up question. The skill isn't coding. The skill is not going on autopilot at the exact moment when autopilot gets expensive.

The cost of checking out

I want to name the failure mode honestly, because it's easy to drift into. You vibe-code something that works. It feels great. You vibe-code the next thing, and the next, and somewhere in there the project gets bigger than your mental model of it. The code still runs. The model still produces. But you've stopped being able to predict what a change will break, because you stopped building the picture of how the pieces connect — you stopped being curious about the parts that weren't on fire.

That's the project that costs you later. Not because the AI failed, but because you disengaged a hundred small times and none of them felt like a decision. Engagement is the practice of not making those hundred small withdrawals. It's cheap in the moment and it compounds, the same way its absence does.

So stay curious

If you're vibe-coding and you take one thing from this, take this: every time the model does something you don't fully understand, that's not a gap to feel bad about. It's a prompt — for you, this time. Ask it to explain. Ask again if the first answer is too shallow. Build the broad strokes a little at a time, in the context of the real thing you're making, and the next project starts from a higher floor.

You don't need to know everything. You need to keep knowing a little more than you did last month, and you need to keep caring whether the road is bending. The model will do a remarkable amount of the work. The judgment about whether you're heading somewhere good — that's the part that's still yours, and it's the part that matters. If you want to build that judgment alongside a real project, the tutorials are a good place to start, and if you'd rather have someone in the loop with you, book a consultation.

The Engaged Vibe-Coder

— Victor

Currents Bookkeeping Is Coming

Sun, 09 Aug 2026 17:00:00 -0700

Editorial

Currents Bookkeeping Is Coming

Automated bookkeeping for Canadian small business — heading into testing this September and a trial run by October. Here's where it stands.

Published August 10, 2026

I've been quietly building something alongside the agent work, and it's close enough to talk about now. It's called Currents Bookkeeping, and the pitch is one sentence: upload your statements and receipts, wake up to reconciled books.

That's the whole idea. The bookkeeping cycle — categorize transactions, match receipts, reconcile against the bank, flag the weird ones, push to your accounting package — is exactly the kind of work that's tedious for a human and tractable for a well-built pipeline. I've been running a version of it on my own books for over a year, across two organizations and six accounts, and it works. Currents is that pipeline, productized for Canadian small businesses that don't want to pay a bookkeeper by the hour and don't want to do it themselves at midnight.

What it actually does

Three steps, on purpose. The whole thing is designed so a small-business owner can use it without learning bookkeeping.

Drop your files. Bank statements and receipts go in by drag-and-drop or email forwarding — PDF, CSV, photos, email threads. The messy real-world formats, not sanitized exports.

It processes overnight. A three-layer categorization engine handles the work: global rules for the common stuff, per-tenant overrides so each business can teach it its own patterns, and receipt extraction that reads the PDFs and matches them to transactions. Anything ambiguous lands in a review queue instead of getting guessed at. The point is that the machine does the grunt work and the human handles the judgment calls — the same division I've been running on my own books for over a year, now behind a product instead of a script.

Review and close. You approve the queued items in one click, see a dry-run preview, and push to Zoho Books or QuickBooks. Nothing writes to your real books until you've seen it. The reconciliation is marked tentative until year-end review, the same way a careful human bookkeeper would treat it.

Why it's built this way

A few decisions shaped the whole thing, and they're worth naming because they're what make it different from the existing options.

Canadian data residency, end to end. Everything runs in ca-central-1 — the AWS Montreal region. No cross-border transfer, no US Cloud Act exposure. For a bookkeeping product handling client financials, that's not a feature; it's the price of admission. PIPEDA-aligned, with SOC 2 controls in the parts that matter.

The AI categorizes, but it doesn't decide quietly. The black-box problem with most "AI bookkeeping" tools is that you can't see why a transaction got categorized the way it did. Currents surfaces a rationale for every flagged item — the rule that matched, the receipt it linked, the amount that looked unusual. You're not trusting the model; you're reviewing its work. That's the same posture I take with agents generally, and it's the only one I'm comfortable shipping financial software with.

Fixed pricing, no per-transaction surprise. $149 a month, unlimited transactions, unlimited receipt extraction. The 14-day trial is free and there's no setup fee. Bookkeeping costs that scale with how messy your books are punish the businesses that need the most help, so Currents doesn't price that way.

Where it stands right now

Honest status, because that's the only useful kind. The core pipeline — ingestion, categorization, reconciliation, the review queue, the Zoho and QuickBooks sync — is built and running against real data on my own books. The customer portal, the onboarding flow, and the billing layer (Stripe-backed, trial-aware) are wired up. What's left before it's trial-ready is the last stretch of polish: the edge cases in receipt extraction, the year-end close flow, and a round of real-user testing to catch the things I can't see from inside my own books.

The plan, as it stands today:

September — internal testing. Close out the edge cases, run the full cycle against a few real business profiles that aren't mine, and harden the parts that break when the inputs get weird. The kind of testing where you find out the receipt OCR misreads a specific vendor's invoice format, and you fix it before a customer ever sees it.
October — trial run. A limited, invite-coded trial with a small set of Canadian small businesses. The goal is to put the overnight cycle in front of people who've never seen the pipeline and watch where it confuses them — then fix that. Trial accounts are the full product, not a demo; the books they close during trial are their real books.

I'm not committing to a public launch date yet, because the trial is what tells me when it's ready. If the trial surfaces something fundamental, I'd rather fix it than ship around it. What I can commit to is that by the end of October, real businesses will be running real books through it, and I'll know whether it's as good in their hands as it is in mine.

Why this is a Clock Lobster post

Currents is the proof that the agent and automation work isn't theoretical. The same patterns I write about here — agents that do real work in guardrails, engagement as the difference between shipping and rotting, pipelines that handle the grunt work while a human holds the judgment — are the ones Currents is built on. It's the bookkeeping challenge from the 2026 #AISkillGap Challenge, grown up into a product. If you've been reading this blog to figure out whether any of this actually works on a real business problem, Currents is the answer for one specific one.

If you want in

Trial invites are limited and going out by invite code. If you run a Canadian small business and you're tired of doing your own books — or paying someone else too much to do them — you can request a trial at currentsbk.ca. I'll be working through the waitlist as the September testing wraps up and the October trial opens.

And if you want the longer story of how the pipeline got here — the receipt ingestion, the categorization rules, the reconciliation steps, the year where I ran it on my own books first — that's the same pipeline I described in the 2026 #AISkillGap Challenge post, where bookkeeping was Challenge 1. Currents is that pipeline, with a product around it.

Currents Bookkeeping Is Coming

— Victor

The 2026 #AISkillGap Challenge

Thu, 02 Jul 2026 17:00:00 -0700

Editorial

The 2026 #AISkillGap Challenge

A year-long personal challenge to build, document, and share the AI agent skills that actually matter. You're welcome to follow along.

Published July 3, 2026

Why I'm Doing This

I build AI-assisted workflows for a living. Productivity companions and work pipelines that manage repeatable steps, draft correspondence, and surface decisions within guardrails. Open Claw and Nemo Claw are examples of that earlier direction.

But here's the thing I've noticed: most of the useful AI skills aren't locked inside expensive platforms. They're patterns. Small, composable capabilities that any reasonably capable agent can learn if someone writes them down. And right now, nobody is writing them down.

So I'm going to.

The Rules

This is a challenge I've issued to myself. No leaderboard, no prizes, no submissions. The format is simple:

Build something real — every post features something I actually created: a container, a script, a skill file, an integration. No theory without practice.
Share the skill — every creation comes with a documented AI agent skill: what it does, how it works, when to use it, what to watch out for.
Keep it accessible — the skills should be useful to anyone running autonomous agents, not just people with my specific stack.
Post throughout the year — periodic updates as the challenge evolves, with all the wins, failures, and lessons learned along the way.

What You'll Find Here

Over the course of 2026, this blog will fill with:

AI agent skill files ready to drop into any compatible runtime
Deep dives into specific agent capabilities: research, reasoning, tool use, memory, delegation
Real infrastructure: how I deploy, scale, and monitor production agents
Failures — tools that didn't work, approaches that broke, lessons paid for in compute credits
Container recipes, prompt patterns, security boundaries, and integration tricks

The skills land in the tutorials as they're ready, and the measurements behind the claims show up in benchmarks with open data. This post is the why; those are the what.

Post #1: Coming Soon

The first post is in the works. I'm documenting a skill I built to solve a genuinely annoying problem — one that cost me hours every week until I automated it. If you run agents, you'll want this one.

Subscribe to the newsletter or check back here for updates.

The 2026 #AISkillGap Challenge

— Victor