DEV Community: Edwar Diaz

From Windsurf to Devin Desktop: my first impressions after migrating

Edwar Diaz — Thu, 04 Jun 2026 01:31:02 +0000

I did not expect this change to happen so suddenly.

After using Windsurf for more than a year, I migrated to Devin Desktop today. For me, this feels like a meaningful change because it is not just another version update: it is another rename in the history of the product. It started as Codeium, then became Windsurf, and now everything is being unified under the Devin brand.

At first, the change can feel a bit unexpected. But the more I look at it, the more it makes sense. Since earlier versions, especially around Windsurf 2.3.15, the direction was already visible: Devin Local and Devin Cloud were becoming more integrated into the editor experience, and the official Devin website already had several signs that the product was moving toward a more unified platform.

The migration experience

One thing I really liked is that after installing and opening Devin Desktop for the first time, it showed an option to migrate from Windsurf. That migration takes care of moving the previous experience without forcing you to start from scratch.

According to the official Devin Desktop FAQ, the migration preserves settings, extensions, workflows, skills, rules, and inherited Windsurf data. It also explains that Devin Desktop reads legacy paths like ~/.config/Windsurf/ and ~/.windsurf/extensions/, while writing new data to ~/.config/Devin/ and ~/.devin/extensions/.

Another important detail: the ~/.codeium/ structure does not change in this release. That matters because it contains user settings, MCP configuration, global workflows, skills, and CLI binaries related to Windsurf.

Not everyone had a perfect migration

From what I saw on X, some early users did not have a perfect migration. A few people reported missing extensions or other small issues after moving to Devin Desktop.

In my case, the experience was good: I installed Devin Desktop, opened the application, selected the migration option from Windsurf, and everything worked. I did not lose my extensions or important configuration.

My recommendation before migrating is simple: make a backup of your previous folders. Even if the official migration is designed to preserve everything, it is always better to keep a backup of paths like:

~/.config/Windsurf/
~/.windsurf/
~/.codeium/

Devin Desktop is no longer just "another editor"

The most interesting part for me is not the rename itself, but the direction of the product.

In the official announcement, Devin Desktop is presented as an Agent Command Center: a central place to manage local agents, cloud agents, sessions, spaces, and AI-assisted development work. The editor is still there, with the VS Code/Windsurf-like experience many of us already know, but the center of gravity now seems to be moving toward agent management.

I like this because it reflects what is already happening in day-to-day development: we are using more AI tools, more models, more CLIs, and more coding assistants. The problem is that we often end up with multiple terminals, sessions, editors, and subscriptions open at the same time.

Devin Desktop seems to be trying to solve that from a single place.

ACP and external coding assistants

Another point I found very interesting is the support for ACP (Agent Client Protocol).

According to the official Devin Desktop announcement, Devin Desktop can integrate with compatible agents through ACP. That opens the door to managing external assistants inside the same interface.

What makes this especially interesting is that the list of assistants you can connect is starting to cover many of the names we already use every day: Claude Code, Codex, Copilot CLI, GitHub Copilot, OpenCode, Kilo Code, Cursor, Qwen Code, and other compatible agents. Not all of them will behave exactly the same, but the direction is clear: Devin Desktop wants to become a coordination layer for assistants, not just another editor.

In my case, I tested it with Copilot CLI, and it was surprising to see Devin Desktop pick up sessions I already had and resume them from there. That feels powerful because I do not need to constantly jump between VS Code, Cursor, separate terminals, or different applications to manage each assistant.

The idea of having one place to coordinate agents and access the models available through different subscriptions feels like a natural evolution of AI-assisted development.

Devin CLI is also good news

Another thing that excites me is that there is now a CLI experience around Devin.

This puts it in the same direction as other tools that are becoming common in developer workflows, such as Gemini CLI, Antigravity CLI, Copilot CLI, and other terminal-based assistants.

