DEV Community: Yeferson Guarin

Sweeft: reclaim the gigabytes your dev tools quietly eat (and how I finally built it with Claude Code)

Yeferson Guarin — Wed, 05 Aug 2026 13:36:35 +0000

Every developer's disk is slowly being eaten alive.

node_modules here, a forgotten bin/obj there, a .gradle cache that somehow grew to a gigabyte, an .iso you downloaded eight months ago "just in case." Multiply that across dozens of projects and old folders, and one day your drive is full and you have no idea where it all went.

I got tired of hunting it down by hand, so I built Sweeft — a small, fast, cross-platform tool (CLI and GUI) that finds this stuff and helps you reclaim the space safely.

Sweep the cruft. — a Jeffersoft tool. MIT-licensed, single native binary, no runtime required.

An idea I'd carried for a long time

Here's the honest backstory: for years I kept losing time manually going project by project, deleting folders to free up space. And for just as long I'd had the idea of building a tool to do that intelligently — but I never made the time. Company work always pulled me away, and "I'll build it someday" stayed a someday.

What changed is that today we have tools powerful enough to close that gap between idea and shipped. I sat down with Claude Code, turned the vague idea in my head into a real plan, and then we executed it. That's how Sweeft was born.

I'll be transparent about my three reasons for building it:

A real need — I genuinely wanted my disk space back.
Curiosity — I wanted to push on what an AI coding agent like Claude Code can actually do on a real, end-to-end project.
To give something back — I wanted to hand the community a tool that might be useful. Use it, fork it, change whatever you want, and if it helps you, drop a ⭐ on the repo.

Install

# macOS / Linux
brew install jeffaristi92/tap/sweeft

# Windows
scoop bucket add sweeft https://github.com/jeffaristi92/scoop-bucket
scoop install sweeft

# Any OS with the .NET SDK
dotnet tool install -g Sweeft

Or grab a single native binary from the releases page.

What makes it more than `rm -rf node_modules`

Deleting build folders is easy. Deleting them without shooting yourself in the foot is the interesting part. That's where Sweeft spends its effort.

1. See where your space actually went

sweeft ~/projects --top 10

   3.2 GB  ████████████████████   79%  ZeroOne/
 302 MB    ██                      7%  AppRecetas/
 118 MB    █                       3%  api-workers/
 ...

The GUI takes this further with an interactive treemap — rectangles sized by disk usage, double-click to drill in. It's the "where did my space go?" view, read-only, it never deletes anything.

2. Clean regenerable folders — carefully

Sweeft knows the usual suspects (node_modules, bin, obj, .vs, target, .gradle, __pycache__, dist, build, virtualenvs…) and reports them sorted by size. By default it sends everything to the Recycle Bin (recoverable), asks before deleting, and refuses unattended permanent deletion unless you explicitly pass --force.

3. It's Git-aware

This is my favorite safety feature. Sweeft detects the Git repo each item belongs to and checks whether it has uncommitted changes. Those items get flagged and are not pre-selected — so you never wipe a build/ folder in a project you're mid-way through.

4. `--stale`: don't touch what you're working on

sweeft ~/projects --stale 90d

This only cleans regenerable folders of projects you haven't touched in 90 days. The project you're coding on today? Untouched. The prototype you abandoned last spring? Fair game.

5. `--global`: the caches nobody ever cleans

sweeft --global

npm, NuGet, pip, Gradle, Maven, Cargo, Go… their global caches grow forever. On my machine:

  npm cache ............. 14.46 GB
  NuGet packages ......... 9.48 GB
  pip / pnpm / Gradle .... ~3 GB
  ────────────────────────────────
  Total reclaimable ..... 27.49 GB

27 GB I didn't know I could get back. All rebuildable on demand.

6. An interactive terminal picker

sweeft ~/projects --tui

Arrow keys, space to toggle, Enter to clean. Regenerable items pre-checked, dirty-repo items flagged. And there's a full WPF GUI on Windows with a scan/stop button, per-type toggles, and that treemap.

Under the hood (the fun part)

A few things I enjoyed building:

.NET 8 + NativeAOT. The CLI ships as a single ~3.5 MB native binary — instant startup, no runtime to install. The trick was making JSON AOT-safe with source generators instead of reflection.
One shared Core. The scan engine, models, Git detection and deletion live in a Core library reused by both the CLI and the GUI. Write once, two front-ends.
A real security bug I had to defend against. Sweeft runs git status inside repositories it discovers — and a hostile repo can set core.fsmonitor to an arbitrary command that Git executes on status. Scanning a downloaded project could run code. Fix: resolve git by absolute path and run it with -c core.fsmonitor= and GIT_CONFIG_NOSYSTEM, so a malicious repo config can't execute anything.
Keyless publishing. Releases are automated on Git tags: GitHub Actions cross-compiles native binaries for Windows, Linux, and both macOS architectures, publishes the GitHub Release, and pushes the .NET tool to NuGet via Trusted Publishing (OIDC) — no long-lived API key stored anywhere. Homebrew and Scoop manifests update themselves.
Cross-compiling macOS on CI. The scarce macOS-Intel runners kept blocking releases, so the Apple-Silicon runner now cross-compiles both macOS binaries. Reliable, and I still ship an Intel build.

