DEV Community: Faith Omobude

Building a Developer Profile That Keeps Working: Introducing Profile Studio

Faith Omobude — Wed, 19 Aug 2026 15:25:00 +0000

Whilst you build, your GitHub profile tells us a lot about the kind of developer you are.

Your repositories show what you build.

Your contributions show that you build consistently.

But your profile README gives people a chance to understand who you are, what you're working on, what you're learning, and what you care about.

Recruiters, developers, collaborators, and potential employers may visit your GitHub profile before they ever speak to you.

And that's what got me thinking:

What if a GitHub profile could be more than just a README?

So I started building Profile Studio.

Introducing Profile Studio

Profile Studio started as a simple idea:

Make it easier for developers to create a good-looking GitHub profile README.

But as I kept building, the idea evolved.

I didn't want to build just another README generator.

I wanted to build a mini landing page for developers that lives directly inside their GitHub profile.

Something that could bring together:

👋 A personalized introduction
🚀 About-me information
🛠️ Technology stack
🔗 Social links
📊 GitHub statistics
📈 Contribution activity
💭 Developer quotes
📝 DEV.to articles
🎨 Custom branding
⚙️ DEV.to automation

The goal is simple:

Your GitHub profile should tell your story without requiring someone to dig through your repositories to understand you.

Why I Built It

I've always found it interesting that developers spend so much time building applications but sometimes spend very little time thinking about how people experience their developer identity.

Your GitHub profile is one of those places.

You might have:

great projects,
interesting repositories,
technical experience,
articles,
certifications,
open-source contributions,

but if someone lands on your profile and sees an empty or generic README, they don't immediately get that context.

Profile Studio is my attempt to solve that.

Not by replacing a portfolio.

Not by replacing your GitHub repositories.

But by creating a better front door to your developer identity.

It's More Than a README Generator

This distinction is important to me.

A README generator usually does something like:

Enter some information → generate Markdown → copy it.

Profile Studio goes a little further.

The application lets you configure your profile visually and generates a README that brings those different pieces together.

And now, it can also package automation for your DEV.to content.

So the generated output isn't just:

README.md

It can also include the supporting files required to keep your DEV.to section updated automatically.

That's where the project became much more interesting from an engineering perspective.

The Architecture Behind Profile Studio

Underneath the interface, Profile Studio is intentionally modular.

The application started with responsibilities living together in a large JavaScript file.

As the project grew, that became increasingly difficult to reason about.

So I started separating responsibilities.

The current architecture looks roughly like this:

                    ┌──────────────────────────┐
                    │       User / Browser     │
                    └────────────┬─────────────┘
                                 │
                                 ▼
                    ┌──────────────────────────┐
                    │       Profile Studio     │
                    │          UI              │
                    │      index.html          │
                    └────────────┬─────────────┘
                                 │
                                 ▼
                    ┌──────────────────────────┐
                    │          app.js           │
                    │   Wizard + UI State Flow  │
                    └────────────┬─────────────┘
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
              ▼                  ▼                  ▼
       ┌────────────┐     ┌────────────┐     ┌────────────┐
       │  state.js  │     │ devto.js   │     │ generator  │
       │            │     │            │     │    .js     │
       │ State      │     │ DEV.to API │     │ Markdown   │
       │ management │     │ integration│     │ generation │
       └────────────┘     └─────┬──────┘     └─────┬──────┘
                                │                  │
                                ▼                  ▼
                         ┌────────────┐      ┌─────────────┐
                         │ DEV.to API │      │ README.md   │
                         └────────────┘      └─────────────┘

                         ┌────────────┐
                         │ security.js│
                         │            │
                         │ URL + HTML │
                         │ sanitizing │
                         └────────────┘

                         ┌────────────┐
                         │ catalog.js │
                         │            │
                         │ Tech/social│
                         │ metadata   │
                         └────────────┘

The major pieces are separated by responsibility:

`app.js`

Handles the application flow and UI interactions.

`state.js`

Owns application state and persistence.

`devto.js`

Handles DEV.to-specific functionality.

`generator.js`

Handles README generation.

`security.js`

Provides output-safety utilities such as URL validation and HTML/Markdown escaping.

`catalog.js`

Contains the catalog of technologies, social platforms, badges, and related configuration.

