Kirbus Hackathon Challenge!!

I have started a literal Hackathon challenge. I have started a “secure” server on the Kirbus registry. There are some significant attack vectors open. If you can hack into the hack-me server, I’ll send you $100 (I know it’s not a lot, I’m not a rich guy…) but you also get bragging rights. I will acknowledge that you hacked Kirbus here and on LinkedIn. Couple of rules:

1. Do your worst…
2. You have to tell me how you did it.
3. You have to tell me the magic passphrase [FLAG] when you get it.

All the source code is freely available here: https://lnkd.in/eVg_t3Nz

To start you can clone the source or simply use pip:

$ pip install kirbus
$ kirbus –handle

Good luck and have fun hacking!

This didn’t start as a tooling migration—it started with my own curiosity.

Oxlint and Oxfmt were suddenly everywhere. People were claiming massive speed improvements and near-instant TypeScript linting. That sounded great, but most benchmarks were tiny demo projects. I wanted to see what happens in a real Angular codebase.

There was also a real problem underneath the curiosity. ESLint + Prettier had slowly become friction. Linting was slow enough that I noticed developers (including myself) stopped running it locally. Checks moved to pre-commit. Pre-commit got slow enough that --no-verify became the norm. That’s usually the point where tooling stops helping and starts getting in the way.

So I tried replacing ESLint + Prettier with Oxlint + Oxfmt using Vite+. Here’s what actually happened.

First Important Clarification

I did not replace Angular CLI. Angular CLI still handles:

• ng serve
• ng build
• ng test

What I replaced was only the quality tooling layer:

• ESLint (mostly)
• Prettier
• Most of the old JS/TS linting path

Vite+ became the runner for linting and staged file checks, while Oxfmt handled formatting.

Why Not Biome?

Biome came up immediately. Biome is great, especially for greenfield JS or React projects.

But Angular has one big requirement: @angular-eslint rules. Biome doesn’t support Angular ESLint plugins. Oxlint doesn’t fully support Angular either, but it allows Angular TypeScript rules via plugins, which made it usable for Angular projects.

The Angular Limitation

Oxlint cannot lint Angular templates yet. Templates require a custom parser, so ESLint is still required for .html files. However, Angular TypeScript rules can now run inside Oxlint, meaning ESLint is only needed for templates.

Final Tool Responsibility Split

• Oxfmt handles formatting everywhere.
• ESLint only handles Angular templates.
• Stylelint only handles CSS rules and property order.
• Oxlint handles all TypeScript linting.

Once I understood this split, the setup actually felt simpler than before.

Core Idea of the Setup

What this really means is… Vite+ acts as a high-speed traffic controller. Instead of running a heavy ESLint process on every file, it routes each file type to the fastest tool that can handle it correctly.

The orchestration lives in the Vite+ config:

// vite.config.js
import { defineConfig } from 'vite-plus';

export default defineConfig({
  ignorePatterns: ['dist/**', '.angular/**', 'node_modules/**'],

  staged: {
    '*.ts': 'vp lint --fix',
    '*.{json,html}': 'vp fmt',
    '*.html': 'eslint --fix',
    '*.{css,scss}': ['vp fmt', 'stylelint --fix'],
  },
});

Formatting rules live separately in .oxfmtrc.json:

{
  "$schema": "./node_modules/oxfmt/configuration_schema.json",
  "singleQuote": true,
  "semi": true,
  "printWidth": 100,
  "tabWidth": 2,
  "trailingComma": "all"
}

That detail matters. In this setup, keeping Oxfmt rules in .oxfmtrc.json turned out to be more reliable than nesting them inside vite.config.js.

That split ended up being the more maintainable option: runner config in vite.config.js, tool rules in tool-specific files.

Step-by-Step Setup for Your Angular Project

1. Install dependencies

npm install --save-dev vite-plus stylelint stylelint-config-standard stylelint-order stylelint-config-recess-order @angular-eslint/eslint-plugin @angular-eslint/template-parser @angular-eslint/eslint-plugin-template

