Tag Archives: artificial-intelligence

Monitor displaying Python code and an AI coding assistant beside a keyboard and mouse

Free AI Coding in GitHub Codespaces with Ox Alpha

If you want a cloud-based coding environment where you can open a GitHub repository, ask an AI to inspect and edit the code, and avoid paying for a separate coding-agent subscription, there is a surprisingly simple setup:

GitHub Codespaces + VS Code + OpenRouter + Ox Alpha

At the time of writing, Ox Alpha (stealth/ox-alpha) is available through OpenRouter for free, with a 1-million-token context window. OpenRouter describes it as a reasoning model designed specifically for coding and sustained agentic work.

The key is that you don’t actually need OpenCode or another separate coding application. VS Code can connect to OpenRouter and use the model from its built-in AI tooling.

What you’ll need

  • A GitHub account
  • A GitHub repository containing your project
  • GitHub Codespaces
  • VS Code’s AI/agent features
  • An OpenRouter account
  • An OpenRouter API key

GitHub Codespaces provides a cloud-hosted development environment that can be opened directly in the browser or through VS Code.


1. Create an OpenRouter API key

Go to:

OpenRouter API Keys

Create a new API key and copy it somewhere safe.

At present, OpenRouter lists Ox Alpha as:

  • Model: stealth/ox-alpha
  • Price: Free
  • Context: 1,048,576 tokens
  • Provider: Stealth

Important: “Free” is the current pricing for the model and can change. Check the OpenRouter model page before relying on it for a longer-term project.


2. Add the key to GitHub Codespaces

Don’t put your API key directly into your repository.

GitHub provides Codespaces secrets specifically for credentials such as API tokens.

Go to your GitHub account’s Codespaces settings:

GitHub Codespaces settings

Create a new secret:

Name:

OPENROUTER_API_KEY

Value:

Your OpenRouter API key.

Give the secret access to your repository

This part is easy to miss.

When creating the secret, make sure the repository containing your Codespace is included in the secret’s repository access.

Codespaces secrets can be assigned to repositories you have access to.


3. Open your Codespace

Open your repository and launch a Codespace.

Once VS Code has loaded, open Chat.

You don’t need to install OpenCode, Codex CLI, or an OpenRouter package.


4. Add OpenRouter to VS Code

In the VS Code Chat interface, click the current model selector.

For example, you may initially see:

Auto

Choose:

Manage Models

Then:

Add Models

Select:

OpenRouter

VS Code will ask for your OpenRouter API key.

Enter the key you created earlier.

VS Code will then retrieve the models available through OpenRouter.


5. Find Ox Alpha

In the model list, search for:

Ox Alpha

You should find:

stealth/ox-alpha

Select/add it.

You can subsequently return to Manage Models to see OpenRouter and the models you’ve added.


6. Use Ox Alpha as your coding agent

Now comes the useful part.

Select Ox Alpha as your model and use VS Code’s Agent mode.

Give it a simple read-only task first:

Inspect this repository and explain what the application does. Identify the main entry point and the most important files. Don’t modify anything yet.

If it successfully examines the project, you know the agent has access to your workspace.

Then you can give it an editing task:

Find the cause of the current bug. Explain what you found, then fix it and run the relevant tests.

The agent can then work with the files in your Codespace rather than simply answering questions about code pasted into a chat window.


7. A useful first prompt

When starting on an unfamiliar repository, I recommend:

First inspect the repository and understand its architecture. Don’t make any changes. Tell me what the application does, what framework it uses, where the main entry point is, and where I should look for the functionality I’m interested in.

Once you’ve established that it understands the project, you can give it permission to make changes.

For example:

Implement the change we discussed. You may edit the necessary files and run tests. Don’t modify unrelated parts of the project. At the end, summarize every file you changed and the tests you ran.


What this setup gives you

The final setup is:

GitHub Repository       

GitHub Codespace

VS Code

VS Code Agent

OpenRouter

Ox Alpha

You get a cloud development environment + AI coding agent + Ox Alpha without needing a separate OpenCode subscription.


One important privacy consideration

There’s a significant caveat with Ox Alpha.

