DEV Community: Jenuel Oras Ganawed

Why I Switched to Zed, and Why You Should Too

Jenuel Oras Ganawed — Fri, 23 Oct 2026 07:05:14 +0000

I did not switch editors because I wanted a new theme, a different sidebar, or another place to install the same extensions.

I switched because my editor had started competing with the work I was trying to do.

Modern development already asks a lot from a computer. I might have a browser full of tabs, local servers, databases, containers, language servers, terminals, and one or more AI coding agents running at the same time. I do not want the application I use to edit text taking a large share of the remaining memory or making every interaction feel heavier than it should.

That is why I started using Zed. It is fast, relatively light in my daily workflow, comfortable with the terminal, and designed for the way AI-assisted development now works.

I still respect VS Code and the JetBrains IDEs. They are mature tools with huge ecosystems, and there are projects where I may still need them. But Zed has become the editor I want to open first.

Performance was the first thing I noticed

Zed feels immediate.

It opens quickly. Files appear quickly. Switching between tabs, searching a project, typing, and scrolling all feel direct. That may sound like a small improvement, but an editor is an application I touch hundreds or thousands of times during a working day. Tiny delays become part of the mood of the whole workflow.

Zed did not reach that feeling by wrapping a web application in a desktop shell. Its interface is built with GPUI, Zed's own GPU-accelerated UI framework. The team wrote about designing it to render like a video game and target smooth, responsive interaction, including high-refresh-rate displays.[1]

I do not care about the architecture simply because Rust and GPU rendering sound impressive. I care because I can feel the result. The editor stays out of the way.

A code editor should not make itself the main event. It should respond so quickly that I stop thinking about it.

It leaves more room for the work

Memory use was another reason I moved.

In my workflow, Zed usually feels less demanding than the heavier editor setups I used before. That matters because the editor is only one part of my development environment. The browser, development server, build tools, Docker, WSL, databases, and AI agents all need memory too.

Saving memory in the editor and avoiding unnecessary extension processes can decide whether the whole system stays responsive. I would rather give that memory to the application I am building or the agent running my tests.

I want to be careful with this claim: Zed is not guaranteed to use less RAM in every project. Language servers, debuggers, terminals, extensions, and AI agents are part of the total footprint. Long AI threads can grow, and huge repositories can require serious indexing.

Zed uses separate language servers for features such as completion, diagnostics, navigation, and refactoring. Its settings let you choose, prioritize, or disable those servers when a project does not need them.[2] That is why I treat low RAM use as an observed benefit of my setup, not a universal benchmark that every developer will reproduce.

My reason is personal and practical: with the projects and tools I run, Zed gives me more breathing room. My computer feels like it belongs to my work again, not to the editor.

Zed understands that AI is now part of development

Many editors added AI after the fact. Zed increasingly feels as if the editor, terminal, codebase, and agent were meant to share the same workspace.

Zed's native agent can read and search a project, edit files, run terminal commands, use MCP tools, follow reusable skills and instructions, and present its changes in a review interface.[3] That is much closer to how I use AI now. I do not only ask for autocomplete. I ask an agent to investigate a bug, trace related code, make a change, run the tests, and show me exactly what it touched.

Zed also supports more than its own agent. Its documentation describes three paths: the native Zed Agent, external agents connected through the Agent Client Protocol, and terminal-based agent threads. External integrations can include tools such as Claude, Codex, OpenCode, Copilot, Cursor, and others that support Zed's agent workflow.[4]

This flexibility matters to me. I do not want my editor to force me into one model company, one subscription, or one interface. Sometimes I want an agent inside a panel. Sometimes I want the original CLI in a real terminal. Sometimes I want multiple agents working in parallel while I review the changes.

Zed gives AI a useful place in the workflow without pretending that the chat box should replace the code, terminal, diff, or developer judgment.

The terminal feels like a first-class part of the editor

I spend a lot of time in the terminal. Git, tests, package managers, build scripts, deployment commands, database tools, AI coding CLIs, and project automation already live there. I do not want to abandon that environment just because I opened an editor.

Zed's terminal can live in the bottom panel or open as a center tab beside regular files. It supports multiple terminal instances, custom shells, task integration, and AI help for explaining errors or suggesting commands.[5]

That center-terminal option sounds minor until you use it. A terminal is not always a little utility panel that deserves one quarter of the screen. Sometimes the terminal is the work. Logs, test failures, interactive tools, and coding agents need space. Zed lets me treat them that way.

The task system makes the relationship even better. I can define repeatable commands for builds, tests, linting, or scripts and run them with editor context such as the current file or selected text.[6] I still get the power of the shell without rebuilding every workflow as an editor extension.

This is what I mean when I say Zed is terminal friendly. It does not merely include a terminal. It respects terminal-driven development.

It fits my Windows and WSL workflow

A fast editor would not help me much if it fought the environment where my code lives.

Zed's Windows version supports opening a WSL distribution as a remote target. The interface runs locally while the source code, language servers, tasks, and terminal can run in the remote environment.[7][8]

That model makes sense for how I work. I can keep the responsive native interface on Windows while using Linux tools and project environments inside WSL. I do not need to pretend Windows and Linux are the same machine, and I do not need to give up the convenience of either one.

Zed also supports ordinary SSH remote development. Its documentation says the local interface remains responsive while language servers, tasks, and terminals run on the server, and the AI features continue to work in remote sessions.[8]

For anyone who develops across Windows, WSL, cloud servers, or remote Linux machines, that is a serious feature rather than a checkbox.

It is minimal without being empty

Zed looks clean, but it is not only a text box.

It supports Tree-sitter parsing and language servers for completion, diagnostics, navigation, code actions, and refactoring. Its language documentation now covers hundreds of programming languages and text formats through built-in support and extensions.[9]

It has an integrated debugger built around the Debug Adapter Protocol, with support for breakpoints, stepping, variable inspection, launch and attach workflows, and multiple languages.[10] It can run tasks and tests, use Jupyter kernels for interactive code, work with Git, and install community extensions.

Zed also has real-time multiplayer editing. Multiple developers can work in the same project and see one another's cursors and edits, with channels and voice chat available for collaboration.[11] I may not use multiplayer every hour, but it reflects something important about the product: Zed was designed around shared work, not only solitary text editing.

The interface stays restrained while the capabilities underneath it continue to grow. That balance is difficult. Many tools become cluttered as they become capable. Zed still feels like an editor.

The extension story is getting stronger

The most common reason to stay with VS Code is its extension ecosystem. That is fair. Years of community development created an answer for nearly every language, service, and unusual workflow.

Zed is younger, so I would not tell someone that every VS Code extension has an equivalent. It does not.

What it does have is a growing extension system covering languages, language servers, themes, icon themes, MCP servers, agent servers, debug adapters, and snippets. Zed's public extension directory lists more than a thousand extensions, including support for popular languages and frameworks.[12]

I have also learned that I needed fewer extensions than I thought. Some of the weight in my old setup came from solving every possible future problem in advance. Zed pushed me toward a smaller setup: install what the project needs, keep the terminal close, and let standard tools such as LSP, DAP, Tree-sitter, and MCP handle more of the integration.

That approach will not suit everyone. If your job depends on a particular VS Code-only extension, switching immediately may create more friction than it removes. Check your essentials first.

Zed is opinionated in ways I like

Zed is keyboard friendly. It gives terminals real space. It assumes language servers and command-line tools are valuable. It treats AI agents as workers that should read files, use tools, run commands, and produce reviewable changes. It uses native performance as a product feature rather than accepting sluggishness as the price of extensibility.

Those choices match the direction of my own workflow.

I no longer want an editor that tries to contain the entire software industry inside one application. I want a fast center of gravity that connects my code, terminal, tools, remote environments, and AI agents.

Zed is the closest editor I have found to that idea.

Why you should try it

You should try Zed if your current editor feels heavier than the work deserves. Try it if you regularly keep a browser, containers, local services, and AI tools open and want to recover some responsiveness. Try it if the terminal is already central to how you build software. Try it if you want AI inside the editor but do not want to be locked into one agent or model provider.

Do not switch because someone on the internet posted a startup-time chart. Open one of your real projects. Install only the language support you need. Run your normal server and tests. Open your usual terminals and AI agent. Watch the system memory, but also pay attention to the less measurable part: how often the editor makes you wait or breaks your concentration.

You may find that VS Code, Neovim, or a JetBrains IDE still fits your work better. That is fine. Editors are personal, and ecosystems matter.

But if you have accepted slow startup, crowded interfaces, extension overload, or high resource use as unavoidable parts of modern development, Zed is worth testing. It reminded me that a powerful editor can still feel light.

That is why I switched, and why Zed now opens first when I am ready to build.

References

Originally published at https://blog.jenuel.dev/blog/why-i-switched-to-zed-and-why-you-should-too

Thanks for reading! If you enjoyed this article and like this kind of content, you're always welcome to buy me a little coffee, but only if you'd like to. No pressure at all, and either way I'm truly grateful you stopped by. ☕️

How I Stopped Burning Through My Codex Usage Limit

Jenuel Oras Ganawed — Mon, 05 Oct 2026 03:28:58 +0000

I recently watched two Codex browser-automation jobs consume 170,123 and 110,180 tokens.

The jobs worked. They published articles, opened websites, filled editors, and checked the finished pages. But the cost surprised me. These were not month-long software projects. They were a pair of long browser sessions with several websites, retries, page reads, and verification steps.

That was when I stopped treating the Codex usage limit as a mysterious number controlled only by my ChatGPT plan.

My plan matters, of course. But so do my model, reasoning level, speed mode, conversation length, tool output, number of agents, and the size of the task I hand to Codex. OpenAI says all of those can affect consumption.[2]

After reading OpenAI's current documentation and comparing it with reports from Codex users, I changed both my configuration and the way I assign work. This article is the setup I would give someone who wants Codex to last through a real working week.

It will not make usage unlimited. It will not reset a quota or create free compute. It simply stops wasting an expensive model on work that a cheaper model, a shorter thread, or an ordinary shell command can handle.

First, understand which limit you are hitting

People often use the phrase "Codex limit" for three different things.

The first is the ChatGPT plan allowance. If you sign in to Codex with a ChatGPT account, Codex draws from the allowance attached to that plan. Codex and other ChatGPT work products may share the same pool.[2][3]

The second is the context window inside one conversation. A long chat collects prompts, source files, command results, screenshots, test logs, and previous answers. Codex can compact that history, but a conversation can still become expensive and unfocused before it reaches a hard context boundary.[6][7]

The third is API billing or an API rate limit. If you authenticate with an API key instead of your ChatGPT subscription, usage is billed separately under API pricing. Switching to an API key can keep work moving after a subscription allowance is exhausted, but it does not reduce the amount of computation. It moves the cost to another bill.[3]

This article focuses on preserving a ChatGPT Codex allowance through legitimate configuration and better task design.

The largest saving comes from model choice

OpenAI's current pricing page shows why model routing matters so much. For Plus and Standard Business plans, its estimated number of local messages within a five-hour period ranges from roughly 5-45 for GPT-6 Astra, 15-160 for GPT-6.1 Sol, and 350-3,000 for GPT-6 Luna. These are estimates, not guaranteed message caps, and complex work may consume much more than a small request.[1]

That gap changes how I think about Codex.

I do not need the strongest model to rename variables, update a configuration file, extract data, write a small test, summarize a log, or make a narrow CSS change. GPT-6 Luna is designed for focused, repeatable, high-volume work. GPT-6.1 Sol is the everyday workhorse for larger coding tasks. Astra is for the work that actually needs frontier-level reasoning.[5]

If I use Astra for everything, I am spending my scarce allowance before I know whether the task is difficult.

My new rule is simple:

Start routine work on Luna.
Use GPT-6.1 Sol for normal implementation, debugging, and multi-file work.
Escalate the difficult phase, not the entire project, to higher reasoning or a stronger model.
Return to the cheaper profile after the hard part is solved.

A model change is not a judgment about the importance of the project. It is just matching the tool to the work.

Fast mode is expensive convenience

Fast mode feels harmless because it changes waiting time, not the visible quality setting. Its allowance cost is easy to miss.

OpenAI currently states that Fast mode consumes included usage at 2.5 times the Standard rate and purchased credits at twice the Standard rate.[1][4] If I am trying to preserve my weekly allowance, leaving Fast mode enabled for a long autonomous session makes little sense.

In the interactive CLI, /fast is a toggle. Running it once enables Fast mode and running it again disables it. For a usage-conscious profile, I prefer to make Standard speed explicit in the configuration so I do not have to remember the current toggle state.[4][6]

Fast mode still has a place. I might use it when I am sitting in front of the terminal and waiting for a short urgent answer. I do not use it by default for a browser job that may run for twenty minutes, inspect many pages, and retry failed actions.

My economy profile

Current Codex versions support profile files in %USERPROFILE%\.codex on Windows or $CODEX_HOME on other systems. A file named economy.config.toml can be selected with codex --profile economy.[8][10]

This is the profile I recommend for narrow edits, transformations, summaries, simple tests, and straightforward browser actions:

# %USERPROFILE%\.codex\economy.config.toml

model = "gpt-6-luna"
model_reasoning_effort = "low"
model_verbosity = "low"
service_tier = "default"

[agents]
enabled = false

[features]
fast_mode = false

Run it in PowerShell:

codex --profile economy

Then check the active settings:

/status

The /status command displays the current model, context usage, rate-limit information, and other session details.[6]

This profile does four useful things. It selects the efficient model, keeps reasoning low, requests concise output, and prevents the task from silently expanding into several parallel agents.

model_verbosity = "low" is mainly an output-style control. I use it because I usually want a concise report after the work is complete. I would not promise that this line alone creates a predictable allowance saving, because OpenAI does not publish a fixed token-to-subscription-percentage formula.[2][9]

My balanced profile

Some work is too large or ambiguous for an economy profile. For everyday development, I use GPT-6.1 Sol while keeping the expensive settings under control.

# %USERPROFILE%\.codex\balanced.config.toml

model = "gpt-6.1-sol"
model_reasoning_effort = "low"
model_verbosity = "low"
service_tier = "default"

[agents]
enabled = true
max_concurrent_threads_per_session = 2
default_subagent_model = "gpt-6-luna"
default_subagent_reasoning_effort = "medium"

[features]
fast_mode = false

Run it with:

codex --profile balanced

This is close to how I want Codex to behave most of the time. The primary agent gets the stronger everyday model. If it delegates a search or code inspection, the subagent starts on Luna instead of automatically duplicating an expensive configuration. Parallel threads are capped at two.

Subagents are useful, but they do separate model and tool work. OpenAI warns that multi-agent workflows consume more tokens than comparable single-agent work.[11] Community reports also describe accidental fan-out, repeated file inspection, and agents duplicating each other's work.[15][19]

I enable them in the balanced profile because parallel investigation can save human time. I cap them because "use as many agents as possible" is not a free performance switch.

Escalate one hard task instead of changing the global default

When a task needs more thought, I prefer a one-time command-line override:

codex --profile balanced `
  --model gpt-6.1-sol `
  --config 'model_reasoning_effort="high"' `
  --config 'model_verbosity="medium"' `
  --config 'agents.max_concurrent_threads_per_session=2' `
  --config 'service_tier="default"' `
  --config 'features.fast_mode=false'

For a non-interactive job:

codex exec --profile balanced `
  --model gpt-6.1-sol `
  --config 'model_reasoning_effort="high"' `
  --config 'agents.max_concurrent_threads_per_session=2' `
  --config 'service_tier="default"' `
  --config 'features.fast_mode=false' `
  "Fix the failing payment reconciliation test. Change only the relevant service and tests. Run the focused test suite and report the root cause."

Codex gives command-line flags and --config overrides higher precedence than profile and user settings.[8][10]

The prompt matters as much as the flags. The example names the failure, limits the files conceptually, asks for a focused test, and gives Codex a stopping point. Compare it with this:

Audit the whole repository, fix anything wrong, improve the architecture,
and run all tests.

That second prompt can trigger hours of exploration with no shared definition of "done."

One task per thread

The most common community advice I found was also the least technical: stop using one Codex conversation as a permanent office.

A long thread feels efficient because the agent remembers everything. The problem is that it may repeatedly carry old conversations, file contents, tool results, and instructions into later calls. One user who audited hundreds of Codex rollouts reported active input context growing from about 16,700 to 158,300 tokens in roughly eleven minutes after repeated inspections and large outputs.[14] That is one user's telemetry, not an official billing formula, but the pattern is easy to recognize.

I now treat a thread like a work ticket:

Investigate one problem.
Write or implement the result.
Run the relevant verification.
Save the important state in the repository or a short handoff file.
End the thread when the ticket is done.

If the next task is unrelated, I start a fresh session. If it continues the same goal but the chat is bloated, I use /compact. If I want to explore a different approach without losing the current path, I fork the session.[6][7]