That separation wasn't where the project started.

It's where the project evolved.

And that evolution taught me something important:

A working application isn't necessarily a well-engineered application.

From "It Works" to "It's Engineered"

It's very easy to look at an application and say:

"It works. Ship it."

But working is only one dimension of good software.

As Profile Studio grew, I started asking different questions:

Can someone else understand this code?
Can I change one feature without breaking three others?
Are important pieces tested?
Is user input handled safely?
What happens when an external service fails?
Can I diagnose problems when something goes wrong?
Does the architecture still make sense as the application grows?

The application wasn't necessarily broken.

But responsibilities were beginning to pile up.

State management was mixed with UI logic.

External integrations were mixed with application logic.

README generation was mixed into the rest of the application.

So I started refactoring.

Not because the application stopped working.

Because I wanted it to be easier to keep working.

That's one of the engineering lessons this project has been teaching me.

Good engineering isn't just about making something work. It's about making it possible for the software to continue working as it evolves.

Security Matters Even at the early stage

One of the things I didn't initially expect to spend so much time thinking about was security.

Profile Studio accepts user-provided information and external URLs.

That means the generated output cannot simply trust everything it receives.

For example, the project has safety helpers such as:

safeUrl()

and:

escapeHtml()

and:

escapeMdText()

These help prevent unsafe URLs and injected markup from being blindly rendered into generated output.

This is something I think is easy to overlook when building seemingly "simple" developer tools.

You might think:

"It's only generating a README."

But the application is still processing input.

And input should be treated as input.

Testing the Application

The project also has automated tests.

At the time of writing, the test suite covers things such as:

DEV.to username normalization
DEV.to URL handling
DEV.to Markdown generation
unsafe article URLs
unsafe cover images
HTML escaping
Markdown escaping
allowed URL schemes
rejected JavaScript URLs
rejected data URLs
safeUrl() behavior

The current test run is:

I also use:

node --check .\js\generator.js
node --check .\js\app.js

and:

npm test

as part of my development workflow.

It's a small project, but I'm trying to apply the same engineering mindset I'd want to use on larger systems.

DEV.to Integration

This is one of the features I'm particularly excited about.

If you enable the DEV.to section in Profile Studio, provide your DEV.to username, select how many posts you want displayed, and enable automated DEV.to fetches, the generated package includes the files needed to automate the README updates.

The package contains:

.github/
├── profile-studio.json
├── scripts/
│   └── update-devto.js
└── workflows/
    └── devto-readme.yml

README.md

The idea is that your GitHub profile can automatically keep its DEV.to section updated instead of requiring you to manually edit the README every time you publish an article.

Setting Up the DEV.to Package

I've tried to make this accessible even if you're relatively new to Git and GitHub.

You don't need to be an expert.

You need:

A GitHub account
A DEV.to account
Your GitHub username
Your DEV.to username
Git installed
The DEV.to Package ZIP generated by Profile Studio

Your GitHub Special Repository

Your GitHub profile README lives in a special repository.

The repository name must be exactly the same as your GitHub username.

For example:

GitHub username:
CloudFay

Special repository:
CloudFay/CloudFay

So:

github.com/CloudFay/CloudFay

The repository should be public.

And then toggle your README.md option ON

Step 1 — Download the DEV.to Package

When you enable the DEV.to integration and configure your username and desired number of posts, Profile Studio can generate the DEV.to package.

Download the .zip file.

For example:

Dev.to-Package.zip

Step 2 — Extract the ZIP

On Windows:

Right-click the ZIP.
Select Extract All...
Extract it somewhere convenient.

You should have something similar to:

Dev.to Package/
├── .github/
└── README.md

NOTE: Because .github is normally treated as a hidden folder, make sure Hidden items are enabled in File Explorer.

Step 3 — Create or Open Your Special Repository

Create your GitHub special repository if you don't already have one.

For example:

CloudFay/CloudFay

Then clone it in your vscode:

git clone https://github.com/YOUR_USERNAME/YOUR_USERNAME.git

Example:

git clone https://github.com/CloudFay/CloudFay.git

Then enter the repository:

cd YOUR_USERNAME

For example:

cd CloudFay

Then run in order to open the repository in your Vscode:

code .

Step 4 — Copy the Package Files

