DEV Community: Reymar

40 New Commits. Zero Motivation to Read Them.

Reymar — Thu, 22 Oct 2026 10:25:17 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady.

What I Built

You take a few days off. Come back, pull the latest changes, and suddenly there are 40 new commits.

Great. Now you have to figure out what everyone did before you can even start working.

Sure, there's git log, git diff, and a bunch of other commands to help. But reading through commits, figuring out which changes belong together, and checking if anything important broke isn't exactly how I want to spend my morning.

So I built RepoSloth, an open-source AI-powered CLI that helps developers catch up on their repositories without digging through every commit.

It reads your Git history, groups related changes, explains what happened, and highlights things you might want to review.

Think of it as a quick briefing from a teammate who actually read all the commits.

Except this one runs locally and doesn't need an API key.

Here's what it can do:

Catch up on recent changes. Get a summary of what happened over the last few days or weeks.
Group related commits. See changes organized by workstream instead of reading a long chronological list.
Spot potential risks. Get a heads-up about migrations, dependency updates, and configuration changes.
Ask questions. Want to know if someone touched authentication? Just ask.
Go full sloth mode. Use --lazy when you only want the important stuff.

Every finding includes references to actual commits and files, so you can verify what the AI tells you.

It's not trying to replace code review. It's just helping you figure out where to start.

Demo

The default command summarizes the last three days:

reposloth

Want to check the past week?

reposloth --since 7d

Don't feel like reading a long report?

reposloth --lazy

Coming back from vacation?

reposloth vacation --since 14d --checklist

This gives you a catch-up report with a checklist of changes worth reviewing.

You can also ask questions about the repository history:

reposloth ask --since 7d

For example:

Did anyone change the authentication logic?

RepoSloth searches the selected history and explains the relevant changes, including which commits and files to check.

Reports can also be exported as Markdown or JSON.

Code

GitHub: memar1992/reposloth

The project is MIT licensed and currently installs from source.

The README includes installation instructions, model setup, available commands, and known limitations.

Contributions are welcome. It's still a relatively small project, and there's plenty of room to improve it.

How I Built It

RepoSloth is written in TypeScript and uses a fully local AI setup.

Here's the stack:

Qwen2.5 Coder 1.5B as the default open-weight LLM.
Ollama for local inference.
Mastra for the agent and workflow orchestration.
Git CLI for collecting commits, changed files, and diffs.
Zod for validating structured AI responses.

I chose a small model intentionally. I wanted something developers could run locally without needing expensive hardware or a paid API.

Of course, smaller models come with trade-offs, especially when analyzing a large amount of code.

So instead of sending the entire Git history to the LLM and hoping for the best, I built a workflow around it.

How the workflow works

RepoSloth uses a five-step Mastra workflow:

Collect history. Read commits, changed paths, line counts, and bounded diffs from the local repository.
Group changes. Organize related files into workstreams so the model has more useful context.
Analyze with Qwen. Generate explanations based on the collected Git evidence.
Identify potential risks. Flag changes involving migrations, dependencies, and configuration that may need review.
Validate and format. Check the references, apply the selected report mode, and cache the result locally.

You can inspect the actual workflow implementation here.

Mastra handles the orchestration, while Qwen runs through Ollama using ollama-ai-provider-v2.

For larger repositories, the input is split into bounded chunks, analyzed separately, and then combined into a final briefing.

Making a small local model useful

One thing I didn't want was an AI confidently reporting changes that never happened.

The generated output goes through schema validation, and RepoSloth checks whether referenced files actually belong to the commits being cited.

That doesn't guarantee the explanation is always correct, but at least the references point to real changes.

Potential risks are also treated as things worth investigating, not confirmed bugs.

If Ollama isn't running or the AI response isn't usable, RepoSloth falls back to a deterministic Git summary.

There's also a --no-ai option if you want to skip inference entirely.

And since the tool reads repository history, I added some boundaries. It doesn't modify repository files or switch branches, filters common sensitive paths and known secret patterns, and restricts inference requests to local addresses. The Mastra agent itself has no tools.

I wanted RepoSloth to be useful without giving an AI agent unnecessary access to the project.

Why Does Open Innovation Matter?

One of the reasons I started this project was that I didn't want another developer tool that required an API key just to do something relatively simple.

Git history can contain internal code, business logic, and implementation details. Sending all of that to a hosted AI service isn't always an option.

With Qwen running through Ollama, RepoSloth can analyze that history on your own machine.

No paid AI API. No cloud inference account. No GitHub integration required.

It even works on local repositories without a remote.

Using an open-weight model also means you're not locked into the default one. RepoSloth uses Qwen2.5 Coder 1.5B, but you can switch to another locally installed model using --model.

And because the project itself is open source, developers can inspect how Git data is collected, how the prompts work, and how the output is validated.

Mastra and Ollama made it practical for me to build this without having to implement local inference or agent orchestration from scratch.

That's what I like about open-source tooling. You can take existing pieces, build something useful, and let other people improve it.

The Lazy Payoff

The biggest time sink when returning to a repository isn't necessarily reading code.

It's figuring out which code you should be reading in the first place.

Normally, I'd start with git log, open a few commits, inspect the diffs, jump between files, and slowly piece together what happened.

And sometimes, after doing all that, I'd realize half the commits weren't even relevant to what I was working on.

With RepoSloth, I can run:

reposloth --since 7d

And get a starting point.

If something looks important, I can inspect the referenced commits. If I only care about a specific feature, I can ask about it. If I just need the highlights, there's --lazy.

I'm not going to claim it saves exactly 30 minutes or makes developers 10x more productive. I haven't benchmarked that.

What it does is remove a lot of the manual scanning involved in catching up.