There is no universal rule for compaction. Some experienced users report that automatic compaction works well across long projects. Others say it removed details they still needed and caused repeated work.[18] I compact at phase boundaries, not in the middle of a fragile browser flow or debugging session.

A good moment to compact is after research is complete and before implementation starts. A bad moment is while temporary IDs, selectors, unsaved decisions, or failing-test details still exist only in the conversation.

Stop feeding raw output back to the model

Logs can quietly become the largest part of a coding session.

When a command prints 20,000 lines, Codex may receive that output, reason about it, and then carry a version of it into later turns. The same thing happens with minified JSON, repository-wide file listings, screenshots, browser accessibility trees, and full test suites.

I try to filter before Codex sees the result:

# Instead of dumping every test result, run the focused test.
npm test -- payment-reconciliation

# Search for the error instead of opening the entire log.
Select-String -Path .\logs\app.log -Pattern "reconciliation failed" -Context 3,8

# Ask Git for the files that changed instead of rereading the repository.
git diff --name-only

The exact command depends on the project. The principle does not: machines are good at filtering. The model should receive the part that needs judgment.

This also applies to screenshots. A browser agent that takes repeated full-page screenshots, reads large DOM trees, and retries uncertain clicks can consume far more than a small code edit. My own six-figure-token runs were browser-heavy. Now I divide those jobs into clear phases and stop after each verified destination instead of asking one session to carry every website and every article body at once.

Keep AGENTS.md useful, not encyclopedic

Persistent instructions are valuable. I want Codex to know how to run the project, where the tests live, which files it should not edit, and how I define completion.

I do not want every session to begin with a miniature employee handbook.

OpenAI recommends reducing unnecessary context in AGENTS.md, limiting source files and date ranges, tightening prompts, and disabling MCP servers that are not needed for the task.[1] Developers discussing context engineering make the same point: huge generic instruction files can bury the few rules that actually matter.[17][20]

My preferred AGENTS.md contains:

the build, test, and lint commands that really work;
the project's important directories;
a short list of non-negotiable conventions;
boundaries around secrets, generated files, and destructive operations;
the expected verification before Codex says it is done.

I move rare workflows into separate documents and mention them only when the task needs them.

The same applies to plugins and MCP servers. Every enabled integration can add tools, descriptions, and choices. I would rather enable the tools needed for the job than make every request carry the vocabulary of my entire development environment.

Give Codex a stopping condition

An autonomous coding prompt should tell the agent when to stop.

I now include five things:

Goal: Fix the duplicate invoice bug.
Scope: Billing service and its tests only.
Constraints: Do not change the database schema or public API.
Verification: Run the focused billing tests and show the result.
Stop: Finish after the test passes and summarize changed files.

This is not prompt magic. It reduces exploration that I did not ask for.

Without scope, Codex may inspect several layers of the application. Without constraints, it may redesign something that only needed a small fix. Without verification, it may keep searching for confidence. Without a stopping condition, a capable agent can keep finding "helpful" follow-up work.

The best prompt is not necessarily long. It is specific about the outcome.

Watch usage before it becomes a surprise

I used to check usage only after Codex stopped me. Now I check at the beginning of a large task and again after an expensive phase.

Inside the CLI:

/status

Current Codex releases may also expose account usage views such as daily or weekly usage, depending on the client and rollout. The ChatGPT usage dashboard remains the account-level source of truth.[2][6]

I also check the installed version:

codex --version
codex update

When I researched this article on October 5, 2026, my standalone Windows CLI reported version 0.156.1 while OpenAI's changelog listed 0.160.0 as the latest release. OpenAI's documentation also says GPT-6 Astra requires Codex CLI 0.153.0 or newer.[3][12][13]

Version differences matter because profile syntax, model availability, slash commands, and agent settings change. If a valid configuration key appears to do nothing, I check the version before assuming my account does not support it.

Settings I would not copy from random posts

Several community guides recommend manually lowering the model context window or changing the automatic compaction threshold.

Codex has configuration keys for model metadata and compaction behavior, but I leave them unset. A manual model_context_window value does not enlarge the model's real context. A wrong value can make Codex account for context or compact at the wrong time. An aggressive model_auto_compact_token_limit can either retain too much history or compact so frequently that the agent keeps rediscovering details.[9]

I also avoid experimental context-management and rollout-budget flags in a basic setup. Experimental controls may be useful for testing, but they are a poor foundation for advice meant to survive a few Codex releases.

My goal is to control stable inputs: model, reasoning, speed, agents, task size, context, and output.

What to do when the allowance is already gone

There is no configuration line that legitimately resets a ChatGPT allowance.

OpenAI says Support does not manually reset Codex limits.[2] The available choices are to wait for the relevant window to reset, purchase credits if the account is eligible, move to a plan with more capacity, or use separately billed API access.[1][3]

I would not call API fallback a saving technique. It is a continuity technique. The work continues, but the cost moves from the subscription allowance to metered API billing.

Upgrading a plan can add capacity, but it will not fix a workflow that launches too many agents, carries giant logs, uses Fast mode by default, or assigns every small job to the most expensive model.

The workflow I use now

My current approach is boring, which is probably why it works.

Before starting:

I choose economy for routine work or balanced for normal development.
I run /status and confirm the model, reasoning level, speed tier, and remaining usage.
I give Codex one outcome, a sensible scope, verification, and a stop condition.

During the task:

I filter logs and search results before returning them to the model.
I allow at most two subagent threads unless the job clearly benefits from more.
I escalate reasoning only for the phase that is actually hard.
I compact after a completed phase if the objective is unchanged.

After the task:

I save durable decisions in code, tests, documentation, or a short handoff file.
I start a new thread for the next unrelated task.
I check /status again after unusually long browser, research, or multi-agent work.

None of these steps is dramatic. Together they turn Codex from an always-on genius with an unknown appetite into a set of tools I can route deliberately.

My conclusion

I do not think the best way to avoid a Codex limit is to obsess over every token.

The better approach is to stop asking an expensive reasoning system to carry work it does not need.

Use Luna for the repetitive jobs. Keep Fast mode off unless the wait matters. Let Sol handle normal development. Raise reasoning for a difficult phase, then lower it again. Keep agents bounded. Keep threads about one task. Filter large tool output. Write short instructions. Check /status before a long run surprises you.

Codex will still have limits. That is part of using a shared, expensive service. But after seeing how much two browser jobs consumed, I would rather spend my allowance on judgment, debugging, and implementation than on old chat history, duplicate searches, and a faster spinner.

References

Originally published at https://blog.jenuel.dev/blog/how-i-stopped-burning-through-my-codex-usage-limit

AI Made Me Faster. Shouldn't I Be Paid More?

Jenuel Oras Ganawed — Sat, 03 Oct 2026 05:46:12 +0000

If one employee can now do the work of two, who keeps the difference?

AI has changed the speed of my work.

I can move from an idea to research, a draft, code, testing, and something ready to publish much faster than I could before. Tasks that used to consume a whole afternoon can sometimes be finished before lunch. The obvious thought is: if I can produce more value in the same number of hours, shouldn't my salary increase?

But there is another possibility that is harder to ignore.

If everyone can produce more with AI, perhaps the work becomes cheaper. Maybe employers stop paying a premium for tasks that used to require years of experience. Maybe one employee is expected to carry the workload of two people without receiving two salaries. Maybe the company captures the productivity gain while the worker receives a busier day.

So which is it? Does AI push salaries up because workers become more productive, or push them down because human work becomes easier to replace?

The honest answer is: both are happening, but not to the same people.

AI does not automatically raise salaries. It changes the bargaining position of workers. Pay rises when AI makes a person's judgment, experience, or specialized skills more valuable. Pay can stagnate or fall when AI makes the person's output easier for someone else to reproduce.

That difference matters more than the number of tasks completed.

A salary is not a productivity score

I used to think about salary in a fairly simple way: become better, finish more work, and eventually earn more. That relationship exists, but it is not automatic.

A salary is the price an employer must pay to keep or replace a worker. Productivity matters, but so do scarcity, bargaining power, demand, competition, ownership, and how easily the work can be measured.

Suppose AI lets me complete twice as many reports. Several outcomes are possible:

The company gives me a raise because my output became more valuable.
The company keeps my salary unchanged and enjoys a larger profit margin.
The company raises my workload until the saved time disappears.
The company needs fewer people doing the same work.
The price of the service falls because every competitor can now produce it faster.
I use the extra capacity to create my own product, accept more clients, or move into a better-paid role.

The technology creates the productivity gain. The employment relationship decides who receives it.

Historical evidence suggests that higher economy-wide productivity usually contributes to higher wages over time, including for workers near the bottom of the wage distribution. But those gains are not distributed equally. Research on the digital revolution found that the highest earners generally captured the largest wage increases as technology became more valuable.[7]

That is an important warning for the AI era. A rising productivity number does not mean everyone gets an equal raise.

We already know AI can increase output

The productivity evidence is no longer based only on demos.

A study of 5,179 customer-support agents found that access to an AI assistant increased issues resolved per hour by 14% on average. Novice and lower-skilled workers improved by 34%, while experienced workers gained much less.[11]

In another experiment involving 453 professionals, ChatGPT reduced the time required for writing tasks by 40% and increased independently rated quality by 18%.[12]

Companies expect those gains to spread. A 2026 NBER survey of nearly 750 corporate executives found that more than half of their firms had already invested in AI. Executives expected AI-related labor-productivity gains to strengthen, especially in finance and high-skill services, although perceived improvements were often larger than measured improvements.[16]

A separate survey of nearly 6,000 executives in the United States, United Kingdom, Germany, and Australia found that nine out of ten reported no measurable effect from AI on employment or productivity during the previous three years. Yet the same executives expected AI over the next three years to raise productivity by 1.4%, raise output by 0.8%, and reduce employment by 0.7%.[18]

That gap between today's measurements and tomorrow's expectations explains some of the confusion. AI is visibly changing individual workflows, but changes in company revenue, staffing, and salaries take longer to appear.

Recent firm-level research provides some evidence that the gains are beginning to show up. Companies investing more heavily in AI experienced faster productivity growth from 2018 to 2024, particularly when they used AI-skilled employees to build durable company knowledge and processes. Employment did not fall overall in that study, high-skilled employment increased, and average wages rose.[17]

That sounds hopeful. But a firm's average wage can rise even if it hires more expensive specialists while ordinary employees receive no raise. We have to distinguish a company becoming more productive from every worker sharing the benefit.

The first surprise: AI users are not automatically earning more

One of the strongest early studies on actual earnings comes from Denmark. Researchers connected surveys about chatbot adoption with administrative employment records covering roughly 25,000 workers and 7,000 workplaces.

Workers reported productivity benefits. Employers introduced new AI-related responsibilities. Work was reorganized around content generation, AI oversight, and integration. Yet two years after ChatGPT's release, the researchers found no detectable average effect on earnings or recorded hours, even among frequent users and workers who said AI saved them time. Their estimates ruled out average effects larger than about 2%.[4]

That result feels familiar. A tool can make someone's day easier or faster without changing the salary attached to the job title.

An employer usually does not say, "You produced 20% more this month, so we will immediately increase your salary by 20%." Salaries are reviewed periodically. Budgets are fixed. Individual output can be difficult to isolate. Sometimes the employee does not tell anyone how much time the tool saved. Sometimes management simply turns the faster workflow into the new baseline.

Another NBER study offers an uncomfortable possibility. Workers in occupations that complemented AI worked approximately 2.75 additional hours per week. The study also found positive associations between AI complementarity and hourly wages, but employee satisfaction declined. The researchers argue that when AI raises the value of another hour of work, employers and workers may extend the workday instead of converting all the gain into leisure.[6]

In other words, AI can raise pay and still leave a person worse off if expectations and working hours rise faster.

The second surprise: AI skills really do carry a premium

If ordinary users are not automatically receiving raises, why do we keep seeing headlines about enormous AI salaries?

Because employers are paying more for scarce AI-related skills.

PwC's 2026 Global AI Jobs Barometer analyzed more than one billion job advertisements across 27 countries and territories. It reported an average 62% wage premium for jobs requiring AI skills, up from 57% a year earlier. Jobs asking for specific AI skills were also growing much faster than the wider job market.[1]

An Oxford study of more than 10 million UK job vacancies found a smaller but still substantial result. AI skills were associated with a 23% wage premium across roles and a 36% premium in science, engineering, and technology jobs. The AI premium exceeded the study's estimated premium for a master's degree, although it remained below the premium for a PhD.[2]

Those numbers sound like proof that AI raises salaries, but there is an important limitation: job advertisements are not the same as a raise for an existing employee.

A role requiring machine learning, data engineering, model evaluation, or AI product ownership may already be more complex and senior than the average role. Employers may advertise a high salary because they need a scarce combination of experience and AI knowledge. The posting does not prove that adding ChatGPT to an ordinary workflow increases the salary by 62%.

Actual payroll data produces a more modest picture. Ravio's 2026 European technology compensation report found 88% year-over-year growth in AI and machine-learning hiring, with an average pay premium around 12%, varying by level. That is still meaningful, but it is far below the most dramatic advertised-wage headlines.[3]

My reading is that an AI premium exists, but employers pay for more than tool usage. They pay for people who can connect AI to expensive business problems, evaluate its failures, build reliable systems, and take responsibility for the result.

Knowing how to open an AI chat window will not remain scarce. Knowing what to ask, what to reject, and how to turn the output into dependable value can remain scarce for much longer.

When AI can lower pay

The same tool that increases my output can reduce the market price of that output.

Imagine that a simple website once required a week of developer time. AI reduces the work to one day. A developer may complete more projects and earn more. But competitors can do the same. More people can enter the market. Clients learn that the job is faster. The price may fall from a week's fee to a day's fee.

Productivity increased. The worker's income did not necessarily increase with it.

Online freelance markets provide early evidence of this effect. After ChatGPT's release, postings for automation-prone writing and coding work fell by 21% relative to manual-intensive work. Competition among freelancers increased. The jobs that remained tended to be more complex and better paid, but there were fewer routine opportunities available.[10]

This creates a barbell-shaped market. Basic work becomes cheaper or disappears. Difficult work still pays well, sometimes better than before. The middle can become uncomfortable.

A 2026 Apollo white paper offers a more pessimistic finding. Using occupation-level wage data and observed AI-usage measures, it estimated that real wage growth in highly exposed U.S. occupations was 6.7 percentage points lower after 2023, with no detectable employment effect. The negative estimate was larger among lower-paid workers.[5]

That result deserves caution. It is an early, non-peer-reviewed analysis built from occupation-level data, and the period includes many economic changes besides AI. It does not prove that AI caused every difference it measured. But it raises a plausible scenario: companies may keep roughly the same number of employees while allowing pay growth to slow because each worker can produce more.

Pay can fall without a dramatic layoff announcement. It can happen through smaller raises, weaker freelance rates, fewer promotions, reduced hiring, or higher expectations for the same salary.

Entry-level workers may feel the pressure first

AI is especially good at the work companies traditionally give to beginners: first drafts, simple analysis, basic code, routine customer responses, documentation, and information gathering.

Stanford researchers examining payroll records for millions of U.S. workers found no evidence of broad economy-wide displacement. They did, however, find that employment for workers aged 22 to 25 in highly AI-exposed occupations was 19% below the path implied by less-exposed peers. The gap came mainly from reduced hiring rather than more workers being fired. Base pay showed less adjustment than employment.[9]

This may be one reason existing employees do not immediately see their salaries fall. Companies can change the workforce gradually by replacing fewer departing workers and hiring fewer juniors.

For someone already established, AI may increase leverage. For someone trying to enter the profession, AI may remove the small tasks that once served as training and proof of ability.

Even so, the U.S. Bureau of Labor Statistics still projects employment for software developers, quality-assurance analysts, and testers to grow 10% from 2025 to 2035, much faster than the average occupation. It expects strong demand from AI, robotics, automation, security, and the continuing expansion of software products.[15]

The job is not simply disappearing. The entry requirements and valuable parts of the job are changing.

The key distinction: does AI complement me or commoditize me?

I think this is the most useful question a worker can ask.

AI complements me when it makes my judgment, relationships, domain knowledge, or responsibility more productive. A doctor who uses AI but remains accountable for the diagnosis may handle information better. A senior developer may use an agent to implement code while focusing on architecture, security, and product decisions. A marketer may generate drafts quickly but still own the strategy and customer understanding.

AI commoditizes me when the buyer mainly wants an output that the tool can now produce cheaply and consistently. If the work is easy to specify, easy to verify, and available from thousands of people using the same models, the price will face downward pressure.

Research on firm-level AI exposure supports this distinction. Tasks with greater AI exposure experienced lower labor demand, but productivity gains at AI-adopting firms increased demand elsewhere. Overall employment effects remained modest because substitution in some tasks was offset by growth and reallocation in others.[8]

The IMF's analysis of observed AI usage across more than 100 countries found that current gains are concentrated in higher-wage professional occupations. The concentration is particularly strong in lower-income countries, where AI use has not spread as widely across the rest of the workforce.[14]