This is where the PowerShell commands make the setup much easier.

If your extracted package is inside your Downloads folder, you can copy the .github folder directly into your repository with:

Copy-Item "$HOME\Downloads\.github" ".github" -Recurse -Force

Then copy the generated README:

Copy-Item "$HOME\Downloads\README.md" "README.md" -Recurse -Force

These commands essentially tell PowerShell:

Take the package's .github directory and README and place them into the repository I'm currently working in.

Verify the `.github` files

Run:

Get-ChildItem ".github" -Recurse -Force

You should see the automation files.

Then verify the README:

Get-ChildItem "README.md" -Recurse -Force

Your repository should now look approximately like:

YOUR_USERNAME/
│
├── .github/
│   ├── profile-studio.json
│   ├── scripts/
│   │   └── update-devto.js
│   └── workflows/
│       └── devto-readme.yml
│
└── README.md

Important: The .github directory must be directly inside the root of your special repository.

You do not want:

YOUR_USERNAME/
└── Dev.to Package/
    └── .github/

You want:

YOUR_USERNAME/
├── .github/
└── README.md

Step 5 — Check Git

Before committing anything, run:

git status

You should see your README and .github changes.

Then:

git add README.md .github

Create a commit:

git commit -m "Add DEV.to integration"

And push:

git push origin main

And then you see this:

Step 6 — Check GitHub Actions

Once the changes reach GitHub:

Open your repository.
Go to Actions.
Find the DEV.to workflow.
Open the workflow run.
Check whether it completed successfully.

GitHub Actions is responsible for running the automation.

Step 7 — Visit Your Profile

Finally, visit:

https://github.com/YOUR_USERNAME

Your generated README should now appear on your profile.

And if the DEV.to automation is configured correctly, your articles can be updated automatically according to the package configuration.

A Small Project, A Lot of Engineering Lessons

Profile Studio started with a relatively simple goal.

Generate a better GitHub profile README.

But building it has exposed me to a much bigger set of engineering problems:

State management.
Modular architecture.
External API integration.
Output security.
Testing.
Git workflows.
GitHub Actions.
Developer experience.
Automation.

And perhaps most importantly:

maintainability.

The project is still evolving.

That's actually part of the point.

I'm building it, breaking things, fixing things, refactoring things, testing things, and documenting what I'm learning along the way.

What's Next?

There are still plenty of things I'd like to explore with Profile Studio.

The project is becoming less about:

"How do I generate a README?"

and more about:

"How can I help developers build a better representation of themselves on GitHub?"

There are features I'd like to improve.

There are architectural decisions I'd like to revisit.

There are probably bugs I haven't discovered yet.

And there are definitely things I would design differently if I started the project again today.

That's part of building software.

You don't always learn everything before you build.

Sometimes building is how you learn.

Try Profile Studio

If you're a developer and want to create your own GitHub profile, you can try Profile Studio here:

🚀 Try Profile Studio

The project is open source, so if you're interested in the implementation, you can also explore the codebase:

💻 View the Profile Studio source code

If you find something that could be improved, have an idea for a feature, or simply want to contribute, I'd love to hear from you.

Final Thought

I'm learning that building software isn't just about getting to the moment where you can say:

"It works."

It's also about asking:

"Can I understand it six months from now?"

"Can someone else contribute to it?"

"Can I safely change it?"

"What happens when something fails?"

"Can I trust what the application produces?"

Those questions are what turn a working application into an engineered application.

And Profile Studio is giving me a very practical place to learn those lessons.

I'm still building. I'm still learning. And this is only the beginning. 🚀

A Working Application Isn't Necessarily a Well-Engineered Application

Faith Omobude — Fri, 14 Aug 2026 08:24:24 +0000

When I started building applications, I used to have a fairly simple definition of success:

𝐈𝐟 𝐢𝐭 𝐰𝐨𝐫𝐤𝐬, 𝐢𝐭'𝐬 𝐰𝐨𝐫𝐤𝐢𝐧𝐠.

And honestly, that mindset makes sense when you're learning.

You build a feature.
You run it.
It works.

You fix a bug.
You run it again.
It works.

You add another feature.

It still works.

So you move on.