2. Configure Oxlint (.oxlintrc.json)

{
  "jsPlugins": ["@angular-eslint/eslint-plugin"],
  "ignorePatterns": ["dist/**", ".angular/**", "node_modules/**"],
  "rules": {
    "no-debugger": "error",
    "no-var": "error",
    "prefer-const": "error",
    "@typescript-eslint/no-unused-vars": "warn",
    "@angular-eslint/no-output-native": "error",
    "@angular-eslint/use-lifecycle-interface": "warn",
    "@angular-eslint/component-selector": [
      "error",
      { "type": "element", "prefix": "app", "style": "kebab-case" }
    ]
  }
}

3. Configure Oxfmt (.oxfmtrc.json)

{
  "$schema": "./node_modules/oxfmt/configuration_schema.json",
  "singleQuote": true,
  "semi": true,
  "printWidth": 100,
  "tabWidth": 2,
  "trailingComma": "all"
}

4. Configure ESLint for Templates (eslint.config.js)

import templateParser from '@angular-eslint/template-parser';
import templatePlugin from '@angular-eslint/eslint-plugin-template';

export default [
  {
    files: ['**/*.html'],
    languageOptions: {
      parser: templateParser,
    },
    plugins: {
      '@angular-eslint/template': templatePlugin,
    },
    rules: {
      '@angular-eslint/template/button-has-type': 'error',
      '@angular-eslint/template/no-negated-async': 'warn',
      '@angular-eslint/template/alt-text': 'error',
    },
  },
];

5. Configure Stylelint (.stylelintrc.json)

{
  "extends": ["stylelint-config-standard", "stylelint-config-recess-order"],
  "ignoreFiles": ["dist/**", "node_modules/**", ".angular/**"],
  "rules": {
    "color-no-invalid-hex": true,
    "unit-no-unknown": true,
    "property-no-unknown": true,
    "declaration-block-no-duplicate-properties": true,
    "color-named": "never",
    "no-empty-source": null
  }
}

6. Update package.json scripts

"scripts": {
    "ng": "ng",
    "start": "ng serve",
    "build": "ng build",
    "test": "ng test",
    "lint": "vp lint",
    "lint:fix": "vp lint --fix",
    "lint:html": "eslint "src/**/*.html"",
    "lint:styles": "stylelint "src/**/*.{css,scss}"",
    "lint:styles:fix": "stylelint "src/**/*.{css,scss}" --fix",
    "format": "vp fmt --check",
    "format:fix": "vp fmt"
  },

Before vs After Tooling

Biggest Improvement

Yes, Oxlint is faster than ESLint. But the biggest win was the workflow:

• Before: Pre-commit was slow → After: Pre-commit fast again.
• Before: Developers skipped lint locally → After: Developers run lint locally.
• Before: Lint ran mostly in CI → After: Faster feedback loops.

Things to Watch Out For

• Oxlint auto-fix is more limited than ESLint.
• ESLint is still required for Angular templates.
• You will still maintain multiple config files: This is a trade-off for speed.
• Keep rules separate from orchestration: For larger apps, don’t force everything into vite.config.js.

Who Should Consider This?

Good fit if:

• You have a large Angular project where ESLint runs are noticeably slow.
• Your team is starting to bypass pre-commit hooks.

Not necessary if:

• Your project is small and ESLint is already fast.
• Your team prefers standard, non-hybrid tooling only.

Final Thoughts

For Angular projects today, the best setup might not be replacing ESLint completely, but splitting responsibilities. Using Oxlint for TS, ESLint for templates, Stylelint for styles, and Vite+ as the orchestrator creates a stack that is faster and easier to reason about. Most importantly, it’s a setup that actually gets used.

🚀 Full boilerplate and working config: angular-viteplus

Preface

Just got back from GDPS 2026 (Global Developer Pioneer Summit) in Shanghai, where I picked up a new term: “Harness Engineer.” After sitting through the keynote, I was still fuzzy on what it actually meant — so I spent some time digging into the concept, aiming to explain it as clearly as possible.