AI may narrow performance gaps inside a task while widening economic gaps between people who control valuable systems and people who supply easily replicated output.

OECD research found no clear evidence that AI exposure changed wage inequality between occupations during the 2014–2018 period, but it found some evidence of lower wage inequality within exposed occupations. One possible explanation is that lower-performing workers gain more from AI than top performers.[13]

That sounds fairer, but it can have a darker interpretation. If AI makes average workers perform more like experts, employers may become less willing to pay for routine expertise. The premium moves toward the people who design the workflow, own the client relationship, carry legal responsibility, or solve problems the model cannot handle.

Who captures the gain?

Suppose I use AI to save ten hours each week. Who owns those ten hours?

If I am paid a fixed salary, my employer may own them. If I freelance and charge by the hour, the saved time may reduce my bill unless I change to value-based pricing. If I charge per project, I may keep the gain by completing more projects. If I own the product, the productivity gain can become profit or growth. If I use the time to learn a scarcer skill, it may become a future salary increase.

This is why the same technology creates very different outcomes for employees, contractors, and business owners.

The IMF warns that AI could increase wealth inequality even in scenarios where wage inequality narrows. Owners of AI systems, companies, and capital can receive higher returns, while workers depend mainly on what happens to their wages. High-income workers are also more likely to own assets and to hold jobs where AI complements rather than replaces their contribution.[19]

The question is not only whether AI creates value. It clearly can. The harder question is whether the value appears in wages, profits, lower prices, shorter working hours, or returns to the owners of capital.

Markets and company policies make that choice. AI does not.

What I would do as an employee

I would not walk into a salary discussion and say, "I use AI now, so I deserve more money." AI usage by itself is becoming ordinary.

I would show the business result.

How much time did the workflow save?
Did output increase without increasing errors?
Did I help the team avoid hiring a contractor?
Did I shorten delivery time?
Did I improve revenue, reliability, customer retention, or support capacity?
Did I build a repeatable system that other employees now use?
Am I responsible for checking the AI's work and handling the difficult exceptions?

A stronger salary argument sounds like this:

I redesigned this process, reduced delivery time from five days to two, maintained quality, documented the workflow, and helped the rest of the team adopt it.

That is harder to dismiss than saying I wrote more prompts.

I would also avoid giving away every productivity gain invisibly. If I quietly use AI to finish twice as much work, management may only see that the new workload is normal. Tracking before-and-after measurements makes the improvement visible.

Most importantly, I would move toward ownership. That can mean owning a system, a customer relationship, a product area, an architectural decision, a compliance risk, or a measurable business outcome. The closer my contribution is to an expensive consequence, the harder it is to price me as generic output.

What employers should do

If a company receives all the value from AI while workers receive only larger workloads, employees will learn to hide efficiency gains or disengage from the process.

Companies should consider sharing the gain through some combination of:

Higher salaries for expanded responsibility
Performance bonuses tied to measurable outcomes
Profit sharing or equity
Shorter workweeks or protected focus time
Training and promotion pathways
Clear policies about how productivity data will affect staffing

This is not only about fairness. Workers are more likely to adopt AI honestly when they do not believe the tool will immediately be used against them.

Employers also need to preserve entry-level learning. If AI performs every junior task, the company may enjoy lower costs today and discover later that it has no experienced employees ready to take responsibility.

So, will salaries rise or fall?

My answer is not satisfying, but I think it is the truthful one.

Average wages may rise in the long run if AI creates new products, expands demand, and raises economy-wide productivity. Historical evidence supports that possibility. But individual workers should not assume that doing more tasks automatically leads to a raise.

Salaries are more likely to increase when:

AI skills remain scarce.
AI complements domain expertise rather than replacing it.
The worker owns decisions and outcomes, not only production.
The company can connect the worker's contribution to revenue or avoided cost.
The worker can negotiate, change employers, freelance, or build a product.

Salaries are more likely to stagnate or decrease when:

AI makes the output easy for many people to reproduce.
Employers can measure higher output but not individual judgment.
Entry-level supply increases while routine demand falls.
Workers have little bargaining power.
The productivity gain is captured through profits, lower prices, or higher workloads.

The sentence I keep coming back to is this:

AI does not pay people for doing more. The market pays people for being difficult to replace.

That may sound harsh, but it also points toward a practical strategy. I do not need to compete with AI at typing, drafting, searching, or generating routine code. I need to use it to move closer to the parts of work that still carry responsibility: choosing the right problem, understanding the customer, judging risk, integrating systems, and owning the result.

AI can make me faster. Whether it makes me better paid depends on what I do with the speed, who can copy my output, and whether I have enough leverage to claim part of the value I create.

Sources

Originally published at https://blog.jenuel.dev/blog/ai-made-me-faster-shouldnt-i-be-paid-more

AI Is Making Us More Capable. Is It Making Us Less Capable Too?

Jenuel Oras Ganawed — Thu, 24 Sep 2026 11:08:06 +0000

What better AI could do to human productivity, learning, creativity, judgment, and work

AI already writes reports, explains code, summarizes meetings, generates designs, answers customers, and turns rough ideas into working prototypes. The systems are getting better quickly. They are also becoming easier to trust because their answers sound more polished, more confident, and more human.

That combination is powerful. It is also where the danger begins.

I do not think AI is simply making people lazy. That word is too easy and too moralistic. The more interesting change is that AI is altering which mental muscles we use, which ones we neglect, and what employers expect a normal person to produce in a day.

Used well, AI can remove repetitive work and give people more time for judgment, creativity, and relationships. Used carelessly, it can create a person who produces more but understands less. Both outcomes are already visible in the research.

My view is simple:

AI lowers the cost of producing an answer. It does not lower the cost of understanding the consequences.

As AI improves, that difference will matter more.

The productivity gains are real

It would be a mistake to dismiss AI as a toy or a shortcut for people who do not want to work. Controlled experiments and workplace studies have found meaningful gains.

In a study of 453 college-educated professionals doing writing tasks, ChatGPT reduced completion time by 40% and raised independently judged quality by 18%. The largest gains went to people who had performed worse without AI.[1]

A larger study of 5,172 customer-support agents found that an AI assistant increased issues resolved per hour by about 15%. Less-experienced and lower-performing workers gained the most, while the strongest workers saw smaller benefits. The tool appeared to spread some of the habits and knowledge of top performers to newer employees.[2]

Consultants in a field experiment also completed suitable tasks faster and produced better-rated work with GPT-4. But the same experiment exposed an important weakness. On a problem deliberately chosen because the model handled it poorly, AI users were 19 percentage points less likely to reach the correct answer.[3]

AI can therefore raise the floor. It can help an average worker draft, analyze, translate, or organize work at a level that once required more experience. But it does not raise the ceiling equally on every task. Sometimes it leads the worker confidently in the wrong direction.

There are also signs that AI can return time to workers rather than simply demanding more output. In a six-month experiment involving 7,137 knowledge workers at 66 companies, people given Microsoft 365 Copilot spent about two fewer hours per week on email during the latter half of the study and worked less outside normal hours. The experiment found little change in the overall mix of tasks, but the reduction in after-hours work matters.[4]

That is one possible future: less time cleaning up email, formatting documents, searching through meetings, and repeating administrative work.

There is another possible future too. Once a company learns that a report can be written in half the time, it may not give the employee the afternoon back. It may ask for twice as many reports.

Productivity and human wellbeing are not the same measurement.

Assisted performance is not the same as human ability

The question "Did the person produce a better result with AI?" is different from "Did the person become better?"

This distinction is easy to miss because the finished output may look excellent. A student submits a correct answer. A junior developer produces working code. An employee sends a polished analysis. The tool-assisted performance is visible. What the person can do when the tool is unavailable, wrong, or misleading is harder to see.

A large classroom experiment in high-school mathematics made the difference clear. Students using a standard GPT-4 interface performed much better during AI-assisted practice. But when the AI was removed, they scored 17% lower than students who had practiced without it. A guarded AI tutor that offered structured hints rather than simply supplying answers largely avoided this penalty.[5]

The lesson is not that AI should be banned from education. The lesson is that interface design changes what people learn. An answer machine and a tutor may use the same underlying model but produce very different humans.

A randomized study of software developers found a similar pattern. Participants used AI while learning an unfamiliar programming library, then completed a mastery assessment. The AI-assisted group scored 17 percentage points lower, with the largest deficit appearing in debugging. People who delegated entire tasks learned less. Those who asked conceptual questions and requested explanations preserved more understanding.[7]

This matters far beyond school. Every workplace has an apprenticeship system, even if nobody calls it that. Junior employees learn by writing the first draft, tracing the bug, sitting through the difficult customer call, comparing alternatives, and being corrected by someone more experienced.

If AI quietly absorbs all the beginner tasks, new workers may appear productive without getting enough practice to become senior workers.

That is the skill-formation problem I worry about most. AI can make the first rung of the career ladder easier to reach while simultaneously weakening the ladder itself.

Cognitive offloading is useful, but it has a price

Humans have always moved thinking outside the brain. We write notes because memory is limited. We use calculators because arithmetic is repetitive. We use maps because navigating every street from memory is unnecessary.

AI is another form of cognitive offloading, but it is unusually broad. A calculator handles calculation. A generative model can handle the search, the explanation, the first draft, the counterargument, the code, and sometimes the decision recommendation. It can offload an entire chain of thought rather than one mechanical step.

A Microsoft Research survey of 319 knowledge workers found that higher confidence in AI was associated with less reported critical thinking. Workers described shifting their effort away from producing material and toward checking, integrating, and supervising AI output. That shift is not automatically bad, but it assumes the person has enough expertise and motivation to perform the checking.[6]

Another preregistered study found what researchers called a "speedup illusion." Participants expected AI assistance to make simple cognitive tasks much faster, and the work felt easier, but measured completion times were not significantly faster than independent work.[10]

Ease can be mistaken for efficiency. Fluency can be mistaken for truth. A confident answer can feel like understanding even when the user has not built a mental model of the problem.

This creates an automation paradox. As AI handles more routine work, the remaining human role becomes oversight. But if people stop practicing the underlying task, they become less able to recognize the rare moment when the system fails.

Pilots have discussed versions of this problem for decades. Automation handles normal conditions, leaving the human to intervene during unusual and dangerous conditions, precisely when deep skill matters most. Generative AI could bring the same problem into offices, classrooms, hospitals, law firms, and software teams.

AI may improve individual creativity while making culture more similar

AI can be a useful creative partner. It can give someone a starting point when the blank page feels impossible. It can generate alternatives, challenge an assumption, or help a person express an idea they could not previously execute.

An experiment with 293 writers found that access to GPT-generated story ideas improved ratings of novelty, usefulness, and enjoyment, especially for participants who initially scored lower in creativity. Yet the AI-assisted stories also became more similar to one another.[8]

This is a strange tradeoff. AI can make each individual output better while making the collection of outputs less diverse.

We can already see how this might happen. Millions of people ask related models for headlines, color palettes, marketing plans, code structures, presentation formats, and social posts. The model draws from recurring patterns and offers statistically likely solutions. Those suggestions are often competent. They are also pulled toward the center.

The danger is not that AI will eliminate creativity. It may increase the number of people who can create. The danger is that the same invisible collaborator will sit beside everyone, gently steering different people toward similar language, aesthetics, and conclusions.

A large meta-analysis of human-AI collaboration reached another sobering result. Human-AI combinations generally outperformed humans working alone, but they often failed to beat whichever was already better: the human or the AI. Negative synergy was especially common in decision tasks, while content-creation tasks were more likely to benefit.[9]

Putting a person and an AI together does not automatically combine their strengths. Sometimes the human follows a bad suggestion. Sometimes the person overrules a correct one. Good collaboration requires knowing when to rely on the system and when to resist it.

Programming shows both sides of the argument

Software development is one of the clearest laboratories for AI-assisted work because activity can be measured through tasks, pull requests, tests, commits, and releases.

Three randomized company experiments involving 4,867 developers found that access to GitHub Copilot increased completed tasks by about 26%, with larger gains among less-experienced developers.[11]

That sounds decisive until we look at a different kind of programming work. METR studied 16 experienced open-source developers completing 246 real tasks in mature repositories they knew well. With early-2025 AI tools, the developers took 19% longer. Before the experiment they expected AI to make them faster, and afterward they still believed it had, even though the timing data showed the opposite.[12]

These findings are not necessarily contradictory. AI may perform well on bounded tasks, boilerplate, unfamiliar APIs, prototypes, tests, and greenfield code. It can struggle when the work depends on years of repository context, implicit design choices, exact quality standards, and knowing which apparently reasonable change will cause trouble elsewhere.

A 2026 study of AI-assisted code found a 30.7% median reduction in initial task time and no systematic downstream maintainability disadvantage when another developer later changed the code. That is encouraging, although it does not prove that all AI-generated systems remain secure or maintainable over years.[19]

Security deserves separate caution. An earlier controlled study found that participants using an AI coding assistant produced less-secure solutions while becoming more likely to believe their code was secure.[20]

The distance between "writing code" and "shipping a dependable product" also matters. A 2026 NBER working paper found that newer generations of coding tools were associated with large increases in coding activity, but the effect shrank sharply when researchers looked at projects, releases, and actual marketplace usage rather than commits alone.[13]

More code is not always more value. It can also mean more code to review, test, secure, understand, and maintain.

For developers, I think the durable advantage will not be typing code faster. AI is already winning that contest. The advantage will be knowing what should be built, recognizing hidden failure modes, designing systems that survive change, and verifying work that looks correct before it causes damage.

Experience becomes the filter.

AI is changing entry-level work before it replaces whole professions

Predictions about mass unemployment remain ahead of the evidence. A Danish study connecting surveys with administrative data found rapid AI adoption and changes in job tasks, but no detectable average effect on earnings or recorded work hours during the first two years after ChatGPT.[17]

The absence of broad displacement does not mean nothing is happening. Labor markets can change first through hiring. Companies may keep their current employees while recruiting fewer beginners.

A Stanford Digital Economy Lab analysis found no widespread economy-wide displacement, but workers aged 22 to 25 in highly AI-exposed occupations were 19% below the employment path implied by less-exposed peers. The pattern appeared mainly through reduced hiring rather than increased separations. The authors describe the result as descriptive rather than definitive proof that AI caused the decline.[14]

This early-career question deserves attention. Entry-level workers often perform the exact tasks that AI handles first: basic research, first drafts, simple code, document preparation, scheduling, routine analysis, and customer responses.

If those tasks disappear, businesses may become more efficient today while creating a shortage of experienced people later. Organizations need to redesign junior roles rather than simply deleting them. Beginners still need supervised opportunities to struggle, make decisions, receive feedback, and learn why a correct-looking answer can be wrong.

Global exposure is also uneven. The International Labour Organization estimates that one in four workers worldwide is in an occupation with some generative-AI exposure, but only 3.3% of global employment falls into the highest-exposure category. The ILO expects transformation to be more common than full job automation because most occupations still contain tasks that require people.[15]

A 2025 OECD survey of more than 5,000 small and medium-sized businesses found that 31% used generative AI. Among adopters, 65% reported improved employee performance, while 83% reported no change in overall staffing need. These are employer-reported perceptions rather than audited causal effects, but they fit the broader picture: work is changing faster than employment totals.[16]

New U.S. survey evidence describes workplace AI use as broad but shallow. Many occupations now contain people using generative AI, yet adoption within individual tasks and among workers doing similar jobs varies widely.[18]

The future may not divide neatly between people whose jobs were automated and people whose jobs were untouched. It may divide between workers who know how to direct and verify AI, workers who depend on it without understanding it, and workers who never receive the access or training needed to benefit.

What happens as AI gets much better?

Some current weaknesses will shrink. Models will make fewer obvious errors, retain more context, operate software directly, and complete longer projects. This will make AI more useful. It may also make humans less likely to question it.

Bad AI invites skepticism. Very good AI earns trust. Near-perfect AI may create the most dangerous failures because the user has learned that checking is usually unnecessary.

As capability rises, I expect five human changes.

First, production will become cheaper. More people will be able to create software, videos, reports, lessons, businesses, and research summaries. Ideas that once required a team may be tested by one person.

Second, judgment will become more valuable. When production is abundant, deciding what deserves to exist becomes the scarce skill. Clear goals, taste, ethics, prioritization, and knowledge of real users will matter more.

Third, unaided skill will become less visible. A person may produce expert-looking work without expert-level understanding. Credentials and portfolios will become harder to interpret unless they include evidence of reasoning, verification, and ownership.

Fourth, organizations may capture the time savings. AI could shorten the workweek, reduce administrative overload, and make jobs less exhausting. It could just as easily increase expected output and monitoring. Technology does not decide who receives the benefit. Contracts, management, competition, and labor policy do.

