DEV Community: Emanuele Bartolesi

Seasoned Developer Advice after 25 years in IT

Emanuele Bartolesi — Fri, 09 Oct 2026 10:09:24 +0000

I've now been working in IT for exactly 25 years.

My impostor syndrome is still very much present. Writing an article called "seasoned developer advice" makes me hesitate a little. There is always something I don't know, a technology I haven't used, or someone who understands a subject much better than I do.

But after 25 years, I think I can start sharing a few thoughts.

These are opinions about how to work, build software, and stay in this profession. Take what helps, question the rest, and adapt it to the team and situation you have in front of you.

Ask the question you are embarrassed to ask

If a requirement is unclear, ask about it before you turn it into code.

What does "active customer" mean? Who can approve this operation? What should happen when the external service is unavailable? These questions can feel basic, especially when everyone else in the meeting appears to understand everything.

I would rather admit that I don't understand a business rule than build an entire feature around my interpretation of it. The same applies to an unfamiliar piece of code. Ask someone to walk you through it, then explain it back in your own words.
This step is even easier with AI nowdays, but asking a colleague still an easier thing to understand maybe something that AI doesn't know behind a business choice or something like that.

Experience should make it easier to say "I don't know yet." I still have to remind myself of that.

Give coordination an owner

Developers need time to develop. If the lead developer also has to chase every dependency, negotiate the scope, update stakeholders, and organize the release, account for that work in the plan.

On a larger project, I would want someone explicitly responsible for coordination. That might be a project manager, a delivery lead, or another role that fits the organization. On a small team, it may be a shared responsibility, but the decisions still need an owner.

A date written in a ticket does not resolve a blocked dependency. Someone has to talk to the other team, agree on what happens next, and adjust the plan when the answer changes.

When estimating a feature, include that work. A week full of meetings leaves less time for implementation than a week with clear decisions and uninterrupted time.
Actually we are still doing this mistake to "overmeetings" but I hope it will change soon or later.

Make meetings earn their place

I don't think every team needs the same meeting schedule.

A short conversation with the person who understands the business process can be useful while a feature is taking shape. Showing a working screen may reveal that the approval flow is wrong before you spend another week building it.

A daily meeting where everyone reads out tickets already visible on the board is harder to justify.

For me, a useful meeting resolves a question, exposes a dependency, or produces a decision. If an update can be written down and read when people have time, try that. If a disagreement needs a conversation, have the conversation.

Record the outcome where the work lives. A decision made on a call is easy to miss if the developer implementing it was somewhere else.

Write code for the person who has to change it

Readable code matters most when someone needs to fix it under pressure.

I prefer a method with a clear name and an obvious flow over an abstraction that takes three files to understand. There are good reasons for abstraction, but I want to know which problem it solves before adding another layer.

The same caution applies to shared code. Two methods that look similar may represent business rules that will evolve independently. Putting them in one common library creates a relationship you will have to maintain.

Extract code when the shared behavior is understood. If several applications depend on it, think about compatibility, ownership, and how updates will reach them. Publishing a package creates a responsibility beyond the original project.
Still a valid advice also for we use a lot of AI for writing code.
We need anywayt to review what is written to understand if we can read and understand the code anyway.

Leave the explanation you would want to find later

Code can show what happens without explaining why it must happen that way.

A comment explaining that a file format is required by an external system is useful. A comment saying that the next line increments a counter usually adds little.

I want documentation that helps someone do the work: how to run the application, which configuration is needed, how to execute the tests, and what to check when a deployment fails. Keep those instructions close to the repository and update them when the workflow changes.

There is also value in a short decision note. If the team rejected a queue because the current workload did not justify operating one, record that reasoning and the condition that would make you reconsider.

AI can help draft these explanations. Check them against the code and the actual setup before treating them as documentation. A plausible installation guide that cannot be followed is another problem for the next developer to debug.

Think about the application after it leaves your machine

A feature needs more than a successful local run.

Before shipping, I want to know how we will recognize a failure and what we can do about it. A useful log entry should give enough context to trace an operation without exposing credentials or customer data. An exception with no context can leave you searching through several unrelated requests.

Be deliberate about tests, too. If a feature moves data between customers, test that boundary. If it sends notifications, consider what happens when an operation is repeated. The failure case should influence the test, rather than becoming an afterthought once the happy path passes.

And discuss recovery. Reverting code will not undo every effect of that code. A database change or an email already sent needs its own consideration.

These questions belong in development, while you can still change the design without an incident forcing the decision.

Review the code without making it personal

Having someone question your implementation can be uncomfortable. With impostor syndrome already in the room, a review comment can feel larger than it is.

Try to keep the conversation specific. Explain which behavior concerns you, point to the assumption, and suggest a way to verify it. "What happens if this request is retried?" is a useful opening for a discussion.

As the author, explain your reasoning and be willing to change it. As the reviewer, distinguish a defect from a preference. A naming choice does not deserve the same treatment as a missing authorization check.

I also like reviews small enough that a colleague can understand the change properly. If a bug fix includes a folder reorganization and a new framework, consider separating those decisions.

The goal is a change the team understands well enough to maintain. Being the person who wins the argument contributes very little to that.

Make maintenance part of the plan

Framework upgrades, dependency updates, and refactoring need time on the calendar.

It is easy to postpone them because the application still works. When you do, be explicit about what you are accepting and when you will revisit it. Otherwise, postponement becomes the plan by default.

A refactoring ticket should name the problem it will address. Perhaps adding a validation rule currently requires changing five different places. That gives the team a concrete improvement to assess and a way to tell whether the work helped.

I would apply the same discipline to modernization. Explain what the upgrade enables, which risk it addresses, and how you will validate the change. The age of a framework alone is a weak explanation for rewriting a working application.

Keep learning through things you can use

You cannot study every language, framework, cloud service, and AI tool that appears.

Choose something relevant and spend enough time with it to understand where it helps. Build a small application, add a feature to a side project, or investigate a part of your production system that you usually avoid.

A course can give you structure. Applying the lesson gives you questions the course may never have covered.

I would also leave room to learn from colleagues. Someone with less experience may know a tool or technique you have never used. Twenty-five years in IT should not make that conversation awkward.

Your main language is useful expertise. Stay curious about the parts around it: the database query, the deployment pipeline, or the interface the user has to navigate. A problem does not stop at the boundary of your preferred stack.

Choose tools you can trust and understand

Use an editor that lets you work comfortably. Learn its debugger, navigation, and refactoring tools before assuming a different editor will solve your frustration.

I would take the same approach to AI. Start with work where you can judge the result: exploring unfamiliar code, preparing a first test draft, or checking an implementation for missed cases.

Read the output and run the checks. When the tool proposes a design, ask what assumptions it made. You remain responsible for the change you submit.

Trying another tool or model can be useful when it answers a specific question about your workflow. You don't need a collection of subscriptions just to feel current.

Build a way of working you can keep doing

After 25 years, I want my advice to include what happens away from the keyboard.

Take breaks. Get up, walk around, do sports, and give yourself permission to stop staring at the same problem. If you are stuck, ask for help rather than making another exhausted hour the price of proving that you can solve it alone.

Talk to teammates sometimes without a ticket as the agenda. It is easier to ask someone a difficult question when your only interaction with them has not been a review disagreement.

And keep something outside work. There will always be another release, article, framework, or project. Closing the laptop does not mean you stopped caring about your profession.

I still don't feel that 25 years gives me an answer to everything. It does give me enough reason to share these thoughts, even while the impostor syndrome tells me to wait a little longer.

If you enjoyed this blog post and want to learn more about C# development, you might be interested in subscribing to my bi-weekly newsletter called Dev Dispatch. By subscribing, you will get access to exclusive content, tips, and tricks, as well as updates on the latest news and trends in the development world. You will also be able to interact with me, and share your feedback and suggestions. To subscribe, simply navigate to https://buttondown.email/kasuken?tag=devto, enter your email address and click on the Subscribe button. You can unsubscribe at any time. Thank you for your support!

My Windows 11 Laptop Was Struggling with Claude and Codex. Defender Exclusions Helped.

Emanuele Bartolesi — Tue, 06 Oct 2026 15:01:47 +0000

My Windows 11 laptop sometimes struggled while I was working with Claude and Codex or GitHub Copilot. CPU usage was high, and the fans were running like crazy.
It means also that my battery runs out in 1 hour and 30 minutes 😀

When I checked Task Manager, Antimalware Service Executable stood out. Disk usage was around 90%, with heavy CPU activity as well, while the two tools were running.

That process belongs to Microsoft Defender Antivirus. You can find it as Antimalware Service Executable in Task Manager's Processes tab, or MsMpEng.exe in the Details tab. Microsoft documents both names here.

I suspected Defender's scanning of the tools' local folders was contributing to the slowdown. Adding folder exclusions solved the problem I was seeing on my laptop. This is my experience with one machine, rather than proof that Claude or Codex always causes this behavior.

