DEV Community: FlutWiz

Most AI developer tools didn't add AI. They added a chat window.

FlutWiz — Thu, 02 Jul 2026 09:24:02 +0000

AI is changing how we build software, but I think a lot of developer tools are solving yesterday's problem.

Many products proudly advertise that they're "AI-powered," but when you actually use them, the experience usually looks like this:

Ask AI to generate something.
Copy the output.
Paste it into another tool.
Run it.
Copy the results back.
Ask AI what to do next.

The AI did the thinking.

You did the integration.

The hidden bottleneck

This became obvious to me while testing APIs with an AI agent.

The agent could generate a perfect request. Headers, body, authentication—it all looked correct.

But it couldn't actually work with my API client.

It couldn't see my request files.

It couldn't execute the request.

It couldn't inspect the response on its own.

So I ended up copying the generated request into my API tool, running it, copying the response back into the chat, then waiting for the next suggestion.

The AI wrote the request.

I moved the data.

That "copy-paste loop" doesn't feel like much at first, but it adds friction to almost every interaction. And once you're working across dozens of requests, environments, or iterations, that friction becomes the workflow.

A chat interface isn't enough anymore

When LLMs were mostly helping with code completion, this wasn't a huge issue.

Today's coding agents are different.

They're expected to carry out tasks, not just suggest them.

That changes what developer tools need to optimize for.

Adding a chat panel beside an existing workflow isn't enough if the agent still depends on a human to move information between systems.

The more context switching required, the less value the agent actually provides.

The tools that stand out are built around agents

The biggest difference I've started noticing isn't which tool has the smartest model.

It's whether the tool exposes its workflow in a way that an agent can actually understand.

One example is Voiden.

Instead of storing API requests in a proprietary format, Voiden keeps them as plain .void files inside your repository.

It also provides AI Skills for Claude and Codex that teach the agents how those files are structured and how to work with them.

That means the agent isn't guessing from screenshots or waiting for me to paste requests into a chat.

It's reading and editing the same files I'm working with.

The workflow becomes something both the developer and the agent can understand.

The shift I'm starting to see

I think we're entering a new phase of developer tooling.

The question is no longer:

"Does this tool have AI?"

It's becoming:

"Can an AI agent actually use this tool?"

Those are very different questions.

Adding AI to an existing workflow often leaves the human acting as the bridge between systems.

Designing the workflow so agents can work with the same artifacts developers already use removes that translation layer.

That's where the real productivity gains start to appear.

I'm curious whether others are seeing the same trend.

Have you found tools that are genuinely built for AI agents, or are most of them still just adding a chat window on top of the old workflow?

If you're interested in the approach I mentioned, you can check out Voiden at https://voiden.md/.

5 Open Source Alternatives I've Been Using Lately

FlutWiz — Mon, 29 Jun 2026 07:02:44 +0000

Like most developers, I have a set of tools I use every day. Most of them work great, and I don't switch tools just because there's a new one.

That said, over the past few months I've been trying more open-source alternatives. Not because I wanted to replace everything, but because I was curious about what the community has been building.

Some of these are self-hostable. Some are easier to customize. Others are just enjoyable to use.

These aren't guaranteed replacements for everyone. They're just a few open-source projects that I've genuinely enjoyed using and they are worth trying as they give you a fresh perspective on what community has been building.

1. Jira → Plane

I've used Jira before, but for personal projects and smaller teams it can sometimes feel like more than I actually need.

Plane covers the things I use most:

Issues
Sprints
Roadmaps
Project planning

The UI is clean, it's open source, and you can self-host it if that's important to you.

If you want something simpler than Jira without giving up the core project management features, it's worth checking out.

2. Postman → Voiden

I've been trying different API clients recently, and Voiden has been the one I've spent the most time with.

A few things I like:

Requests and environments are Git-friendly.
AI agents can work directly with your API workspace.
Supports REST, GraphQL, and more.
Feels built around developer workflows instead of just sending requests.