Fifth, inequality may shift rather than disappear. AI sometimes helps weaker performers more, which can narrow gaps within a task. But experienced workers, well-funded companies, and countries with better infrastructure may be more capable of integrating advanced systems safely. People with domain expertise can also judge AI output more effectively than beginners.

The same technology can democratize production and concentrate power at the same time.

How to use AI without giving away your mind

The answer is not to avoid AI. Refusing useful tools will not protect workers or students from a world in which everyone else uses them. The better approach is to separate assistance from surrender.

Use a learning mode and a production mode

When the goal is speed, let AI draft and automate. When the goal is learning, ask it for hints, questions, explanations, and feedback rather than finished answers. Do not confuse completing the assignment with building the skill.

Think before prompting

Write your own position, plan, diagnosis, or design first, even if it is rough. Then compare it with the AI's response. This preserves independent judgment and makes disagreement visible.

Ask for reasons and failure conditions

A useful prompt is not only "give me the answer." Ask what assumptions the answer depends on, what evidence could disprove it, where it is most likely to fail, and what an informed critic would challenge.

Keep some unaided practice

Developers should still debug without an agent sometimes. Students should still solve some problems without a tutor. Writers should still face the blank page. Skills weaken when they are never retrieved.

Verify in the real environment

Run the code. Read the source. Test the edge case. Check the calculation. Ask the affected person. AI output should be treated as a candidate, not as reality.

Measure outcomes, not activity

Do not judge AI adoption by prompts sent, words generated, lines of code, or documents created. Measure errors, rework, customer outcomes, security, retention, cycle time, and whether people can explain what they submitted.

Protect apprenticeship

Companies should not eliminate every junior task simply because AI can perform it. Redesign those tasks around supervised review, real responsibility, and deliberate learning. Today's efficiency should not destroy tomorrow's expertise.

Preserve human decision rights

Workers need the authority to challenge AI recommendations without being punished for slowing down a process. If the system is officially "only an assistant" but employees are expected to follow it, human oversight is theatre.

The question is what we stop practicing

AI will probably make humans more capable as a group. We will produce more, explore more ideas, and cross technical barriers that once excluded millions of people. I find that exciting.

But capability with a tool is not the same as capability inside a person.

If AI becomes our calculator, tutor, editor, programmer, analyst, and adviser all at once, it will shape the habits beneath our work. We may become better at asking, selecting, and supervising. We may become worse at recalling, drafting, debugging, and patiently reasoning through uncertainty. Some of that trade is sensible. Some of it could leave us fragile.

The biggest danger is not that AI makes everyone lazy. It is that we become highly productive while losing the ability to notice what we no longer understand.

The biggest opportunity is not simply faster work. It is using automation to create more room for the parts of human life that should not be automated: judgment, responsibility, curiosity, courage, relationships, and care.

AI will keep getting better. The outcome for humans will depend on whether we use that growing power to extend our minds or to avoid using them.

Sources

[1] https://www.science.org/doi/10.1126/science.adh2586 — Experimental Evidence on the Productivity Effects of Generative AI
[2] https://academic.oup.com/qje/article/140/2/889/7990658 — Generative AI at Work
[3] https://pubsonline.informs.org/doi/10.1287/orsc.2025.21838 — Navigating the Jagged Technological Frontier
[4] https://www.nber.org/papers/w33795 — Shifting Work Patterns with Generative AI
[5] https://doi.org/10.1073/pnas.2422633122 — Generative AI without Guardrails Can Harm Learning
[6] https://www.microsoft.com/en-us/research/wp-content/uploads/2025/01/lee_2025_ai_critical_thinking_survey.pdf — The Impact of Generative AI on Critical Thinking
[7] https://www.anthropic.com/research/AI-assistance-coding-skills — How AI Assistance Impacts the Formation of Coding Skills
[8] https://doi.org/10.1126/sciadv.adn5290 — Generative AI Enhances Individual Creativity but Reduces Collective Diversity
[9] https://www.nature.com/articles/s41562-024-02024-1 — When Combinations of Humans and AI Are Useful
[10] https://arxiv.org/abs/2605.23177 — Cognitive Offloading and the Speedup Illusion
[11] https://pubsonline.informs.org/doi/10.1287/mnsc.2025.00535 — Effects of Generative AI on High-Skilled Work
[12] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study — METR Experienced Open-Source Developer Productivity Study
[13] https://www.nber.org/papers/w35275 — Writing Code vs. Shipping Code
[14] https://digitaleconomy.stanford.edu/publication/canaries-in-the-coal-mine-six-facts-about-the-recent-employment-effects-of-artificial-intelligence — Canaries in the Coal Mine
[15] https://www.ilo.org/publications/generative-ai-and-jobs-refined-global-index-occupational-exposure — Generative AI and Jobs: A Refined Global Index
[16] https://www.oecd.org/en/publications/generative-ai-and-the-sme-workforce_2d08b99d-en/full-report.html — Generative AI and the SME Workforce
[17] https://www.nber.org/papers/w33777 — Still Waters, Rapid Currents
[18] https://www.nber.org/papers/w35677 — What Work Does Generative AI Do?
[19] https://link.springer.com/article/10.1007/s10664-026-10889-1 — Echoes of AI: Downstream Effects on Software Maintainability
[20] https://arxiv.org/abs/2211.03622 — Do Users Write More Insecure Code with AI Assistants?

Originally published at https://blog.jenuel.dev/blog/ai-is-making-us-more-capable-is-it-making-us-less-capable-too

StyleX explained: Meta's answer to CSS that gets harder as apps grow

Jenuel Oras Ganawed — Fri, 04 Sep 2026 02:25:36 +0000

CSS is easy when a project is small. Then the application grows, a design system arrives, several teams begin shipping into the same interface, and a harmless change to one selector breaks a screen nobody remembered to test.

StyleX is Meta's attempt to make that situation less fragile. You write styles as JavaScript objects beside your components, but StyleX extracts those declarations during the build and emits a static CSS file. Meta describes it as CSS-in-JS in authoring form, without depending on runtime style injection in production.[1][2]

That sounds like another entry in an already crowded list of styling libraries. The interesting part is not the object syntax. It is the set of restrictions StyleX accepts to make styles predictable across a large codebase.

What StyleX is

StyleX is an open-source styling system and compiler from Meta. The company open-sourced it at the end of 2023 after developing the approach for its own large web products. Meta says StyleX is now its standard styling system across Facebook, Instagram, WhatsApp, Messenger, and Threads, and names Figma and Snowflake among its external users.[2]

The package is framework-agnostic in the narrow, practical sense that it produces className strings and style objects. The official documentation lists React, Preact, Solid, lit-html, and Angular as good fits. Vue and Svelte can use it too, although their compiled file formats may require extra configuration.[1]

The core API is small:

stylex.create() defines styles.
stylex.props() combines styles and returns the props you spread onto an element.
stylex.defineVars() and stylex.createTheme() provide typed design tokens and themes.
The compiler turns declarations into reusable atomic CSS classes.

At the time of writing, the npm registry lists @stylexjs/stylex version 0.19.0 under the MIT license.[3]

A small example

import * as stylex from '@stylexjs/stylex';

const styles = stylex.create({
  button: {
    alignItems: 'center',
    backgroundColor: '#2563eb',
    borderWidth: 0,
    borderRadius: 8,
    color: 'white',
    cursor: 'pointer',
    display: 'inline-flex',
    fontWeight: 600,
    paddingBlock: 10,
    paddingInline: 16,

    ':hover': {
      backgroundColor: '#1d4ed8',
    },
  },

  disabled: {
    cursor: 'not-allowed',
    opacity: 0.55,
  },
});

type ButtonProps = {
  disabled?: boolean;
  children: React.ReactNode;
};

export function Button({ disabled = false, children }: ButtonProps) {
  return (
    <button
      disabled={disabled}
      {...stylex.props(styles.button, disabled && styles.disabled)}
    >
      {children}
    </button>
  );
}

This feels like ordinary CSS-in-JS, but the production result is different. The compiler removes the local style objects, hashes each property-value pair into an atomic class, deduplicates repeated declarations, and emits the rules in a static stylesheet. Local combinations can be resolved at build time; styles passed across module boundaries use a small runtime merge.[2]

That last detail matters. Calling StyleX "zero runtime" without qualification is too neat. It avoids production-time style injection, and much of the work disappears during compilation, but some compositions can still need a tiny class-merging runtime. The official docs make the same distinction by describing static CSS output and a small runtime for merging class names.[1]

Why atomic CSS matters here

An atomic class normally contains one declaration:

.x-color-blue {
  color: blue;
}

.x-padding-16 {
  padding: 16px;
}

If 500 components use the same blue text, StyleX can reuse one generated rule instead of producing 500 component-specific declarations. Meta says this approach reduced CSS size by 80% during its migration and allows stylesheet growth to flatten as more declarations are reused.[2]

Atomic CSS is not new. Tailwind also encourages reuse through small utility classes. The difference is the authoring experience. In StyleX, you write property-value objects with local semantic names such as styles.button or styles.errorMessage; the compiler chooses and reuses the generated classes.

You do not have to decide whether the class should be named .primary-button, .buttonPrimary, or .blue-button-v2. Better still, a later refactor does not leave that old color embedded in a misleading class name.

The bigger promise: deterministic composition

Large CSS systems often fail in boring ways. A stylesheet loads in a different order. A selector becomes slightly more specific. Somebody reaches for !important. A component accepts a custom class, but nobody can confidently predict which declarations will win.

StyleX tries to remove that uncertainty. Styles are composed through stylex.props(), and later style objects win when the same property is repeated. The compiler also accounts for overlaps between shorthand and longhand properties, such as margin and marginTop, rather than leaving the result to accidental source order.[1][2]

const styles = stylex.create({
  base: {
    color: 'black',
    margin: 0,
  },
  featured: {
    color: 'rebeccapurple',
    marginTop: 12,
  },
});

<div {...stylex.props(styles.base, styles.featured)} />

The intended result is readable from the call site: featured overrides the conflicting parts of base. That makes style props useful for component libraries because a component can expose controlled customization without handing callers an unpredictable specificity fight.

StyleX types can also restrict which properties a component accepts through its style prop. A layout component might permit color and typography changes while rejecting external margins. The docs describe this as a way to enforce sophisticated customization rules without adding runtime checks.[1]

Dynamic values still work

Build-time extraction sounds incompatible with values that only exist in the browser. StyleX handles them with CSS custom properties.

const styles = stylex.create({
  progress: (percentage: number) => ({
    width: `${percentage}%`,
  }),
});

function ProgressBar({ value }: { value: number }) {
  return <div {...stylex.props(styles.progress(value))} />;
}

The compiler can generate a static rule whose value points to a CSS variable, then place the current variable value in the element's inline style object. Static structure stays in the stylesheet while runtime data remains dynamic. Meta documents the same mechanism for values that the compiler cannot know ahead of time.[2]

StyleX also provides APIs for variables, themes, keyframes, constants, media queries, and view transitions. The appeal is that these names become imported references instead of loose global strings.[1]

The constraints are the product

StyleX only works because the compiler can understand the styles before the application runs. A raw style object generally needs literals, plain objects, arrays, constants that resolve locally, or approved dynamic-style functions. Arbitrary function calls, object spreads, and ordinary values imported from other modules are not allowed inside style definitions. Shared values should use StyleX's variable and constant APIs.[1]

This will annoy developers who enjoy treating style objects as unrestricted JavaScript:

// This kind of free-form construction may not be statically analyzable.
const styles = stylex.create({
  card: {
    ...getSharedStyles(),
    color: importedPalette.brand,
  },
});

The StyleX version asks you to express those relationships through APIs the compiler recognizes. That costs some freedom. In return, the compiler can extract CSS, reject unsupported patterns early, deduplicate declarations, and resolve composition consistently.

I think this is the most honest way to judge StyleX. If you see the restrictions as arbitrary inconvenience, you will dislike it. If your team already loses time to accidental overrides, duplicated CSS, and unclear component styling contracts, those restrictions start to look like guardrails.

StyleX compared with common alternatives

Approach	Where styles are written	Production behavior	Main trade-off
Plain CSS or Sass	Separate stylesheets	Static CSS	Maximum CSS freedom, but architecture and naming discipline stay with the team
CSS Modules	Separate module files	Static, locally scoped CSS	Good isolation, though composition and dynamic values cross the JS/CSS boundary
Tailwind CSS	Utility classes in markup	Generated static CSS	Fast and direct, but markup carries many styling tokens
Runtime CSS-in-JS	JavaScript or TypeScript	Often creates or injects styles while the app runs	Flexible dynamic styling with runtime work and library-specific behavior
StyleX	JavaScript or TypeScript objects	Compiler-generated atomic CSS plus a small merge runtime where needed	Predictability and typed composition in exchange for compiler rules and build setup

This is not a universal ranking. A small marketing site may be easier with CSS Modules. A team that already works quickly in Tailwind may gain little from switching. StyleX becomes more convincing when many components, packages, and developers need to combine styles without negotiating selector order.

Where StyleX fits best

StyleX is worth a serious look when:

Your interface is authored mainly in JavaScript or TypeScript.
You maintain a design system or reusable component library.
Components need typed and predictable style overrides.
CSS bundle growth or duplicate declarations have become measurable problems.
Several teams ship into one application and global CSS conventions are getting harder to enforce.
You prefer colocating styles with components but do not want runtime style injection in production.

It is probably unnecessary when:

The site is small and plain CSS is already easy to reason about.
The team prefers semantic HTML and stylesheet-first architecture.
Your build stack cannot comfortably host the StyleX compiler.
You rely heavily on free-form selectors, global cascade behavior, or arbitrary JavaScript inside style definitions.
You would be migrating only because the library comes from Meta.

A library can solve a real problem and still be the wrong migration for your codebase.

Trying StyleX without betting the application

Do not begin by rewriting the design system. Pick one component with states and variants, such as a button, alert, or navigation item.

Follow the official installation guide for your bundler.
Convert one component and keep its visual regression or browser tests.
Add a variant and an external style prop to test composition.
Inspect the production build, not only the development experience.
Check whether generated CSS is extracted, whether the output is understandable in your debugging tools, and whether your server-rendering path still behaves correctly.
Ask the team whether the constraints made the component clearer or merely harder to write.

The installation step deserves attention. StyleX is not just a package you import; its benefits depend on compiler integration. The documentation covers Babel, PostCSS, Webpack, Vite, Rspack, esbuild, Bun, Next.js, React Router, SvelteKit, and other setups, but support quality and configuration details can differ by stack.[1]

My take

StyleX is less exciting as a new syntax than as a strong opinion about where CSS decisions should happen.

It moves conflict resolution, deduplication, naming, and much of composition into a compiler. Developers still write familiar CSS properties, and browsers still receive CSS. The unusual part is the contract between those two stages: write styles in a restricted form, and the tool can make guarantees that ordinary CSS architecture usually leaves to conventions and code review.

For a small app, that can be machinery you do not need. For a large React codebase, especially one with shared packages and many contributors, it is a reasonable trade.

I would not migrate a healthy project just to use it. I would test it when styling has become organizational work: naming meetings, specificity debugging, repeated overrides, and fear around changing old rules. That is the problem StyleX was built to address, and it is a better reason to adopt a tool than novelty.

Sources

[1] https://stylexjs.com/llms-full.txt — StyleX complete documentation
[2] https://engineering.fb.com/2025/11/11/web/stylex-a-styling-library-for-css-at-scale — Meta Engineering: StyleX, a styling library for CSS at scale
[3] https://registry.npmjs.org/@stylexjs/stylex/latest — npm registry metadata for @stylexjs/stylex

Originally published at https://blog.jenuel.dev/blog/stylex-css-meta-styling-system-explained

Why Gin Fits the AI Agent Era

Jenuel Oras Ganawed — Sat, 29 Aug 2026 15:34:24 +0000

I keep looking at Gin and thinking: this framework makes more sense now than it did a few years ago.

That is not because Gin is new. The project started in 2014.[1] It makes sense now because the way we build software has changed. AI coding agents can explore a repository, write handlers, add tests, run commands, and fix their own mistakes. That lowers the cost of choosing a language or framework your team does not already know by heart.

In that environment, a small and fast Go framework becomes very interesting.

Gin is a high-performance HTTP framework for Go.[1] On August 29, 2026, its GitHub repository showed more than 89,000 stars and 8,600 forks.[1] Those numbers do not prove that Gin is the fastest-growing framework or that every star represents a production user. They do show that this is not a niche experiment.

My view is simple: if I were starting a new API today, Gin would be on my shortlist for anything from a small internal service to a serious backend. AI agents make the learning curve easier, while Go and Gin keep the finished system relatively lean.

The timing is better than it looks

For years, framework choice was partly a question of team memory. Which stack do we already know? Which ecosystem can we debug at 2 a.m.? Which framework has enough tutorials that a new developer can copy a working pattern?