Having a CLI matters because you do not always want to open a full editor. Sometimes you want something lighter that you can use from a terminal, inside a server, or even on a VPS to work remotely without depending on a full graphical interface.

It does not necessarily replace Devin Cloud, but it opens more possibilities for people who prefer a more controlled or terminal-first workflow.

My first impression

My first impression is positive.

Yes, the rename can feel unexpected, especially because we already went from Codeium to Windsurf and now from Windsurf to Devin. But this time the change seems to have a clear reason: unify the ecosystem under one brand and turn the editor into a broader platform for managing agents.

What I liked the most:

The migration from Windsurf appeared directly when opening Devin Desktop.
I did not lose my extensions or important settings.
The product keeps the editor experience I already knew.
Devin Local, Devin Cloud, and Devin CLI are starting to feel like parts of the same platform.
ACP support could turn Devin Desktop into a real hub for managing different assistants.

I still want to keep testing it more deeply, but at first glance I like how the product is evolving.

To me, Devin Desktop no longer feels like just the new name for Windsurf. It feels like the beginning of a stage where the editor becomes the place where we coordinate multiple agents, models, and workflows.

And honestly, I find that pretty exciting.

Useful links

Official Devin Desktop FAQ: https://docs.devin.ai/desktop/devin-desktop-faq
Devin Desktop changelog: https://docs.devin.ai/desktop/changelog
Official announcement: https://devin.ai/blog/windsurf-is-now-devin-desktop

From an Abandoned Angular Traceroute App to an Interactive Internet Route Lab

Edwar Diaz — Tue, 02 Jun 2026 19:15:35 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Uni Route is an educational web app for learning how messages travel through the internet.

The idea started in 2021, while I was at university taking a computer networks class. I wanted a way to make traceroute easier to understand: instead of reading a long terminal output line by line, students could see the hops, latency, approximate geographic locations, and the path that a packet might take when reaching a domain or IP address.

The first version was built with Angular, based on the knowledge I had from my first work experience at the time. It supported two learning modes:

Local tracing: users could run tracert or traceroute on their own machine and paste the result.
Global tracing: users could use public looking glass providers to run traceroute from servers in different continents and compare how internet traffic changes depending on the origin.

After a few years, the project became abandoned. Some public traceroute providers stopped working, the IP information API no longer responded as expected, dependencies aged, and the UI felt more like a student prototype than a tool I could confidently share with other learners.

For this challenge, I revived it as a modern static web app and turned it into a more complete learning experience:

Rebuilt the active app with React, TypeScript, and Vite.
Preserved the legacy Angular version in the repository for historical reference.
Added a responsive and modern interface with shadcn/ui.
Replaced the old Google Maps / Angular Google Maps approach with mapcn + MapLibre.
Added latency charts with Recharts.
Added map playback, where the route is revealed hop by hop and the animation speed is scaled from latency so students can feel the difference between faster and slower hops.
Added parser support for Windows and Unix-like traceroute output.
Added IP classification before geolocation, so private, reserved, loopback, documentation, multicast, and other non-public ranges do not waste API calls.
Added modern geolocation fallback support with IPinfo, ipgeolocation.io, and ipapi.co.
Added English and Spanish i18n directly in the static app.
Added documentation, unit tests, GitHub Actions, and GitHub Pages deployment.

The goal is not to create a network diagnostic tool for experts. The goal is to help students and self-learners understand the journey: "When I send a message through the internet, what are some of the networks it may cross before it reaches the destination?"

Demo

Live app: https://botoom.github.io/route/

Repository: https://github.com/BOTOOM/route

Before: legacy Angular version

If the animation does not play in the DEV preview, open the GIF directly: legacy Angular demo.

After: modern Uni Route landing page

If the animation does not play in the DEV preview, open the GIF directly: modern React demo.

The Comeback Story

The original version solved a real learning problem, but it was frozen in time.