If you're looking for an open-source alternative that's taking a different approach, Voiden is definitely worth a look.

3. Vercel → Coolify

Vercel is still one of the easiest ways to deploy an application.

Coolify isn't trying to be a clone—it solves a different problem.

If you already have a VPS and want to host your own applications without manually managing containers and deployments, Coolify makes that process much easier.

It's open source, easy to get started with, and gives you full control over where your applications run.

4. Zapier → n8n

Whenever I need to automate something now, n8n is usually the first tool I think of.

The biggest reason is flexibility.

You can self-host it, connect hundreds of services, and even drop JavaScript into your workflows when you need something custom.

It feels much more developer-friendly than many no-code automation platforms.

5. Figma → Penpot

I'm definitely not a designer, but I still spend a fair amount of time looking at design files.

Penpot has become one of the strongest open-source alternatives in this space.

It supports collaborative editing, works in the browser, and can be self-hosted if your team prefers keeping everything in-house.

If your workflow already leans toward open-source tools, Penpot fits in nicely.

Final Thoughts

I don't think open-source tools have to replace every commercial product.

A lot of paid tools are excellent, and I still use plenty of them.

But I do like having alternatives.

Whether it's self-hosting, avoiding vendor lock-in, contributing back to projects you use, or simply trying something new, the open-source ecosystem has come a long way.

These are just five tools I've been using lately.

If there are other open-source alternatives you've been enjoying, I'd love to hear about them. There's always another good project waiting to be discovered.

Why Open Source API Tools Are Having a Moment

FlutWiz — Wed, 24 Jun 2026 08:33:26 +0000

Over the last year or so, I've noticed more developers talking about open source API tools.

Not just using them, but contributing to them, building plugins, opening issues, and sharing workflows.

I don't think that's happening by accident.

A lot of modern development workflows naturally fit with what open source tools offer.

Ownership Matters

Developers like having control over their tools.

When collections, environments, and configurations live as files, they become part of the project itself. They can be version controlled, reviewed in pull requests, and shared with the rest of the team.

That feels natural because it's already how we manage code.

Local-First Feels Nice

A lot of us spend our days jumping between terminals, editors, browsers, and APIs.

Sometimes you just want a tool that opens, does its job, and stays out of your way.

No extra setup. No unexpected dependencies.

That local-first experience is something many open source tools have embraced well.

Extensibility Is a Big Deal

One thing I appreciate about open source tools is that if something is missing, there's usually a path to build it yourself.

Maybe it's a plugin.

Maybe it's an integration.

Maybe it's a workflow that only your team needs.

Instead of waiting for a feature request to be prioritized, developers can experiment and share solutions with others.

AI Is Making Open Tools More Interesting

Something else I've been noticing is how AI is starting to fit into developer workflows.

It's no longer just about asking a chatbot questions.

Developers are using AI agents to inspect codebases, generate code, interact with APIs, and automate repetitive work.

For that to work well, tools need to be accessible and easy to integrate with.

Open ecosystems tend to have an advantage here because they expose their workflows and make it easier for developers (and increasingly AI agents) to interact with them.

Community Matters

The best open source projects aren't just software.

They're communities.

A developer builds something useful, another improves it, someone writes documentation, someone reports a bug, and the tool gets better for everyone.

That's a pretty powerful feedback loop.

Final Thoughts

I don't think open source API tools are becoming popular just because they're open source.

I think they're becoming popular because they align with how many developers already work: Git-based, extensible, collaborative, and increasingly AI-assisted.

As someone who has been spending more time around this space, it's been interesting to watch.

I've personally enjoyed following projects like Voiden. It's been interesting to see how quickly the project has evolved and how much the community has contributed.
Recently they've even added support for AI agents like Claude and Codex through skills, which feels like a glimpse of where developer tools are heading next.

Maybe I'm wrong, but it feels like we're only at the beginning of this shift.

Why I Left Postman — The Real Cost of a Cloud-First API Client