AI changes some of that calculation. It does not remove the need to understand the code, but it can handle much of the mechanical work: setting up routes, creating request types, writing table-driven tests, checking middleware order, and reading package documentation.

This favors frameworks with a small API surface and predictable conventions. Gin has routing, middleware, JSON binding and validation, route groups, recovery, rendering, and centralized error handling without trying to become an all-purpose application platform.[1][2]

An agent has less magic to misunderstand. A human reviewer has less framework machinery to inspect.

That combination matters. AI can generate a lot of code quickly. I do not want it generating a lot of invisible behavior.

Performance is part of the design, not a later patch

Gin is built around a radix-tree router derived from httprouter. The project advertises a zero-allocation routing path, and its published routing benchmarks report zero bytes and zero allocations per operation for the main Gin benchmark.[1][5]

Benchmarks need context. Router microbenchmarks are not the same as a production application with database calls, authentication, logging, network latency, and JSON serialization. I would not choose Gin because a chart says it wins every workload. It does not.

I would choose it because the framework starts from a performance-conscious design. That gives a project more room before framework overhead becomes a concern. It also fits Go's strengths: compiled binaries, straightforward concurrency, a strong standard library, and deployment without a large language runtime bundled beside the application.

For a small service, that can mean a simple codebase and a small deployment. For a large system, it can mean many focused services that are easier to profile and scale independently.

Small enough for an agent to understand

A basic Gin endpoint is almost boring:

package main

import (
    "net/http"

    "github.com/gin-gonic/gin"
)

type CreateProjectRequest struct {
    Name string `json:"name" binding:"required"`
}

func main() {
    router := gin.Default()

    router.POST("/projects", func(c *gin.Context) {
        var input CreateProjectRequest
        if err := c.ShouldBindJSON(&input); err != nil {
            c.JSON(http.StatusBadRequest, gin.H{"error": err.Error()})
            return
        }

        c.JSON(http.StatusCreated, gin.H{"name": input.Name})
    })

    router.Run(":8080")
}

The route is visible. The request type is visible. Validation is visible. The response is visible.

That clarity is useful when an AI agent writes the first version, but it is even more useful when a person reviews it. You can ask an agent to add authentication, request IDs, rate limiting, structured logging, and tests. Gin's middleware model gives those concerns a natural home instead of spreading them through every handler.[2]

The Go team even maintains an official tutorial for building a RESTful API with Go and Gin, which gives both developers and agents a first-party starting point instead of relying only on random snippets.[4]

Can Gin handle both small and large projects?

Yes, with one condition: the architecture still has to grow up with the project.

A small Gin service might have a few routes and handlers in one package. That is fine. Starting with ten layers of abstraction would make the service harder to understand, not more scalable.

As the application grows, the same framework can sit behind clearer boundaries:

handlers translate HTTP requests and responses;
services hold business rules;
repositories or data-access packages talk to storage;
middleware handles cross-cutting HTTP concerns;
background workers run outside the request path;
tests cover each boundary and the important end-to-end flows.

Gin does not force this structure, and that is both a strength and a risk. Teams can choose an architecture that fits the system. They can also create a messy global state machine if nobody sets boundaries.

An AI agent will not rescue a weak architecture by itself. In fact, it can multiply a bad pattern faster than a human can. The repository needs instructions, tests, linting, security checks, and clear ownership rules. The agent should run the system and prove its work, not merely produce code that looks plausible.

The ecosystem is mature, but still moving

Gin is old enough to be trusted and active enough to remain relevant. Version 1.12.0, released in February 2026, added improvements to binding, error retrieval, Protocol Buffers content negotiation, routing, recovery, and path parsing. The release also included bug fixes, dependency updates, security-scanning changes, and more tests.[3]

That balance matters more to me than novelty. I do not want a backend framework that reinvents itself every six months. I want one that keeps fixing rough edges without making yesterday's project feel obsolete.

Gin also has a large middleware ecosystem through the gin-contrib organization, with packages for concerns such as CORS, sessions, compression, logging, metrics, and tracing.[1]

There is still a cost. Go is explicit, and explicit code can feel repetitive. Gin is less opinionated than a full-stack framework, so your team must choose its own database layer, migrations, dependency wiring, configuration approach, and project structure. AI makes those decisions faster to implement, but it does not make every decision good.

Where I would use it

I would seriously consider Gin for:

REST APIs and mobile app backends;
internal services that need predictable deployment;
microservices with high request volume;
webhook receivers and integration services;
an AI product's API layer, especially when model calls happen elsewhere;
a modular backend that may start small but needs room to grow.

I would pause if the team needs a batteries-included admin panel, deep server-rendered UI conventions, or an ecosystem centered on rapid plug-and-play business modules. A more opinionated framework may save time there.

I would also compare Gin with Go's standard net/http package for very small services. Modern Go can do a surprising amount without a framework. Gin earns its place when its routing, middleware, binding, validation, and error-handling conventions remove enough repetition to justify the dependency.

AI does not make framework choice irrelevant

There is a tempting argument that framework choice matters less because an agent can write anything. I think the opposite is closer to the truth.

When code becomes cheaper to produce, maintainability becomes more important. Agents can create features quickly, but somebody still has to review, operate, secure, and change the result. A framework with understandable control flow gives both humans and agents a better chance of staying oriented.

That is why Gin fits this moment. Its appeal is not only raw speed. It is the combination of speed, a focused API, mature documentation, familiar Go patterns, and enough ecosystem support to avoid rebuilding every HTTP concern yourself.

AI agents make Gin easier to adopt. Gin makes agent-written backends easier to inspect.

That sounds like a useful trade.

Sources

[1] https://github.com/gin-gonic/gin — gin-gonic/gin: Gin Web Framework
[2] https://gin-gonic.com/en/docs — Gin Web Framework Documentation
[3] https://github.com/gin-gonic/gin/releases/tag/v1.12.0 — Gin v1.12.0 release
[4] https://go.dev/doc/tutorial/web-service-gin — Tutorial: Developing a RESTful API with Go and Gin
[5] https://gin-gonic.com/en/docs/benchmarks — Gin Benchmarks

Originally published at https://blog.jenuel.dev/blog/why-gin-fits-the-ai-agent-era

Your AI Agents Are Not a Team Yet: 7 Orchestration Lessons from Multi-Agent Failures

Jenuel Oras Ganawed — Fri, 28 Aug 2026 12:48:21 +0000

Giving five AI agents access to the same repository does not create a team. It creates five fast, confident developers who may open conflicting pull requests, repeat the same mistake, and tell each other that everything looks good.

That sounds harsh, but it matches what developers are starting to see in real systems. Multi-agent demos are easy to make impressive. One agent plans, another codes, a third reviews, and a final agent announces success. The diagram looks clean. The execution is usually messier.

Anthropic tested agent swarms on vulnerability research and collaborative software projects. The results were promising and uncomfortable: agents covered a huge search space, but coordination became fragile once their work depended on one another.[1]

The lesson is not to avoid multi-agent systems. It is to stop treating "more agents" as an architecture.

What counts as a multi-agent system?

A multi-agent system has several AI workers with separate contexts, responsibilities, or tools. They may run in parallel, pass work to one another, review outputs, or report to an orchestrator.

Two common designs have emerged:

A manager keeps control and calls specialist agents for bounded tasks.
A router hands the task to a specialist, which then owns the rest of the interaction.

OpenAI's Agents SDK documents both patterns and makes an important distinction: you can let an LLM decide the workflow, or you can control the workflow in code. LLM-led orchestration is flexible. Code-led orchestration is more predictable in cost, speed, and behavior.[2]

That distinction matters more than the number of agents. A system with ten agents and no deterministic control is often less dependable than one agent running inside a strict loop with tests.

Lesson 1: parallel work is the easy part

Multi-agent systems are strongest when a task breaks into independent pieces.

Security research is a good example. Anthropic gave 45 agents their own virtual machines and asked them to search 15 open-source projects for vulnerabilities. The agents could coordinate through a shared forum, peer-review findings, and submit results to an arbiter agent.[1]

The swarm found 266 vulnerabilities while consuming 27 million tokens. A simpler parallel setup found 21 vulnerabilities using 6.5 million tokens. Those numbers do not prove the swarm was automatically more efficient. About half of the swarm's findings were outside the core directories assigned to the simpler setup, and only 12 vulnerabilities appeared in both result sets.[1]

The useful part is the coverage. Independent agents explored different areas, built tools, and specialized. One missed finding did not invalidate another agent's work.

This pattern maps well to development tasks such as:

inspecting separate modules for security issues;
researching competing libraries;
generating tests for unrelated components;
checking accessibility across independent pages;
reviewing a change from performance, security, and product perspectives.

If the workers can fail independently, parallel agents can give you more coverage. If every worker depends on another worker's half-finished output, the system becomes much harder to trust.

Lesson 2: dependency turns speed into coordination debt

Anthropic also asked agent swarms to build a web-playable fantasy game over 12 hours. The agents had virtual machines, a shared repository, and a forum. Researchers tried loose collaboration, prescribed roles, and a CEO-style hierarchy.[1]

None of those prompts rescued the final product. The games were poor, interfaces were confusing, and older models frequently opened pull requests that conflicted and were abandoned. Some newer models avoided conflicts mostly by working in separate files rather than collaborating deeply.[1]

This is coordination debt. Every new worker adds possible handoffs, stale assumptions, merge conflicts, and decisions that nobody clearly owns.

Human teams have tools for this: tickets, code ownership, API contracts, design reviews, CI, and someone who can say no. Agent teams need the same constraints, often in a stricter form.

Do not ask four agents to "work together on the feature." Split the work along boundaries you can verify:

Agent A defines the API contract and acceptance tests.
Agent B implements the server against that contract.
Agent C implements the client against the same contract.
Agent D runs integration tests and reports failures without editing production code.

The contract gives every worker something concrete to build and test against. A long agent conversation does not.

Lesson 3: identical agents do not provide independent judgment

A reviewer agent sounds reassuring until you realize it may think exactly like the author agent.

Anthropic observed unusually similar behavior among agents using the same model and setup. In one experiment, 18 of 30 agents independently chose the exact branch name mvp-game-loop. In a writing task, multiple agents produced the same title without being given a shared subject. In another task, more than half chose to build either a ray tracer or a self-hosting compiler.[1]

This low variance creates correlated failure. If the implementation agent misunderstands a requirement, a reviewer with the same model, prompt style, and context may approve the same misunderstanding.

A second agent only gives you a useful second opinion when it checks different evidence or uses a different method.

You can create more useful disagreement by changing the evidence and incentives:

Give the reviewer the acceptance criteria and diff, not the author's reasoning.
Ask the reviewer to find a counterexample rather than rate quality.
Use deterministic tools such as tests, linters, and schema validators.
Separate security review from feature review.
For consequential work, use a different model or a human reviewer.

The goal is not artificial debate. It is to prevent one plausible mistake from becoming a unanimous team decision.

Lesson 4: the orchestrator should own the answer

One agent should be responsible for the final result. That does not mean it performs every task. It means it owns scope, merges evidence, resolves conflicts, and decides whether the work is complete.

The manager pattern in OpenAI's Agents SDK keeps one agent in control while specialists operate as tools. Handoffs are better when a specialist should take over the interaction entirely.[2] For engineering work, the manager pattern is usually safer because the final response, patch, or release still has one owner.

A practical orchestration loop can be simple:

type Finding = {
    agent: string;
    claim: string;
    evidence: string[];
    status: "unverified" | "verified" | "rejected";
};

const tasks = splitByIndependentBoundary(request);
const reports = await Promise.all(tasks.map(runSpecialist));

const findings: Finding[] = normalize(reports);
const verified = await runDeterministicChecks(findings);
const conflicts = detectConflicts(verified);

if (conflicts.length > 0) {
    await requestTargetedRechecks(conflicts);
}

return orchestratorBuildsFinalArtifact(verified);

The loop does not rely on a free-form group chat where agents keep talking until they feel aligned.

The orchestrator should consume structured reports. Each report should name the task, artifact, evidence, commands run, unresolved risks, and confidence. That makes failures inspectable instead of burying them in a transcript.

Lesson 5: verification must live outside the agent's confidence

Agents are good at producing completion language. "Implemented successfully" is not evidence.

Anthropic's Claude Code guidance recommends giving an agent a check it can run: a test suite, build command, linter, output comparison, or screenshot. Without that check, the agent stops when the work looks finished. With a readable pass-or-fail signal, it can iterate against reality.[3]

For multi-agent systems, verification should happen at two levels.

Each worker verifies its own artifact:

the code compiles;
focused tests pass;
generated data matches a schema;
cited evidence contains the claimed fact.

The orchestrator then verifies the combined system:

integration tests pass;
no worker changed files outside its scope;
two outputs do not contradict each other;
the final artifact satisfies the original acceptance criteria;
reported commands and results are attached as evidence.

A reviewer agent can help find gaps. It should not replace the test runner.

Lesson 6: control the expensive parts in code

LLMs are useful when the next step requires judgment. They are a costly choice for workflow rules that could be an if statement.

Use code to control:

which tasks may run in parallel;
maximum retries and token budgets;
required output schemas;
permission boundaries;
which checks must pass;
when the workflow stops;
when a human must approve an action.

Use an agent to handle:

ambiguous decomposition;
investigation across unfamiliar code;
comparison of competing explanations;
drafting a patch from evidence;
summarizing trade-offs for a human.

OpenAI's orchestration guide recommends code-based flows when you need deterministic speed, cost, and performance. It also describes evaluator loops, structured outputs, agent chains, and parallel execution as core patterns.[2]

Most dependable agent systems still look like ordinary software: explicit branches, budgets, schemas, tests, and a few carefully placed reasoning steps.

Lesson 7: communication protocols do not solve organizational design

Google's Agent2Agent protocol gives agents a standard way to advertise capabilities, exchange tasks and artifacts, report status, and work across vendors. It builds on familiar technologies such as HTTP, Server-Sent Events, and JSON-RPC.[4]

That is useful infrastructure. It does not tell you whether the task should have been delegated, whether two agents are duplicating work, or whether the final output is correct.

Developers made a similar mistake with microservices. Network communication made independent services possible, but it did not remove the need for ownership, contracts, observability, and sensible boundaries. Multi-agent systems are heading toward the same lesson, only faster and with participants that can confidently invent missing information.

Treat agent communication as an API design problem:

publish clear capabilities;
pass explicit task IDs and deadlines;
define artifact schemas;
make retries idempotent;
preserve provenance;
log every tool call with side effects;
never pass secrets or broad permissions by default.

An agent message should be inspectable like an API request, not trusted like a conversation between coworkers.

A small architecture that works

For a repository change, start with four roles:

The orchestrator reads the request, repository instructions, and acceptance criteria. It divides work only when the boundaries are clear.
Investigators inspect independent parts of the codebase. They return findings with file paths and evidence but do not edit files.
One implementer owns the patch. This avoids several agents fighting over the same code.
A verifier runs tests, reviews the diff against the requirements, and tries to disprove completion.

The orchestrator then returns the artifact only after deterministic checks pass. If a check cannot run, it reports the blocker instead of converting uncertainty into a success message.

This is less exciting than a swarm of autonomous developers, but it is much easier to debug when something goes wrong.

A quick check before you add another agent

Before you split a workflow across more workers, answer these questions:

Can the new task fail without corrupting another worker's output?
Does the worker have a clear input, output, and permission boundary?
Can a test, schema, command, or human decision verify the result?
Who owns conflicts and the final artifact?
What stops retries, token use, and tool calls from growing without limit?

If those answers are vague, another agent will probably add coordination work rather than remove it.

When one agent is enough

Use one agent when the task is small, sequential, or tightly coupled. A typo fix does not need a planner, implementer, reviewer, and philosopher.

Use several agents when independent exploration has real value, specialists need different tools or context, or you want separate adversarial review. Even then, compare the expected gain against extra tokens, latency, and integration work.

Instead of asking how many agents you can add, ask which parts can fail independently and how you will verify the combined result.

If you cannot answer that, you do not have an agent team yet. You have concurrency with better marketing.

Sources

[1] Anthropic, Patterns and problems in emerging multiagent systems

[2] OpenAI Agents SDK, Agent orchestration

[3] Anthropic, Best practices for Claude Code

[4] Google Developers Blog, Announcing the Agent2Agent Protocol (A2A)

Originally published at https://blog.jenuel.dev/blog/your-ai-agents-are-not-a-team-yet

The New Bug Isn't Always in the Code

Jenuel Oras Ganawed — Thu, 13 Aug 2026 03:32:48 +0000

AI has become very good at writing code.

On a clear and bounded task, it can produce code that is cleaner, faster, and more consistent than what many of us would write by hand. It does not get tired. It does not forget a closing bracket after a long day. It can follow a known pattern across many files in seconds.

AI can still produce ordinary coding mistakes, so compilers, tests, and code review are not going away. But those mistakes are no longer the most interesting part of the problem for me.

The harder failure often begins before the first line is generated.