But as I've spent more time building and maintaining applications, I'm realizing that "𝐰𝐨𝐫𝐤𝐢𝐧𝐠" 𝐢𝐬 𝐨𝐧𝐥𝐲 𝐨𝐧𝐞 𝐩𝐚𝐫𝐭 𝐨𝐟 𝐠𝐨𝐨𝐝 𝐬𝐨𝐟𝐭𝐰𝐚𝐫𝐞 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠.

An application can work perfectly and still be difficult to maintain.

It can produce the right output while having an architecture that becomes painful to change.

It can pass a few manual tests while having almost no automated protection against regressions.

It can look polished while handling user input poorly.

And it can work today while making tomorrow's development significantly harder.

That's a distinction I'm learning to appreciate.

The questions start changing

Earlier in my development journey, I was mostly asking:

"𝘏𝘰𝘸 𝘥𝘰 𝘐 𝘮𝘢𝘬𝘦 𝘵𝘩𝘪𝘴 𝘧𝘦𝘢𝘵𝘶𝘳𝘦 𝘸𝘰𝘳𝘬?"

Now I'm increasingly asking:

Can someone else understand this code?
Can I change one feature without breaking three others?
Are the important parts tested?
What happens when an external service fails?
Is user input handled safely?
Can I diagnose a problem when something goes wrong?
Are responsibilities separated properly?
Will this architecture still make sense as the application grows?

Those questions don't necessarily make an application look better.

But they can make it last 𝐥𝐨𝐧𝐠𝐞𝐫.

And I think that's where engineering starts becoming different from simply writing code.

I experienced this while building

I recently found myself confronting this while working on a developer tool.

The application worked.

There wasn't some massive bug forcing me to stop everything.

The problem was subtler.

As I added features, responsibilities started accumulating in the same places.

Application state was mixed into the main application logic.

External integrations were living alongside UI behaviour.

README generation was becoming part of a large application file.

Again, nothing was necessarily broken.

But the code was becoming harder to reason about.

And that was enough of a problem.

So I started refactoring.

I extracted application state into its own module.

I separated the DEV.to integration.

I moved README generation into its own generator module.

I added tests around important behaviour.

I introduced security helpers for things like URL validation and output escaping.

And suddenly, the goal of the refactoring became clearer.

I wasn't refactoring because the application stopped working.

I was refactoring because I wanted to make it easier to keep working.

That's a different way of thinking about software

There's a temptation, especially when you're building quickly, to think about engineering quality as something you add later.

First:

Build it.

Then:

Make it work.

Then:

Maybe we'll clean it up.

But I'm starting to think some of these concerns aren't really "cleanup."

Testing isn't cleanup.

Security isn't cleanup.

Good separation of responsibilities isn't cleanup.

Readable code isn't cleanup.

A structure that makes future changes easier isn't cleanup.

They're all part of the product.

Maintainability is a feature

This is probably the biggest lesson I'm taking away.

When we talk about application features, we usually think about things users can directly see:

authentication
dashboards
search
notifications
integrations
reports

But maintainability is also a feature, just one that developers experience rather than end users.

A maintainable application makes it easier to:

𝙪𝙣𝙙𝙚𝙧𝙨𝙩𝙖𝙣𝙙 → 𝙘𝙝𝙖𝙣𝙜𝙚 → 𝙩𝙚𝙨𝙩 → 𝙙𝙚𝙗𝙪𝙜 → 𝙚𝙭𝙩𝙚𝙣𝙙

And that has a real impact on how quickly a team can build.

I'm still learning this

I don't think I've suddenly figured out what "good software engineering" means.

Far from it.

I'm learning by building things, breaking things, refactoring things, reading other people's code, and occasionally looking at something I wrote a few weeks earlier and asking:

"𝙒𝙝𝙮 𝙙𝙞𝙙 𝙄 𝙙𝙤 𝙞𝙩 𝙩𝙝𝙞𝙨 𝙬𝙖𝙮 😂?"

But that's probably part of the process.

The more I build, the more I realize that software engineering isn't simply about making something work.

It's about making something that continues to work as people, requirements, dependencies, and the codebase itself change.

And I'm beginning to appreciate that:

Good engineering isn't just about making software work. It's about making it possible for the software to keep working as it evolves.

That's a lesson I'm taking with me into every project I build from here.

If you're early in your software journey like me, don't feel like you need to understand all of this immediately.