The folders I excluded

These are the four entries in my Windows Security exclusion list:

C:\Users\barto\.claude
C:\Users\barto\.codex
C:\Users\barto\.copilot
C:\Users\barto\.github-copilot-cli

The last two entries are for my Copilot tooling. Their presence in this list does not establish that they contributed to the Claude and Codex slowdown.

There is a security tradeoff: a folder exclusion removes Defender antivirus scanning coverage for that folder and its contents. Files placed there later are also covered by the exclusion. Trusting the tool does not guarantee that every file it writes or downloads is safe. Microsoft explains the exclusion options and risks.

Treat this list as a record of my setup. For your machine, identify the affected folder first and keep any exclusion as narrow as possible.

How to add a folder exclusion in Windows 11

Open Start, search for Windows Security, and open it.
Select Virus & threat protection.
Under Virus & threat protection settings, select Manage settings.
Scroll to Exclusions and select Add or remove exclusions. Approve the administrator prompt if it appears.
Select Add an exclusion, then Folder.
Browse to the folder you want to exclude, for example C:\Users\YOUR_USERNAME\.claude, and select Select Folder. Replace YOUR_USERNAME with your Windows user folder name.
Confirm that the folder appears in the exclusion list. Repeat for other folders only where needed.

These steps follow Microsoft's Windows Security guidance. On a company-managed laptop, your IT team may control these settings.

Moving to European Digital Services, One Decision at a Time

Emanuele Bartolesi — Thu, 24 Sep 2026 16:13:19 +0000

My move to European digital services includes Proton, Qwant, and DeepL. When it came to Notion, I went further and replaced it with Brainy, the product I built for my own notes, projects, and tasks.

That sounds like a migration, but the word creates the wrong expectation. I did not spend a weekend exporting every account, cancelling every subscription, and declaring myself independent from American technology on Monday morning.

I am changing one decision at a time.

I do not want a US provider to be the automatic answer for every digital need simply because it is the most visible option. Europe has credible products. Some are good enough to compete directly, and some fit my needs better. That does not mean I will replace a working service because a company has the wrong flag beside its logo.

Proton made the change visible

Proton is where the migration became a system rather than a few unrelated experiments.

Proton Mail replaced my previous email setup. Proton VPN replaced NordVPN. Proton Pass replaced NordPass. I also use Lumo for selected private AI conversations rather than treating every chat as suitable for any general-purpose assistant.

The immediate benefit was consolidation. One privacy-focused Swiss ecosystem replaced several separate accounts and subscriptions. I did not need to find a different European company for email, another for passwords, and another for the VPN before making progress.

There is an obvious trade-off: consolidation reduces vendor sprawl while increasing dependence on Proton. Moving three services into one company is not diversification. I still prefer the current setup, but it would be dishonest to describe concentration as independence.

Lumo has a similar boundary. Proton says stored conversations use zero-access encryption, which is why it has a place in my private workflow. I do not pretend that it replaces every AI service or every model. The choice depends on the conversation and the job I need to complete.
For the moment I am using Lumo only for questions related my health and other sensitive information.

The corporate map is more complicated than the logos

Once I started checking where services were based, the simple Europe-versus-USA story stopped working.

NordVPN is not an American service. NordVPN says it is based in and operates under Panama's jurisdiction, while its parent company, Nord Security, is based in the Netherlands. Moving to Proton VPN is a Panama-to-Switzerland change at the service-jurisdiction level, with a European parent company also involved in the old setup.

WeTransfer is European too. WeTransfer B.V. is based in Amsterdam, so my switch to SwissTransfer was not about escaping an American company. It was about the product.

For my file-sharing needs, SwissTransfer has a privacy model I prefer and a much more useful free allowance for large files. Infomaniak says SwissTransfer accepts transfers up to 50 GB, stores the files in Switzerland, supports password protection, and deletes the files after the transfer period. WeTransfer's current free-account documentation describes an allowance of up to ten transfers or 3 GB in total over a rolling 30-day period.

That is a concrete difference. I am not using SwissTransfer because the landing page has a Swiss flag. I am using it because privacy and larger transfers matter in this workflow.

This distinction changed how I evaluate alternatives. I now look separately at the service jurisdiction, parent company, data location, underlying infrastructure, business model, portability, and actual product quality. Those facts do not always point to the same country.

Some changes need almost no migration

Qwant and DeepL were easier decisions.

I use Qwant for search. Qwant is a French company, and its current privacy policy says it does not use targeted advertising or retain search history by default. Search is also easy to test: use it, compare the results, and keep another engine available when it does not find what you need.

I use DeepL for translation. It was founded in Cologne, Germany, and it is a good example of why the word "alternative" can be misleading. I do not need to treat a European translation service as a political compromise. I can use it because it does the work.

Neither choice required a dramatic data migration. There was no archive to restructure and no DNS record that could break a production system. They simply became part of the workflow.

New domains are another low-risk entry point. I now use Infomaniak Domains instead of GoDaddy for new registrations. I am not forcing every existing domain through an immediate transfer. When I need a new domain, the new default is a Swiss, ICANN-accredited registrar. That is progress without creating unnecessary operational risk.

DNS is an even quieter change. I use Quad9 as my resolver. Quad9 is a Swiss nonprofit, and its documentation says the recommended 9.9.9.9 service blocks lookups for malicious domains without logging end-user IP addresses. It also supports encrypted DNS protocols. This is closer to changing an infrastructure setting than migrating an account, but it moves a foundational part of normal browsing away from whichever resolver happened to be the default.

Replacing Notion meant building the alternative

Notion was different because a knowledge system accumulates structure as well as data. Notes connect to projects, tasks carry context, and the way information is captured affects whether it becomes useful work or remains another page in an archive.

I replaced Notion with Brainy, my own product.

Brainy is a practical second brain organized around the PARA method. It captures notes and ideas, connects them to projects and tasks, and focuses on turning stored knowledge into action. The goal was not to reproduce every Notion feature. It was to build a workflow that matches how I move from an idea to a project, from a project to the next task, and from planning to today's work.

Owning the product gives me control over that workflow, the data model, portability, and the roadmap, but it also gives me the maintenance work. I own the deployments, bugs, database changes, security decisions, and migration logic.

This is the clearest reason the entire transition cannot happen in two hours. Replacing a service can mean changing a setting or moving years of habits and information. In this case, it also meant building and operating a product.

For the moment, Brainy is free and you can create your own account here: www.brainy-me.com.

Sometimes the correct migration is no migration

I still use Spotify.

The reason is simple: Spotify is already European and it works for me. Its consumer terms identify Spotify AB in Stockholm, Sweden. Replacing it with another service only to increase the number of changed logos would add work without moving me closer to the actual goal.

A useful migration should leave some rows unchanged. Otherwise the process is driven by ideology rather than requirements.

Here is the current map:

Workflow	Current choice	Decision
Email	Proton Mail	Moved into the Proton ecosystem
VPN	Proton VPN	Replaced NordVPN
Passwords	Proton Pass	Replaced NordPass
Private AI chats	Lumo	Used selectively for private conversations
Large file transfers	SwissTransfer	Chosen for privacy and transfers up to 50 GB
New domain registrations	Infomaniak	Replaced GoDaddy as the default for new domains
DNS	Quad9	Uses a Swiss nonprofit resolver focused on privacy and security
Search	Qwant	In active use
Translation	DeepL	In active use
Knowledge and planning	Brainy	Replaced Notion with my own product
Music	Spotify	Kept because the European service already fits

The process I use before changing a service

The European Alternatives directory is useful for discovery, but inclusion in a directory is the beginning of the evaluation, not the conclusion.

Before changing a service, I work through a small set of questions:

What job does the current product perform?
Which features are genuinely non-negotiable, and which ones are habits?
Where is the service legally based, where is the data processed, and which external platforms does it still depend on?
Can I export the data in a useful format and move again later?
Can I run the old and new services in parallel before cancelling anything?
Is the alternative better, equivalent, or merely acceptable for this specific job?

That last question matters. I am willing to accept a small difference when privacy, control, or supporting a European provider makes the trade worthwhile. I am not willing to ignore a product that fails the workflow simply because it is European.

The safest changes happen at natural decision points. Register the next domain with a different registrar. Test another search engine without removing the old one. Import a copy of a password vault before cancelling the existing subscription. Send the next large file with a service that supports the size you need.

Moving all of them at once would turn a preference into an outage plan.

Change the next decision

I still use services from American companies, and I expect that to continue. Work, collaboration, audience, and network effects do not disappear because a European alternative exists.

The difference is that I no longer want the American option to win by default. When a subscription renews, a new need appears, or a current product creates friction, I check what exists in Europe before repeating the old decision.