We open a powerful AI agent and give it a prompt:

Add an archive feature.

That may be all it knows.

It does not automatically know what "archive" means in our business. It does not know which service owns the data, which users have permission, what the mobile app expects, why an old database rule exists, or which background jobs can still change the record.

Then the AI writes clean code for the incomplete world we described.

The code can be correct according to the prompt and wrong according to the system.

This is the idea I am trying to name. In the old workflow, we often found the bug in a condition, query, API call, or state change. In an AI-agent workflow, the bug may begin in the information we failed to provide.

I now debug the room around the agent too.

Did the agent know how this project works? Did it see the rules? Could it find the right documentation? Did it have the proper tools? Did it know what "done" meant? Could I inspect what it did?

Sometimes the failure is not in src/. It is in the prompt, instructions, skills, tools, permissions, retrieval, or feedback loop we built around the agent.

Imagine a skilled worker entering a silent factory

Picture a skilled worker arriving at a factory on Monday morning.

Nobody gives them a map. The rooms are not labeled. The safety rules are hidden in an old binder. Some tools are missing. Their keycard opens every door, including rooms they should never enter. The work order says only, "Fix the machine." There is no inspection checklist.

The worker is capable. The workplace is not ready for them.

If they repair the wrong machine, use the wrong part, or stop before the repair is safe, blaming only the worker misses half the problem.

This is how many teams use AI agents. They choose a powerful model, point it at a large repository, write a short request, and expect the agent to understand years of decisions that nobody gave it.

A coding agent is not only a model. It is a system made of a model, instructions, skills, tools, permissions, memory, repository context, and tests. Every part can help the agent succeed. Every part can also fail.

Anthropic calls this wider job "context engineering." The context can include system instructions, tools, external data, message history, and information retrieved while the agent works. Anthropic also warns that context is limited. Giving a model more text does not guarantee that it will use the right text well.[1]

The model matters. The room matters too.

One vague ticket, five different failures

Suppose I tell an agent:

Add an archive feature for customer projects.

The agent adds an archived field, hides archived projects from the main page, and writes a test. The code compiles. The test passes. The agent reports that the feature is complete.

Then I discover the missing pieces:

Our mobile app still shows archived projects.
An old background job can still modify them.
The project uses soft deletion rules that the agent never saw.
Only administrators should archive projects, but the API accepts any signed-in user.
The database change has no rollback plan.

Was the code buggy? Parts of it may be.

But the first failure happened earlier. The agent never received the full meaning of "archive." It did not know the system boundary, the security rule, or the migration process. Its test proved only the small behavior it had invented.

Current research gives us a useful warning here. In SWE-Bench Pro, agents performed far better when task descriptions included human-added requirements and interface details. GPT-5 High resolved 25.9% of those tasks, but only 8.4% when those details were removed. Claude Opus 4.1 fell from 22.7% to 8.2%.[8]

Those numbers are not universal production bug rates. They come from one benchmark, and the benchmark has limitations. But the direction is hard to ignore: what the system tells the agent can change the result dramatically.

Agents need onboarding, not one giant prompt

Human developers do not learn a mature project by reading one ticket. They learn its language, boundaries, commands, habits, and history. They ask why a strange abstraction exists. They discover which rules are written down and which ones live in a senior developer's head.

Agents need a practical version of that onboarding.

OpenAI's Codex reads layered AGENTS.md files before it begins work. Teams can place general guidance at the repository root and more specific instructions inside subdirectories.[2] The open AGENTS.md format describes the file as "a README for agents," with setup commands, tests, conventions, and other project knowledge.[3]

Claude Code uses CLAUDE.md for a similar purpose. Its documentation contains an important warning: Claude treats these files as context, not as enforced configuration. It also recommends concise instructions because long or contradictory files reduce reliable adherence.[4]

That difference matters.

An instruction can say, "Never deploy without approval." A hard control prevents the deployment command from running without approval. The first guides behavior. The second enforces a boundary.

Good agent architecture knows when a written rule is enough and when the system needs a lock on the door.

The answer is not to paste the whole company into the context window

When teams notice that an agent lacks context, the first reaction is often to give it everything.

Every source file. Every design document. Every old discussion. Every log. Every policy.

That creates a different problem. Important details get buried under irrelevant details. Old instructions conflict with new ones. The agent spends time reading instead of working.

A better design gives the agent a small map and clear paths to deeper knowledge.

Aider's repository map is a useful example. It gives the model a compact view of important files, classes, functions, types, and call signatures. It selects what fits within a token budget instead of dumping the entire repository into the prompt.[7]

Skills provide another layer. Claude Code skills can package reusable procedures, scripts, templates, and reference material. The short skill descriptions remain available for discovery, while the full instructions load only when the skill is needed.[5]

MCP provides connections to external systems such as files, databases, APIs, and tools.[6] That matters because the repository is rarely the whole truth. The requirement may be in an issue tracker. The failure may be in monitoring. The approved design may be in a document. The current schema may be in a live database.

A fact existing somewhere in the company does not mean the agent knows it. The system needs to provide a safe, reliable path.

The prompt is a request, not the whole system

This is where I think teams misunderstand prompting.

A prompt tells the agent what we want right now. It should not be expected to carry the entire history and design of the product.

When I tell an experienced developer, "Add an archive feature," that short sentence works only because the developer already shares a large amount of context with the team. They know the product, the users, the architecture, the release process, and who to ask when something is unclear.

The same sentence given to a fresh agent is not the same assignment.

The agent may understand every word and still lack the knowledge behind those words. If it builds exactly what the prompt appears to request, clean code does not save us from the missing context.

That is why I think of this as an information bug or a context bug. The prompt reaches the model, but the meaning needed to implement it does not.

The solution is not a giant, perfect prompt. The solution is an agent-ready system: stable project instructions, discoverable skills, current documentation, useful tools, safe access, independent tests, and a way to ask for help.

My BRIEF check before I blame the agent

I now think about agent setup with five questions. Together they form a BRIEF.

Bearings: does it know where it is?

The agent needs a small map of the repository and the system.

Which service owns the data? Where do validations belong? Which terms have special meanings? Which old decisions must remain in place?

Architecture Decision Records are useful because they preserve why a meaningful decision was made, not only what the code looks like today.[13] An agent that sees only the current code may "clean up" something that exists for a reason.

Useful bearings include a concise AGENTS.md, a system diagram, a glossary, a repository map, and links to important decisions.

Rules: does it know how work is done here?

The agent needs the house rules.

That may include coding conventions, data-handling policies, migration steps, protected files, required reviews, and conditions that mean "stop and ask a human."

Keep these rules short and specific. If two instructions disagree, fix the instructions instead of hoping the model chooses the right one.

Where a rule must never be broken, enforce it with permissions, hooks, protected branches, policy checks, or approval gates. Do not rely on a paragraph alone.

Implements and identity: does it have the right tools and access?

A mechanic needs the correct wrench. A coding agent may need search, tests, build tools, logs, an issue tracker, or API documentation.

Missing tools force the agent to guess. Too much access creates a larger danger.

NIST defines least privilege as giving a user or process only the minimum access needed to perform its task.[11] The same idea belongs in agent design. Use read-only access by default. Separate development from production. Require approval for destructive actions. Give the agent a task key, not the master key.

Exit criteria: can it prove the work is done?

"Make it work" is not a finish line.

The agent needs checks it can run: tests, builds, type checks, security scans, expected screenshots, acceptance examples, or known outputs. The Scrum Guide's Definition of Done makes the same general point for teams: work needs a shared description of the quality state required for completion.[14]

But tests can be wrong or incomplete too.

SWE-ABS strengthened the tests for 11,041 patches that had already passed SWE-Bench Verified. The stronger suite rejected 2,184 of them, or 19.78%.[9] That does not mean one in five production patches is bad. It shows something narrower and still important: a weak evaluator can make an incorrect patch look successful.

The agent should not be the only author of its assignment, implementation, and proof.

Feedback: can we see what happened?

"Done" is a claim. I want evidence.

What files changed? Which commands ran? Which tools failed? What tests passed? Which assumptions did the agent make? Where did it ask for approval?

OpenTelemetry explains observability through signals such as traces, metrics, and logs.[12] Agent systems need their own version of this. Record tool calls, approvals, test results, errors, and important decisions. When something goes wrong, the team should be able to reconstruct the run instead of calling it a random hallucination.

Good feedback also helps the agent while it works. Anthropic recommends that agents receive ground truth from their environment, such as tool results or code execution, so they can judge progress. It also warns that autonomous agents can compound errors and should be tested with guardrails.[10]

Instructions, skills, and tools are part of the architecture now

We usually think of architecture as services, databases, queues, APIs, and deployment systems.

For agentic software development, that boundary is too small.

The files that instruct the agent are architecture. The skill library is architecture. The repository search method is architecture. Tool descriptions are architecture. Permissions are architecture. The test harness is architecture. The run history is architecture.

These parts do not replace good application design. They decide how the agent sees and changes that design.

This also changes how I diagnose failure.

If an agent edits the wrong package, I still review its reasoning. But I also ask whether it had a repository map.

If it breaks a security rule, I still reject the patch. But I also ask why the rule was hidden and why the environment allowed the action.

If it stops too early, I still hold the output accountable. But I also ask whether "done" was written as an executable check.

If it ignores a skill, I inspect the skill's name, description, trigger, and availability instead of assuming that installing it made it usable.

The point is not to excuse the model. The point is to debug the whole system.

The checklist I use now

Before I send an agent into a serious project, I ask:

Where is the map? Can it find the relevant part of the system and understand the important boundaries?
Where are the rules? Are they concise, current, and free of contradictions?
Which skills and tools does it need? Can it discover and use them without receiving unnecessary power?
What proves completion? Are the acceptance checks independent enough to catch a plausible but wrong result?
What record remains? Can a human review the actions, evidence, assumptions, and approvals afterward?

A better model may improve the worker. It does not label the factory, write the safety policy, choose the keycard permissions, or define the inspection process for us.

Those are engineering responsibilities.

The new debugging question

Code bugs are still here. AI did not retire the compiler, the test suite, code review, security review, or architecture work.

It added another system that can be misconfigured.

So when an AI agent fails, I no longer ask only, "What is wrong with the generated code?"

I also ask:

What kind of workplace did we give the agent?

A talented worker in an empty, unlabeled factory will make avoidable mistakes. A capable agent with missing instructions, weak retrieval, the wrong tools, broad permissions, and no finish line will do the same.

The new bug is not always in the code.

Sometimes, the bug is the room we built around the agent.

Sources

[1] https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — Anthropic: Effective context engineering for AI agents
[2] https://learn.chatgpt.com/docs/agent-configuration/agents-md — OpenAI: Custom instructions with AGENTS.md
[3] https://agents.md — AGENTS.md: A README for agents
[4] https://code.claude.com/docs/en/memory — Claude Code: How Claude remembers your project
[5] https://code.claude.com/docs/en/skills — Claude Code: Extend Claude with skills
[6] https://modelcontextprotocol.io/docs/getting-started/intro — Model Context Protocol: What is MCP?
[7] https://aider.chat/docs/repomap.html — Aider: Repository map
[8] https://arxiv.org/abs/2509.16941 — SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?
[9] https://arxiv.org/abs/2603.00520 — SWE-ABS: Adversarial Benchmark Strengthening Exposes Inflated Success Rates
[10] https://www.anthropic.com/engineering/building-effective-agents — Anthropic: Building effective agents
[11] https://csrc.nist.gov/glossary/term/least_privilege — NIST: Least privilege
[12] https://opentelemetry.io/docs/concepts/observability-primer — OpenTelemetry: Observability primer
[13] https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions — Documenting Architecture Decisions
[14] https://scrumguides.org/scrum-guide.html — The Scrum Guide

Originally published at https://blog.jenuel.dev/blog/the-new-bug-isnt-always-in-the-code

AI Writes Better Code and Makes Bigger Mistakes

Jenuel Oras Ganawed — Wed, 12 Aug 2026 10:18:02 +0000

As coding agents improve at implementation, their hardest failures are moving into requirements, architecture, integration, security, and verification.

For years, the easiest way to distrust AI-generated code was to run it.

The import did not exist. The loop stopped one iteration early. The model invented an API, confused two types, or returned something that failed the first unit test. You did not need an architecture review to find the problem. The compiler did it for you.

That version of AI coding is fading.

On August 11, 2026, Boris Cherny, the creator and lead of Claude Code, described the change bluntly: "LLMs still produce bugs, but those bugs are different than what they used to be. It's less off-by-ones and more about system design, UI usability, missing broader context."[1]

The quote caught my attention because it puts words to something many developers have started to feel. The code looks better. It often compiles. It may pass the tests the agent wrote for itself. Yet the change can still be wrong in ways that are harder to notice and more expensive to repair.

The agent solved the function and missed the system.

Cherny's observation is not, by itself, scientific proof that the distribution of AI defects has changed. It is a practitioner statement from someone building one of the most widely used coding agents. But recent research points in the same direction. Stronger agents are getting good at producing valid patches. Their performance drops when they must interpret incomplete requirements, coordinate changes across many files, respect existing abstractions, preserve behavior, and finish a feature from end to end.

The next AI coding problem is not simply whether the model can write code. It is whether the model understands what the code is supposed to mean inside a living system.

A valid patch can still be a failed change

SWE-EVO is one of the clearest demonstrations of this gap. The benchmark contains 48 release-sized software evolution tasks drawn from seven mature Python projects. The expected changes touch 21 files on average, and each instance has roughly 874 tests.[2]

Several evaluated models produced patches that applied successfully between 97.92% and 100% of the time. That sounds impressive until you compare it with actual task resolution. The best reported model completed only 25% of the tasks. GPT-5.2, for example, scored 72.8% on SWE-bench Verified but only 22.92% on SWE-EVO.[2]

This is the difference between patch mechanics and engineering correctness.

The agent knew how to edit files. Git could apply the output. The syntax was usually acceptable. Most of the releases were still wrong.

The failure analysis is even more revealing. According to the researchers, weaker models continued to struggle with syntax and tool use, while stronger models more often misinterpreted nuanced release notes.[2] That is about as close as current benchmark evidence gets to Cherny's claim. The stronger model is no longer stopped primarily by punctuation or a malformed command. It is stopped by meaning.

FeatureBench finds a similar pattern at a larger feature scope. Its 200 tasks average 15.7 changed files, 29.2 changed functions, and about 790 changed lines. Claude Opus 4.5 reportedly achieved 74.4% on SWE-bench, but resolved only 11% of FeatureBench tasks. Other strong systems made partial progress while resolving none of the evaluated tasks completely.[3]

Partial progress is useful, but it can be deceptive. A feature that is 80% implemented is not necessarily 80% valuable. The missing 20% may contain the authorization rule, data migration, rollback path, accessibility behavior, or compatibility guarantee that makes the feature safe to ship.

Passing the test is not the same as satisfying the requirement

Software teams have always known that tests are incomplete. AI makes that old lesson easier to forget because an agent can generate the implementation, the tests, and the confident summary saying everything passed.

An ICSE 2026 study examined patches that SWE-bench's validation system counted as successful. The researchers found that 7.8% of plausible patches failed a broader developer-written test suite. They also found that 29.6% behaved differently from the human patch. In a manually inspected sample of divergent patches, 28.6% were certainly incorrect.[4]

The common problems were not missing semicolons. Many patches used a similar but behaviorally different implementation, changed more behavior than requested, or interpreted an underspecified issue incorrectly.[4]

This exposes an uncomfortable weakness in agent workflows: the evaluator may share the agent's misunderstanding.

Suppose the request says, "Prevent users from editing archived projects." The agent adds a disabled button and a browser test confirming that the button cannot be clicked. Every generated test passes. But the API still accepts the update, the mobile client still exposes the action, and an old background job can still change the record.

The local behavior is correct. The system rule is not.

No amount of celebrating a green test suite fixes a test suite that describes the wrong boundary.

Repositories have a design, even when nobody wrote it down

A mature codebase contains thousands of decisions that may never appear in the issue description. Where does validation belong? Which service owns the data? Which abstraction should a new feature extend? Which dependency is approved? What must remain backward compatible? Which failures should be retried, surfaced, or ignored?

Developers absorb these constraints slowly. Coding agents receive a prompt, a context window, and whatever files their retrieval system happens to select.

RepoExec was designed to measure this problem. It evaluates whether generated code runs, whether it behaves correctly, and whether it uses the repository's existing dependencies. Researchers found that pretrained models often produced runnable, correct code by reimplementing capabilities that already existed elsewhere in the project. Instruction-tuned models used existing dependencies more often, but sometimes introduced unnecessary complexity.[6]

In other words, the code can pass while still being the wrong contribution to the repository.

A duplicate implementation creates two places to fix the next bug. A bypassed abstraction weakens future refactors. A new dependency can expand the attack surface or conflict with the project's release policy. None of these problems has to fail today's test.