Build things.

Make them work.

Break them.

Fix them.

Then go back and ask:

"What would make this easier to maintain?"

Because sometimes, that's where the real learning begins.

Beyond the Hype: The Realignment of AI Power and the Rise of Model-Agnostic Infrastructure

Faith Omobude — Tue, 10 Mar 2026 11:32:58 +0000

Just as we've seen in the DevOps world, most organizations adopt AI tools, but few truly understand the outcomes they are buying into. In February 2026, the industry moved past the "honeymoon phase" of generative AI and into a gritty, politically charged reality. What we witnessed wasn't just a series of product updates; it was a fundamental realignment of the power structures that govern how we build, deploy, and trust the intelligence that now powers our production systems.

The Loyalty Trap

I've had discussions on DevOps generally, and I often talk about the "tool trap", the mistaken belief that installing a tool is the same as a transformation. In the AI space, we are seeing a similar phenomenon: the "loyalty trap". We’ve spent the last two years tethering our workflows to specific models, assuming that the companies behind them would remain the stable, mission-driven entities they claimed to be.

February 2026 shattered that illusion. From political mega-donations to the militarization of LLMs, the events of the last few weeks have proven that in the world of high-stakes AI, loyalty is a luxury that neither users nor developers can afford. This isn't just a PR crisis; it's a production risk. This is just to say, tech companies are stable ... until they are not.

And your entire AI layer might depend on them.

Now, let's talk

Part 1: The Political Cost of "Neutrality"

The $25 Million Shockwave

The month began with a seismic shift in the public's perception of OpenAI. When the company’s president donated $25M to MAGA, it wasn't just a personal political statement; it was a brand-defining moment that triggered the #QuitGPT movement. Over 700,000 users pledged to cancel their subscriptions within days.

I read this and thought, "Wait... people are migrating AI models because of political donations now?"

Well, I've seen teams migrate their entire stack for far less.

So yes...

What a time to be alive, don't you think?

This highlights a critical lesson for tech leaders: in 2026, your cap table and your political affiliations are as much a part of your "product" as your API response times. For the first time, we saw a massive migration of users not because the technology failed, but because the ethics did.

Welcome to non-functional requirements 2.0

The Monetization Pivot

Around the same time, ChatGPT began showing ads to free users. For a tool that has become the "second brain" for millions of developers, the introduction of interruptive advertising was the final straw.

The result?

Users began migrating towards Claude AI.

Anthropic, which had been positioned as the "safer, more academic" alternative, suddenly found itself the unexpected winner of OpenAI’s aggressive monetization experiment.

SHOCKING!!!!

Tell me why I'm so loving this.

It's like watching two cloud providers fight, and somehow DigitalOcean wins by doing absolutely nothing.

Moving on...

Part 2: The Developer Ecosystem and the "Open" Fallacy

The Peter Steinberger/OpenClaw incident

The developer community, which has always been the backbone of AI adoption, faced its own set of challenges. Anthropic, in a move that can only be described as a PR nightmare, sent a cease-and-desist to Peter Steinberger over the name "ClawdBot." While it was technically a trademark protection move, it felt like a betrayal to the devs who had been Anthropic’s biggest evangelists.

This was followed by Anthropic banning Claude subscription tokens in OpenClaw. In a poetic twist of fate, OpenClaw officially switched to OpenAI models, and Steinberger, the very developer Anthropic had alienated, joined OpenAI to build agents for the competition.

At this point, the story started feeling less like a tech news article and more like:

"Season 3 of Silicon Valley: AI Edition."

You alienate a developer, and the developer joins your competitor.

You can't script that better.

The Lesson for DevOps Leaders: Anti-Patterns in AI Platforms

This is the "Golden Path" in reverse. When you make it difficult for developers to build on your platform, whether through aggressive legal action or sudden API restrictions, they will find the path of least resistance.

In the DevOps industry, we know that Developer Experience (DevEx) is the nervous system of productivity. When DevEx breaks, adoption quietly walks out the door and sometimes takes half your ecosystem with it.

Anthropic's recent moves are a classic anti-pattern. Instead of building a well-lit road for developers to follow, they've erected toll booths and legal barriers.

And developers have a very predictable response to that.

They just leave.

