Github Copilot for the Rest of Us

by Joche Ojeda | Feb 4, 2026 | A.I

How GitHub Copilot Became My Sysadmin, Writer, and Creative Partner

When people talk about GitHub Copilot, they almost always describe it the same way: an AI that writes code.
That’s true—Copilot can write code—but treating it as “just a coding tool” is like calling a smartphone
“a device for making phone calls.”

The moment you start using Copilot inside Visual Studio Code, something important changes:
it stops being a code generator and starts behaving more like a context-aware work partner.
Not because it magically knows everything—but because VS Code gives it access to the things that matter:
your files, your folders, your terminals, your scripts, your logs, and even your remote machines.

That’s why this article isn’t about code autocomplete. It’s about the other side of Copilot:
the part that’s useful for people who are building, maintaining, writing, organizing, diagnosing, or shipping
real work—especially the messy kind.

Copilot as a Linux Server Sidekick

One of my most common uses for Copilot has nothing to do with application logic.
I use it for Linux server setup and diagnostics.

If you run Copilot in VS Code and you also use Remote development (SSH), you essentially get a workspace that can:

Connect to Linux servers over SSH
Edit remote configuration files safely
Run commands and scripts in an integrated terminal
Search through logs and system files quickly
Manage folders like they’re local projects

That means Copilot isn’t “helping me code.” It’s helping me operate.

I often set up hosting and administration tools like Virtualmin or Webmin, or configure other infrastructure:
load balancers, web servers, SSL, firewall rules, backups—whatever the server needs to become stable and usable.
In those situations Copilot becomes the assistant that speeds up the most annoying parts:
the remembering, the searching, the cross-checking, and the “what does this error actually mean?”

What this looks like in practice

Instead of bouncing between browser tabs and old notes, I’ll use Copilot directly in the workspace:

“Explain what this service error means and suggest the next checks.”
“Read this log snippet and list the most likely causes.”
“Generate a safe Nginx config for this domain layout.”
“Create a hardening checklist for a fresh VPS.”
“What would you verify before assuming this is a network issue?”

The benefit isn’t that Copilot is always right. The benefit is that it helps you move faster with less friction—
and it keeps your work inside the same place where the files and commands actually live.

Copilot as an Operations Brain (Not Just a Code Brain)

Here’s the real mental shift:

Copilot doesn’t need to write code to be useful. It needs context.

In VS Code, that context includes the entire workspace: configuration files, scripts, documentation, logs,
command history, and whatever you’re currently working on. Once you realize that, Copilot becomes useful for:

Debugging infrastructure problems
Translating “error messages” into “actionable steps”
Drafting repeatable setup scripts
Creating operational runbooks and checklists
Turning tribal knowledge into documentation

It’s especially valuable when the work is messy and practical—when you’re not trying to invent something new,
you’re trying to make something work.

Copilot as a Writing Workspace

Now switch gears. One of the best non-coding Copilot stories I’ve seen is my cousin Alexandra.
She’s writing a small storybook.

She started the way a lot of people do: writing by hand, collecting pages, keeping ideas in scattered places.
At one point she was using Copilot through Microsoft Office, but I suggested a different approach:

Use VS Code as the creative workspace.

Not because VS Code is “a writing tool,” but because it gives you structure for free:

A folder becomes the book
Each chapter becomes a file
Markdown becomes a simple, readable format
Git (optionally) becomes version history
Copilot becomes the editor, brainstormer, and consistency checker

In that setup, Copilot isn’t writing the story for you. It’s helping you shape it:
rewrite a paragraph, suggest alternatives, tighten dialogue, keep a consistent voice,
summarize a scene, or generate a few options when you’re stuck.

Yes, Even Illustrations (Within Reason)

This surprises people: you can also support simple illustrations inside a VS Code workspace.
Not full-on painting, obviously—but enough for many small projects.

VS Code can handle things like vector graphics (SVG), simple diagram formats, and text-driven visuals.
If you describe a scene, Copilot can help generate a starting SVG illustration, and you can iterate from there.
It’s not about replacing professional design—it’s about making it easier to prototype, experiment,
and keep everything (text + assets) together in one organized place.

The Hidden Superpower: VS Code’s Ecosystem

Copilot is powerful on its own. But its real strength comes from where it lives.

VS Code brings the infrastructure:

Extensions for almost any workflow
Remote development over SSH
Integrated terminals and tasks
Search across files and folders
Versioning and history
Cross-platform consistency

So whether you’re configuring a server, drafting a runbook, organizing a book, or building a folder-based project,
Copilot adapts because the workspace defines the context.