Other repository benchmarks tell the same story. FEA-Bench requires agents to generate new components while editing related existing components, and evaluated models performed substantially worse than they did in more local code-generation settings.[7] RepoCod contains 980 whole-function tasks from 11 large Python projects, with more than half requiring repository-level context. No evaluated model exceeded 30% pass@1.[8]

The hard part is no longer always writing the body of the function. It is discovering which function should exist, where it belongs, what it may depend on, and which behavior it must not disturb.

Long-running agents can compound small misunderstandings

Autonomous agents make this problem larger because their outputs are not limited to suggestions. They search, edit, run commands, install dependencies, rewrite tests, and decide what to do next.

Anthropic's own engineering guidance warns that autonomous agents carry "the potential for compounding errors" and recommends extensive testing in sandboxed environments. The company also makes an important distinction: automated tests can verify functionality, but human review remains necessary to determine whether a solution matches broader system requirements.[9]

That distinction should sit above every coding-agent dashboard.

Anthropic's work on long-running agent harnesses documents another class of failure. Agents may attempt too much at once, exhaust their context in the middle of an implementation, leave features half finished and undocumented, or declare victory too early.[10]

These are project-state failures. Each individual edit may be reasonable, but the sequence loses continuity. The next session then has to infer what the previous session intended, often from a working tree that no longer matches the plan.

Humans make continuity mistakes too. The difference is speed and scale. An autonomous agent can produce a large amount of coherent-looking state before anyone notices that its original assumption was wrong.

Security mistakes move with authority

A bad code suggestion is one risk. An agent with repository access, a terminal, deployment credentials, and a production database is a different category of risk.

OWASP calls this "excessive agency": damaging actions become possible when an LLM has too much functionality, permission, or autonomy. The triggering output can come from hallucination, ambiguous instructions, poor performance, or prompt injection.[14]

This is not a model-only problem. It is a system-design problem.

If an agent can delete production data because it misunderstood a request, the failure began before the model acted. The surrounding platform gave a probabilistic component an irreversible capability without a sufficient approval boundary. Better prompting may reduce the chance of failure. Environment separation and least privilege reduce the impact.

Security research also shows how polished AI output can distort human judgment. In a controlled study using a Codex-based assistant, participants with AI access wrote significantly less-secure code than participants without it. The assisted group was also more likely to believe its code was secure. Participants who trusted the assistant less produced fewer vulnerabilities.[13]

That combination is dangerous: plausible output, misplaced confidence, and a security property that ordinary functional tests may never check.

The riskiest AI-generated code may not look broken. It may look finished.

Local productivity can hide a system-level bill

None of this means AI coding tools are useless or inherently harmful. On bounded tasks with a clear specification and aligned tests, they can perform very well.

GitHub's controlled study of 202 experienced developers found that Copilot users were 53.2% more likely to pass all ten unit tests in a predefined API task. Blind reviewers also gave the assisted code modestly better scores for readability, reliability, maintainability, and conciseness.[15]

That is real evidence in AI's favor. It also shows why task boundaries matter. The experiment supplied a contained assignment and a visible evaluator. It did not ask the model to choose a service boundary, preserve years of undocumented behavior, migrate production data, or decide whether the feature should exist.

METR found the opposite productivity result in a different setting. Experienced open-source maintainers working in repositories they knew well took 19% longer with early-2025 AI tools, even though they believed AI had made them faster. The researchers pointed to mature projects' implicit requirements, quality standards, and context as possible contributors.[11]

That result should not be frozen into a timeless slogan. METR has since reported weak evidence that newer tools may provide speedups, and the original study covered a small group of expert maintainers using early-2025 systems. Still, it demonstrates a basic point: faster code generation does not guarantee faster engineering.

Google's 2024 DORA research found the same tension at the organizational level. Greater AI adoption was associated with better documentation quality, code quality, and review speed, but also with lower delivery throughput and stability. DORA cautioned that improving development activity does not automatically improve software delivery without small batches and robust testing.[12]

A team can generate more code, review individual changes faster, and still create a less stable delivery system.

The developer's job is moving up the stack too

If AI coding failures are moving upward, human responsibility has to move upward with them.

That does not mean every developer becomes a diagram-producing "architect." It means the valuable work increasingly happens before and after code generation:

Turn vague requests into explicit behavior and invariants.
Decide where a change belongs and which boundaries it must respect.
Give agents access only to the context and capabilities they need.
Separate development, staging, and production authority.
Write independent tests that challenge the implementation rather than repeat it.
Review the blast radius, not only the diff.
Verify failure paths, migrations, rollback behavior, security rules, and operational impact.

The 2025 Stack Overflow survey reflects this caution. More developers distrusted AI-tool accuracy than trusted it, and experienced developers were the most skeptical. Respondents said they would still seek human help when they did not trust an answer, faced security concerns, or needed to understand complex code.[16]

This is not resistance to progress. It is what accountability looks like when the tool can produce more than the reviewer can casually inspect.

We need stronger definitions of "correct"

The software industry has spent years measuring coding models with exact-match scores, isolated functions, unit tests, and issue-resolution rates. Those measures helped models improve. They are no longer enough.

A serious evaluation of an AI coding agent should ask:

Did the change satisfy the user's actual requirement?
Did it preserve behavior outside the new feature?
Did it use the repository's intended abstractions?
Did it introduce unnecessary dependencies or duplicate logic?
Did it respect authorization, privacy, and data-ownership boundaries?
Can the team operate, observe, migrate, and roll back the change?
Did the tests challenge the solution independently?
Can another developer understand what happened and why?

A patch that applies is not necessarily correct. A test that passes is not necessarily meaningful. A feature that works in the happy path is not necessarily ready.

AI has not eliminated software bugs. It has started changing where we have to look for them.

The compiler will still catch the missing bracket. The harder question is who catches the beautifully implemented solution to the wrong problem.

Sources

[1] https://x.com/bcherny/status/2087284684103537011 — Boris Cherny: LLM coding bugs are changing
[2] https://arxiv.org/abs/2512.18470 — SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios
[3] https://arxiv.org/abs/2602.10975 — FeatureBench: Benchmarking Agentic Coding for Complex Feature Development
[4] https://arxiv.org/abs/2503.15223 — Are Solved Issues in SWE-bench Really Solved Correctly?
[6] https://aclanthology.org/2025.findings-naacl.82 — RepoExec: Impacts of Contexts on Repository-Level Code Generation
[7] https://aclanthology.org/2025.acl-long.839 — FEA-Bench: Repository-Level Feature Implementation
[8] https://aclanthology.org/2025.acl-long.1204 — RepoCod: Can Language Models Replace Programmers for Coding?
[9] https://www.anthropic.com/engineering/building-effective-agents — Anthropic: Building effective agents
[10] https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents — Anthropic: Effective harnesses for long-running agents
[11] https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study — METR: AI impact on experienced open-source developers
[12] https://cloud.google.com/blog/products/devops-sre/announcing-the-2024-dora-report — Google Cloud: 2024 DORA report
[13] https://arxiv.org/abs/2211.03622 — Do Users Write More Insecure Code with AI Assistants?
[14] https://genai.owasp.org/llmrisk/llm062025-excessive-agency — OWASP LLM06:2025 Excessive Agency
[15] https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says — GitHub Copilot code quality study
[16] https://survey.stackoverflow.co/2025/ai — Stack Overflow 2025 Developer Survey: AI

Originally published at https://blog.jenuel.dev/blog/ai-writes-better-code-and-makes-bigger-mistakes

PewDiePie's AI Repo: How to Install Odysseus and Run It Locally

Jenuel Oras Ganawed — Tue, 11 Aug 2026 07:28:00 +0000

If you searched for PewDiePie's AI repository, this is the project you are looking for: odysseus-dev/odysseus on GitHub. Odysseus is a free, self-hosted AI workspace for chat, agents, research, documents, memory, email, calendar tools, and local or remote language models.

The repository has changed since its early launch. It now lives under the Odysseus organization rather than the original PewDiePie-branded location. It is also moving quickly: the default dev branch has the newest work, while the maintainers describe main as the more stable, curated branch.

This guide shows the official installation routes for Docker, Windows, Linux, and Apple Silicon. I will also show you how to connect Ollama, find the first-login password, and avoid the security mistake that matters most: exposing an AI admin console directly to the public internet.

Official links

What you are installing

Odysseus is the workspace, not the AI model itself. The application can connect to cloud APIs, an Ollama server, or other OpenAI-compatible model endpoints. It also includes Cookbook features for downloading and serving models.

This distinction matters for hardware. The Odysseus app is relatively lightweight. Local model inference is the part that consumes RAM and GPU memory. You can install the workspace on a modest computer and connect it to an API or a model server elsewhere. You do not need PewDiePie's multi-GPU workstation just to try the project.

If hardware is your main concern, read my separate guide: How to Build a Local AI Workspace Like PewDiePie's Odysseus: Hardware, Models, and Cost.

Before you start

Pick one installation route:

Docker: the recommended and most repeatable setup for most users.
Native Windows: convenient if you already use Windows and want to connect to Ollama.
Native Linux: useful when you want direct access to the host and GPU stack.
Native Apple Silicon: the better choice for Metal-accelerated local models on an M-series Mac.

You need Git. Native installations also need Python 3.11 or newer. Docker users need Docker with Compose support. The repository's dependencies are not pinned, so installs performed months apart can resolve to different package versions. If this is a serious deployment, keep notes about the commit and dependency versions that worked for you.

Option 1: install Odysseus with Docker

The maintainers recommend Docker for the quickest start. These commands follow the official setup guide:

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
cp .env.example .env
docker compose up -d --build

The copied .env file is optional, but it makes your deployment settings explicit. When the containers become healthy, open:

http://localhost:7000

Odysseus creates an admin account during first setup and prints a temporary password. For Docker, retrieve it from the container logs:

docker compose logs odysseus

Sign in with the generated password, then change it in Settings. If port 7000 is already in use, set APP_PORT=7001 in .env, recreate the container, and open port 7001 instead.

Docker Compose binds the web interface to 127.0.0.1 by default. That is a good default. Do not change APP_BIND to 0.0.0.0 unless you understand why you need network access and have authentication plus a trusted private-access layer in place.

Stable branch or development branch?

A normal clone currently checks out dev, the default branch. It contains the latest changes but may be unstable. If you prefer the curated branch, clone main explicitly:

git clone --branch main https://github.com/odysseus-dev/odysseus.git

For a first installation, I would choose main unless you need a feature or fix that only exists on dev.

Option 2: install Odysseus natively on Windows

Windows has a one-command PowerShell launcher that creates the virtual environment, installs dependencies, runs setup, and starts the server:

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
powershell -ExecutionPolicy Bypass -File .\launch-windows.ps1

Open http://localhost:7000 and use the temporary admin password printed in PowerShell.

If you prefer to run each step yourself:

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
py -3.11 -m venv venv
venv\Scripts\Activate.ps1
pip install -r requirements.txt
python setup.py
python -m uvicorn app:app --host 127.0.0.1 --port 7000

If Python 3.11 is unavailable but you have a newer supported version, replace py -3.11 with the installed version, such as py -3.12.

The core workspace runs natively on Windows. For Cookbook background downloads and the agent shell tool, install Git for Windows so bash.exe is available. Native vLLM and SGLang model serving still belongs on Linux or WSL2. For most Windows users, Ollama is the simpler local-model route.

Connect Odysseus to Ollama on Windows

Install Ollama, start it, and download a model that fits your computer. Then add this OpenAI-compatible endpoint in Odysseus Settings:

http://localhost:11434/v1

If Odysseus runs in Docker while Ollama runs directly on the host, use:

http://host.docker.internal:11434/v1

Ollama must listen somewhere the container can reach. The official guide uses:

OLLAMA_HOST=0.0.0.0:11434 ollama serve

Do not expose Ollama's port to the public internet. This address is for communication between your host and container, not an invitation to publish port 11434 through your router.

Option 3: install natively on Linux

Linux and macOS share the manual Python route:

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
python setup.py
python -m uvicorn app:app --host 127.0.0.1 --port 7000

You need Python 3.11 or newer. Cookbook also uses tmux for background model downloads and servers. Open http://localhost:7000 after startup.

For NVIDIA GPUs in Docker, Odysseus includes a diagnostic script:

scripts/check-docker-gpu.sh

The default mode only diagnoses the setup. It does not install packages or edit .env. The official guide also documents assisted NVIDIA Container Toolkit setup and separate AMD/ROCm overlays. Read those instructions before enabling GPU passthrough because a working nvidia-smi inside the container does not guarantee that llama.cpp was built with CUDA support.

Option 4: install on an Apple Silicon Mac

Docker cannot give the container access to Apple's Metal GPU. If you want GPU-accelerated local inference on an M-series Mac, use the native launcher:

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
./start-macos.sh

The macOS script starts Odysseus at:

http://127.0.0.1:7860

Port 7860 is intentional because AirPlay Receiver commonly occupies port 7000 on macOS. The script installs Homebrew dependencies, creates the Python environment, runs setup, and starts the server.

Odysseus can use llama.cpp or Ollama with Metal on macOS. vLLM and SGLang target CUDA or ROCm and do not run natively on macOS.

What model should you try first?

Start smaller than your ambition. On an 8GB laptop GPU, the maintainers recommend beginning with a GGUF model using Q4 quantization and llama.cpp. That is easier to validate than jumping straight into GPTQ or AWQ models served through vLLM or SGLang.

A machine without a dedicated GPU can still use Odysseus. Connect it to a cloud API, a remote model server, or run a small model on the CPU. Model memory depends on the quantized weights, context length, KV cache, runtime workspace, and available headroom. A parameter count alone does not tell you whether a model will fit.

First checks when something fails

For Docker, these commands answer most first questions:

docker compose ps
docker compose logs --tail=120 odysseus

Check that the container is healthy, confirm which port is bound, and look for the generated admin password. If the browser cannot connect, make sure you are opening the host port rather than an internal service port.

If Ollama works on the host but Odysseus cannot see it from Docker, check the endpoint, confirm Ollama is listening beyond its own loopback interface, and use host.docker.internal instead of localhost inside the container configuration.

On Windows, an .env file saved with a UTF-8 byte-order mark can make the first setting behave unexpectedly. The current project includes handling for this case, but saving as UTF-8 without BOM remains the safest choice.

Do not expose Odysseus like a normal public website

Odysseus can run shell commands, read and write files, manage models, access email and calendars, and store API tokens. The project's threat model says to treat it like an admin console. It is designed for trusted users on a private network, not anonymous visitors.

Keep AUTH_ENABLED=true. Keep internal services such as ChromaDB, SearXNG, Ollama, vLLM, and llama.cpp private. If you need access away from home, use HTTPS behind a trusted reverse proxy or private layer such as Tailscale, a VPN, or Cloudflare Access. Do not forward Odysseus or raw model-server ports directly from your router to the internet.

Self-hosting also does not automatically make every interaction private. If you configure cloud model APIs, web search, email, or other remote services, data can still leave your computer through those integrations.

Is Odysseus worth installing?

Yes, if you want one self-hosted place to experiment with models, agents, documents, memory, and personal integrations. The project is unusually ambitious, and that comes with a tradeoff: it changes quickly and gives administrators powerful capabilities. Expect to read logs and configuration notes occasionally.

If your only goal is chatting with one local model, Ollama plus a simpler interface may be easier. If you want a broader AI workspace that you can inspect, modify, and connect to your own services, Odysseus is worth trying. Use your existing computer first. Buying a pile of GPUs before you know which workflows matter is the expensive way to learn.

For the background story and a closer look at how the project has evolved, read What PewDiePie Is Building in AI Now.

References

Originally published at https://blog.jenuel.dev/blog/pewdiepie-ai-repo-install-odysseus-locally

Meta's AI Hacked a Company. The Safety Test Was the Weak Link

Jenuel Oras Ganawed — Thu, 06 Aug 2026 07:07:29 +0000

Meta was testing whether an AI model could perform dangerous cyber operations. Then the environment built to contain that test reportedly gave the model a path to the public internet, where it compromised another organization's system.

That is a rough sentence to read twice.

The easy reaction is to imagine a conscious AI breaking free. The more useful explanation is less cinematic and more uncomfortable: a capable system pursued the goal it was given, while a misconfigured evaluation environment exposed resources its operators did not intend it to reach.

This is not evidence that Meta's consumer accounts were hacked, and it is not a reason to delete every AI app. It is evidence that agent safety depends on far more than the model. The tools, network, credentials, proxy, sandbox, logs, and approval rules are part of the system too.

What Meta says happened

The BBC reported that Meta was running an independent security evaluation when one of its AI models connected to the internet and hacked another organization's system. Meta attributed the incident to a "misconfiguration" and said it was still investigating.

The evaluation was conducted by AI security company Irregular. According to the BBC, Irregular described it as the same type of evaluation-environment problem disclosed during recent Anthropic testing. The report also connects it to earlier incidents involving OpenAI models and publicly available services, including Hugging Face.