The outcomes vary. A European product may be good enough, SwissTransfer may be better for large files, or Spotify may already be the European answer. Brainy sits at the other end of the range because I had to build the alternative around the workflow I wanted.

This process does not need a dramatic finish. The next decision is enough.

Thanks for reading this post, I hope you found it interesting!

Feel free to follow me to get notified when new articles are out 🙂

Emanuele BartolesiFollow

🏆 Microsoft MVP (12x) & GitHub Star (4x) ⭐ 👨‍🎓 LinkedIn Technical Instructor 🎓

Fixing “Your organization has deleted this device” Without Reconnecting Everything

Emanuele Bartolesi — Tue, 19 May 2026 06:49:19 +0000

For two days, my company laptop kept showing this error:

Your organization has deleted this device.

To fix this, contact your system administrator and provide error code 700003.

At first, it looked like the only option was to disconnect and reconnect my work account from Windows.

I really did not want to do that.

Removing and adding the account again can work, but it is annoying. You may need to re-authenticate apps, reconnect services, and deal with device registration again.

Luckily, there is a better option.

The command that fixed it

Open a terminal and run:

dsregcmd /forcerecovery

After running the command, Windows asks you to sign in again with your work account.

That is it.

In my case, after logging in again, everything started working without disconnecting all accounts manually.

It saved me a lot of wasted time.

When this helps

This can help when:

You get error code 700003
Windows says your organization deleted the device
Your device is Microsoft Entra joined
You want to avoid fully disconnecting and reconnecting your work account

A small warning

This is not magic.

If your device was intentionally removed by IT, or your company uses Intune, Autopilot, Conditional Access, or Hybrid Join, talk to your administrator first.

🔖 Stay ahead of the dev curve
I created a Curated RSS Feed Bundle for Web Developers — a hand-picked OPML file of the best dev blogs and websites on the internet.
💡 Just download, import into your favorite RSS reader (like Feedly or NetNewsWire), and enjoy fresh insights every day.

👉 Grab it on Gumroad — stay sharp without the noise.

Stop Coding Through Remote Desktop. Use VS Code Remote Tunnels Instead

Emanuele Bartolesi — Wed, 15 Apr 2026 07:10:40 +0000

There is a pattern I keep seeing with customer environments.

You get access to a VM for development. The code stays there. The dependencies are already there. The network access is there too. On paper, it looks fine.

Then reality starts.

You are expected to work through Remote Desktop, as if software development were the same thing as clicking around a server. It is not. Remote Desktop is tolerable for admin work. For actual coding, it is a bad experience. The editor feels disconnected from your normal workflow. Shortcuts feel wrong. Terminals are awkward. Moving between tools is slower than it should be. You are technically “inside” the environment, but you are not really productive.

In my case, there was another constraint. I could not even sign into VS Code on the customer VM with my own account, which meant no normal setup, no synced configuration, and no easy way to work the way I usually do.

That is where VS Code Remote Tunnels becomes the right solution.

The real-world scenario

Instead of living inside a remote desktop session, you expose the development environment through a secure tunnel and connect to it from your local VS Code. The code stays on the customer VM. The execution stays on the customer VM. But the editor experience comes back to your own machine, where you can actually work properly.

Remote Tunnels is the answer I would pick for that every time.

What VS Code Remote Tunnels actually does

VS Code Remote Tunnels gives you a way to connect to a remote machine from VS Code without setting up SSH access. The official model is simple: you create a secure tunnel from the remote machine, and then connect to it from a VS Code client somewhere else. Microsoft’s documentation describes it as connecting to a remote machine, such as a desktop or VM, through a secure tunnel using Microsoft dev tunnels.

That matters because it changes where the work happens.

The code stays on the remote VM. The terminals run on the remote VM. Debugging happens against the remote VM. VS Code installs its server-side components on that machine, and your local VS Code becomes the client for that remote environment.

Another practical point is that SSH is not required. That is one of the biggest advantages in customer environments, because SSH is often blocked, restricted, or simply not part of the approved setup. Remote Tunnels gives you another path that still keeps the work inside the target machine.

You can then connect in two main ways. You can use local desktop VS Code with the Remote - Tunnels extension, or you can connect through VS Code for the Web in the browser. That browser path is useful when you need access from a locked-down device, although the desktop client is usually the better experience.

There is one important limitation worth stating clearly. The VS Code Server used behind this model is designed for a single user, not as a shared multi-user development service. Microsoft also states that hosting the VS Code Server as a service is not allowed. So this is a personal remote development setup, not a team-hosted IDE platform.

That is why Remote Tunnels fits this customer scenario so well. It gives you remote development, not remote desktop. That is the real difference.

Why it fits this customer use case

This is exactly the kind of setup where Remote Tunnels is the right answer.

The customer wants the work to stay inside their environment. That is reasonable. The code, dependencies, network access, and internal services are already on the VM. Moving everything to a local machine would create more friction, more approvals, and in some cases more risk.

At the same time, working through Remote Desktop is a bad trade.

How to set it up

The setup is surprisingly simple. That is part of why this works so well in customer environments.