If your legal department is interacting with developers more than your DevRel team, something has probably gone very wrong.

In the talent wars of 2026, your legal department shouldn't be your most active developer relations team.

Part 3: Ethics vs. Expansion: The Battle for the Pentagon

The Great Divergence

Perhaps the most significant event of February 2026 was the divergence in how the two giants approached government contracts. Anthropic made headlines by refusing Pentagon demands for mass surveillance and autonomous weapons integration.

Well... that escalated quickly.

This principled stand, however, came at a cost: the Trump administration subsequently banned every federal agency from using Anthropic, labeling them "left-wing nut jobs."

At that moment, I realized something interesting about AI infrastructure in 2026:

Apparently, model selection is now also a geopolitical decision.

The OpenAI Pivot

The very same night, OpenAI signed a massive deal for the Pentagon's classified network. Sam Altman's subsequent post about "deep respect for safely" rang hollow for many, especially as the company quietly dropped the word "safely" from its own mission statement.

When companies start editing mission statements quietly, engineers start reading commit history like detectives.

This move has profound implications for the software engineering industry.

We can now see the emergence of two distinct AI ecosystems:

The State-Aligned AI: High-scale, government-funded, and deeply integrated into the military-industrial complex.
The Independent AI: Focused on research, safety, and potentially limited by political gatekeeping.

Now we might be choosing between AI political blocs

Now for the main event (Drumrolls please 😂)

Part 4: The Economic Reality: The "Week the AI Replaced Us"

The Block Shockwave: 4,000 Lives for AI

Jack Dorsey's Block (formerly Square) announced a staggering layoff of 4,000 employees, nearly 40% of its workforce.

The reason?

A direct pivot to AI-driven operations.

Dorsey's blunt assessment that "most companies are late" sent a chill through the industry.

Well... that's one way to accelerate your AI adoption roadmap.

This isn't just a corporate restructuring; it's a human displacement spiral. For the first time, a major fintech player has publicly traded half its headcount for automated agents.

In the DevOps world, we've always automated to empower engineers; we are now entering an era where automation is being used to replace them.

And that's a very uncomfortable shift.

For years, we said:
"Automation removes toil."

Now the uncomfortable question appearing in boardrooms is, "What if automation removes the job?"

The Anthropic "Displacement" Report

Adding fuel to the fire, Anthropic released a landmark research report mapping out what some are calling the "Great Recession for White-Collar Workers."

The findings were sobering.

While mass layoffs hadn't fully materialized across the board yet, the youngest workers in high-exposure fields (like junior developers and QA engineers) are already being squeezed out of the hiring market.

Every generation of engineers is told, "Learn this new technology or get left behind," but this time I hear, "Learn how to work with AI... or compete against it."

And that is a very different ballgame entirely.

Part 5: The Impact on the DevOps Industry and Tech as a whole

The Shift from Model Loyalty to Model Agnosticism

In DevOps, we prioritize resilience and portability. The events of February 2026 have forced us to apply these same principles to our AI integrations. We are moving from a world of "ChatGPT-first" to a world of "Model-Agnostic Infrastructure"

Aspect	The "Loyalty" Era (Pre-Feb 2026)	The "Agnostic" Era (Post-Feb 2026)
Vendor Strategy	Single-model dependency (mostly OpenAI)	Multi-model orchestration (Claude, GPT, Llama)
Integration	Hard-coded API calls	Abstracted "AI Gateway" layers
Risk Management	Performance-based metrics	Ethics-based, political, and labor risk assessments
Workforce	Scaling via headcount	Scaling via Agentic Orchestration
Developer Sentiment	Evangelism for specific brands	Pragmatic, survival-first approach

The "Safely" Omission and the Trust Deficit

The removal of "safely" from OpenAI's mission statement is more than just a linguistic change; it's a signal to every Site Reliability Engineer (SRE) and DevOps lead that the guardrails are being loosened in favor of rapid deployment.

In production, we treat "safety" as a non-functional requirement that is as critical as latency or uptime. If the provider is deprioritizing it, we must Shift Left our AI validation. We can no longer treat LLM outputs as trusted data; they must be treated as untrusted user input that requires rigorous automated testing and observability.

Conclusion: The Toxic Situationship