The Reframe

If there’s one idea worth keeping, it’s this:

GitHub Copilot is not a coding tool. It’s a general-purpose work companion that happens to be excellent at code.

Once you stop limiting it to source files, it becomes:

A sysadmin assistant
A documentation partner
A creative editor
A workflow accelerator
A “second brain” inside the tools you already use

And the best part is that none of this requires a new platform or a new habit.
It’s the same VS Code workspace you already know—just used for more than code.

From Airport Chaos to Spec Clarity: How Writing Requirements Saved My Sanity

by Joche Ojeda | Sep 24, 2025 | Github Spec Kit, Vibe Code, Vibe document

I thought vibe coding was chaotic at home. Try doing it while traveling halfway across the world.

Between layovers, hotel lobbies, and unpredictable Wi-Fi, I convinced myself I could keep momentum by letting AI carry the weight. Just toss it some prompts, let it generate code, and keep vibing in transit. Sounds good, right?

It wasn’t. Instead of progress, I found myself trapped in the same entropy loop as before—except now with added airport noise and bad coffee. It finally hit me: coding wasn’t the hard part anymore. The real challenge was lowering the chaos of my ideas into clear, executable requirements.

The Travel Chaos of Vibe Coding

While bouncing from Saint Petersburg to El Salvador, I leaned on vibe coding like a crutch. I threw half-formed prompts at the AI:

“Build me a service that works offline.”
“Hook this into a booking flow.”
“Make it sync when online again.”

And, of course, the AI delivered: endless snippets, scaffolds, and fragments. But none of it fit together. It was like watching a band jam without ever agreeing on the key. Six hours in, all I had was a disjointed mess—again.

Enter GitHub Spec Kit and New Perspectives

Somewhere between flights, I stumbled on GitHub Spec Kit, thanks to a Visual Studio Code podcast episode: Let it Cook – Introducing Spec Kit for Spec-Driven Development! (Episode 13).

Not long after, I tuned into the Merge Conflict podcast: All in on Spec-Driven Development (Episode 479), where James Montemagno and Frank Kruger broke down what spec-driven workflows really mean for developers.

Spec Kit showed me a different angle: instead of treating the AI like a mind reader, treat it like a contractor. Write clear specs, break them down into tasks, and then let the AI handle execution.

James and Frank went further. They contrasted waterfall (where everything is specified upfront) with agile (where progress is iterative and requirements evolve). Their point was simple but profound: no matter the methodology, you can’t skip requirements. Even agile depends on clarity at each iteration.

The Programmer’s True Role

That’s when it clicked: my job as a human programmer isn’t to crank out lines of code anymore. The AI can do that faster than I ever could. My job is to reduce entropy.

I take vague ideas, half-baked business rules, and chaotic travel thoughts—and refine them into something structured. That’s the blueprint AI thrives on. Without it, I’m asking the model to improvise a symphony from random notes. With it, I get clean, working solutions in minutes.

Why Requirements Are the Real Magic

Spec Kit and similar tools are amazing, but they don’t remove the hardest part—they expose it. Writing good requirements is the bottleneck. Once that’s done, the rest flows.

Think of it this way:

Vibe coding while traveling = chaos squared.
Spec-driven clarity = progress even in noisy, unpredictable environments.

It’s not about choosing waterfall or agile. It’s about embracing the timeless truth that clarity upfront—whether in a full spec or a tight user story—is what makes AI effective.

Conclusion

My journey from vibe coding on the road to spec-driven clarity taught me that code is no longer the hardest problem. The real magic lies in writing requirements that reduce chaos and give AI a fighting chance to deliver.

So next time you feel tempted to vibe code—whether at home or 30,000 feet in the air—pause. Write the requirement. Structure the idea. Then let the AI do what it does best: execute clarity at scale.

Because in the end, humans reduce entropy. AI executes it.

Related Articles

From Vibe Coding to Vibe Documenting: How I Turned 6 Hours of Chaos into 8 Minutes of Clarity | Joche Ojeda

Introduction to Machine Learning in C#: Spam Detection using Binary Classification

by Joche Ojeda | Dec 13, 2023 | A.I

Introduction to Machine Learning in C#: Spam using Binary Classification

This example demonstrates the basics of machine learning in C# using ML.NET, Microsoft’s machine learning framework specifically designed for .NET applications. ML.NET offers a versatile, cross-platform framework that simplifies integrating machine learning into .NET applications, making it accessible for developers familiar with the .NET ecosystem.

Technologies Used