First of all, you need to download VS Code Server.
You can download it directly from the official Download page of Visual Studio Code website (https://code.visualstudio.com/Download)

From this page, as you can see in the image above, you can select your OS and your CPU family.
You can also use VS Code with the UI, but it doesn't make sense if you want to install only the server part.

Then you start the tunnel with:

code tunnel

When you run that command, VS Code downloads and starts the VS Code Server on that machine, then creates the tunnel for remote access. The first time, you will also be asked to accept the server license terms, unless you pass the CLI flag to accept them up front.

After that, the CLI gives you a vscode.dev URL tied to that remote machine. When you open that URL the first time from a client, you will be asked to authenticate with GitHub. That authentication is how VS Code checks that both sides are tied to the same account and that you are allowed to access the remote machine.

There are two practical ways to connect.

The first is through the browser using that vscode.dev link. This is the fastest way to prove the setup works.

The second, and usually better option, is from your local desktop VS Code. For that, install the Remote - Tunnels extension, open the Command Palette, and run Remote Tunnels: Connect to Tunnel. You can also see available machines in the Remote Explorer.

So the basic flow looks like this:

On the customer VM, run code tunnel
Authenticate when prompted
Open the generated vscode.dev URL or connect from local VS Code
Start working on the remote codebase from your own editor

There are two practical details worth calling out.

First, the tunnel is only reachable while VS Code is running there, unless you explicitly set it up to keep running. Microsoft documents a service mode for this with code tunnel service install, and there is also a --no-sleep option to help prevent the remote machine from going to sleep.

Second, this does not require VS Code to open inbound listeners on the VM. Microsoft states that hosting and connecting use authenticated outbound connections to the Azure-hosted tunneling service, and that no firewall changes are generally necessary. That is one of the reasons this can fit locked-down environments better than people expect.

Trade-offs and limits

Remote Tunnels is a strong solution for this scenario, but it is not magic. It has constraints, and it is better to say them clearly.

The first limit is the trust model. To create and access a tunnel, you authenticate with GitHub or Microsoft, and the tunnel itself is brokered through Microsoft’s dev tunnel service. That is exactly why setup is easy, but it also means some customer environments may reject it on policy alone, even if the technical setup works.

The second limit is extension support, especially in the browser. The desktop VS Code client is usually the best experience. The browser option is useful, but not every extension behaves the same way there. VS Code’s remote documentation is explicit that extensions may run in different locations, local or remote, depending on the extension type and the client being used.

The third limit is that this is not a shared remote IDE platform. Microsoft states that the VS Code Server is intended for a single user and that hosting it as a service is not allowed. So this is a personal remote development workflow, not something you should pitch as a team-wide hosted development environment for many users.

The fourth limit is operational persistence. A tunnel is easy to start, but if the remote machine sleeps, shuts down, or the tunnel service is not kept running, your session is gone until it comes back. Microsoft documents service mode and sleep-related options for that reason.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Using GitHub Copilot CLI with Azure AI Foundry (BYOK Models) – Part 2

Emanuele Bartolesi — Fri, 10 Apr 2026 09:54:00 +0000

In Part 1, you ran GitHub Copilot CLI against a local model using LM Studio.

That setup gives you control. No external calls. No data leaving your machine. But it comes with clear limits. Small models struggle, and output quality drops fast on anything non-trivial.

This is where Azure AI Foundry comes in.

Instead of running models locally, you connect Copilot CLI to a cloud-hosted model you control. You still use the same BYOK (Bring Your Own Model) approach, but now the model runs on Azure.

That changes the trade-offs:

You gain better models and stronger reasoning
You keep control over the endpoint and deployment
You accept cost and network dependency

This is not a replacement for the local setup. It is the next step if you want privacy but at the same time, more power.

Setting Up Azure AI Foundry

This is the only "Azure-heavy" part. Keep it minimal. You just need a working endpoint and a deployed model.

1. Create or Use an Existing Resource

Go to Azure AI Foundry in the Azure portal.

You need:

A resource already created
Access to it (permissions matter)

If you already use Azure OpenAI, you can reuse it.

2. Deploy a Model

This step is mandatory.

In Azure, you cannot call a model directly. You must deploy it first.

Steps:

Open your resource
Go to Model deployments
Select a model (for example GPT-4 class)
Assign a deployment name

Example:

copilot-gpt53codex

This name is what Copilot CLI will use later.

This is how the GPT 5.3 Codex looks like, but you can also deploy models directly from the HuggingFace catalog.

If your AI Foundry is good, you can deploy the models directly with the Deploy button in the model details page.

3. Get Endpoint and API Key

From the resource, retrieve:

Endpoint URL
API key

Typical endpoint:

https://<your-resource>.openai.azure.com/

You will combine this with the deployment in the next step.

4. Build the Final Endpoint

Copilot CLI expects a full path, not just the base URL.

Format:

https://<your-resource>.openai.azure.com/openai/deployments/<your-deployment>/v1

Example:

https://my-ai.openai.azure.com/openai/deployments/copilot-gpt53codex/v1

If this path is wrong, nothing will work.

5. Quick Validation

Before using Copilot CLI, validate:

The deployment exists
The API key is valid
The endpoint is reachable

If you skip this, debugging later becomes painful.

Connecting Copilot CLI to Azure

This is the same pattern as Part 1. Different endpoint. More constraints.

Set the Environment Variables

You must point Copilot CLI to your Azure deployment.

PowerShell example:

$env:COPILOT_PROVIDER_BASE_URL="https://<your-resource>.openai.azure.com/openai/deployments/<your-deployment>/v1"
$env:COPILOT_MODEL="<your-deployment>"
$env:AZURE_OPENAI_API_KEY="<your-api-key>"

What matters:

COPILOT_PROVIDER_BASE_URL → full Azure endpoint
COPILOT_MODEL → deployment name, not model name
AZURE_OPENAI_API_KEY → required for authentication

No COPILOT_OFFLINE here. Requests go to Azure.

Run a Simple Test

Open Copilot CLI with the following command in a project folder you want to test:

copilot --banner

Ask a simple tasks like: "Give me the list of all the files larger than 2MB".

If everything is configured correctly:

The response comes from your Azure AI Foundry Model
The answer is really fast, at least faster than the answers from the Part 1

Reality Check

This is not “Copilot with Azure magic”.

It is:

Copilot CLI acting as a thin client
Azure acting as the model provider

You gain better models, not better tooling.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Using GitHub Copilot CLI with Local Models (LM Studio)

Emanuele Bartolesi — Thu, 09 Apr 2026 11:36:59 +0000

Local AI is getting attention for one simple reason: control.

Cloud models are strong and fast, but for many companies and developers, especially when experimenting or working with sensitive code, that is not ideal.

This is where local models come in.

Tools like LM Studio let you run LLMs directly on your machine. No external calls. No data leaving your environment or your network.

Instead of sending prompts to cloud models, you can point Copilot CLI to a local model running in LM Studio.

This setup is not perfect. It is not officially seamless. But it works well enough for learning, experimentation, and some real workflows.

What You Need

Before setting this up, make sure the basics are clear. This is not a plug-and-play setup. There are a few moving parts, and some assumptions.

GitHub Copilot CLI

You need GitHub Copilot CLI installed and working.

You can launch GitHub Copilot CLI with the following command:

copilot

or even better, if you want to see the banner in the terminal:

copilot --banner

By default, the CLI uses GitHub-managed models, but now you can override that.

Note: You must be authenticated with GitHub and have access to Copilot.

LM Studio

LM Studio is the simplest way to run local LLMs without dealing with raw model tooling.

What it gives you:

A UI to download and run models
A local server that exposes an OpenAI-compatible API
No need to manually manage inference engines

Once running, it exposes an endpoint like (OpenAI compatible):

http://localhost:1234/v1

This is the key piece. Copilot CLI will talk to this endpoint instead of the cloud.

A Local Model (Be Realistic)

Not all models are equal. And your hardware matters.

For this guide, a small model like:

qwen/qwen3-coder-30b

is enough to get started.

But be clear on the trade-offs:

Small models → fast, but weaker reasoning
Large models → better output, but slow or unusable on most laptops

If you are on a standard laptop:

1B–3B models → OK
7B+ models → borderline
13B+ → usually not practical without a GPU

On my laptop I am giving a chance to the NVidia model nemotron-3-nano-4b but on my gaming PC (that I use for developing and not gaming) I use bigger models la Qwen3 Code or similar.

Tip: Start small. The goal here is understanding the workflow, not benchmarking models.

Connecting Copilot CLI to LM Studio

This is the part most people get wrong.

Copilot CLI is not designed primarily for local models. You are using a BYOK (Bring Your Own Key/Model) path that is still evolving.

It works, but you need to be precise.

Reference: https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models

1. Set the Environment Variables

You must override the default Copilot provider.

In PowerShell:

$env:COPILOT_PROVIDER_BASE_URL="http://localhost:1234/v1"
$env:COPILOT_MODEL="google/gemma-3-1b"
$env:COPILOT_OFFLINE="true"

What they do:

COPILOT_PROVIDER_BASE_URL → points to your local LM Studio server
COPILOT_MODEL → defines which model to use
COPILOT_OFFLINE → prevents fallback to cloud models

If COPILOT_OFFLINE is not set, Copilot may silently use cloud models.

2. Run a Simple Test

Open LM Studio, and open the *Developer * tab.
Click on the switch of the Status and the server will start in a second.

Then, click on Load Models and load the models you prefer that you downloaded previously on your machine.

Open Copilot CLI with the following command in a project folder you want to test:

copilot --banner

Ask a simple tasks like: "Give me the list of all the files larger than 2MB".

If everything is configured correctly:

The response comes from your local model
No external API calls are made

Don't expect a result in seconds like a normal cloud model, but it depends on your hardware; it can also take minutes sometimes.

Reality Check

This is not a first-class integration.

No guarantee of full compatibility
No optimization for local inference
No smart routing like in GitHub-hosted Copilot

But for simple CLI workflows, it is good enough.

When This Setup Makes Sense

Do not use this everywhere. Use it where it actually gives you an advantage.

1. Privacy-Sensitive Environments

If code cannot leave your machine, this setup is useful.

Examples:

Internal tools
Proprietary scripts
Regulated environments

You avoid sending prompts and contexts to external services.

This is the strongest reason to use local models.
Especially in some companies like insurances or military, it makes absolutely sense.

2. Offline Workflows

If you work without a stable connection or you don't have a connection at all (like during a flight).

It is slower, but always available.

3. Learning and Understanding AI

This setup forces you to see how LLMs actually behave.

You learn:

Prompt sensitivity
Model limitations
Output variability

This is valuable if you want to go beyond "just using Copilot".

When It Does NOT Make Sense

Avoid this setup if you need:

High accuracy
Large context handling
Production-grade reliability

In those cases, cloud models are still the better option.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

GitHub Copilot Is Too Nice. Fix It With a Tone of Voice File.

Emanuele Bartolesi — Wed, 01 Apr 2026 12:21:58 +0000

Most GitHub Copilot setups are too polite to be useful.

By default, Copilot tries to agree, avoid criticism, and keep answers "safe".
That sounds good, but in practice it leads to weak suggestions, missed problems, and bad decisions slipping through.

If you want better output, you need to change its behavior.

The simplest way is a tone of voice file.

Create a voice-instructions.md in your repo and force Copilot to be critical:

---
applyTo: '**'
---

Give direct, critical feedback.
Identify mistakes, weak assumptions, unnecessary complexity, unclear naming, hidden risks, and poor trade-offs without softening the message.

Do not add generic praise or filler. Do not agree by default.

When something is wrong, say exactly what is wrong, why it is a problem, and what should be done instead.

Prioritize correctness, clarity, simplicity, maintainability, and practical delivery.

Challenge vague requirements and surface missing constraints, edge cases, and operational risks.

Be blunt but professional. Never be insulting. Always aim to be useful.

You get:

Clear problems called out
Weak assumptions challenged
Simpler and more maintainable alternatives

The result is better code and faster decisions.

There is a trade-off.

It feels harsher.
It is not ideal for beginners.
It removes the "friendly assistant" vibe.

But if you are building real systems, that is the wrong goal anyway.

If you want better output, demand better behavior.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

Git Mirroring During Migrations: `--all` vs `--mirror`

Emanuele Bartolesi — Mon, 16 Mar 2026 07:00:00 +0000

During a Git migration, the new platform is rarely switched on overnight.

In many real scenarios, two systems must coexist for a while. For example:

repositories move from GitLab to GitHub
CI pipelines still run in GitLab
developers start working in GitHub

In this transition phase, the repositories must stay synchronized between both platforms.

One common solution is repository mirroring, where changes from one repository are pushed to another remote so both systems stay aligned.

Two approaches are often used for this:

git push gitlab --force --all
git push gitlab --force --tags

git push gitlab --force --mirror

At first glance, these commands may look equivalent. They are not.

The Common Approach: Pushing Branches and Tags

A common way to keep two repositories in sync is pushing all branches and tags to the second remote.

git push gitlab --force --all
git push gitlab --force --tags

These two commands are often used together during migrations.

`git push --all`

git push gitlab --force --all

This command pushes all local branches to the remote.

Important details:

It pushes every branch under refs/heads/*
It does not push tags
It does not push other reference types

So after this command runs, the remote repository will contain the same branches as the local repository.

`git push --tags`

git push gitlab --force --tags

This command pushes all tags under refs/tags/*.

Tags are often used for:

releases
versioning
deployment markers

Since --all does not include tags, they must be pushed separately.

What This Approach Synchronizes

Using these two commands ensures that:

all branches are synchronized
all tags are synchronized

For many teams, this is already enough to keep two repositories aligned during a migration.

However, this approach does not synchronize the entire repository state. Some Git references are still missing.

This is where --mirror behaves differently.

The Full Mirror Option

Git also provides a command designed specifically for repository mirroring:

git push gitlab --force --mirror

This command behaves differently from pushing branches and tags separately.

Instead of pushing selected references, --mirror pushes every reference under refs/* from the local repository to the remote.

This includes:

branches (refs/heads/*)
tags (refs/tags/*)
remote-tracking branches
notes
any other custom references

Another important behavior is that --mirror synchronizes deletions.

If a reference exists on the remote but no longer exists locally, --mirror will remove it from the remote as well. The goal is to make the remote repository an exact replica of the source repository.

In other words:

--all + --tags copies branches and tags
--mirror copies the entire reference namespace

This makes --mirror the closest thing to a true Git repository mirror.

Quick Recommendation

Both approaches can work during a migration, but they serve slightly different goals.

Use `--all` + `--tags` when

git push gitlab --force --all
git push gitlab --force --tags

This approach is usually enough if you only need to synchronize:

branches
tags

It is also safer in environments where the target repository may contain additional references created by tooling, CI systems, or platform features.

Since it does not delete references on the remote, it reduces the risk of accidentally removing something important.

Use `--mirror` when

git push gitlab --force --mirror

This option is appropriate when you want the destination repository to be a complete mirror of the source.

Typical cases include:

temporary mirrors during platform migrations
backup repositories
strict synchronization between two Git servers

However, --mirror is more aggressive. It will overwrite and delete references on the remote to match the source exactly.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

GitHub Copilot to Generate Conventional Commit Messages in VSCode and JetBrains Rider

Emanuele Bartolesi — Tue, 17 Feb 2026 08:03:45 +0000

Update, August 2026: The original VS Code configuration is no longer enough in some setups. Commit message generation uses VS Code's chat.utilitySmallModel, so you may need to select that model explicitly. I use Claude Haiku 4.5 because it has produced the best commit messages in my tests.

Most commit messages are useless.

"fix stuff"
“update code"
"changes"

They work in the moment. They fail six (actually one) months later.

Commit messages are not for today or for something special. They are for:

your future self
your teammates
automation pipelines
changelog generators
semantic versioning

Writing structured commit messages takes discipline. Under pressure, discipline disappears. Even without the pressure sometimes, just because as developers, we are lazy by nature.

This is where GitHub Copilot becomes interesting.

Instead of using Copilot just for code, you can use it as a commit quality guardrail. With the right instructions, it generates strict Conventional Commit messages automatically, directly inside:

VS Code
JetBrains Rider

Why Conventional Commits Still Matter

Conventional Commits are not about style.
They are about structure.

The format is simple:

type(scope): description

Example:

feat(auth): add JWT token validation
fix(api): handle null response in user endpoint
refactor(ui): simplify navbar component

Readable Git History

Compare:

update stuff
fix bug
changes

With:

fix(auth): prevent null pointer on login
feat(api): add user filtering by role
ci(github-actions): add build cache

The second history is self-documenting.

Using GitHub Copilot for Commit Messages in VS Code

Copilot can generate commit messages directly from the Source Control panel.

By default, generation is generic.
Custom instructions make it strict.

In recent VS Code versions, however, the instructions alone may not be enough. Users have reported commit message generation failing with 422 Unprocessable Entity and promptFiltered, even with harmless instructions or diffs (issue #315997 and issue #316204).

VS Code now documents that commit message generation uses chat.utilitySmallModel. There is no model picker dedicated only to commit messages, and an open issue proposes a specific setting.

Add the model and your custom instructions to settings.json:

// "chat.utilitySmallModel": "copilot/gpt-5.4-mini",
"chat.utilitySmallModel": "copilot/claude-haiku-4.5",

"github.copilot.chat.commitMessageGeneration.instructions": [
    { "text": "Follow Conventional Commits: type(scope): description." },
    { "text": "Use lowercase type and scope." },
    { "text": "Use imperative mood: 'add', 'fix', 'update', not past tense." },
    { "text": "Keep subject under 50 characters. No period." },
    { "text": "Describe the intent clearly. Avoid vague messages like 'update code'." },
    { "text": "Use only these types: feat, fix, docs, style, refactor, perf, test, chore, ci." },
    { "text": "Include a scope when the change targets a specific area." },
    { "text": "Ensure each commit represents one logical change." },
    { "text": "Add a body when needed, separated by a blank line." },
    { "text": "Use bullet points (*) in the body for multiple changes." },
    { "text": "Explain why the change was made, not only what changed." },
    { "text": "Add BREAKING CHANGE: in the footer when applicable." }
]

You can choose another model available to your account. I tested GPT-5.4 mini as well, but Claude Haiku 4.5 gave me the most consistent commit messages while staying fast enough for this small task.

One important trade-off: chat.utilitySmallModel is not limited to commits. VS Code also uses it for lightweight utility tasks such as rename suggestions, branch name generation, prompt categorization, and intent detection. Changing it affects those features too. You can find the complete behavior in the official VS Code documentation.

After staging changes, generate the commit message.

Instead of:

update login logic

You’ll get:

fix(auth): prevent null pointer on login

* add null check for user object
* improve error handling for invalid credentials

Copilot becomes consistent because the rules are explicit.

Using GitHub Copilot for Commit Messages in JetBrains Rider

In Rider, Copilot integrates in the Commit tool window.

With strict instructions, you can enforce full compliance.

Example instruction structure:

Follow the Conventional Commits specification strictly.

<type>(<scope>): <short description>

All sections except the first line are optional.
Use only these types: feat, fix, docs, style, refactor, perf, test, chore, ci.
Max 50 characters. Imperative mood. No period.
Each commit must represent one logical change.
Use BREAKING CHANGE: footer when applicable.

Example output:

feat(auth): add refresh token support

* implement refresh token endpoint
* update token validation logic
* improve session security

Breaking change example:

refactor(api): rename user endpoint

BREAKING CHANGE: /users endpoint is now /v2/users

Go to Settings *> **Tools *> **GitHub Copilot > Git Commit Instructions > Global.

Rider allows more verbose enforcement.
VS Code favors compact rule lists.

Both approaches work.

Making Copilot Strict (Not Creative)

Copilot predicts text.
Constraints reduce variance.

Key principles:

Write hard rules, not suggestions
Limit allowed types
Enforce atomic commits
Require proper breaking change footers
Review output before committing

Copilot is not replacing judgment.
It removes repetitive formatting work.

When configured correctly, writing a proper Conventional Commit becomes easier than writing a bad one.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

A Practical GitFlow Setup That Works on GitHub

Emanuele Bartolesi — Mon, 02 Feb 2026 12:06:43 +0000

I use GitFlow even for my side projects.

Not because it is elegant. Not because it is modern. I use it because it forces me to behave like the project matters, even when nobody else is watching.

When you work alone, shortcuts are tempting. You push directly to main. You skip reviews. You promise yourself you will clean it up later. Later never comes. GitFlow, with the right rules, removes that option. It makes discipline the default instead of a personal choice.

This is important to say upfront. GitFlow is not light. It adds structure, friction, and process. If you deploy to production ten times per day, GitFlow will slow you down. In that case, trunk-based development with feature flags is usually the better choice.

But when you ship versioned releases, when you have a real staging phase, or when you want a clean separation between “work in progress” and “ready to release”, GitFlow still works well. Even for a solo developer.

Everything in this article is what I actually run on GitHub today. On client projects (when they want to use GitFlow, of course). On open source. On side projects that may never make money.

If you are going to use GitFlow, use it properly. Otherwise, do not use it at all.

2. When GitFlow Makes Sense and When It Does Not

GitFlow is a release model, not a productivity hack.

I use it when the way I ship software matches the assumptions GitFlow makes. If those assumptions are wrong, the model fights you every day.

When GitFlow makes sense

GitFlow works well for me in these cases.

You ship versioned releases. You care about v1.2.3 meaning something. You want a clear moment where a release is cut, stabilized, tested, and then shipped.

You have a real staging phase. Not “production with a flag”, but an environment where release candidates live, get tested, and sometimes get rejected.

You need parallel workstreams. New features continue on develop while a release is being stabilized, or while a hotfix is being prepared.

You want a hard separation between work in progress and releasable code. main always deployable. develop allowed to move faster and break occasionally.

In these scenarios, GitFlow reduces stress instead of adding it. The branches reflect reality.

When GitFlow is the wrong choice

I avoid GitFlow in these situations.

You deploy to production continuously. Multiple times per day. No staging. No release windows. In that world, GitFlow adds branches without adding safety.

Your team already struggles to keep develop stable. GitFlow assumes you can treat develop as an integration gate. If you cannot, you are better off with trunk-based development and feature flags.

You do not have environments to support it. No staging. No separation between integration and production. In that case, GitFlow becomes naming theater.

The most common mistake

The worst setup I see is this.

Teams adopt GitFlow “by the book”, but keep their old habits. Direct pushes sneak in. Hotfixes do not get merged back. Releases happen straight from develop because it is “almost ready”.

3. The GitFlow Branch Model I Actually Use on GitHub

I keep the branch model boring and strict. No variations. No “almost GitFlow”. If I start bending the rules, the model stops working.

These are the only branches I use.

`main`

main is always releasable. Always.

I never push directly to it. Not even for a typo. If main is broken, the whole model failed upstream.

What this gives me is simple. At any point in time, I can tag main and ship. No excuses. No cleanup phase.

If you cannot guarantee this, GitFlow gives you nothing.

`develop`

develop is my integration branch.

This is where features meet. This is where conflicts show up early. This is where I accept temporary instability, but only temporarily.

I treat develop as protected, even when I work alone. No direct pushes. Always via pull request. That PR is my forced pause to think: is this actually ready to be integrated?

If develop stays broken for days, GitFlow collapses. Integration must be frequent and boring.

`feature/*`

All work starts here.

Feature branches are short-lived by design. If a feature takes more than three to five days, I split it. Long-lived feature branches are the biggest source of merge pain and hidden risk.

I do not optimize for “perfect feature branches”. I optimize for deleting them quickly.

Examples:

feature/auth-token-refresh
feature/api-rate-limits
feature/ui-settings-page

Once merged into develop, the branch is gone. No reuse. No resurrection.

`release/*`

I only create a release/* branch when I actually need stabilization.

If there is no staging phase, I skip release branches entirely. Creating them without a purpose is pure ceremony.

A release branch exists to say one thing: no new features. Only fixes, hardening, documentation, and versioning.

Typical names:

release/1.4.0
release/2026.02

When the release is ready, it gets merged into main, tagged, and then merged back into develop. Always both. This is where many teams drift.

`hotfix/*`

Hotfixes are rare. That is intentional.

A hotfix starts from main, never from develop. It fixes production. Nothing else.

After the fix, I merge it into main and immediately back into develop. Skipping the back-merge is the fastest way to reintroduce the same bug later.

Names stay explicit:

hotfix/login-nullref
hotfix/payment-timeout

Hotfixes are treated with more care, not less.

4. The Rules That Make GitFlow Work (And Why I Enforce Them on Myself)

GitFlow without rules is just branch naming.

I enforce the same rules on my side projects that I enforce on client projects. The reason is simple. If the setup only works when I am “careful”, it will fail under pressure.

Protected branches are non-negotiable

I protect main and develop. Always.

No direct pushes.
No force pushes.
No branch deletion.
Pull requests only.

Even when I am the only contributor.

This removes temptation. I cannot “just push a quick fix”. Every change goes through the same path. That consistency is the real value.

Pull requests are mandatory checkpoints

A pull request is not about collaboration. It is about forcing a decision point.

Before merging, I answer a few basic questions:

Why does this change exist?
What exactly changed?
How did I verify it works?
What is the risk?

If I cannot answer those clearly in a PR description, the change is not ready.

This sounds heavy. In practice, it saves time. It avoids “I’ll fix it later” commits.

Approvals still matter, even solo

I require at least one approval.

Yes, I approve my own PRs. That is not the point.

The point is the pause. The forced context switch. Opening the PR, reading the diff in GitHub, and approving it is different from pushing code from an editor.

That pause catches mistakes more often than people expect.

Conversation resolution is underrated

I require all conversations to be resolved before merging.

This prevents half-finished reviews and “we will come back to this” comments that never get addressed.

If a comment exists, it deserves a decision. Fix it. Reject it. Explain it. Then resolve it.

Linear history vs merge commits

This is where teams hurt themselves.

If your team is comfortable with rebasing and understands it well, require a linear history. It keeps develop clean.

If not, allow merge commits. But standardize it. Do not mix strategies per PR.

I personally use:

Squash merge for feature/* into develop
Merge commits for release/* and hotfix/* into main

The key is not which option you pick. The key is that it is enforced, not debated every time.

5. Pull Requests as the Core Unit of Work

In my setup, branches exist to create pull requests. Pull requests are the real workflow.

If you get PRs right, GitFlow becomes manageable. If PRs are large, vague, or inconsistent, GitFlow falls apart.

A boring PR template on purpose

I use the same PR template everywhere. It is intentionally simple.

Why: the problem or reason for the change
What: what changed at a high level
How tested: tests run, manual checks, environments
Risk: what could break
Rollback: how to undo it if needed

This is not documentation. It is a forcing function. If I cannot fill this in quickly, the PR is probably doing too much.

Small PRs beat clever branch strategies

If a reviewer needs more than 30–45 minutes, the PR is too big.

Large PRs hide bugs. They also create social pressure to approve without fully understanding the change. That is how regressions slip in.

I optimize for PRs that can be reviewed quickly and confidently. That usually means slicing features into vertical, mergeable steps.

GitFlow does not fix big PRs. It amplifies the pain if you allow them.

CODEOWNERS even for tiny repos

I use CODEOWNERS even when I am the only owner.

It makes review routing explicit. It also prepares the repo for future contributors without rethinking the rules.

More importantly, GitHub treats CODEOWNERS reviews differently. That gives you another enforcement layer, not another convention.

6. Naming, Traceability, and Future Me

Most conventions exist for one reason. You will forget.

Future me is the main consumer of my Git history. Not GitHub. Not tools. Me, six months later, trying to understand why something exists.

Branch names should explain intent

I use explicit branch names. Not clever ones.

feature/login tells me nothing.
feature/oauth-token-refresh tells me exactly what problem was being solved.

If I use an issue tracker, I include the ID:

feature/ABC-123-oauth-token-refresh

This costs seconds. It saves minutes every time I search history.

PR titles are part of the changelog

I treat PR titles as public API.

Release notes, changelogs, and audit trails are generated from them. If the title is vague, everything downstream becomes vague.

I avoid “fix stuff” or “cleanup”. I prefer:

“Fix token refresh race condition”
“Add rate limiting to public API”

If I cannot summarize the change in one sentence, the PR is probably too large.

Link everything, even when it feels redundant

I always link PRs to issues. Always.

Even on side projects. Even when the issue only exists to track the PR.

GitHub already gives you the syntax. Use it.
Closes #123 is enough.

This creates a navigable graph. Branch to PR. PR to issue. Issue to release. Without links, GitFlow loses one of its biggest advantages.

Traceability must be enforced, not suggested

If traceability is optional, it will be skipped.

I enforce naming and linking through:

Branch naming patterns
PR templates
Required checks

The goal is not bureaucracy. The goal is predictability.

Why this matters more with GitFlow

GitFlow creates more branches than trunk-based development. That increases cognitive load.

Naming and traceability reduce that load. They make the model survivable over time.

In the next section, I will map this structure to CI/CD pipelines, and explain what I run where, and why.

6. Naming, Traceability, and Future Me

Most conventions exist for one reason. You will forget.

Future me is the main consumer of my Git history. Not GitHub. Not tools. Me, six months later, trying to understand why something exists.

Branch names should explain intent

I use explicit branch names. Not clever ones.

feature/login tells me nothing.
feature/oauth-token-refresh tells me exactly what problem was being solved.

If I use an issue tracker, I include the ID:

feature/ABC-123-oauth-token-refresh

This costs seconds. It saves minutes every time I search history.

PR titles are part of the changelog

I treat PR titles as public API.

Release notes, changelogs, and audit trails are generated from them. If the title is vague, everything downstream becomes vague.

I avoid “fix stuff” or “cleanup”. I prefer:

“Fix token refresh race condition”
“Add rate limiting to public API”

If I cannot summarize the change in one sentence, the PR is probably too large.

Link everything, even when it feels redundant

I always link PRs to issues. Always.

Even on side projects. Even when the issue only exists to track the PR.

GitHub already gives you the syntax. Use it.
Closes #123 is enough.

This creates a navigable graph. Branch to PR. PR to issue. Issue to release. Without links, GitFlow loses one of its biggest advantages.

Traceability must be enforced, not suggested

If traceability is optional, it will be skipped.

I enforce naming and linking through:

Branch naming patterns
PR templates
Required checks

The goal is not bureaucracy. The goal is predictability.

8. Releases, Tags, and Changelogs I Can Trust

Releases are not a side effect. They are a deliberate action.

GitFlow only pays off if releases are predictable and traceable. That starts with being strict about where and how you tag.

Tags exist only on `main`

I tag releases only on main. No exceptions.

If a tag exists anywhere else, it lies. A tag should mean “this is what went to production” or “this is the shipped artifact”.

Tagging on develop or release/* breaks that guarantee and creates confusion later when you try to answer a simple question: what is actually running?

Release branches are not releases

A release/* branch is a candidate. Not a promise.

It can be delayed. It can be fixed. It can even be abandoned. That is fine.

The release only exists when:

The release branch is merged into main
A tag is created on main

Anything else is pre-release noise.

Versioning decisions are made early

I decide versioning strategy at the start of a project, not during the first release.

Semantic versioning when public contracts matter
Date-based versioning for internal tools or fast-moving products

Changing versioning mid-stream creates churn and inconsistent expectations. Pick one and live with it.

Changelogs are generated, not remembered

I do not write changelogs by hand.

They are generated from:

PR titles
Labels
Commit history on main

This is why PR titles matter. Sloppy titles produce useless release notes.
(Actually GitHub Copilot helps me a lot to create these ones and commit messages)

9. Environments or GitFlow Is Just Ritual

GitFlow assumes environments. Without them, you are just renaming branches.

I see many setups where GitFlow exists on paper, but everything deploys to the same place. In that case, the extra branches add zero value.

The minimum environment setup I use

I keep it simple. Three environments.

Dev / Integration
Automatically deployed from develop. This is where features meet and conflicts surface early.
Staging
Deployed from release/*. This environment exists to say “no”. If something fails here, the release is not ready.
Production
Deployed from main. Always. No exceptions.

If you cannot support at least this, GitFlow will not protect you.

Why each environment matters

develop needs a shared place where the system actually runs. Unit tests are not enough. Integration bugs appear only when components talk to each other.

release/* needs a stable environment. The whole point of a release branch is to freeze scope and validate reality.

main maps one-to-one with production. If you blur this line, you lose confidence in every tag and every rollback.

GitFlow without environments is overhead

Branches alone do not reduce risk. Feedback loops do.

If all feedback arrives only after merging to main, GitFlow becomes slower trunk-based development, nothing more.

In the next section, I will explain how I handle hotfixes, and why this is where most teams break the model.

10. Handling Hotfixes Without Breaking the Model

Hotfixes are where GitFlow discipline is tested.

They arrive under pressure. Something is broken. Time matters. This is exactly when shortcuts feel justified. That is also when long-term damage happens.

Hotfixes start from `main`

A hotfix always branches from main. Never from develop.

main represents what is running in production. If you start a hotfix anywhere else, you are guessing what you are fixing.

The goal of a hotfix is simple. Fix production. Nothing more.

Scope is deliberately small

A hotfix branch contains the minimal change required to restore service.

No refactoring. No cleanup. No “since we are here” improvements. Those belong on develop or in a future release.

Every extra change increases risk at the worst possible moment.

CI and reviews still apply

I do not disable checks for hotfixes.

Pipelines might be slightly faster. Reviews might be faster. But rules still apply.

Hotfixes are urgent, not special.

Why teams drift here

Under pressure, people optimize for now. GitFlow optimizes for later.

Skipping the back-merge or bypassing rules feels harmless in the moment. It creates invisible debt that surfaces weeks later.

If your GitFlow setup cannot survive hotfix pressure, it is not real.

11. Merge Conflicts and How I Keep Them Boring

Merge conflicts are not a Git problem. They are a workflow problem.

Every painful conflict I have dealt with had the same root cause. Branches lived too long.

Short-lived branches solve most conflicts

I keep feature branches short. Days, not weeks.

If a feature cannot be merged within three to five days, I split it. Vertical slices. Mergeable steps. Incremental progress.

This single habit reduces conflicts more than any Git command ever will.

12. GitHub Actions Patterns I Reuse Everywhere

Automation is what makes GitFlow survivable long term.

If the workflow depends on people remembering rules, it will degrade. GitHub Actions are there to make the right path the default path.

Required checks are gates, not guidelines

Every protected branch has required checks.

If a check is required, the PR cannot merge. No override. No “just this once”.

This removes social pressure. The system says no, not a person.

I treat required checks as part of the branch contract. If they are flaky or slow, I fix the checks. I do not remove the requirement.

Reusable workflows or nothing

I do not copy-paste workflows across repositories.

I use reusable workflows so:

The same rules apply everywhere
Changes are made once
Drift is impossible

Environment protection is part of GitFlow

For production deployments, I use GitHub environments with protection rules.

Required reviewers
Scoped secrets
Explicit approval step

This adds a final safety net without bypassing GitFlow.

If main deploys to production, production must be protected.

Secrets and permissions are minimal

Workflows get only the permissions they need. No wildcard tokens. No long-lived secrets when OIDC is available.

This matters more as automation grows. GitFlow increases automation surface. Least privilege keeps that surface manageable.

13. Security and Governance I Enable by Default

Security and governance are not enterprise-only concerns. I enable them even on side projects. Especially on side projects.

If the repo matters enough to use GitFlow, it matters enough to protect it.

Dependabot is always on

I enable Dependabot alerts and PRs by default.

Alerts tell me when I am exposed.
PRs force the fix through the same PR rules as any other change.

I never update dependencies directly on protected branches. Updates go through PRs, checks, and reviews like everything else.

Code scanning is part of the pipeline

At minimum, I run code scanning on:

develop
main

This catches obvious issues early and prevents shipping known problems.

I do not chase perfect security scores. I want signal, not noise. But no scanning at all is not an option.

14. In a nutshell, what I do (copy this section)

This is the setup I apply by default. On client projects. On open source. On side projects.

Branches

main
Always releasable. Production only.
develop
Integration branch. Can move fast, but must stay usable.
feature/*
Short-lived. One purpose. Merged into develop.
release/*
Created only when a real stabilization phase exists.
hotfix/*
Urgent fixes from main. Always merged back.

Protection rules

Protected branches:

main
develop
release/*
hotfix/*

Rules applied:

Pull requests required
At least one approval
Required status checks
Conversation resolution required
No direct pushes
No force pushes
No branch deletion

Pull request rules

Mandatory PR template: Why, What, How tested, Risk, Rollback
Small PRs by design
CODEOWNERS enabled
One merge strategy enforced

Merge strategy

Squash merge for feature/* into develop
Merge commits for release/* and hotfix/*
No rebasing of shared branches

CI/CD

feature/*: build, unit tests, lint
develop: full test suite, security checks
release/*: full suite, packaging, deploy to staging
main: production deploy, tag, changelog

Releases

Tags on main only
Semantic or date-based versioning decided early
Changelogs generated from PR metadata

Environments

develop → dev/integration
release/* → staging
main → production

Hotfix discipline

Branch from main
Minimal scope
Merge to main
Merge back to develop
No skipped steps

This policy is intentionally boring. Boring scales.

👀 GitHub Copilot quota visibility in VS Code

If you use GitHub Copilot and ever wondered:

what plan you’re on
whether you have limits
how much premium quota is left
when it resets

I built a small VS Code extension called Copilot Insights.

It shows Copilot plan and quota status directly inside VS Code.

No usage analytics. No productivity scoring. Just clarity.

👉 VS Code Marketplace:
https://marketplace.visualstudio.com/items?itemName=emanuelebartolesi.vscode-copilot-insights

How I created a Cozy Workspace in VS Code

Emanuele Bartolesi — Thu, 11 Dec 2025 15:54:26 +0000

I love VS Code. It is fast, flexible, and works for almost any stack. But the default layout is not great if you want a clean space to think. The editor area is smaller than it should be, and the UI is packed with elements that pull attention away from the code. With the new Copilot Chat panel taking even more space, the problem becomes obvious. Too much noise, not enough room to work.

In the picture above, the default layout, with Copilot opened on the right, the space for code is really limited.

I have been searching for a layout that removes distractions without sacrificing functionality. Something simple, comfortable, and optimized for long sessions. This article explains the setup I finally arrived at. It is a Productivity profile built around a few key layout changes: moving the sidebar to the right, putting the Activity Bar at the top, centering Quick Input, hiding the Command Center, switching themes automatically based on daylight, improving cursor visibility, and adding one small bonus to make the day more pleasant.

These changes are minimal but have a clear impact. They turn VS Code into a focused, cozy environment that gives space back to the code instead of the UI.

Creating a Dedicated “Productivity” Profile

VS Code profiles let you build isolated setups for different workflows. This solves a common problem. When you install extensions or change layout settings for one project, everything else gets affected. A dedicated Productivity profile keeps your focused environment clean and consistent.

I use this profile only for work sessions. For the training session I usually have, of course I still use the Default profile, otherwise the people are confused and lost.

Creating the new profile takes a minute:

Open the Command Palette.
Run Profiles: Create Profile.
Choose Empty.
Name it Productivity.
Customize settings only for this profile.

You can also click on the Gear icon on the bottom left and select "Profiles" from the menu.

Moving the Primary Sidebar to the Right

By default, VS Code puts the sidebar on the left. This works, but it also competes with your natural reading flow. Having the file tree on the left constantly pulls the eye away from the editor.
Also, when you close the sidebar, the code moves a little bit on the left, because the sidebar is not present anymore.

Moving the sidebar to the right reduces this tension. It keeps the editor centered and makes the coding area the first thing your eyes land on.

"workbench.sideBar.location": "right"

You can also click with the right button on the sidebar and select "Move Primary Sidebar Right".

This simple switch makes the layout feel more balanced and less cluttered.

Activity Bar at the Top

The Activity Bar is highly visible. Keeping it on the left (or right, if the primary sidebar is on the right) creates unnecessary vertical columns. Moving it to the top uses horizontal space instead of eating into the editor.

"workbench.activityBar.location": "top"

It's possible to change the same settings, even by clicking on the top of the sidebar and choose Top from the Activity Bar Position menu.

This change pairs well with the right-aligned sidebar and creates a cleaner overall layout.

Centering Quick Input for Better Focus

The Command Palette and file switcher usually appear at the top. This forces a constant eye shift upward. Centering Quick Input keeps everything in your immediate focus area.

"workbench.quickInput.location": "center"

This is especially useful if you use the keyboard heavily.

Hiding the Command Center

If you already use keyboard shortcuts and the centered Quick Input, the Command Center becomes redundant. It adds noise without adding value.

"window.commandCenter": false

Hiding it cleans up the top UI and keeps attention on the code.

Move the Menu bar

How often do you use the Menu? I think not so much, so, you can use that space for something else by changing the position of the menu, on the top of the Activity Bar.

"window.menuBarVisibility": "compact"

If you want to use the UI to change this settings, click on the Customize Layout on the top right corner of VS Code window and change the Visibility of the Menu Bar.

One more row is saved but first of all you are not distracted by the menu items on the top.

Automatic Light/Dark Theme Switching With PowerToys LightSwitch

PowerToys LightSwitch changes your Windows theme based on sunrise and sunset. VS Code can detect this automatically and switch between your preferred light and dark themes.

"workbench.preferredDarkColorTheme": "JetBrains Rider Dark Theme",
"workbench.preferredLightColorTheme": "Default Light+",
"window.autoDetectColorScheme": true

I use the JetBrains Rider Dark theme because I also use it on Rider, and it helps me stay focused when switching between IDEs.

This keeps the editor comfortable throughout the day with zero manual work.

Improving Cursor Visibility With “Expand” Blinking

The default cursor blink is subtle. In a busy file, it is easy to lose track of it. The “expand” style is more visible without being distracting.

"editor.cursorBlinking": "expand"

A small tweak, but surprisingly helpful.

Bonus: A Bit of Fun With VS Code Pets

A cozy environment should be enjoyable, not just efficient. The VS Code Pets extension adds a small animated pet to your workspace. It keeps you company during long sessions and adds a bit of charm without affecting focus.

It is optional, but it makes the environment feel more human.

Final Result

A cozy development environment is not about adding more tools. It is about removing friction. By focusing only on VS Code's layout settings, you can reclaim space, reduce noise, and make the editor feel purpose-built for deep work.

In the screenshot below, you can see the final result after all these easy changes.

If you want to spend time changing all the settings manually, you can find all my settings in the following repo:

kasuken / Windows11-Setup

My settings for Windows 11 and other tools I use everyday.

Windows 11 Setup & Automation

Automate, configure, and optimize your Windows 11 environment with ease.

🚀 Overview

This repository provides a comprehensive, automated, and customizable setup for Windows 11. It includes PowerShell scripts, terminal and VS Code configurations, and best practices to help you:

Set up a new Windows 11 machine in minutes
Apply productivity-boosting tweaks
Install essential tools and extensions
Maintain a consistent, portable dev environment

📦 Features

PowerShell Automation: Scripts for system tweaks, package installs, and profile management
Terminal Customization: Pre-configured settings for Windows Terminal
VS Code Setup: Recommended extensions and settings for a modern dev workflow
Modular Structure: Use only what you need—easy to extend and adapt
Documentation: Clear instructions for every step

🗂️ Repository Structure

Windows11-Setup/
├── PowerShell/         # PowerShell scripts and user profile
│   └── profile.ps1
├── Terminal/           # Windows Terminal settings
│   └── settings.json
├── VSCode/             # VS Code

…

View on GitHub

This layout turned VS Code into a cleaner and more intentional workspace for me. If you try it or customize it, share your version. Every developer ends up with their own definition of cozy.

📘 Get the Book with 50% Off!

I turned my beginner programming mistakes into a guide so you don’t have to repeat them.

Grab The Mistakes I Made as a Beginner Programmer today with a special discount.

👉 Get it on Gumroad

💸 Use code MISTAKESDEVTO50 at checkout for 50% off.

DEV Community: Emanuele Bartolesi

Seasoned Developer Advice after 25 years in IT

Ask the question you are embarrassed to ask

Give coordination an owner

Make meetings earn their place

Write code for the person who has to change it

Leave the explanation you would want to find later

Think about the application after it leaves your machine

Review the code without making it personal

Make maintenance part of the plan

Keep learning through things you can use

Choose tools you can trust and understand

Build a way of working you can keep doing

My Windows 11 Laptop Was Struggling with Claude and Codex. Defender Exclusions Helped.

The folders I excluded

How to add a folder exclusion in Windows 11

Moving to European Digital Services, One Decision at a Time

Proton made the change visible

The corporate map is more complicated than the logos

Some changes need almost no migration

Replacing Notion meant building the alternative

Sometimes the correct migration is no migration

The process I use before changing a service

Change the next decision

Emanuele BartolesiFollow

Fixing “Your organization has deleted this device” Without Reconnecting Everything

The command that fixed it

When this helps

A small warning

Stop Coding Through Remote Desktop. Use VS Code Remote Tunnels Instead

The real-world scenario

What VS Code Remote Tunnels actually does

Why it fits this customer use case

How to set it up

Trade-offs and limits

👀 GitHub Copilot quota visibility in VS Code

Using GitHub Copilot CLI with Azure AI Foundry (BYOK Models) – Part 2

Setting Up Azure AI Foundry

1. Create or Use an Existing Resource

2. Deploy a Model

3. Get Endpoint and API Key

4. Build the Final Endpoint

5. Quick Validation

Connecting Copilot CLI to Azure

Set the Environment Variables

Run a Simple Test

Reality Check

👀 GitHub Copilot quota visibility in VS Code

Using GitHub Copilot CLI with Local Models (LM Studio)

What You Need

GitHub Copilot CLI

LM Studio

A Local Model (Be Realistic)

Connecting Copilot CLI to LM Studio

1. Set the Environment Variables

2. Run a Simple Test

Reality Check

When This Setup Makes Sense

1. Privacy-Sensitive Environments

2. Offline Workflows

3. Learning and Understanding AI

When It Does NOT Make Sense

👀 GitHub Copilot quota visibility in VS Code

GitHub Copilot Is Too Nice. Fix It With a Tone of Voice File.

👀 GitHub Copilot quota visibility in VS Code

Git Mirroring During Migrations: `--all` vs `--mirror`

The Common Approach: Pushing Branches and Tags

git push --all

git push --tags

What This Approach Synchronizes

The Full Mirror Option

Quick Recommendation

Use --all + --tags when

Use --mirror when

👀 GitHub Copilot quota visibility in VS Code

GitHub Copilot to Generate Conventional Commit Messages in VSCode and JetBrains Rider

Why Conventional Commits Still Matter

Readable Git History

Using GitHub Copilot for Commit Messages in VS Code

Using GitHub Copilot for Commit Messages in JetBrains Rider

`git push --all`

`git push --tags`

Use `--all` + `--tags` when

Use `--mirror` when

`main`

`develop`

`feature/*`

`release/*`

`hotfix/*`

Tags exist only on `main`

Hotfixes start from `main`