You still need to review code, understand the changes, and make your own decisions. RepoSloth just handles some of the boring work before that.

And that's really the idea behind the project.

I don't want AI writing every line of code for me.

Sometimes I just want it to read the commits I don't feel like reading. 😂

Prize Categories

Best Use of Mastra

RepoSloth uses a five-step Mastra workflow to collect, group, analyze, validate, and summarize Git history. A Mastra agent powered by local Qwen inference handles the AI briefings and follow-up questions.

I Built 3 Apps That Didn't Take Off. Here's What I'm Doing Differently With My 4th.

Reymar — Fri, 16 Oct 2026 01:58:11 +0000

I've been working as a software engineer for years, mostly building stuff for other people.

At some point, I thought, why not build something for myself?

So I did.

Three apps, actually.

None of them really took off.

And now I'm building my fourth. Apparently, I haven't learned enough yet.

The first three

Steppet was an iOS step tracker where you raise virtual pets by walking. The more you walk, the more your pets grow and evolve. I thought making fitness feel a bit like playing a game would be fun.

EasyReceipt Scanner was an app for scanning and organizing receipts, tracking expenses, and keeping everything in one place.

ForecastedFit was an app that suggested what to wear based on the weather. Nothing too complicated, just something I thought could be useful.

All three were different ideas, but they had one thing in common.

I spent most of my time building them and almost no time getting people to use them.

I'd get excited about an idea, start working on it, add features, improve the UI, fix things, and eventually launch.

Then I'd check if anyone was using it.

Not exactly the numbers I was hoping for.

Vibe coding made things worse. Sort of.

I've been a software engineer for years, so I'm used to writing code, debugging things, and spending hours figuring out why something isn't working.

But these days, I'm mostly vibe coding my personal projects.

And I have to admit, it's pretty addictive.

An idea pops into my head, I open my AI coding tool, explain what I want, and suddenly I have a working prototype.

Something that would've taken me weeks before can now take days, sometimes even hours.

Of course, the AI still manages to break something that was working perfectly fine five minutes ago. Some things never change.

But overall, building software has become much faster for me.

The problem is, now it's even easier to start another project.

Before, I'd think twice about spending months building an idea.

Now I just think, "I could probably build that this weekend."

And that's how you end up with multiple apps and barely any users.

The part AI can't really solve for me

Getting people to actually use what I build.

I can ask AI to create a landing page, improve the UI, implement a feature, or help fix a bug.

But getting someone to care about the product is a different problem.

I used to think that if I built something good enough, people would eventually find it.

I'd launch, share it somewhere, and hope for the best.

Then go back to coding because that was the part I enjoyed.

Looking back, I was basically using development as an excuse to avoid marketing.

There's always another feature to add, another bug to fix, or another part of the UI that could look better.

And now with AI, I can do all of that even faster.

Which doesn't help when the actual problem is that nobody knows the app exists.

So naturally, I built another app

My fourth project is ZaneShot, a screenshot and screen recording app for macOS.

I use screenshots a lot in my daily work, especially when explaining bugs, sharing UI feedback, or showing someone how something works.

I wanted a tool that could handle screenshots, annotations, scrolling capture, and screen recording without making the workflow complicated.

So I started building one.

And yes, I vibe coded a lot of it.

I still review things, test features, debug issues, and make technical decisions. Having years of development experience definitely helps when AI confidently generates something that makes absolutely no sense.

There are already some great screenshot tools for macOS. I'm not pretending I came up with something nobody has ever thought of.

I just wanted to build my own version, with the features and workflow I personally wanted.

But this time, I'm trying not to repeat what happened with my previous apps.

What I'm doing differently

For starters, I'm trying to talk about the product instead of just building it.

I've started posting on Threads, sharing what I'm working on, asking for feedback, and learning a bit more about marketing.

I'm also working on SEO and figuring out how people actually discover apps like mine.

Which, to be fair, is a lot less exciting than building another feature.

I'm still tempted to open my editor whenever I have a new idea.

Sometimes I'll be working on marketing, then suddenly think of a feature that would be cool to add.

Next thing I know, I'm back talking to Codex.

Old habits.

But I'm trying to be more intentional about what I build.

Instead of immediately adding something because it sounds useful, I'm asking whether it's something people actually want.

I'm also trying to share the process while I'm building, rather than waiting until everything feels perfect.

Because if I wait until the app is perfect before I start marketing, I'll probably end up building a fifth app first.

One thing I've realized

AI has made it ridiculously easy to build software.

That's a good thing, especially for developers who have more ideas than free time.

But it also means more people can build and launch products.

And when everyone can ship apps quickly, simply having a working product isn't much of an advantage anymore.

You still need to figure out who it's for, why they should care, and how they'll find it.

I spent years learning how to build software.

Now I'm realizing I probably need to spend some time learning how to get people to use it.

Not exactly my favorite part, but here we are.

Will the fourth app do any better?

I have no idea.

ZaneShot is live, and I'm still improving it.

Maybe it'll grow into something. Maybe it won't.

I'm not going to write about how I cracked the secret to building a successful SaaS when I'm still figuring out how to get people to visit my website.

For now, I'm just trying something different.

Less building in silence. More sharing, getting feedback, and learning how to reach the right people.

I'll probably share some technical stuff about ZaneShot here too, especially what I've learned building a native macOS app with Swift and AI coding tools.

And hopefully, my next article won't be titled:

"I Built 4 Apps That Didn't Take Off. Here's What I'm Doing Differently With My 5th."

Anyway, I'm curious.

For developers who are also vibe coding their own products, is building still the hard part, or is getting users the real challenge now?

Because I'm starting to think shipping the app was the easy part.