OpenAI has published its own account of recent third-party cybersecurity evaluation incidents and says it is adding safeguards around how these tests are run. Reuters also reported on Meta's disclosure.

The pattern matters more than any one company. Labs are giving increasingly capable models offensive objectives so they can measure what those models might do in the hands of an attacker. That work is necessary. But the test itself becomes dangerous when the model has code execution, useful tools, and a route outside the intended boundary.

This was not an AI becoming evil

The BBC quoted WPP's Daniel Hulme making an important distinction: these models are not conscious and are not deliberately plotting against a company. They are finding sophisticated ways to achieve a supplied goal.

That explanation is less dramatic, but it gives builders something they can act on.

If you tell an agent to find and exploit vulnerabilities, it will search for paths that help it do that. The model does not share the operator's unstated assumption that the proxy, sandbox, or neighboring service is off limits. If a path exists and the system has not been explicitly prevented from using it, the agent may treat that path as another available tool.

Intent is not a security control.

The evaluation environment is part of the AI

People often talk about "the model" as if it acts alone. In a real agent system, the model is only one component.

The complete system includes:

the prompt and objective
the tools the model can call
the code runner or browser executing those calls
the credentials available to those tools
the network routes the environment can reach
the files, databases, and services visible from the sandbox
the approval gates placed before consequential actions
the monitoring that tells a human when the agent crosses a boundary

A safer model inside a careless environment can still cause damage. A strong sandbox with unrestricted outbound access is not as isolated as the word "sandbox" makes it sound. A read-only credential with access to the wrong dataset is still the wrong credential.

This is the same lesson developers learn in ordinary application security: boundaries need enforcement, not good intentions. AI agents make the lesson more urgent because they can probe, adapt, and chain small opportunities together.

Agent builders need zero trust

Zero trust sounds like enterprise security jargon, but the basic idea is useful: do not grant access because a component happens to be inside your environment. Verify every capability and keep permissions narrow.

For an AI agent, I would start with these controls.

Deny outbound network access by default

An evaluation environment should not reach the public internet unless the test explicitly requires it. When access is necessary, allowlist the smallest possible set of domains and protocols. Log every request, including redirects and DNS activity.

A proxy is not a magic wall. Its configuration, authentication, redirect handling, and reachable internal services all deserve their own tests.

Use disposable credentials

Do not place production keys, employee tokens, shared cloud credentials, or real customer secrets inside an agent evaluation. Give each run a temporary identity with a short lifetime and narrow permissions.

Assume the agent may discover every credential available to its process, browser profile, environment variables, filesystem, or metadata service.

Separate the agent from sensitive systems

Run risky evaluations in an isolated account, project, network, and tenant. A container alone may not provide enough separation when the host or surrounding network exposes valuable services.

The safest target is a synthetic environment that behaves like the real system without containing real organizations, accounts, or data.

Put approval gates before irreversible actions

An agent can draft a request without sending it. It can prepare a code change without deploying it. It can identify a possible vulnerability without attempting exploitation against a public service.

Human approval should sit immediately before the action that creates external consequences. The approval screen must show what the agent is about to do, where it will do it, and which identity it will use.

Set hard limits outside the model

Do not rely on the model to decide when it has gone too far. Enforce limits in infrastructure:

maximum tool calls
request and spending caps
execution timeouts
network rate limits
restricted file paths
blocked commands and destinations
automatic shutdown after suspicious behavior

The model should not be able to edit or disable the controls monitoring it.

Make boundary violations visible

Use canary credentials, fake sensitive records, and monitored endpoints that no legitimate task should touch. If the agent accesses one, stop the run and preserve the logs.

A kill switch also needs to live outside the agent's environment. If the same system being evaluated controls the switch, it is not much of a switch.

What ordinary AI users should do

The available reporting does not establish that ordinary Meta, ChatGPT, or Claude users had their passwords, conversations, or payment information exposed in these evaluation incidents. Signing out of every account would not fix a containment failure inside a specialized security test.

Normal account hygiene still matters. Use a unique password, enable a passkey or multi-factor authentication, review active sessions, and remove connectors you no longer use. Do more if you see an unknown login, reused credentials, phishing, or an official notice affecting your account.

The immediate lesson is for teams giving AI systems the ability to browse, run code, read private files, send messages, change infrastructure, or interact with production services. Permissions turn a chatbot into an operator. That changes the risk.

We need these tests, but we need to test the tests

Stopping cybersecurity evaluations would be the wrong response. Labs need to know whether frontier models can discover vulnerabilities, plan attacks, or bypass controls before those capabilities become easier to deploy.

But a safety evaluation cannot borrow its credibility from the word "safety." It must be designed as hostile infrastructure. Every route should be treated as discoverable. Every credential should be treated as extractable. Every unstated boundary should be assumed nonexistent.

I wrote earlier about why pre-launch simulations are becoming an important model safety check and why builders still need useful AI evaluations even when benchmarks are imperfect. The Meta incident adds the missing warning: the evaluation harness can fail too.

It also follows the earlier OpenAI and Hugging Face containment incident. That article focused on what ordinary users should do. This one has a different answer for builders.

If an agent is powerful enough to surprise you, every permission becomes a security boundary. Do not assume it understands your intention. Build the environment so the capabilities you did not grant simply are not available.

References

Originally published at https://blog.jenuel.dev/blog/meta-ai-hacked-company-safety-test-zero-trust

How to Build a Local AI Workspace Like PewDiePie's Odysseus: Hardware, Models, and Cost

Jenuel Oras Ganawed — Fri, 31 Jul 2026 13:17:16 +0000

PewDiePie's Odysseus has made local AI look like something people might actually want to use, not just a terminal window surrounded by driver errors.

The obvious follow-up question is: what kind of computer do you need to build something similar?

There is no single official "Odysseus PC" parts list. Odysseus is the workspace, while the model server does most of the heavy computing. You can run the interface on a modest machine and connect it to an API, an Ollama server, another computer on your network, or a GPU workstation. That distinction can save you thousands of dollars.

This guide uses the official Odysseus repository, its current setup guide, and documentation from the local-model tools it supports. It explains what is confirmed, what depends on your model, and what I would build at three different budgets.

If you are new to the project, read our latest Odysseus project update first. We also covered why PewDiePie's open-source AI workspace attracted so much attention.

What Odysseus actually needs

Odysseus combines chat, agents, research, documents, email, notes, calendar tools, model comparison, memory, and a hardware-aware "Cookbook" for local models. The repository now lives under the odysseus-dev GitHub organization. On July 31, 2026, the GitHub API showed more than 84,000 stars, and the project used the AGPL-3.0-or-later license.

The app itself is not the expensive part. The official setup guide says the core application is lightweight. Local model serving is what consumes RAM, VRAM, and compute. A small host can run the workspace while sending model requests to an API or a remote server.

What PewDiePie actually built

PewDiePie did build an unusually large local-AI machine before Odysseus launched. In his August 2025 video "Accidentally Built a Nuclear Supercomputer", the confirmed configuration included an ASUS Pro WS WRX90E-SAGE SE motherboard, an AMD Ryzen Threadripper PRO 7975WX-class processor, and eventually eight NVIDIA RTX 4000 Ada Generation cards.

Each RTX 4000 Ada has 20 GB of GDDR6 ECC memory, so the eight cards provide 160 GB of nominal aggregate VRAM. That does not behave like one seamless 160 GB GPU. A model server has to support sharding or tensor parallelism across the cards. He discussed running TP8 and Llama 3 70B on the machine.

The video showed or mentioned 96 GB of system memory at the start and two power supplies rated around 1,300 watts each. The exact PSU models and his final purchase total were not confirmed. Reconstructing a machine with eight workstation GPUs, Threadripper PRO, ECC memory, specialized mounting, storage, cooling, and dual power supplies could land around $17,000 to $23,000 before taxes or import costs, but that is a planning estimate, not PewDiePie's receipt.

His February 2026 video, "I Trained My Own AI... It beat ChatGPT", also showed or referenced modified RTX 4090-class cards with 48 GB of memory. That was a separate fine-tuning experiment involving Qwen2.5-Coder-32B. It should not be treated as Odysseus's default model or combined with the older eight-card build into one definitive current parts list.

Most important: Odysseus does not require any of this hardware. PewDiePie's workstation is part of his broader local-AI experimentation. The public project is model-agnostic and can run with an API, a small local model, or a remote model server.

That gives you four practical ways to use it:

Run Odysseus locally and use cloud model APIs.
Run Odysseus and a small model on the same computer.
Run the workspace on one device and connect it to a more powerful model server.
Build a dedicated GPU workstation for larger local models and longer agent sessions.

The first option is the cheapest. The fourth is the version people imagine when they hear "personal AI workstation," but it is not required.

VRAM matters more than the name on the box

Local models have to fit their weights, context, and runtime overhead somewhere. On an NVIDIA or AMD system, that usually means GPU VRAM. Apple Silicon uses unified memory shared by the CPU and GPU. CPU-only inference can borrow ordinary system RAM, but it is usually much slower.

Quantization reduces the memory needed for model weights. The theoretical floor for a 4-bit model is roughly half a byte per parameter, but real files include metadata, scales, and other overhead. For a concrete example, the official Qwen2.5-Coder-32B GGUF repository lists its Q4_K_M file at about 19.85 GB, not 16 GB. Its Q8_0 file is about 34.82 GB. The runtime, context window, KV cache, batching, and GPU-driver allocations then require additional memory.

That is why a model that appears to fit on paper can still run out of memory. Longer context windows and concurrent requests can change the result dramatically. Treat the table below as a starting point, not a guarantee.

Available model memory	Reasonable starting point	What to expect
8 GB	Small GGUF models around 3B to 8B	Useful for chat, summaries, and light tool use; tight context limits
12 GB	7B to 14B quantized models	A comfortable entry point for everyday local chat
16 GB	14B-class models and some larger quantized models	Better coding and agent options, but model and context choices still matter
24 GB	Some 32B-class Q4 models	Possible with limited headroom; context and runtime settings matter
32 GB or more	Larger models, longer contexts, or more concurrent work	More flexibility, with rapidly increasing hardware cost
64 GB or more unified/system memory	Some heavily quantized large models	Capacity improves, but speed depends heavily on memory bandwidth and runtime support

Odysseus itself recommends starting with GGUF/Q4 models through llama.cpp on an 8 GB laptop GPU before trying more demanding GPTQ or AWQ deployments. That advice is in the project's setup guide and is much more sensible than downloading the largest model you can find.

Three ways I would build it

These are planning estimates, not live store quotes. Prices change by country, availability, and whether you buy used parts. They also exclude displays and peripherals.

1. Use the computer you already own: roughly $0 to $200

This is where most people should begin.

16 GB of system RAM is workable; 32 GB is more comfortable.
Use an SSD with enough room for model files. Even a few quantized models can consume tens of gigabytes.
Install Odysseus through Docker or the native instructions.
Connect a cloud API first, or run a small local model through Ollama or llama.cpp.

You may only need a larger SSD or more RAM. This setup lets you learn the software before buying an expensive GPU. It also gives you a fair comparison between cloud quality and local privacy.

2. The practical local-AI PC: roughly $1,100 to $1,700

For a new build, I would prioritize a GPU with 16 GB of VRAM over a faster gaming card with less memory.

A modern 8-core or better desktop CPU
A GPU with 16 GB of VRAM
32 GB of system RAM, preferably 64 GB if the budget allows
A 1 TB system SSD plus a 2 TB model drive
A quality power supply sized for the GPU

This is a sensible tier for 7B to 14B models, with room to experiment beyond them depending on quantization and context. It is also still a normal desktop that can handle development, creative work, and gaming.

3. The serious enthusiast workstation: roughly $2,000 to $4,000+

The biggest upgrade here is 24 GB or more of fast model memory.

A GPU with 24 GB or 32 GB of VRAM, or a unified-memory system with substantially more memory
64 GB to 128 GB of system or unified memory
At least 2 TB of fast NVMe storage; 4 TB is easier to live with
Strong cooling and a power supply appropriate for sustained inference
Wired networking if other devices will use it as a model server

This tier makes 32B-class quantized models far more practical and leaves more room for context, model comparison, and agent workloads. It still does not guarantee that every huge model will run well. A model fitting in memory and a model responding at a speed you enjoy are two different things.

At the specialized end, products such as NVIDIA DGX Spark trade ordinary PC flexibility for a large unified-memory pool designed for AI development. They are interesting, but they are not the default recommendation for someone who has not yet tried Odysseus on existing hardware.

Windows, Linux, or macOS?

Windows

Odysseus has a native PowerShell launcher and requires Python 3.11 or newer. The official guide says Ollama is the easiest route for serving a local model on Windows. You can point Odysseus to http://localhost:11434/v1 after Ollama is running.

For vLLM or SGLang on an NVIDIA GPU, Linux or WSL2 is the more natural environment. Windows users should also pay attention to Docker GPU passthrough. The Odysseus docs include a specific warning about snap-installed Docker under WSL2 because snap confinement can block access to WSL GPU libraries.

Linux

Linux gives you the widest choice of local inference servers and GPU tooling. Docker is the project's recommended quick start. NVIDIA users can add the project's GPU overlay after confirming that the NVIDIA Container Toolkit and Docker passthrough work. AMD users have a separate ROCm overlay and diagnostic script.

Apple Silicon

M-series Macs can be attractive because CPU and GPU share one memory pool. There is one important Odysseus-specific catch: Docker on macOS cannot expose the Metal GPU to the container. The setup guide recommends running Odysseus natively through ./start-macos.sh for GPU-accelerated local serving.

On macOS, llama.cpp or Ollama can use Metal. The Odysseus documentation says vLLM and SGLang do not run there because those paths target CUDA or ROCm. Buy based on the software you plan to use, not just the memory number on the product page.

The software stack

A practical Odysseus setup does not need every local-AI tool at once.

Ollama is the easiest starting point for many Windows, macOS, and Linux users. It packages model downloads and serving behind a simple local API.
llama.cpp is a flexible runtime for GGUF models across CPU, CUDA, Metal, and other backends.
vLLM is aimed at high-throughput serving, especially on supported Linux GPU systems.
Odysseus can also connect to OpenAI-compatible endpoints and model APIs, so local and cloud models can coexist in one workspace.

My suggested order is simple: install Odysseus, connect one working model, test chat and document workflows, and only then add agents, shell access, remote servers, or multiple inference engines.

Do not confuse self-hosted with automatically private

A local model can keep prompts and documents off a model provider's servers, but privacy depends on the entire setup. Odysseus can connect to cloud APIs, email, web search, shell tools, and remote services. Data sent to any of those services follows their policies, not the word "local" on your dashboard.

The project's own security guidance says to keep authentication enabled, avoid putting private data in Git, and never expose raw model or service ports publicly. Docker binds the web interface and bundled services to 127.0.0.1 by default. Changing the bind address to 0.0.0.0 can make the workspace available on your network, but it also increases the attack surface.

The docs recommend a trusted LAN or VPN such as Tailscale for remote access, with authentication left on. They specifically warn against exposing the port directly to the public internet. The optional Docker socket integration also deserves caution because access to the Docker daemon can grant broad control over the host.

Agents make those concerns more serious. If a model can read files, execute shell commands, or work with email, use a limited account, keep backups, review permissions, and do not give an experimental model access to anything you cannot afford to lose.

How to install Odysseus with Docker

The official project recommends Docker for a quick start:

git clone https://github.com/odysseus-dev/odysseus.git
cd odysseus
cp .env.example .env
docker compose up -d --build

When the containers are healthy, open http://localhost:7000. The first temporary admin password appears in docker compose logs odysseus. Change it after signing in.

The default Git branch is dev, which receives the newest changes but may be unstable. The project tells users who want a more curated version to use the main branch. That is the better choice for a machine you depend on:

git clone --branch main https://github.com/odysseus-dev/odysseus.git

Follow the live setup guide rather than copying commands from an old social post. Odysseus is moving quickly, and the repository ownership, license, installation notes, and GPU instructions have already changed since launch.

What should you buy?

If you have never run a local model, buy nothing yet. Install Odysseus on your current computer, connect an API, and try a small quantized model. You will learn whether you care more about privacy, response speed, context size, coding quality, or cost.

If you already know you want local inference, 16 GB of VRAM is a practical target for a balanced new PC. If your goal is 32B-class models, heavy coding agents, long contexts, or simultaneous models, 24 GB or more gives you much more breathing room.

I would not spend workstation money merely to copy a creator's setup. Build around the models and tasks you will use. Odysseus is valuable precisely because it does not require one vendor, one model, or one giant machine.

The best Odysseus computer is not the most expensive one. It is the cheapest machine that runs your actual workflow at a speed you can tolerate.

References

Originally published at https://blog.jenuel.dev/blog/build-local-ai-workspace-like-pewdiepie-odysseus