Building it with an AI agent — the process

Since one of my goals was to test how far an AI coding agent can go on a real project, here's an honest account of how the work actually went. It wasn't "type a prompt, get an app." It was a back-and-forth where I made the calls and Claude Code did the heavy lifting — and, importantly, it hit real-world walls and had to work through them:

Plan first, then execute. We started from architecture decisions (a shared Core reused by a CLI, with a GUI to come later), not from code. Having that skeleton made everything after it faster.
Iterative, in vertical slices. CLI scanner → WPF GUI → Git-awareness → shared config → then the features (--stale, --global, disk-usage treemap, the TUI). Each landed as a working, tested slice.
A security review that found a real bug. I asked for a security pass, and it surfaced the git core.fsmonitor remote-code-execution vector above — then proved it with an actual exploit (a repo that dropped a marker file when scanned) and confirmed the fix blocked it. That's the moment I stopped treating this like a toy.
Real friction, real fixes. My antivirus (McAfee) quarantined the unsigned native binary; a macOS-Intel CI runner sat stuck in a queue for 90+ minutes and blocked a release; re-tagging once rebuilt the binaries with new hashes and broke the Homebrew/Scoop manifests. None of these are things you plan for — we diagnosed and solved each one.
The boring-but-crucial 80%. Cross-platform line endings, an MIT license, CI, four distribution channels, OIDC publishing, self-updating package manifests, English-only docs, a rename/rebrand to "Sweeft." The kind of scaffolding that usually never gets done on a side project — this time it did.

My honest takeaway: the agent didn't replace the engineering judgment (naming, trade-offs, "ship the Intel build too," "don't ship a self-hosted runner on a public repo," what to prioritize). It removed the friction that kept this idea in my backlog for years. That's the part that felt new.

Roadmap

It's early (v1.1.0) and open source — contributions welcome. On the list: a duplicate-file finder, sweeft doctor, shell completions, a cleanup history/undo, and code signing to keep antivirus engines happy with the unsigned native binary.

Try it — and make it yours

👉 github.com/jeffaristi92/Sweeft

I built this out of a real need, out of curiosity about what these tools can do, and to put something useful in the community's hands. So: use it, fork it, change whatever you want, open issues and PRs. If it frees up a few gigabytes for you, a ⭐ on the repo would genuinely make my day.

What's the biggest space hog hiding on your dev machine? Run sweeft --global and tell me in the comments 👇

Take care of the quality of your software and do not fail in the attempt: Part 2

Yeferson Guarin — Wed, 13 Jan 2021 22:55:40 +0000

In the last post I told you about the quality criteria to take into account for the project development. Today, I will continue to tell you about this so you can be a more professional developer. Before continuing, I remind you of the six quality attributes:

Functionality
Reliability
Usability
Efficiency
Maintainability
Portability

In this post I am going to tell you about the last three.

Efficiency is the ability of the software to respond to a user request with the appropriate speed. You may think that I mean "the application responds fast", but this would be ambiguous, since how can you determine what is fast and what is not? At this point you must take into account what is an adequate response time for your user, as well as take into account the norms or standards that exist about this. You as a developer can help the software have adequate response times by correctly managing hardware resources, using good development practices, such as using efficient ordering methods or long-proven industry libraries.

Maintainability is the ability of the software for the user to invest minimal effort to maintain or improve it. Perhaps this attribute you understand better with examples. Suppose that in your work you were assigned a new requirement for an application that was developed by a person who no longer works for the company. The first thing you are going to do is check the code to try to understand it, if the code is easily understood by you or by another of your colleagues, we could say that the software is maintainable, but this is not enough. Now, suppose that you are going to start making the request, but you find that to do it, you have to change many things and that when you move something, the application begins to present unexpected effects, in this case we would see that the application cannot be " easily modified "and it is" not very stable ", so in this case we could say that the application is not very maintainable. Finally, suppose that you have finished the adjustments that you requested in the requirements, now you must do the corresponding tests to validate that the change you made has been correct, if the application is modular, doing these tests will probably be easy, in this case we could say the software is maintainable. In general, to determine if software is maintainable, we must ask ourselves how understandable, changeable, stable, and testable it is.

Ultimately, portability is the ability of software to be transferred from one environment to another and function in it. This means that the software can be installed / executed in different environments, for example that it can run on Windows, Linux or IOS, if it is a web application, that can be viewed in different browsers, or if it is a mobile application, that it can be installed on Android or IOS. It also refers to the ease of installation, preferably having an assistant to perform the installation and in each step it is clear to the user what he is doing, always avoiding that he makes decisions that affect the environment where it is executed and does not generate conflicts with other system. Portability also refers to the ability that the software can have to be used instead of another product, for the same purpose, in the same environment, for example, a mailing API that can replace another API that does the same. same.