FlutWiz — Tue, 23 Jun 2026 10:11:25 +0000

I used Postman for years. It was the first thing I installed on every new laptop, the default answer to "how do I test this endpoint," and for a long time it was genuinely good at that job.

Then Postman killed free teams.
That wasn't what made me leave, but it did make me look at my setup again.
I realised something weird, why does testing an API running on my own machine require a cloud account?

What started bothering me

This isn't really about pricing. Plenty of people will tell you to just pay for Postman, or just use the free tier, or just wait for them to walk it back. That misses the point.

At first I didn't care. Then I started noticing things

Your data isn't really yours. Every request, every header, every auth token you've ever tested lives on Postman's infrastructure, not your machine. I went looking and found that Postman, like most cloud-first tools, collects telemetry by default. None of this is secret or hidden, it's in the privacy policy, but most of us never read it before clicking through setup.

You're testing a localhost API through someone else's cloud. This one actually bothered me once I noticed it. Hitting an endpoint running on my own laptop, through a tool that wants an internet connection and an account first, started to feel backwards.

Vendor lock-in is real, even with an export button. Postman lets you export collections as JSON. In practice, every export I've done has lost something: an OAuth flow, a binary body, a header that didn't quite map. "You can always export" is true and also not the same as actually owning your data.

What I looked at instead

I didn't jump straight to one alternative. A few options came up enough times in threads and comment sections that I actually tried them.

The first thing I tried was Bruno because that's what almost everyone recommends when somebody says they're leaving Postman.
I actually liked it. Requests live on disk, Git works properly, and I never felt like I was fighting the tool. For a while I thought my search was over.
The thing that eventually bothered me was the .bru format.
Maybe this won't matter to everyone, but one of the things I was trying to get away from was tool-specific formats. If I open a request file in a text editor, I want to immediately understand what's going on. With .bru files, I still felt tied to Bruno. 
I also spent some time with Yaak.
The UI is great. It's fast, lightweight, and honestly one of the nicest API clients I've used. If all I cared about was the experience of sending requests, I could have happily stayed there.
But I kept coming back to the same question:
"If this tool disappeared tomorrow, what happens to my API definitions?"
That's when I started paying a lot more attention to the actual files being stored on disk rather than the application around them.

Where I landed

I ended up on Voiden, and the reason is almost embarrassingly simple: it stores API requests as plain Markdown files.

Not a proprietary format that happens to live on disk. Actual Markdown. A .void file opens and reads fine in VS Code, in Vim, in GitHub's file viewer, with nothing installed beyond a text editor. That's the whole pitch, and it turned out to matter more to me than I expected.

A few things that made the actual switch from Postman easier than I assumed it would be:

It imports Postman collections directly, drag and drop, into native .void files. I lost less in that import than I lost moving between two different versions of Postman itself a few years back.
Requests are built from reusable blocks instead of static forms. Auth, headers, and params can be shared across requests instead of duplicated in every single one. The first time I updated one auth block and watched a dozen requests update with it, I understood why people make a big deal out of this.
No account, no login screen, nothing to set up before sending a request. The thing I do most often, test something on localhost, finally just works without a network round-trip to someone else's server first.
It's open source under Apache 2.0, which matters to me more after this whole experience than it did before. If a small team's funding model changes, I want my tooling to survive that, not vanish behind a new pricing page.

It's not the most established option here. Bruno has a much bigger community, and that's worth weighing honestly if community size and plugin ecosystem matter to you more than file format does. For me, the actual day-to-day difference, files I can read, share, and review like code, was worth being on a smaller, younger project.

The actual lesson here

I'm not saying Postman is bad.
It solved a lot of problems and I used it for years. 
I just realized I care more about local files, Git, Markdown and owning my data than I do about cloud workspaces.
That's what made me switch.

Download Voiden here: https://voiden.md/download
Repo, if you want to see how it actually works: https://github.com/VoidenHQ/voiden