As we look at the fallout of February 2026, the conclusion is clear: we are all in a toxic situationship with every AI company. The #CancelChatGPT trend proved that users will rotate back to Claude the moment OpenAI crosses a line, only to return to GPT when Anthropic makes a misstep.

In the DevOps and software engineering industry, this means we must architect for model agnosticism. Just as we don't tie our entire infrastructure to a single cloud provider without a multi-cloud strategy, we can no longer afford to tie our intelligence layer to a single provider.

The future of tech isn't about loyalty; it's about resilience. It's about building systems that can swap models as easily as we swap containers. Because in this landscape, the only thing you can count on is that the company you trust today will likely be the one you're trying to quit by next Tuesday.

How is your team handling the shift toward model agnosticism in your CI/CD pipelines? Are you building "AI gateways" yet?, or still hard-coding your API calls?

Let's discuss in the comments!

Let's keep making it REAL

Stay tuned for more adventures 😊!

LinkedIn | GitHub | X

GitHub Copilot CLI Challenge: I Built an AI Mentor in My Terminal

Faith Omobude — Sun, 15 Feb 2026 17:02:49 +0000

**This is a submission for the GitHub Copilot CLI Challenge

What I Built

I didn't build clioraOps because I wanted another CLI tool.

I built it because I was tired of pretending I fully understood what I was running in my terminal.

A year ago, when I started my cloud/DevOps journey, I noticed a pattern in how I was learning. I would search for a command, copy it, run it, and move on once it worked. The problem was that execution became faster, but understanding didn't always follow.

If something broke later, I had to start over.

And in DevOps, that's dangerous.

Infrastructure mistakes aren't always obvious. A single command can delete data, expose services, or break prodution systems. I realized that many learners including myself, were optimizing for speed instead of comprehension.

So I built clioraOps

clioraOps is an AI-powered DevOps learning companion that lives inside the terminal. Instead of just giving answers, it focuses on helping developers understand what they are doing before they execute it.

The goal isn't automation

The goal is confidence through understanding.

clioraOps helps users:

Understand deeply through contextual explanations
Learn safely by reviewing commands before execution
Visualize system architectures directly in the terminal
Generate production-ready configurations using best practices
Debug errors with guided reasoning instead of guesswork

Demo

GitHub Repository: https://www.github.com/CloudFay/clioraOps

Example Interactions

Asking conceptual questions in natural language
Safely testing risky commands before execution
Generating production-ready Docker or CI/CD configurations
Visualizing architectures like microservices or pipelines
Debugging infrastructure errors step-by-step

The experience is conversational but structured around learning rather than shortcuts.

My Experience with GitHub Copilot CLI

GitHub Copilot CLI played a major role in how this project evolved.

Initially, I approached it as a productivity tool — something that could help generate commands faster. But during development, it became more than that. It became a thinking partner inside the terminal.

The biggest challenge wasn’t writing code. It was understanding how to structure interactions between Python workflows and an AI-driven CLI environment.

Some challenges I faced included:

Version and command format changes during development
Handling subprocess interactions cleanly
Designing prompts that encouraged explanation instead of shortcuts
Debugging environment and installation issues across systems
Balancing flexibility with safety in command execution

There were moments where things broke repeatedly especially around CLI integrations and environment setup but those moments forced me to understand the tooling at a deeper level.

The biggest realization was this:

Copilot CLI is most powerful when used as a collaborator, not just an autocomplete tool.

It helped accelerate experimentation while still allowing me to stay in control of architecture and decision-making.

For someone building DevOps tools, that balance matters.

Challenges Faced

Building ClioraOps came with several practical challenges:

Designing an MVP without overcomplicating the architecture
Ensuring safety checks didn’t slow down interaction
Making AI explanations useful for both beginners and advanced users
Supporting both cloud AI (Gemini) and local models (Ollama)
Structuring the project so it remains extensible as features grow

One of the hardest parts was resisting the urge to add more features early. Keeping the MVP focused on learning, safety, and clarity made the tool stronger.

What This Project Means to Me

ClioraOps represents my transition from simply learning tools to building tools that help others learn better.

DevOps can feel overwhelming at the beginning. There are too many tools, too many commands, and too many ways to break things.

I wanted to build something that reduces fear without removing responsibility.

Something that teaches before it executes.

And something that grows with the developer using it.

