Launching Moxie Docs

Caden Sumner — Tue, 09 Jun 2026 21:22:36 +0000

👋 Hey all,

I haven't used this platform often, my last real blog post was about me failing at running a startup - so it's exciting and scary to say I'm at it again!

Over the last few months I've been quietly thinking about how AI is changing the field of software development, and what that means for engineers. I've been building full-stack applications (and desktop, and mobile, and some other stuff) for around 8+ years now, and the changes I've seen in the last year alone are such a fundamental shift in the industry - and how engineers work - that I thought about what kinds of issues I've had adopting new technology.

My Agentic Coding Workflow

I'm going to keep this short and avoid buzzwords, in fact I'll just give a TL;DR list of how I've been using AI:

PR Code reviews, 100% of the PRs I open are reviewed by an agent alongside humans, I use greptile for this at my work and CoPilot / Gemini (antigravity) on my personal plans for side projects.
Small front-end, well-scoped features. AI excels at highly specific tasks with well defined context & conventions.
PR descriptions, my least favorite part of development is writing commit messages, 100% of my messages are authored by AI now.
Testing. To some degree unit tests are great candidates to offload to LLMs, but also things like storybook stories for UI libraries where they aren't necessarily user-facing and are low risk, I delegate to agents.

Where things don't work well...

The biggest pain point I've found adopting AI tooling in my day to day workflow is the amount of loops / iterations needed to get a "ready to go" final implementation.

I found myself continually typing "follow our codebase conventions" in prompts, pointing it to example files to use as a reference, and then prompting it to update documentation (if I remember).

Enter: Moxie Docs

Moxie Docs

I developed Moxie Docs after much iteration and frustration. I had dissolved the last startup I attempted (after around 7 years of customers using it!) and it was quite the walk down memory lane recreating Stripe, buying domains, setting up marketing flows, auditing SEO. The million little things that go into trying to build a product for users.

What does it do?

In short - it solved a problem for me (and I imagine many others) by truly creating living documentation in your codebase, automated developer docs sitting next to the code itself. Auto-updated, auto indexed, checked on every PR merge. Alongside that we have an MCP for users using AI agents - connect Moxie Docs to Claude Code, Cursor, Codex, etc. and we give the tools and guidance for AI workflows to detect what changes impact docs, update them automatically in the same PR they are making changes in, and pull in codebase conventions before starting changes.

Every API file requires a test? Components split into domain folders? Re-use templates for back-end routes? File name conventions, organization, all of it is detected & continually updated by Moxie Docs and surfaced to agents.

A short list of features:

Moxie Docs MCP - agent-ready context continually updated as your codebase changes
A changelog viewer / copy feature tied directly to PRs, organized by internal and external changes
We detect orphaned documentation, documentation drift, and missing docs. We give you 1-click buttons to generate a PR from Moxie Docs into your codebase - yours to review and accept.
PR Description alignment - we can automatically categorize PR types, rewrite & summarize them to keep formats / templates consistent, easier for engineers to know what's going in / what to review.

It's been a lot of fun to build & launch - and I've gotten some great feedback already :) would love to answer any questions or hear thoughts if you'd like to check it out: Moxie Docs

Imbue-js: Making vanilla JS more attractive

Caden Sumner — Thu, 07 Nov 2019 18:27:14 +0000

What's wrong with JavaScript?

I'd like to think I'm not alone in my feeling that the front-end ecosystem is chaotic. When I learned table-layout HTML pages in high school, JavaScript was barely mentioned, but when it was we used basic event handlers in HTML such as onClick for buttons. As I continued to pursue web development as an interest in college & eventually a career, I learned more JavaScript to handle DOM events and manipulations. Here I was introduced to querySelectorAll and addEventListener which gives developers much more control over the DOM, without having to use HTML to add functionality.

At some point, developers decided that JavaScript can be used in lieu of any HTML to create dynamic and robust applications, subbing in JSX, JavaScript powered elements, and similar component based frameworks. There's nothing wrong with this, but it was surely a strange step away from my initial table-focused knowledge I started from. I've cycled through React and Vue and consistently found that they address a lot of use cases, and in many are the right tool for the job, but even so I felt a sense that they add complication to front-end development. I believe that the root of that is the removal of HTML and relying instead of reusable components in JavaScript to manipulate and populate the DOM.

Eventually I found Svelte and immediately fell in love. Unfortunately I haven't found the case to use Svelte in a production app, but I have had the opportunity to use it in side-projects and making toy examples of things. The reason I love Svelte so much is that it brings HTML back to the forefront and instead of replacing or fighting vanilla JavaScript, it enhances it in extraordinary ways and augments front-end development with useful additions. The Vue-like component syntax is also extremely easy to pick up, as it follows similar semantics and separations as standard HTML (although I'm not a fan of the .svelte extension). It's important to note that since Svelte is compiled, it's not technically JavaScript, as discussed in this blog post. But the speed improvements, and ease of use is a huge benefit that I see propelling Svelte usage forward.

So what is Imbue?

This post isn't intended as a rant against Javascript nor a promotion of the library I'm trying to build (Imbue). It's more of a reflection of my thoughts on the front-end development experience, and my desire for something to address what I see as issues.

I've worked with jQuery for several years, and for most of my projects, jQuery is the first thing I plopped in to the lib directory, or installed in Bower, or NPM, or linked with a CDN. It honestly got to the point where jQuery was a required drop-in for a project, and from the look of a lot of recent articles, I was not alone in this experience. Over time jQuery's popularity surged and at some point I, like many others, began to see it as an unnecessary, slow, bulky, and strange requirement. Sites like You might not need jQuery popped up to help people take a step back and remove the dependency from their systems. In a production application I'm working on, I also took a step back and made the decision to slowly rip jQuery away from our app.

I began by replacing $() with document.getElementById and document.querySelectorAll, the replacement wasn't hard and I did anecdotally feel like everything ran faster after the replacement, but I immediately hated looking at the source code of our pages. I made the discovery that the main reason I used jQuery was because the vanilla JS methods for the DOM are poorly named, sometimes confusing, and lacking in features. Additionally, the developers I worked with were just as ingrained in the jQuery mindset as I was, and we all had to dust off JavaScript books and take a look at the DOM related methods again.

So this is where Imbue comes in. Imbue is a small (~5kb currently) library (not framework), that provides semantic and simple prototype extensions to vanilla JavaScript, to speed up development and make source code easier to understand. The lengthy "document ready" code that jQuery made $(document).ready() is supplied in Imbue as document.whenReady(), the selector methods in jQuery are replaced by document.getElement() and document.getElements(), which simply use querySelector calls underneath. HTMLElements are extended to have whenVisible(), onClick(), getData(), setData(), toggleClass(), and many more.

I'm exploring just how much functionality Imbue should provide, keeping in mind that it's not a jQuery replacement, but a substitute for projects that just need the DOM related functionality. The main reason I decided to write this post, was that I was curious to see if any other developers would find benefit in a mini-library like Imbue, and whether or not your projects could eschew jQuery for something like lighter and more focused?

Would love to have a discussion on the usefulness, how to move forward, and the current state of front-end development overall.

Check out Imbue

imbue.js.org

DEV Community: Caden Sumner