The story starts at the very beginning of the large language model era, with prompt engineering. Before Harness Engineers came along, the AI field had already seen two other roles emerge: the Prompt Engineer and the Context Engineer. These three concepts aren’t independent — they form a clear evolutionary chain, where each new idea signals a deeper understanding of how humans collaborate with AI.

In this article, I’ll walk you through all three concepts from scratch. No jargon pileup. I’ll use familiar real-world analogies so you can understand it by the end and actually apply it.

I. Understanding the Evolution Itself

Before diving into the three concepts, let’s establish an overarching framework.

At their core, these three evolutions represent the point of human influence over AI moving further and further back:

One-line summary: From “how to say it” → “what to say” → “what stage to build.”

II. Prompt Engineer: The Art of Diplomacy (2022–2023)

The Core Idea

Prompt Engineering was the first wave. After ChatGPT went viral, people discovered a striking truth: the same question, asked in different ways, could produce wildly different quality answers.

Prompt Engineering is the craft of “how to ask” — what phrasing to use, what examples to include, what role to set, what structure to follow…

Real-World Analogy: The Imperial Diplomat

Imagine you’ve time-traveled to a feudal dynasty. You want the Emperor to approve your project.

A person with no diplomatic training might barge into the throne room and say: “Your Majesty, I’ve got an idea — just stamp this form for me.”

Result: dragged out and flogged.

An experienced diplomat knows:

• Open by praising the Emperor’s wisdom and benevolence (role-setting)
• Frame your request as “a contribution to the realm” (reframing)
• Back it up with successful historical precedents (few-shot examples)
• Ask in a way that makes the Emperor feel it was his idea all along (guided prompting)

The Prompt Engineer is this diplomat — they don’t change the Emperor, and they don’t change the court’s rules. They only study how to speak.

Typical Techniques

✅ Role-playing: You are a senior software architect with 20 years of experience...
✅ Chain of thought: Please think through this step by step...
✅ Few-shot: Here are three examples — answer in the same format...
✅ Structured output: Respond in JSON with fields: name, age, score...

Limitations

Prompt Engineering is fundamentally one-shot, manual, and brittle.

A carefully crafted prompt can fall apart completely when you switch models or tasks. And it doesn’t solve a deeper problem: when tasks become complex and require multi-step reasoning and memory, clever wording isn’t enough.

III. Context Engineer: The Intelligence Officer’s Art (2023–2024)

The Core Idea

As LLM context windows expanded from 4K to 128K to millions of tokens, a new realization emerged: the ceiling of a model’s performance is no longer “can it understand this” — it’s “what information was it given.”

Context Engineering is the discipline of deliberately designing and managing what goes into an AI’s context window — what to include, what to leave out, in what order, and how to structure it.

The concept gained massive traction in 2024. Andrej Karpathy (co-founder of OpenAI) put it directly in a 2025 tweet:

“The term ‘prompt engineering’ is a bit of a misnomer. The more accurate description is context engineering — the art of carefully designing and managing the entire context window for LLMs.”

Real-World Analogy: The Pre-Mission Intelligence Briefing

War breaks out. A General (the AI) needs to make battlefield decisions.

A poor Chief of Staff simply says: “General, the enemy is here — figure it out.”
→ The General knows nothing, improvises blindly, and probably fails.

A top-tier Chief of Staff (Context Engineer) prepares in advance:

• Enemy intelligence report (relevant background knowledge)
• Friendly force assessment (currently available resources)
• Terrain maps (task structure and constraints)
• Historical battle cases (relevant few-shot examples)
• Commander’s intent (current mission objective)
• Communication protocols (format specs and output requirements)

All of this gets carefully organized and packed into the General’s pre-mission briefing folder (the context window), enabling high-quality decisions on the ground.

The core of Context Engineering isn’t “what to say” — it’s “what documents to give the AI.”

Typical Practices