C#: A modern, object-oriented programming language developed by Microsoft, which is widely used for a variety of applications. In this example, C# is used to define data models, process data, and implement the machine learning pipeline.
ML.NET: An open-source and cross-platform machine learning framework for .NET. It is used in this example to create a machine learning model for classifying emails as spam or not spam. ML.NET simplifies the process of training, evaluating, and consuming machine learning models in .NET applications.
.NET Core: A cross-platform version of .NET for building applications that run on Windows, Linux, and macOS. It provides the runtime environment for our C# application.

The example focuses on a simple spam detection system. It utilizes text data processing and binary classification, two common tasks in machine learning, to classify emails into spam and non-spam categories. This is achieved through the use of a logistic regression model, a fundamental algorithm for binary classification problems.

Creating an NUnit Test Project in Visual Studio Code

Setting up NUnit for DecisionTreeDemo

Install .NET Core SDK

Download and install the .NET Core SDK from the .NET official website.
Install Visual Studio Code

Download and install Visual Studio Code (VS Code) from here. Also, install the C# extension for VS Code by Microsoft.
Create a New .NET Core Project

Open VS Code, and in the terminal, create a new .NET Core project:
```
dotnet new console -n DecisionTreeDemo
cd DecisionTreeDemo
```
Add the ML.NET Package

Add the ML.NET package to your project:
```
dotnet add package Microsoft.ML
```
Create the Test Project

Create a separate directory for your test project, then initialize a new test project:
```
    
mkdir DecisionTreeDemo.Tests
cd DecisionTreeDemo.Tests
dotnet new nunit
```

Add Required Packages to Test Project

Add the necessary NUnit and ML.NET packages:

dotnet add package NUnit
dotnet add package Microsoft.NET.Test.Sdk
dotnet add package NUnit3TestAdapter
dotnet add package Microsoft.ML

Reference the Main Project

Reference the main project:

    dotnet add reference ../DecisionTreeDemo/DecisionTreeDemo.csproj

Write Test Cases

Write NUnit test cases within your test project to test different functionalities of your ML.NET application.

Define the Data Model for the Email

Include the content of the email and whether it’s classified as spam.

    
public class Email
{
    [LoadColumn(0)]
    public string Content { get; set; }

    [LoadColumn(1), ColumnName("Label")]
    public bool IsSpam { get; set; }
}

Define the Model for Spam Prediction

This model is used to determine whether an email is spam.

  
public class SpamPrediction
{
    [ColumnName("PredictedLabel")]
    public bool IsSpam { get; set; }
}

Write the test case

       
// Create a new ML context for the application, which is a starting point for ML.NET operations.
        var mlContext = new MLContext();

        // Example dataset of emails. In a real-world scenario, this would be much larger and possibly loaded from an external source.
        var data = new List
        {
            new Email { Content = "Buy cheap products now", IsSpam = true },
            new Email { Content = "Meeting at 3 PM", IsSpam = false },
            // Additional data can be added here...
        };

        // Load the data into the ML.NET data model.
        var trainData = mlContext.Data.LoadFromEnumerable(data);

        // Define the data processing pipeline. Here we are featurizing the text (i.e., converting text into numeric features) and then     applying a logistic regression model.
        var pipeline = mlContext.Transforms.Text.FeaturizeText("Features", nameof(Email.Content))
            .Append(mlContext.BinaryClassification.Trainers.SdcaLogisticRegression());

        // Train the model on the loaded data.
        var model = pipeline.Fit(trainData);

        // Create a prediction engine for making predictions on individual data samples.
        var predictionEngine = mlContext.Model.CreatePredictionEngine<Email, SpamPrediction>(model);

        // Create a sample email to test the model.
        var sampleEmail = new Email { Content = "Special discount, buy now!" };
        var prediction = predictionEngine.Predict(sampleEmail);

        // Output the prediction to the console.
        Debug.WriteLine($"Email: '{sampleEmail.Content}' is {(prediction.IsSpam ? "spam" : "not spam")}");
        Assert.IsTrue(prediction.IsSpam);

Running Tests

Run the tests with the following command:

dotnet test

As you can see the test will pass because the sample email contains the word “buy” that was used in the training data and was labeled as spam

You can download the source code for this article here

This article has explored the fundamentals of machine learning in C# using the ML.NET framework. By defining specific data models and utilizing ML.NET’s powerful features, we demonstrated how to build a simple yet effective spam detection system. This example serves as a gateway into the vast world of machine learning, showcasing the potential for integrating AI technologies into .NET applications. The skills and concepts learned here lay the groundwork for further exploration and development in the exciting field of machine learning and artificial intelligence.