OpenRouter currently states that Ox Alpha is operated by a third-party provider called Stealth, and that prompts and completions are retained by the provider, although they are not used for training.

So I’d avoid using this setup with:

  • API keys
  • passwords
  • private customer information
  • proprietary secrets
  • sensitive production data

And make sure secrets aren’t sitting in your repository for the agent to accidentally read.


The result

The attractive part of this setup is that there are three separate pieces, each doing one job:

GitHub Codespaces gives you the actual cloud computer and repository.

VS Code Agent provides the interface that can understand and work on your codebase.

OpenRouter + Ox Alpha provides the AI model. OpenRouter currently lists Ox Alpha as free and specifically describes it as being designed for coding and sustained agentic work.

So you can essentially turn a GitHub repository into a free, browser-based AI coding workspace with Ox Alpha doing the coding.

Person facing a security gate undergoing facial recognition scan on a digital device

When “Consent” Isn’t a Choice: Why Being Forced to Hand Over Your Face Should Worry All of Us

Imagine buying tickets online, from one of the biggest ticketing platforms, for years without a problem. Then one day your account is quietly frozen. You can still see your past orders, but you can no longer buy anything. There was no warning, no explanation of what you did wrong, and no human you can talk to. To get your account working again, the company tells you there is exactly one path forward: submit a scan of your face to a third-party verification company.

That’s it. No document check. No phone call. No manual review. A facial scan, or nothing.

This is happening now, to ordinary customers, at major platforms. And while it might look like a minor inconvenience, it touches some of the most important protections we have under data protection law. Here’s why it matters — not just for one person, but for everyone.

The problem with calling it “consent”

Your face is not like an email address or a postcode. Under the GDPR, a facial scan used to identify you is special-category biometric data — the most sensitive tier of personal information, alongside health records and religious beliefs. The law sets a deliberately high bar for processing it. In most consumer situations, the only realistic legal basis is your explicit consent.

But consent has a precise legal meaning. It must be:

  • Freely given — a genuine choice, with no penalty for saying no.
  • Specific and informed — you know exactly what you’re agreeing to and who gets your data.
  • Explicit — a clear, affirmative act, not something inferred from your behaviour.

Now hold that definition against how these schemes actually work. You’re told your account will stay restricted unless you provide the scan. When you ask whether there’s any other way to prove who you are, you’re told — in writing — that there is no alternative, and that the facial scan is a condition of using the service again.

Pause on that. If something is a condition with no alternative, it is not a choice. And if it is not a choice, it cannot be “freely given consent.” You can’t dress up a requirement as a favour by calling it consent on the sign-up screen. Regulators and the courts have been clear about this for years: consent that is bundled into service access, and backed by a penalty for refusing, is not valid consent at all.

There’s an even simpler tell. Some of these systems treat you as having “consented” merely by proceeding with the verification. But consent to biometric processing must be explicit — a deliberate, unambiguous act. “You clicked next, so you agreed” is the opposite of explicit.

The illusion of alternatives

Companies defending these schemes often point to “options.” Look closely and the options tend to evaporate:

  • “Just delete your account and make a new one.” Except account deletion is frequently blocked if you’re holding tickets or orders for a future event — so you can’t leave even if you want to. And a new account runs through the same risk-scoring system, so it can be flagged and sent down the exact same biometric funnel.
  • “Completing the check restores access.” Sometimes the fine print admits it doesn’t guarantee anything.

When every exit is a dead end, the “choice” is theatre. What’s really happening is compulsory biometric collection wearing a consent costume.

Decisions made by a machine, with no one accountable

Many of these account restrictions are triggered by an automated risk-scoring model — an algorithm that decides you look suspicious. You’re rarely told what data points it used, how it weighed them, or why you specifically were flagged.

The GDPR anticipated exactly this. It gives people rights around decisions made solely by automated means that significantly affect them, including the right to meaningful human intervention and an explanation. But “human review” only counts if a human can actually reach a different outcome. If the review’s only possible result is “comply with what the algorithm already demanded,” and the company won’t explain how it reached its conclusion, that isn’t meaningful oversight. It’s a rubber stamp with a person’s name on it.