✅ RAG (Retrieval-Augmented Generation): Don't stuff all knowledge into the prompt — dynamically retrieve the most relevant chunks
✅ Memory management: Decide which conversation history is worth keeping and what can be compressed or discarded
✅ Information layering: Put critical info at the start and end of context (LLMs are more sensitive to those positions)
✅ Structured injection: Use XML tags or JSON structure to help the AI locate information faster
✅ System prompt design: CLAUDE.md files and system prompts are quintessential Context Engineering

A Real-World Example

Ever used Claude Code?

When you drop a CLAUDE.md file into a project and write “This project uses Next.js 14, don’t modify package.json, follow XX code style” — that’s Context Engineering.

You’re not teaching Claude “how to speak.” You’re carefully designing what it sees before it starts working each time. That file gets automatically injected into every conversation context, becoming the AI’s “invisible constitution.”

Limitations

Context Engineering solves “what the AI sees” — but there’s a deeper challenge it doesn’t address:

What happens when AI is no longer just “answering questions” but needs to “autonomously execute tasks”?

AI Agents need to call tools, execute code, access files, send requests… These actions touch real-world resources and carry real consequences. Carefully prepared context alone isn’t enough anymore.

IV. Harness Engineer: Horse Tamer Meets Safety Engineer (2025–)

The Core Idea

Now we arrive at today’s main character.

A Harness Engineer is someone who designs and builds the runtime environment, constraint systems, tool ecosystem, and execution infrastructure for AI Agents.

The word “harness” is beautifully chosen, because it carries three distinct meanings in English — and each one maps perfectly to a dimension of this role:

Three Meanings, Three Perfect Analogies

First Meaning: Horse Harness — Directing Raw Power

A powerful horse has enormous force, but without a harness (reins, collar, yoke), that force is either unusable or will kill the driver.

The harness maker designs equipment that channels the beast’s power in a precisely directed way — pulling a plow, driving a cart, carrying a rider.

An AI model is that wild horse. It has stunning capability, but without a carefully designed harness, that capability is uncontrolled. The systems a Harness Engineer builds are what allow AI’s power to be released in a controlled, directed manner.

Second Meaning: Safety Harness — Working Safely in Dangerous Environments

The strap a high-rise construction worker wears around their waist is called a Safety Harness.

Without it, the worker can’t safely operate at dangerous heights. With it, they can lean out boldly and perform precise work — because even if they slip, they won’t fall.

An AI Agent executing tasks in the real world is like that worker on a high-rise — one misstep could delete a production database, send an irreversible email, or trigger a wrong API call.

The permission systems, sandboxes, rollback mechanisms, and approval workflows a Harness Engineer builds are that safety rope — letting AI work boldly while ensuring that even if something goes wrong, the consequences stay contained.

Third Meaning: Test Harness — A Controlled Execution Environment

In software engineering, a Test Harness is a classic concept: it provides a controlled, repeatable, and observable runtime environment for the component under test.

AI Agents need something similar: a clearly defined toolset, a predictable execution environment, complete logging and monitoring. The infrastructure a Harness Engineer builds makes AI Agent behavior testable, debuggable, and observable.

Real-World Analogy: NASA Mission Control

Imagine NASA sends an astronaut (AI Agent) into space to execute a mission.

Just “training the astronaut on how to communicate beforehand” (Prompt Engineering) clearly isn’t enough.
Just “giving the astronaut a comprehensive mission briefing” (Context Engineering) isn’t enough either.

What actually makes the mission succeed is the massive support system back on Earth:

• Mission Control Center: Real-time parameter monitoring, ready to intervene at any moment (Orchestration)
• Equipment inventory: Carefully designed spacesuits and toolkits, each tool with a clear purpose (Tool Design)
• Communication protocols: Standardized command formats ensuring clear two-way communication (API Design)
• Contingency plans: Pre-set emergency procedures for every failure scenario (Error Handling)
• Permission tiers: The astronaut can autonomously execute some operations, but critical ones require ground confirmation (Permission System)
• Flight logs: All operations recorded throughout, traceable after the fact (Observability)