In 2021, using Angular made sense for me because it matched the tools I was learning professionally. But trying to upgrade that stack all the way from the old dependency versions to a 2026-ready application would have meant fighting years of breaking changes before even improving the product.

I had already tried to upgrade it once and hit the expected problem: old packages, deprecated services, broken APIs, and a lot of effort spent only to keep the same experience alive.

So this time I made a different decision: keep the educational purpose, keep the legacy code as history, but rebuild the active app from the ground up.

Before	After
Angular app from 2021	React + TypeScript + Vite static app
Old dependency tree	Modern pnpm-based project
Google Maps / Angular Google Maps	mapcn + MapLibre
Harder to maintain UI	Responsive shadcn/ui interface
Spanish-only user flow	English and Spanish language switcher
Deprecated or unreliable external services	Curated looking glass tools and geolocation fallback providers
Mostly text-based output interpretation	Tables, map, chart, and latency-based playback
Manual/old deployment style	GitHub Actions deployment to GitHub Pages
Abandoned university project	Shareable learning tool for students and self-learners

One of the biggest product decisions was not to execute traceroute directly from the browser. That would be amazing, but browsers intentionally do not allow web pages to run native network diagnostic commands on a user's operating system. Instead, Uni Route teaches the safe and realistic flow:

Copy the suggested command for Windows, Linux, or macOS.
Run it in your own terminal.
Paste the complete result into the app.
Explore the route visually.

For global routes, the app also avoids unreliable iframe embedding. Many public looking glass sites block embedding with security headers, and that is reasonable. Uni Route opens those tools externally, explains how to use them, and then normalizes the pasted result locally.

The most satisfying improvement is the map playback. A static line on a map is useful, but watching the path appear hop by hop makes the concept easier to teach. Latency becomes visible instead of just numeric: slower hops take longer in the animation, making the relationship between network delay and route progression more intuitive.

I also wanted the app to be responsible with geolocation APIs. Not every hop has a public IP, and not every IP should be sent to an external provider. The new version classifies private and reserved ranges first, then only calls a provider when a public IP can reasonably be geolocated. This makes the app more respectful of free-tier limits and more accurate about what it can and cannot know.

My Experience with GitHub Copilot

GitHub Copilot helped me treat the revival like a real migration instead of a quick redesign.

I used Copilot CLI as a coding partner to:

Audit the old project and decide whether an Angular upgrade or a full React rebuild made more sense.
Plan the migration around GitHub Pages constraints.
Move the legacy Angular app into a reference folder while creating a new active application.
Build a shared traceroute parsing domain for Windows and Unix-like outputs.
Add tests for parser behavior, private IP classification, geolocation states, and route playback timing.
Refactor repeated page logic into shared hooks and components.
Review the UI with Chrome DevTools across desktop and mobile sizes.
Improve contrast, copy, navigation, and user-facing explanations.
Add bilingual English/Spanish i18n without changing the GitHub Pages route structure.
Write documentation for setup, environment variables, local/global usage, and deployment.

Copilot was especially useful for the parts that required both memory and consistency. For example, when adding i18n, it helped identify hardcoded text across pages, shared components, domain helpers, map popups, chart labels, and error states. Instead of translating only the obvious UI, I refactored domain messages into structured codes so the parser does not return Spanish strings directly.

It also helped me avoid modernizing only the surface. The final project is not just "the same app with newer colors." It now has a clearer architecture, tests, deployment automation, better provider handling, safer API usage, and a more educational experience.

What I Learned

Finishing an old project is different from starting a new one.

When a project has personal history, it is tempting to preserve everything exactly as it was. But finishing it sometimes means protecting the original intention while letting go of the old implementation.

In this case, the intention was always the same: help people understand how internet communication travels across networks.

The implementation changed completely.

That made the project easier to maintain, easier to deploy, and more useful for the students and self-learners I originally wanted to help.

Transparency