Final Thoughts

AI is changing how we build software.

But understanding still matters.

clioraOps is my attempt to make sure speed doesn’t replace learning, especially in infrastructure and DevOps, where understanding is the difference between automation and reliability.

If you’re learning DevOps or building in the terminal every day, I’d love your feedback.

Hey Dev.to 👋

Faith Omobude — Tue, 20 Jan 2026 11:47:26 +0000

Hey Dev.to Community 👋

My name is Faith Omobude, an aspiring Cloud/DevOps Engineer with a passion for building robust, scalable infrastructure solutions.

A bit about myself: I'm a Chemistry graduate with a background in Content writing and Digital marketing. Before I began my journey in Cloud, I worked as a social media manager at Cubithost. While researching and creating tech-related content, I kept coming across topics related to cloud computing.

Initially, it was simply curiosity.

I wanted to understand how modern applications scale and get deployed so smoothly across the world. How do apps stay available? How does everything "just work" behind the scenes?

That curiosity slowly turned into a hands-on journey of learning and building with cloud technologies, and that's how my Cloud and DevOps journey really began.

Why I created this Blog?

I created this account to document my journey in DevOps and Cloud, and more importantly, to break down complex concepts in a way beginners (like me) can understand.

Because let's be honest, DevOps can feel overwhelming. There are:

Too many tools,
Too much hype and
Too many tutorials that assume you already "get it".

I'm not here to pretend I know everything.
I'm here to learn in public, share what I build, explain what I understand, and be honest about what I don't.

Writing helps me clearly, and if it helps someone else along the way, that's a win.

What You Can Expect From this Blog

I'll be writing about:

🧠 Beginner-friendly explanations of Cloud, DevOps, and related concepts
🔨 Projects I'm working on, including what breaks and what I learn
💡 Mental models, not just commands and configurations
🔥 Honest opinions on tools, trends, and industry hype
📈 Career and learning insights for people just starting out

My goal is simple:

Make confusing things feel approachable.

Who This is For

This blog is mainly for:

Beginner learning Cloud or DevOps
Developers transitioning into DevOps
Anyone tired of overcomplicated explanations

If that sounds like you, welcome 🤗

If you ever disagree with something I write, or have a better way of thinking about it, I'd love to hear from you. Learning is better when it's shared.

Looking forward to connecting and collaborating with you.

CloudFay out 😎

DEV Community: Faith Omobude

Building a Developer Profile That Keeps Working: Introducing Profile Studio

Introducing Profile Studio

Why I Built It

It's More Than a README Generator

The Architecture Behind Profile Studio

app.js

state.js

devto.js

generator.js

security.js

catalog.js

From "It Works" to "It's Engineered"

Security Matters Even at the early stage

Testing the Application

DEV.to Integration

Setting Up the DEV.to Package

Your GitHub Special Repository

Step 1 — Download the DEV.to Package

Step 2 — Extract the ZIP

Step 3 — Create or Open Your Special Repository

Step 4 — Copy the Package Files

Verify the .github files

Step 5 — Check Git

Step 6 — Check GitHub Actions

Step 7 — Visit Your Profile

A Small Project, A Lot of Engineering Lessons

What's Next?

Try Profile Studio

Final Thought

A Working Application Isn't Necessarily a Well-Engineered Application

The questions start changing

I experienced this while building

That's a different way of thinking about software

Maintainability is a feature

I'm still learning this

Beyond the Hype: The Realignment of AI Power and the Rise of Model-Agnostic Infrastructure

The Loyalty Trap

Part 1: The Political Cost of "Neutrality"

Part 2: The Developer Ecosystem and the "Open" Fallacy

Part 3: Ethics vs. Expansion: The Battle for the Pentagon

Part 4: The Economic Reality: The "Week the AI Replaced Us"

Part 5: The Impact on the DevOps Industry and Tech as a whole

Conclusion: The Toxic Situationship

GitHub Copilot CLI Challenge: I Built an AI Mentor in My Terminal

What I Built

Demo

My Experience with GitHub Copilot CLI

Challenges Faced

What This Project Means to Me

Final Thoughts

Hey Dev.to 👋

`app.js`

`state.js`

`devto.js`

`generator.js`

`security.js`

`catalog.js`

Verify the `.github` files