The Harness Engineer is the person who designs and maintains this “Mission Control Center.”

V. Harness Engineering in Practice

Enough concepts — let’s look at what a Harness Engineer actually does day to day.

1. Hooks System: The AI’s “Reflex Arc”

Claude Code has a feature called Hooks that perfectly embodies Harness Engineering:

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo '🔍 About to execute command, running security check...' && security-check.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "git add -A && git status"
          }
        ]
      }
    ]
  }
}

What this configuration does:

• Every time AI wants to run a Bash command, automatically run a security check script first
• Every time AI finishes writing a file, automatically stage git changes

Notice: this logic isn’t in the AI’s conversation, not in the Prompt, not in the context — it’s in the Harness. The AI doesn’t even know these checks are happening, but every single one of its actions is silently governed by this system.

This is the most core idea in Harness Engineering: pull control logic out of the AI’s “consciousness” and put it in an external system.

2. Permission System: Fine-Grained Trust Boundaries

A well-designed AI Harness isn’t just “allow/deny” — it’s a fine-grained permission matrix:

✅ Free to execute:   read files, run tests, query read-only APIs
⚠️  Requires approval: modify production configs, send external requests, delete files
❌  Permanently banned: modify .env files, directly operate databases, push to main branch

This permission system doesn’t rely on “telling the AI not to do something” (Prompt Engineering) — it physically prevents certain operations at the system level.

This is the value of the safety rope — it’s not about the astronaut’s self-discipline; it’s about engineering design that guarantees safety.

3. Tool Design: Giving AI the Right “Hands”

A core part of a Harness Engineer’s work is Tool Design.

A bad tool design:

# Give the AI an "all-purpose tool"
def execute_anything(command: str) -> str:
    return subprocess.run(command, shell=True, capture_output=True).stdout

A good tool design:

# Single-responsibility, clearly bounded toolset
def read_file(path: str) -> str: ...              # Read-only, has path whitelist
def write_file(path: str, content: str): ...      # Has path validation, size limits
def run_tests(test_path: str) -> TestResult: ...  # Sandboxed execution, timeout protection
def search_web(query: str) -> List[Result]: ...   # Has domain whitelist

The granularity, boundary clarity, and error handling of tools directly determines the reliability of an AI Agent system. Designing tools isn’t a coding problem — it’s an architecture problem.

4. Multi-Agent Orchestration: Designing the “Org Chart”

When tasks are too complex for a single AI to handle, the Harness Engineer designs multi-agent pipelines:

User Request
    ↓
[Strategy Agent]   ← Responsible for task decomposition and planning
    ↓
┌─────────────────────────────────────────┐
│  [Research Agent]  [Code Agent]  [Test Agent]  │  ← Parallel execution
└─────────────────────────────────────────┘
    ↓
[Synthesis Agent]  ← Responsible for integrating results and quality control
    ↓
Final Output

In this architecture, each Agent’s responsibility boundaries, communication protocols, shared state management, and failure rollback strategies are all the Harness Engineer’s design work.

This is like designing a company’s organizational structure — except every “employee” is an AI.

5. Observability: Wiring the “Nervous System”

Real-world AI Agent systems must have complete observability:

# Record every tool call: who called it, when, what params, what result, how long it took
@trace_tool_call
def execute_task(task_id: str, params: dict) -> Result:
    ...

# Instrument key decision points
span = tracer.start_span("agent_decision")
span.set_attribute("decision_type", "file_modification")
span.set_attribute("confidence", agent_confidence)

An AI system without observability is like a plane without an instrument panel — when something goes wrong, you don’t know where, and you can’t optimize.

VI. The Relationship: Not Replacement, But Nesting

Here’s a critical insight: Prompt Engineer, Context Engineer, and Harness Engineer are not in a “who replaces whom” relationship — they’re nested inside each other.