Transparency you were never given

Data protection law requires companies to tell you, up front, what they do with your data and who they share it with. Yet in several of these cases:

  • The privacy notice names some fraud-screening partners but not the biometric verification provider actually collecting your face.
  • The notice may even state the company doesn’t typically make automated decisions — while an automated model is quietly freezing accounts.

You cannot meaningfully consent to something you were never told was happening. Transparency isn’t a nicety; it’s the foundation the rest of the framework stands on.

Collecting more than necessary — and keeping it too long

Two more principles are at stake:

  • Data minimisation — you should only collect what’s genuinely necessary. If a document check or manual review can confirm someone’s identity, insisting on a facial scan and refusing every less-intrusive method suggests the goal is to harvest biometrics, not to verify identity.
  • Storage limitation — sensitive data shouldn’t be kept longer than needed. When biometric data from failed or refused checks is retained for years — often because the company chose a long retention period, not because any law requires it — that’s a serious overreach.

Why this is bigger than tickets

It’s tempting to shrug this off. It’s just an entertainment account, right? But the principle scales terrifyingly well. Once we accept “hand over your biometrics or lose access” as a normal way to use everyday services, the same logic can be applied to banking, travel, utilities, healthcare portals — anything. Your face is not a password you can change if it leaks. Once it’s captured, scored, shared with third parties, and stored, you have permanently lost control of it.

Biometric coercion normalised in low-stakes contexts becomes biometric coercion everywhere.

What people can actually do

If you find yourself in this position:

  1. Ask, in writing, for the specific legal basis for processing your biometric data, and request a non-biometric alternative (document check or manual review).
  2. Request the logic behind any automated decision affecting you, and ask for genuine human review.
  3. Make a Subject Access Request to see what data they hold and how it’s being used.
  4. Keep every reply. A company’s own written words — “there is no alternative,” “this is a condition” — are often the strongest evidence that its “consent” basis doesn’t hold up.
  5. Complain to your data protection authority. In Ireland that’s the Data Protection Commission; across the EU, every country has one. Regulators can investigate lawful basis, transparency, automated decision-making, and retention — and can order companies to change course.

The bottom line

Fraud prevention is a legitimate goal. Nobody disputes that companies need to protect their platforms. But the law is clear that fighting fraud does not give a company a blank cheque to demand the most sensitive data you have, strip away real alternatives, hide who’s involved, and then call the result “consent.”

Consent means the freedom to say no. The moment saying no costs you the service, it stops being consent — and starts being coercion. Recognising that difference, and pushing back when the line is crossed, is how we keep it from becoming the default for everything.

Comprehensive Guide to Helping an Ai Coding Agent Identify and Avoid Common Coding Bad Practices

Introduction

In large projects, subtle anti-patterns can slip through reviews—like importing modules mid-file or conditionally. These non-standard import placements obscure dependencies, make static analysis unreliable, and lead to unpredictable runtime errors. This web article dives into that practice, outlines a broader set of coding bad practices, and even provides a ready-to-use AI coding agent prompt to catch every issue across your codebase.

What Is Non-Standard Import Placement?

Imports or require statements buried inside functions, conditional branches, or midway through a file violate expectations of where dependencies live. Best practices and most style guides mandate that:

  • All imports sit at the top of the file, immediately after any module docstring or comments.
  • Conditional or lazy loading only happens with clear justification and documentation.

When imports are scattered:

  1. Static analysis tools can’t reliably determine your project’s dependency graph.
  2. Developers hunting for missing or outdated modules lose time tracing hidden import logic.
  3. You risk circular dependencies, initialization bugs, or runtime surprises.

A Broader List of Coding Bad Practices

Below is a table of widespread anti-patterns—some classic hygiene issues and others that modern AI agents might inject or overlook:

Bad PracticeDescription
Spaghetti CodeCode with no clear structure making maintenance difficult.
Hardcoding ValuesEmbedding constants directly instead of using config or constants.
Magic Numbers/StringsUsing unexplained literals instead of named constants.
Global State AbuseOverusing global variables causing unpredictable side effects.
Poor Naming ConventionsUsing vague or misleading variable and function names.
Lack of ModularityWriting large monolithic blocks instead of reusable functions.
Copy-Paste ProgrammingDuplicating code rather than abstracting shared logic.
No Error HandlingIgnoring exceptions or failing to validate inputs.
OverengineeringAdding unnecessary complexity or abstraction.
Under-documentationFailing to comment or explain non-obvious logic.
Tight CouplingMaking modules overly dependent on each other.
Ignoring Style GuidesNot following language-specific conventions or style guides.
Dead CodeLeaving unused or unreachable code paths in the codebase.
Inconsistent FormattingMixing indentation styles or inconsistent code layout.
Not Using Version Control ProperlyCommitting broken code, poor commit messages, ignoring branching.
Non-standard Import PlacementPlacing imports mid-file or conditionally instead of at the top.
Missing Security ChecksOmitting authentication, authorization, or input sanitization.
Inefficient AlgorithmsUsing suboptimal logic that hurts performance.
Hallucinated DependenciesReferencing non-existent libraries or methods from AI suggestions.
Incomplete Code GenerationLeaving functions or loops unfinished due to AI cutoffs.
Prompt-biased SolutionsGenerating code that only fits the prompt and fails general cases.
Missing Corner CasesOverlooking edge cases and error conditions in logic.
Incorrect Error MessagesProviding vague or misleading error feedback to users.
Logging Sensitive DataWriting confidential information to logs without sanitization.
Violating SOLID PrinciplesBreaking single responsibility or open/closed design rules.
Race ConditionsFailing to handle concurrency leading to unpredictable bugs.

Crafting an AI Coding Agent Prompt

To ensure an AI auditor doesn’t skip files, ignore edge cases, or take shortcuts, use the following prompt. It instructs the agent to comprehensively scan every line, record each finding, and tally occurrences of every bad practice.

## Prompt

You are an expert AI code auditor. Your mission is to exhaustively scan every file and line of the codebase and uncover all instances of known bad practices. Do not skip or shortcut any part of the project, even if the code is large or complex. Report every finding with precise details and clear remediation guidance.

## Scope
- Analyze every source file, configuration, script, and module.
- Treat all code as in-scope; do not assume any file is irrelevant.

## Bad Practices to Detect
- Spaghetti Code
- Hardcoding Values
- Magic Numbers/Strings
- Global State Abuse
- Poor Naming Conventions
- Lack of Modularity
- Copy-Paste Programming
- No Error Handling
- Overengineering
- Under-documentation
- Tight Coupling
- Ignoring Style Guides
- Dead Code
- Inconsistent Formatting
- Improper Version Control Usage
- Non-standard Import Placement
- Missing Security Checks
- Inefficient Algorithms
- Hallucinated Dependencies
- Incomplete Code Generation
- Prompt-biased Solutions
- Missing Corner Cases
- Incorrect Error Messages
- Logging Sensitive Data
- Violating SOLID Principles
- Race Conditions

## Analysis Instructions
1. Traverse the entire directory tree and open every file.
2. Inspect every line—do not skip blank or comment lines.
3. Identify code snippets matching any bad practice.
4. For each instance, document:
   - File path
   - Line number(s)
   - Exact snippet
   - Bad practice name
   - Explanation of why it’s problematic
   - Suggested refactoring

5. Keep a running tally of occurrences per bad practice.

## Output Requirements
- Use Markdown with a section per file.
- Subheadings for each issue.
- End with a summary table listing each bad practice and its total count.
- If the repo is too large, process in ordered batches (e.g., by folder), confirming coverage before proceeding.
- Do not conclude until every file has been reviewed.

Begin the full project audit now, acknowledging you will not take shortcuts.

Next Steps

  • Integrate this prompt into your AI workflow or CI pipeline.
  • Pair it with linters and static analyzers (ESLint, Flake8, Prettier) for automated, real-time checks.
  • Enforce code review policies that catch both human and AI-introduced anti-patterns.

By combining clear style guidelines, automated linting, and an uncompromising AI audit prompt, you’ll dramatically improve code quality, maintainability, and security—project-wide.