It is important to clarify that the software does not necessarily have to comply with 100% of these attributes, it all depends on the requirements, needs and even the budget of the client, but if it is important that when you make the software, you have all this in mind, think in the impact it will have in the future, since the conditions and needs of the environment and your client may change

You can read the first part here

Take care of the quality of your software and do not fail in the attempt: Part 1

Yeferson Guarin — Tue, 15 Dec 2020 05:46:50 +0000

Today you listen, you read, you see many talking about this, they give you hundreds of tips, recommendations of what you should and should not do, but do you really know how to evaluate if your code is of quality or not? I am going to tell you what are the criteria that you must take into account, regardless of what language or tool you are using, since these are part of an international standard. Software, like any product, has quality attributes that can be objectively measured to determine whether it is a good product or not. There are six quality attributes:

functionality
Reliability
Usability
Efficiency
Maintainability
Portability

In this post I'm going to talk to you about the first three, all so you don't get bored (Yes, I know, I'm the best) and in the next post I'll talk about the remaining three.

The first three quality attributes are related and very end-user oriented. The functionality attribute is very simple, this attribute refers to the ability of the software to do the tasks for which it was created, nothing more, nothing less, something that seems trivial, but that many times developers because they are "too creative" not We comply, maybe the user wanted a calculator that would add two numbers but we make a calculator that obtains the square root, divides, makes derivatives but does not add or does not do it well, believe me, the user first needs you to do what he wanted you do, the rest is addition. That can generate value if you first comply with the fundamentals.

Reliability is the ability of the software to maintain its operation under normal conditions, that is, that the software works continuously and controls common errors, such as validating that only numerical data types are entered when you try to do a sum in the calculator or avoid doing divisions by zero, or at least show an error message when something unexpected happens, the important thing is that the user understands that something happened and has the possibility to continue using the software if possible or notify the error, write it in a log file and make a secure close

Finally, usability is the ability of the software to make the user invest the least possible effort in its use, for example, that the user does not require many clicks to be able to navigate to an application option, that the application is intuitive and easy to understand the purpose of a functionality. This may seem a bit subjective to you, but there are certain rules that give you guidelines to comply with this, but the most important thing is to do tests with your users, to be able to receive feedback from them, because each group has its peculiarities and culture has an important influence

As you can see, validating the quality of your software is not something from the other world, it is something that you can measure and evaluate and taking it into account will have a positive impact on the end user, which you can make very happy and you can even make your user enjoy product.

You can read the second part here

Something you should know if you want to be a better developer

Yeferson Guarin — Tue, 01 Dec 2020 00:23:37 +0000

Hello friend, I hope everything is going well for you. Today I want to talk to you about a very important topic that you may have overlooked because the day-to-day eagerness did not give you the space to pause and reflect on it, but don't worry, it is something that almost all developers have past, but you learn from mistakes and I can help you to make them as little as possible. What I'm talking about is the SOLID principles, 5 principles that every good developer should know and apply in their day-to-day work. I will quickly explain what they consist of. The SOLID principles are a set of principles that guide us to apply good practices in the developments we make, seeking that our products have a very high quality (I will tell you about these quality criteria later)

Each of the initials of these principles has a meaning. The 'S' refers to "Single Responsibility Principle", that is, to make our developments in a modular way, where each module, function, library, component, as you want to call it, should only have one responsibility since with this we could understand more quickly makes our code and modify it without generating side effects, or replace it with another more efficient implementation.

The second principle, the 'O', refers to Open / Closed, this principle tells us that when we make a component of our development, it should be open to be extended, but closed to be modified (speaking of its inputs and outputs) , since with this we will guarantee that in the future our code continues to be compatible.

The third principle, the 'L' refers to the 'Liskov Substitution Principle', this may scare you or sound very bombastic, but this principle simply tells us that classes that inherit from other classes should be able to be replaced by their base classes without alter the correct operation of the software, this allows us to create different implementations of a functionality and to test them without having to modify the code.

The fourth principle, the 'I' refers to 'Interface Segregation Principle' another name that may scare us a bit, but in practice it is easy to understand, this principle tells us that we should make small and concrete interfaces, this In order not to force our components to implement functionalities that have nothing to do with their nature, it would be preferable that our class implements several small interfaces.

Finally, the fifth principle, the 'D' refers to 'Dependency Inversion Principle', once again, a name that may scare many, but when you understand its philosophy and its power, you will evolve as a developer. This principle tells us that our components should not depend on implementations (classes that implement interfaces or abstract classes), but on their abstractions, this in order to minimize the dependency between components and therefore have a low coupling, which will allow us make our software more extensible, maintainable, bearable among many other benefits.

As once, these principles are very important in the development world and are widely considered (although there is no shortage of criticism), so much so that it is almost a requirement that every experienced developer handle them and have the criteria of how and when to apply them, as well. I invite you to continue delving into this topic, which is sure to hook you.