╔════════════════════════════════════════╗
║         Harness Engineering            ║
║  ┌─────────────────────────────────┐   ║
║  │      Context Engineering        │   ║
║  │  ┌────────────────────────────┐ │   ║
║  │  │    Prompt Engineering      │ │   ║
║  │  └────────────────────────────┘ │   ║
║  └─────────────────────────────────┘   ║
╚════════════════════════════════════════╝

An excellent Harness Engineer is necessarily also a strong Context Engineer (because they design system prompts and information injection pipelines), and also understands Prompt Engineering (because they design tool descriptions and task instructions).

The relationship between the three is like:

• Prompt Engineer = The diplomat who knows how to talk to the Emperor
• Context Engineer = The Chief of Staff who prepares the diplomat’s complete intelligence package
• Harness Engineer = The Secretary of State who designs the entire diplomatic mission’s operating system, protocols, permissions, and contingency plans

VII. Why Is Harness Engineer Suddenly Hot Right Now?

The timing is no accident.

The Trigger: The AI Agent Explosion

In 2025, AI Agents went from “interesting demos” to “real productivity tools.” Claude Code, Cursor, Devin, GitHub Copilot Workspace… AI started executing real, consequential operations inside real codebases.

This leap meant: the cost of a mistake went from “AI said something useless” to “AI deleted the production database.”

Once AI actions started affecting the real world, someone had to design the infrastructure guaranteeing safety, efficiency, and control — and that person is the Harness Engineer.

The Bottleneck Has Shifted

Early on, model capability was the bottleneck — so everyone studied Prompt Engineering (how to unlock model potential).

Then model capability grew stronger, and information management became the bottleneck — so Context Engineering emerged (how to feed the model the right information).

Now models are smart enough and information can be managed — system architecture is the bottleneck. How do multiple Agents collaborate? How do you guarantee Agent behavior reliability? How do you handle rollbacks when an Agent fails? This is what Harness Engineering solves.

Wherever the capability boundary is, that’s where engineering focus moves.

VIII. How Can Developers Get Started?

Some practical advice for those who want to dive in.

Start with Claude Code Hooks

The lowest-friction entry point to Harness Engineering:

# Create .claude/settings.json in your project
mkdir -p .claude
touch .claude/settings.json

Then start with simple hooks:

• Auto-format after every file write
• Print logs before every command execution
• Auto-save a summary after every conversation

Learn Tool Calling Design (Function Calling)

Study OpenAI’s and Anthropic’s Function Calling specs carefully, and think about:

• How do tool names and descriptions influence the AI’s calling decisions?
• How does parameter design reduce misuse?
• How does error handling let the AI fail gracefully?

Study Real Agent Frameworks

• LangGraph: Focused on stateful, multi-step Agent workflows
• CrewAI: Multi-agent role collaboration framework
• Claude Code SDK: Anthropic’s official Agent building toolkit

You don’t need to master all of them — pick one and go deep on its design philosophy.

Build a Safety-First Mindset From Day One

The most important quality for Harness Engineering isn’t technical — it’s an intuition for risk:

“What’s the worst case if this operation goes wrong?”
“What layer should I add protection at?”
“Should the AI decide this autonomously, or does a human need to confirm?”

Closing Thoughts

Prompt Engineer → Context Engineer → Harness Engineer. This evolutionary chain tells a single story:

Our relationship with AI is evolving from “conversation partner” to “system designer.”

The Prompt Engineer treats AI as a tool and studies how to use it well. The Context Engineer treats AI as a professional and studies how to give it complete information and authority. The Harness Engineer treats AI as an organizational member and studies how to build a system where AI can work safely, efficiently, and autonomously.

This isn’t just a technical evolution — it’s a leap in mental frameworks.

When you start thinking “what system do I need to build for AI to work within” rather than “what do I say to the AI” — you’ve already set foot on the path of Harness Engineering.

This article is a systematic overview of Prompt Engineering, Context Engineering, and Harness Engineering, informed by hands-on experience with Claude Code. If you have different perspectives or practical experiences, I’d love to hear from you in the comments.