The modern version keeps the legacy app in the repository for reference, but the active application is a full refactor built with React, TypeScript, Vite, shadcn/ui, mapcn, MapLibre, Recharts, Zod, Vitest, and GitHub Actions.

Map visualization uses MapLibre and map tiles with their required attributions. External looking glass services remain external resources, and Uni Route guides users to use them respectfully.

👤 Author

Edwar Diaz
DEV: @botoom
GitHub: https://github.com/BOTOOM

Why Ignoring Token Costs Can Kill Your AI Product (and How to Fix It)

Edwar Diaz — Wed, 25 Mar 2026 23:21:31 +0000

When building applications powered by LLMs from providers like OpenAI, Google, or Mistral AI, there’s a detail that often gets overlooked:

token cost.

At small scale, it’s barely noticeable. But once your application starts getting real usage, token consumption grows quickly—and if you’re not measuring it, you can easily end up with a feature that costs more than the value it delivers.

The real problem with token usage

Every interaction with an LLM typically involves:

input tokens (your prompt)
output tokens (the model’s response)
sometimes cache tokens, depending on the provider

Individually, these costs are small. But combined with:

longer prompts
verbose outputs
high request volume

they scale faster than most people expect.

And there’s an important nuance here:

Not all models cost the same, and not all tasks require the same type of model.

Model selection is a cost decision

It’s common to default to the most capable model available, but that’s rarely the most efficient choice.

For example:

you don’t need a reasoning-heavy model for simple transformations
you don’t need multimodal capabilities if you're only processing text
many providers offer smaller or optimized variants (mini, nano, etc.)

Choosing the right model affects:

cost
latency
throughput

This is where cost awareness becomes part of system design, not just an afterthought.

Why you should estimate costs early

If you’re building anything beyond a prototype, you should be able to answer:

how much does each request cost?
what is the expected daily usage?
what does that translate to monthly or yearly?

Frameworks like LangChain, Azure AI Foundry, or AWS Bedrock usually provide token usage metrics (input/output/cache). That’s helpful, but incomplete.

In many cases, you still need to map those numbers to actual pricing yourself.

Calculating token costs

If you already have token counts, the calculation is straightforward:

cost = (input_tokens / 1000 * input_price) + (output_tokens / 1000 * output_price)

The challenge is when you don’t have those token counts directly.

In that case, you can approximate them by tokenizing:

the input text you send
the expected output

This gives you a reasonable baseline for estimation.

Tools that make this easier

There are a couple of tools that simplify this process.

LLM Prices

https://www.llm-prices.com/

This tool lets you:

input token counts
select specific models
estimate cost per request
define custom pricing if needed

Token Budget Calculator

https://tokenbudget.edwardiaz.dev/

A more complete approach is to use a tool that combines token estimation with cost projection.

With this kind of platform, you can:

paste input and output text
automatically estimate token usage
calculate:
- cost per request
- daily cost
- monthly cost
define request frequency (per day / per month)

It also allows you to:

compare across a large set of models (100+)
filter by provider or capabilities
sort by cost efficiency
get a recommendation for the most cost-effective model

In addition, there is API support, which makes it possible to integrate cost estimation directly into your own systems. This is especially useful if you want to:

track cost per request internally
build usage dashboards
enforce budgets or limits at the application level

Planning for scale

Once you start tracking token usage and costs, you can:

forecast infrastructure expenses
define budgets
prevent unexpected spikes
choose models more intentionally

This is what turns an experimental feature into something sustainable.

Tokens also impact rate limits

Cost is only one side of the problem.

Many providers enforce limits based on tokens, such as tokens per minute. If your prompts or outputs are too large, you may run into:

throttling
increased latency
failed requests under load

Reducing token usage helps both with cost and system stability.

What comes next

Understanding cost is the first step. The next one is optimization.

In a follow-up post, I’ll go deeper into:

prompt optimization techniques
reducing token usage without losing quality
practical ways to make LLM integrations more efficient

Final thoughts

If you’re not measuring token usage, you’re making decisions without visibility.

Tracking tokens, estimating costs, and choosing the right model are not optional if you care about building scalable AI systems.

It’s a small investment early on that can save you a lot later.

I Built a Context-Aware AI Browser Mentor Powered by GitHub Copilot CLI

Edwar Diaz — Fri, 13 Feb 2026 20:58:37 +0000

This is a submission for the GitHub Copilot CLI Challenge

I Built a Context-Aware AI Browser Mentor Powered by GitHub Copilot CLI

What if GitHub Copilot CLI could see what you see, understand your context, and help you without breaking your workflow?

That question led me to build DevMentorAI — a browser extension that transforms Copilot CLI into a real-time AI mentor inside your browser.

Built entirely with GitHub Copilot CLI — from extension to backend to landing page to release workflows.

🧠 What I Built

DevMentorAI is a context-aware AI assistant that lives inside your browser and understands:

What page you're on
What text you've selected
What you're trying to write
What you're troubleshooting
What you want to improve

Instead of copying context into prompts, DevMentorAI sends context automatically to Copilot CLI.

✨ Core capabilities

📄 Context capture from the current page
📸 Screenshot understanding
✍️ Grammar correction & rewriting
🔄 Replace text directly inside inputs (emails, chats, forms)
🛠 Works for development, DevOps, writing, learning, and more

No framework lock-in. No domain restriction. Just AI assistance anywhere.

🎥 Demo

🌐 Project Links

Landing page
https://devmentorai.edwardiaz.dev/
Installation Guide
https://devmentorai.edwardiaz.dev/installation
GitHub Repository
https://github.com/BOTOOM/devmentorai
Backend NPX Package
https://www.npmjs.com/package/devmentorai-server
Extension Downloads
https://github.com/BOTOOM/devmentorai/releases

▶️ Full Walkthrough

📺 Video:
.

⚡ Feature Highlights

Context-aware assistance

Grammar correction replacing text directly in inputs

Installation from zero using NPX backend

🏗 How It Works

Extension captures page context + optional screenshot
Sends to local backend
Backend communicates with Copilot CLI
AI response returned
Optional direct replacement into page inputs

This creates a seamless AI workflow without leaving the browser.

🔐 Privacy & Security

DevMentorAI runs locally and respects user control:

No credentials required
Uses your Copilot CLI session
Backend runs locally via NPX
Users control what context is shared

🤖 My Experience with GitHub Copilot CLI

Using GitHub Copilot CLI was both enriching and fun. I discovered capabilities far beyond what I previously experienced using Copilot inside editors.

I started with little experience using Copilot CLI, but by following the official documentation and experimenting with slash commands, I learned how to:

Create custom agents
Implement skills (including WXT extension knowledge)
Use advanced TypeScript skills
Plan and execute complex builds through the CLI

One of the most impressive features was agent-based planning mode. Copilot could:

Plan the entire feature
Execute it
Iterate quickly

All from the terminal — lightweight and extremely fast.

🔍 What surprised me most

Copilot CLI enabled building an entire full-stack project:
- Browser extension
- Backend server
- Landing page
- Release workflows
- NPX package
The planning file memory system was incredibly powerful.

🧪 Workflow I Discovered

As sessions grew large, context sometimes became less effective. I learned to:

Start a new session per major feature
Refine functionality within that session
Commit once complete

This dramatically improved results.

🛠 Problem Solving with Copilot

Occasionally, Copilot would get stuck in a loop trying the same solution. When that happened, guiding it to consider alternative perspectives helped it resolve issues successfully.

🎯 Why This Matters

DevMentorAI demonstrates a new paradigm:

AI assistance that adapts to your context instead of forcing you to adapt to it.

GitHub Copilot CLI made this possible.

👤 Author

Edwar Diaz
DEV: @botoom
GitHub: https://github.com/BOTOOM