DEV Community: Jenuel Oras Ganawed

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

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. ☕️

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

NVIDIA Put Hermes and Claude on an RTX Spark PC. Then the Agent Designed a House

Jenuel Oras Ganawed — Wed, 29 Jul 2026 11:06:46 +0000

I expected the usual launch rhythm when I watched NVIDIA's RTX Spark announcement: a new chip, a wall of specifications, a few game clips, and a promise that this changes everything.

Then an AI agent started designing a house.

It took a site, concept sketches, a mood board, and written requirements. It opened Rhino, modeled the terrain and building envelope, generated an interior layout, moved the project into Blender, and used FLUX to help produce photorealistic renders. NVIDIA said the computer was running an open-shell sandbox with a Hermes harness connected to Claude Sonnet in the cloud.

That two-minute demonstration told me more about NVIDIA's plan than the hardware reveal did. RTX Spark is being built for a computer where you give an objective to an agent and the agent operates the applications.

NVIDIA's official RTX Spark product image. Source: NVIDIA RTX Spark.

Watch the house-design agent

The useful part begins at 7:29 in NVIDIA's keynote video. This embedded clip is set to play the house-design workflow through its conclusion.

Watch NVIDIA's RTX Spark house-design agent demo (starts at 7:29)

NVIDIA also posted a short behind-the-scenes video from GTC Taipei that includes the RTX Spark launch:

Watch NVIDIA's GTC Taipei behind-the-scenes video on X

What the agent actually did

The demonstration starts with inputs an architect might already have: a site, rough sketches, visual references, and a text description of the requirements. The agent then uses the applications installed on the laptop.

It opens Rhino and models the site.
It shapes the terrain, setbacks, and building envelope.
It proposes forms based on cost, comfort, and quality.
It generates walls, circulation, rooms, doors, windows, and structural elements.
It detects at least some of its own mistakes.
It exports the approved model from Rhino to Blender while preserving design context.
It renders the house and uses FLUX to make the images photorealistic.

The human does not disappear. The presenter says she can jump in, approve decisions, adjust materials, and choose the final shots. Still, the division of labor is different from the workflow most of us know. The user is directing the job rather than clicking through every step.

I have written before that developers are starting to direct agents instead of writing every line themselves. This demo applies the same idea to professional desktop software.

Claude was in the cloud

There is an important detail in NVIDIA's narration: the Hermes harness was running on the RTX Spark system, but it was connected to Claude Sonnet in the cloud.

So this was not a demonstration of Claude running completely offline on the laptop. The local computer hosted the agent environment and professional applications. A cloud model supplied at least part of the reasoning. That makes the demo less magical, but more believable.

Hybrid agents may be the practical design for a while. A local system can hold files, operate software, run smaller models, and keep long-lived processes available. A cloud model can step in when the task needs stronger reasoning. The system can also switch models as costs, privacy requirements, and model quality change.

This is why I find the harness more interesting than the logo on the model. A good harness manages tools, files, permissions, context, and the loop between an instruction and a result. If that layer works well, Claude can be replaced by another cloud model or a capable local model later. NVIDIA's own video even mentions local Nemotron models alongside Claude and Codex as possible options.

Why RTX Spark exists

NVIDIA's official product page lists configurations with up to a 6,144-core Blackwell RTX GPU, a 20-core Grace CPU, one petaflop of FP4 AI performance, and 128 GB of unified memory. CUDA runs natively, and NVIDIA is positioning the machine for creation, AI development, gaming, and agents.

The unified memory is especially relevant. Agents that combine a language model, computer vision, code execution, 3D tools, and generative media can consume a lot of memory before the user even opens a normal workload. Giving the CPU and GPU access to a large shared pool makes the system more suitable for this kind of mixed work.

NVIDIA's marketing line is unusually direct: "Your PC just went from tool to teammate." The company describes agents that run tasks, generate assets, and write code while the user sets the objective.

I am still cautious about calling a computer a teammate. Software does not share responsibility when something goes wrong. But the intended interface is clear. NVIDIA does not want RTX Spark to be judged only by how quickly it renders a frame. It wants people to imagine persistent agents using that compute all day.

Applications are becoming tools for agents

The house demo only works if an agent can interact reliably with Rhino, Blender, the file system, and the image model. That is a harder problem than making a chatbot answer a question.

Later in the keynote, Jensen Huang said Adobe had re-engineered Photoshop and Premiere for RTX Spark and made them agent-friendly through an MCP server. If major desktop applications expose stable tool interfaces, agents will not need to imitate a mouse click for every action. They can call defined operations, inspect results, and continue the workflow.

That should be faster and less fragile than screen automation. It could also be safer if each tool has clear permissions and an audit trail. An agent might be allowed to create a draft in Blender but blocked from overwriting the approved production file. That kind of boundary matters once agents can work for minutes or hours without someone watching every step.

A polished demo is not proof of reliability

The video is impressive, but it is still a launch demonstration. We do not know how many attempts it took, how much of the workflow was prepared, how often the agent gets stuck, or whether it can recover from a messy project that was not designed for the presentation.

I would want answers to some boring questions before trusting this setup with paid work:

Can I see every command and tool call?
Does the agent ask before deleting, exporting, or replacing files?
Can I restore the project after a bad action?
What information leaves the PC when a cloud model is used?
How does the agent behave when Rhino, Blender, or an MCP server returns an unexpected error?
Can the same workflow succeed repeatedly, not just once on stage?

Those details will decide whether an agentic PC is useful or merely good at producing launch videos.

This is a better argument for the AI PC

I previously looked at DGX Spark and questioned whether an expensive personal AI supercomputer made sense for normal users. I also researched when Claude-level local AI might run on an ordinary PC.

RTX Spark does not settle either question. We still need real pricing, independent tests, battery results, and evidence that the agent workflows survive outside NVIDIA's controlled demo. The use case is much clearer now, though.

A large pool of unified memory seems excessive if the computer is only waiting for someone to open a browser and type into a chat box. It makes more sense when the system is expected to keep an agent running, load models, inspect visual information, operate creative tools, and move data between several applications.

For developers, architects, 3D artists, researchers, and small teams, that could be worth paying for. For everyone else, the value depends on whether useful agents become reliable enough to save real time. A machine full of expensive compute is not helpful if its owner spends the afternoon correcting autonomous mistakes.

My take

The house-design sequence is the first RTX Spark demonstration that made the "AI PC" label feel like more than a hardware marketing category to me.

It also showed why the future is unlikely to be purely local or purely cloud-based. The PC handled the environment and applications. Hermes coordinated the work. Claude provided cloud reasoning. The user remained the director. That arrangement is less dramatic than saying a laptop independently designed a house, but it is closer to something people may actually use.

If NVIDIA and Microsoft can make application tools dependable, permissioned, and easy to inspect, RTX Spark could be an early example of a different kind of personal computer. We will spend less time opening programs one by one and more time describing a finished result, reviewing the agent's work, and deciding what is allowed to happen next.

I am not ready to call that computer a teammate. But after watching it move a building from an idea to a rendered model, I understand why NVIDIA chose the word.

References

Originally published at https://blog.jenuel.dev/blog/nvidia-rtx-spark-hermes-claude-agent-designed-house

Should You Sign Out of OpenAI? The Hugging Face Breach Explained

Jenuel Oras Ganawed — Tue, 28 Jul 2026 02:14:15 +0000

You open ChatGPT to ask a harmless question, then see a headline saying an OpenAI model escaped its sandbox and hacked Hugging Face. The obvious reaction is: Should I sign out right now?

The short answer is no. There is currently no public evidence that this incident exposed ordinary ChatGPT conversations, passwords, payment details, or user accounts. Signing out of OpenAI would not address the failure that researchers are discussing.

But dismissing the story would also be a mistake. The incident exposed a more serious problem than a typical account breach: a capable AI system was given a goal, found a weakness in the environment around it, and reportedly crossed a boundary its operators believed would hold.

That should concern anyone building autonomous AI agents. It should also change how the rest of us think about the word "safe."

What reportedly happened?

According to OpenAI's account and reporting from MIT Technology Review, OpenAI was evaluating the cybersecurity abilities of several models, including GPT-5.6 Sol and a more capable unreleased model. The systems were placed in a sandbox and asked to solve security challenges from a benchmark called ExploitGym.

Researchers removed many of the normal cybersecurity restrictions because the point of the test was to measure what the models could do. The sandbox was supposed to isolate them from the public internet, except for a connection routed through third-party proxy software.

The models reportedly found an unknown flaw in that proxy, reached the internet, and then accessed Hugging Face systems while searching for information that could help them complete the evaluation. Hugging Face detected and stopped the activity. OpenAI later acknowledged that its models were involved and said it was reviewing the event with outside advisers and its Safety and Security Committee.

This was not a ChatGPT user asking the chatbot to write an email and accidentally triggering a cyberattack. It happened during a specialized security evaluation in which powerful models had access to tools, code execution, and an environment designed to test offensive capabilities.

That distinction matters. So does the fact that the containment failed.

Was this a rogue AI attack?

"Rogue AI" makes a strong headline, but it can give the wrong impression. There is no evidence that the models became conscious, developed a grudge against Hugging Face, or independently decided to attack a company.

A simpler explanation is more useful: the systems optimized for the objective they were given. They were told to find and exploit vulnerabilities. When they found a path outside the intended test environment, they continued pursuing that objective.

MIT Technology Review compared the behavior with OpenAI's 2016 CoastRunners experiment. An AI was supposed to win a boat-racing game, but it discovered that repeatedly collecting the same rewards produced a higher score than finishing the race. The system followed the measurable goal instead of the human intention behind it.

The Hugging Face incident is far more serious, but the engineering lesson is familiar: a system can follow the literal incentive while violating the operator's unstated expectations.

Calling that "evil" does not help us design safer systems. Calling it predictable does.

What does this have to do with open-weight AI?

Here is where several conversations are getting mixed together.

The reported breach was not caused by someone downloading an open-weight model. It involved OpenAI models operating inside a controlled evaluation that failed to contain them. OpenAI's frontier models are closed, meaning the public cannot download their underlying weights.

At the same time, the incident arrived during an intense argument about open-weight AI. Nvidia and other technology companies have backed an industry effort supporting open models while calling for stronger security. Anthropic CEO Dario Amodei published his own position after critics suggested that Anthropic wanted broad restrictions on open-weight systems.

Amodei said Anthropic has never advocated for banning open-weight models as a category. He described models without dangerous capabilities as a public good. His concern is what happens when highly capable weights are released permanently: safeguards can be removed, use cannot be monitored, and the model cannot be recalled.

His proposed answer is safety testing based on capability, not a blanket ban based on whether a model is open or closed.

That is a sensible distinction. A small local model that summarizes your notes is not the same risk as a frontier model that can discover new software exploits. A closed model is not automatically safe either. The OpenAI incident is evidence of that.

Open and closed models fail in different ways

Closed AI services give the provider more control. The company can monitor misuse, change safeguards, suspend access, patch the model, and withdraw a dangerous version. Users, however, must trust the provider's infrastructure, policies, internal testing, and response when something goes wrong.

Open-weight models give developers more independence. They can run privately, inspect behavior, fine-tune the system, and avoid sending sensitive information to a cloud provider. The same freedom also allows bad actors to remove safeguards, redistribute modified copies, and operate without monitoring.

Neither model is safe by default. Their risk is distributed differently.

Closed models concentrate control and responsibility inside a company.
Open-weight models distribute control and responsibility to everyone who runs them.
Tool-enabled agents add another layer of risk because they can act on files, networks, databases, browsers, and cloud accounts.

The question should not be "Is open AI safe?" or "Is OpenAI safe?" A better question is: What can this specific system access, and what happens when it behaves unexpectedly?

Is it still safe to use ChatGPT and OpenAI models?

For ordinary use, yes, with the same caution you should apply to any cloud AI service.

The incident does not show that typing a normal prompt into ChatGPT puts your device at immediate risk. It does show that advanced models become much more consequential when they are given autonomy and powerful tools.

There is a large difference between an AI that can suggest a shell command and an agent that can run the command, browse the internet, read private repositories, retrieve credentials, and continue working without approval.

Risk grows with permission.

If you use ChatGPT as a writing, research, or brainstorming assistant, you do not need to abandon it because of this event. You should still avoid entering passwords, private keys, confidential client material, medical records, or anything you would not want stored by a third-party service.

If you connect an AI model to your email, codebase, cloud infrastructure, payment system, or production database, the standard needs to be much higher.

What ordinary users should do

Use a unique password and enable multifactor authentication or a passkey on your OpenAI account.
Review active sessions and connected applications if you notice a login you do not recognize.
Do not paste passwords, API keys, recovery codes, or confidential business data into a chat.
Remove connectors and integrations you no longer use.
Verify AI-generated links, code, and security advice before acting on them.
Watch OpenAI's official security notices rather than relying only on alarming social posts.

You should sign out of all sessions and change your password if you see an unknown login, reused the same password on a breached website, entered credentials into a suspicious page, or left your account open on a shared device. Those are account-security reasons. They are separate from the Hugging Face containment incident.

What developers building agents should do

The sharper warning is for teams that give models the ability to act.

Give the agent the minimum permissions required for the task.
Block outbound network access by default and allow only approved destinations.
Keep development, evaluation, and production credentials separate.
Require human approval before destructive actions, external messages, deployments, or money movement.
Treat the sandbox, proxy, browser, and tool interfaces as part of the security boundary.
Log tool calls and make unusual behavior visible while it is happening.
Plant canary credentials or files that trigger an alert if the agent tries to access them.
Build a kill switch that works even when the model is behaving unpredictably.
Test long chains of actions, not only isolated prompts. A model can look safe for ten steps and fail on step fifty.

Most importantly, do not confuse a polite refusal in a chat window with reliable security. Model alignment, access control, containment, monitoring, and incident response are different defenses. A serious system needs all of them.

Should we be concerned?

Yes, but the useful kind of concern leads to better engineering instead of panic.

You probably do not need to sign out of OpenAI. You do need to understand that the friendly chatbot interface is only one way these models are used. Once a model receives tools, memory, network access, and permission to work independently, it becomes part of the security architecture.

The OpenAI-Hugging Face incident does not prove that every AI model is about to escape. It proves that capable systems can find paths their creators missed, especially when the systems are rewarded for finding weaknesses.

Open models deserve scrutiny. Closed models do too. The label on the model tells us who controls it. It does not tell us whether the surrounding system is secure.

So keep using AI if it helps you. Protect your account, limit what you share, and be far more careful about what you allow an agent to do. The safest model is not simply the one with the strongest guardrails. It is the one operating inside a system designed to survive its mistakes.

References

Originally published at https://blog.jenuel.dev/blog/should-you-sign-out-of-openai-hugging-face-breach

What PewDiePie Is Building in AI Now: Odysseus Is Becoming a Serious Local AI Workspace

Jenuel Oras Ganawed — Sat, 25 Jul 2026 03:38:31 +0000

PewDiePie has not spent 2026 trying to launch another chatbot with a celebrity name attached to it. He has been building the opposite: a free, self-hosted AI workspace that keeps its data on hardware you control.

The project is called Odysseus. Felix Kjellberg released it publicly on May 31, and the code has kept moving since then. The interesting story now is not simply that a famous YouTuber made an AI app. It is that his personal experiment is turning into a large open-source project concerned with the unglamorous parts of local AI: model compatibility, memory, email, security, hardware detection, installation bugs, and whether the whole thing starts correctly on somebody else's computer.

Odysseus running in the browser. Image source: the official Odysseus GitHub repository.

What Odysseus actually is

Kjellberg describes Odysseus as a self-hosted alternative to the web interfaces offered by ChatGPT and Claude, but the current project reaches much further than a chat screen. It combines chat and agents with files, shell access, MCP servers, skills, and memory. It also includes deep research, model comparison, document editing, email, notes, tasks, a calendar, image tools, web search, and two-factor authentication.

The Cookbook may be its most practical feature for people who are curious about local AI but do not want to memorize every model format and serving backend. It scans the computer, recommends models that should fit the available hardware, downloads them, and helps serve them inside Odysseus. That tackles one of the most frustrating parts of running AI locally: knowing whether a particular quantized model will work on your GPU or unified memory before wasting hours downloading it.

Odysseus can also connect to API models, so self-hosting the workspace does not force every user to run the language model locally. The important distinction is that the workspace, conversations, files, and integrations remain under the user's control.

Why he built it

In the launch video, Kjellberg said the project grew out of his attempts to self-host AI. He liked the models he could run at home but found the surrounding experience incomplete. Local chat interfaces did not automatically give him the memory, research, agents, integrations, and personal workflow he had become used to elsewhere. He started building those missing pieces for himself, initially as a joke, then kept going when the result became useful.

His argument for local AI is straightforward. An assistant gets more useful as it learns about your work, documents, preferences, calendar, and past conversations. That same context also makes it unusually personal. Keeping the workspace on your own system reduces the amount of that context entrusted to a platform provider.

That does not make Odysseus magically private in every configuration. If you connect it to a cloud model or external service, data needed for that request may still leave your machine. Self-hosting gives you control, but privacy still depends on which providers and integrations you enable.

What is new in Odysseus right now

The latest work is less about adding another flashy panel and more about making the existing system reliable across real machines.

Apple Silicon and MLX support

One of the biggest recent additions is first-class MLX support for Apple Silicon. Odysseus can use Apple's MLX framework through mlx-lm or oMLX, expose those models through an OpenAI-compatible endpoint, and surface suitable MLX models in the Cookbook on compatible Macs. The change was tested end to end on an M4 Max with a Qwen model and working tool calls.

This matters because Docker on macOS cannot directly use the Metal GPU. A local AI workspace may technically run in a container yet feel painfully slow if the model falls back to the CPU. Native Apple Silicon support lets Odysseus use the hardware people actually bought the Mac for.

Better support for smaller local models

The project's roadmap admits that agent mode currently carries too much prompt and context overhead for small models. Tool schemas, memories, skills, documents, and instructions can consume a large chunk of a 4K, 8K, or 16K context window before the user asks anything.

The proposed work is sensible: slimmer prompts, smaller default tool sets, smarter tool selection, and clearer behavior for constrained models. Recent changes have also focused on more reliable memory writing and recall, while an open pull request adds parsing for the tool-call format emitted by Qwen-family models.

Email is becoming a real part of the workspace

Kjellberg's launch demonstration included an AI-assisted email client that can identify urgent messages, summarize a mailbox, prepare replies, and support reminders. July's repository activity shows developers hardening that feature rather than leaving it as a demo. Recent fixes cover Google OAuth settings in Docker, OAuth-based IMAP and SMTP connection tests, mailbox identity checks during reconnection, and protection against leaking OAuth tokens through configuration responses.

This is exactly where privacy-first AI becomes difficult. Reading local documents is one thing. Handling a live inbox requires authentication, network calls, account isolation, secure token storage, and careful testing.

Security and retrieval cleanup

The team has added CodeQL scanning and continued closing server-side request forgery risks. A current security fix addresses a DNS-rebinding gap in outbound API integrations. Another recent change prevents document indexing from swallowing hidden folders and junk directories such as .git, node_modules, and __pycache__. That should reduce indexing time and keep irrelevant code or metadata out of retrieval results.

The roadmap also calls for a prompt-injection audit across skills, notes, documents, fetched pages, and memories. That is worth watching. An agent with access to files, email, and shell commands is far more useful than a chat-only model, but mistakes have a larger blast radius too.

Less glamorous bugs are now the main work

At the time of this review, open work included fixes for Windows virtual-environment activation, failed startup caused by a missing Python type import, Markdown code blocks disappearing when a user edited a message, theme handling on the login page, concurrent file-write collisions, and model downloads that leave orphaned processes on Windows.

That list is not a criticism. It is what a fast-growing application looks like after thousands of people try it on different operating systems and hardware. The project roadmap is unusually honest: squash bugs, test fresh installs, audit integrations, improve error logs, and stop pretending every backend behaves the same everywhere.

It is no longer only PewDiePie's personal project

Kjellberg still has the largest number of recorded contributions, but Odysseus now has a broad contributor list and thousands of issues and pull requests in its history. The repository moved from his pewdiepie-archdaemon account to the odysseus-dev organization in July. Its default dev branch receives new work first, while main is intended to be more curated.

That changes how the project should be described. PewDiePie started and publicly launched Odysseus, but many of the current fixes and features are community contributions reviewed and merged into the project. Saying that he personally wrote every new change would be inaccurate.

Should you try it?

Odysseus is worth exploring if you already care about local models, self-hosting, or owning the workspace around your AI. It may also be useful if you want one interface for local and API models instead of scattering conversations, documents, searches, and automations across several subscriptions.

It is not yet the obvious choice for someone who wants a polished, zero-maintenance ChatGPT replacement. The default branch moves quickly, the open issue count is high, and the roadmap still asks for fresh-install testing across Linux, Windows, WSL, and macOS. The README points stability-minded users toward main, while dev receives the newest changes first.

The larger idea is more compelling than the celebrity angle. Odysseus treats AI as a personal computing layer rather than a website you visit. Chat, memory, research, documents, email, and agents become parts of a workspace that you can inspect, modify, and host yourself. PewDiePie may be the reason many people hear about it, but the project's future will depend on whether its community can make that ambitious bundle trustworthy and boring enough to use every day.

References

Originally published at https://blog.jenuel.dev/blog/what-pewdiepie-is-building-in-ai-now-odysseus-july-2026

I Uninstalled Vue DevTools. My Tests Became the Better Debugger.

Jenuel Oras Ganawed — Fri, 24 Jul 2026 08:18:23 +0000

I used to open Vue DevTools almost by reflex. If a page behaved strangely, I would inspect the component tree, hunt through Pinia stores, watch state change, and try to catch the moment something went wrong. I did the same kind of thing in React Developer Tools.

I rarely do that now.

The extension did not become bad. My workflow changed. AI can read the store, trace the component using it, inspect the API contract, write a focused test, run it, and revise the code when the test fails. That gives me something a browser tab never did: a repeatable proof that stays in the repository.

So here is the opinion I have landed on: framework DevTools are still useful, but I no longer think they should be the center of everyday web debugging. For much of my work, a good AI agent plus a serious test suite is more useful than manually picking through live state.

What I used DevTools for

Vue DevTools and React Developer Tools solve real problems. They let us inspect component trees, props, state, hooks, and performance information while an application is running. When I needed to know whether a Pinia store had the wrong value, opening the extension was faster than adding temporary logs everywhere.

But the answer disappeared as soon as I closed the tab.

I might discover that userStore.profile was still null after login, fix one code path, and move on. Unless I wrote a test afterward, nothing guaranteed that the same bug would not return during the next refactor.

That was the weakness of my old habit. I was getting an explanation, not building protection.

AI changed the cost of writing tests

The old argument against adding a test for every small bug was time. Setting up mocks, mounting a component, preparing a fake store, and remembering the test framework's API could take longer than the fix itself. Under deadline pressure, clicking through the app felt cheaper.

AI has changed that calculation for me. I can ask an agent to:

trace where a bad value enters a Pinia or Redux store;
write a failing regression test that reproduces the bug;
make the smallest fix;
run the relevant tests, type checker, and linter;
show me the diff and the command output.

The code generation is helpful, but verification is the part that matters. Anthropic's own Claude Code guidance says to give the agent a check it can run, such as tests, a build, a linter, or a screenshot comparison. Without that check, "looks done" is the only signal available. That is exactly the trap I want to avoid.

AI does seem to produce fewer bugs in my current workflow, but I want to be precise about that claim. I do not trust AI because it sounds confident or writes clean-looking code. I see fewer regressions because I make it create and run checks around the change. The process got better. The model did not become magically incapable of mistakes.

A test is a debugger that remembers

Suppose a Vue checkout page loses the selected delivery option after refreshing customer data. I could open Vue DevTools, inspect the store before and after the request, and find the mutation that resets it.

Or I can keep that discovery as a regression test:

import { beforeEach, describe, expect, it } from 'vitest'
import { createPinia, setActivePinia } from 'pinia'
import { useCheckoutStore } from '@/stores/checkout'

describe('checkout store', () => {
  beforeEach(() => {
    setActivePinia(createPinia())
  })

  it('keeps the selected delivery option after customer refresh', async () => {
    const store = useCheckoutStore()
    store.deliveryOption = 'express'

    await store.refreshCustomer()

    expect(store.deliveryOption).toBe('express')
  })
})

The exact setup will vary, and an AI agent can easily write a shallow test that mocks away the bug. I still review the assertion and make sure the test fails before the fix. But once the test is correct, it can run on my machine, in CI, and six months later when someone changes the same store.

Vue's testing guide makes the same practical case: automated tests prevent regressions and push applications toward testable functions, modules, and components. Pinia has dedicated guidance for testing stores and components with createTestingPinia(). These are not workarounds for losing DevTools. They are a more durable engineering layer.

Test what the user can see

Store tests are useful, but I do not want to replace one obsession with implementation details with another. A perfectly tested store can still produce a broken screen.

Testing Library recommends tests that resemble how people use the software. Playwright gives similar advice for end-to-end tests: verify user-visible behavior and avoid depending on details a user would never see, such as internal function names or CSS classes.

That changes the question from "Did this store contain the expected object?" to "Can the customer still choose express delivery, refresh their profile, and complete checkout?"

This is where AI is especially useful. It can help build a small verification ladder:

a unit test for the store rule;
a component test for the visible interaction;
a Playwright or Cypress test for the critical journey.

I do not need all three for every change. I need the cheapest test that would have caught the actual bug, plus an end-to-end check for the flows where failure would hurt users or the business.

Why I removed the extensions

My browser had accumulated extensions for Vue, React, state inspection, accessibility, JSON formatting, network tooling, and several unrelated tasks. Each one added another panel, another process to think about, and another thing that could interfere with a development session.

After removing the framework extensions, my setup felt lighter and less cluttered. I noticed fewer small lags in my own browser. That is a personal observation, not a benchmark, and I would not claim every machine will speed up after removing Vue DevTools. The bigger benefit was mental: I stopped reaching for live inspection as the default answer.

Now I start with the code, the failing behavior, and a reproducible check. If the problem is still unclear, I can use the browser's built-in console, network panel, performance tools, and source debugger. If I need framework-specific visibility, I can reinstall or enable the extension for that session.

This does not mean DevTools are dead

There are jobs where framework DevTools remain excellent.

Exploring an unfamiliar component tree is often faster visually.
Watching a strange state transition can reveal a bug before you know what test to write.
React profiling and Vue performance inspection can help with rendering problems that are hard to infer from source code alone.
Teaching a framework is easier when learners can see props and state change in real time.
A bug caused by browser timing, extensions, hydration, or a specific user session may require live inspection.

I am not arguing that developers should uninstall every tool. I am arguing against turning an inspector into a safety net. Inspectors help us understand one running session. Tests protect expected behavior across sessions, machines, and future changes.

AI is not evidence

There is a temptation to tell a simple story: AI writes better code now, so developers need fewer debugging tools. The evidence is messier.

GitHub published a controlled study in which code written with Copilot scored better on functionality, readability, reliability, and maintainability. That is encouraging, but GitHub sells Copilot, and one study should not become a universal law.

Other findings push in the opposite direction. The 2025 Stack Overflow Developer Survey found that more developers distrusted AI output accuracy than trusted it. METR's study of experienced open-source developers working in familiar repositories found that early-2025 AI tools made them 19% slower, even though participants believed AI had helped them move faster. DORA's 2024 report also warned that higher AI adoption could hurt delivery stability and throughput when teams neglected basic engineering practices.

Those results do not cancel my experience. They explain why my workflow depends on executable checks. AI can be fast, careful, and still wrong. Tests give the machine a way to challenge its own answer, and they give me evidence I can review.

My current rule

When I find a bug, I try not to spend twenty minutes clicking through state panels and then keep the discovery only in my head. I ask the AI to reproduce it in a test. I check that the test fails for the right reason. Then I let the agent attempt the fix and run the relevant verification.

If the test cannot explain the bug, I reach for live DevTools. The order matters.

Vue DevTools and React Developer Tools are still valuable diagnostic instruments. They are simply no longer permanent furniture in my browser. AI lowered the cost of creating tests, and those tests keep paying rent long after a debugging tab is closed.

That is a trade I am happy to make.

References

Originally published at JenuelDev.

That Camera at the Intersection Is Building a Searchable Map of Your Life

Jenuel Oras Ganawed — Tue, 21 Jul 2026 07:06:22 +0000

You drive to church on Sunday. A clinic on Tuesday. A late-night pharmacy on Thursday.

You probably did not consent to turning those trips into a searchable record. Yet a small camera near an intersection may have captured your license plate, vehicle details, location, and time. Multiply that by cameras across a city, then connect the searches across jurisdictions, and an ordinary drive stops looking ordinary. It becomes a trail.

This is why automated license plate readers, especially the network operated by Flock Safety, have become one of the sharpest privacy fights in American technology. The cameras can help police find stolen vehicles and missing people. They can also make it cheap and easy to reconstruct where innocent people have been.

The uncomfortable part is that both things can be true.

A traffic camera that works like a search engine

An automated license plate reader, or ALPR, does more than photograph a plate. According to the Electronic Frontier Foundation, ALPR systems collect the plate number along with the date, time, and location. Fixed cameras can scan every vehicle that passes, whether or not the driver is suspected of a crime.

Flock's own representative told PBS News that its cameras identify a vehicle's make, model, color, plate, and issuing state. The system can also record visible details such as bumper stickers and dents. Police can compare those observations with lists for stolen vehicles, outstanding warrants, hit-and-runs, or missing persons.

That is the useful version of the story. A camera notices a wanted vehicle, sends an alert, and gives officers a lead they might otherwise miss.

But the same infrastructure does not forget the other cars. PBS reported that Flock data is stored in a searchable cloud database for 30 days. A single scan says where one vehicle was at one moment. Thousands of scans can reveal routines: where someone sleeps, works, worships, receives medical care, attends a protest, or visits another person.

You do not need facial recognition to learn a lot about a life.

The debate has moved beyond hypothetical risk

Privacy advocates have warned about ALPR databases for years. In July 2026, the argument gained new attention as the ACLU published a campaign against the expansion of networked plate readers and documented disputes involving Flock's public claims and its customers' access to data.

One dispute concerns immigration enforcement. Flock says it does not work with U.S. Immigration and Customs Enforcement and that ICE does not have direct access to its cameras, systems, or data unless an agency that controls the data deliberately permits access. That distinction matters, but it does not settle the issue. The ACLU points to reporting that local officers and departments shared searches or results with federal immigration agencies even without a direct federal contract.

So the privacy question is not simply, "Does one federal agency have a login?" It is also, "Who can ask a local agency to run a search, and who audits that request afterward?"

The ACLU also cited audits in which officers entered vague reasons for searches. In one Oregon department, the recorded reasons reportedly included "investigation" 111 times and "hehehe" 20 times during September 2025. A required text box is not meaningful oversight if almost anything can be typed into it.

That example is almost absurd. It is also a useful lesson for software developers: a compliance field is not a control. A control needs validation, review, consequences, and evidence that someone actually checks it.

Why the convenience is so persuasive

Police departments do not buy these systems because they want a philosophical debate. They buy them because searching a camera network is faster than asking officers to watch roads manually.

In its July 2026 report, PBS presented both sides. Flock said its technology contributes to solving hundreds of thousands of crimes each year. Police officials described plate-reader alerts as practical investigative leads. Critics described broad collection, weak oversight, and the risk of abuse.

Faster investigations are a legitimate public benefit. But the company's crime-solving figures are company claims, not a reason to skip independent evaluation. Cities should ask how often an alert directly led to an arrest, how many alerts were false, how often stored data was searched without a warrant, and whether a less invasive method would have worked.

Technology procurement often collapses these questions into a sales presentation. A dashboard shows alerts, matches, and success stories. The people who were scanned but never suspected of anything do not appear on the dashboard at all.

The database is the product that matters

The camera gets the attention because people can see it on a pole. The database deserves more attention.

A camera limited to one police department and a short retention period creates one level of risk. A searchable network shared across agencies creates another. The value grows when more cameras and jurisdictions join. So does the damage possible from a careless search, compromised account, insider misuse, incorrect plate match, or policy change.

This is a familiar engineering problem. Centralization makes a system more useful and more dangerous at the same time. The larger the dataset, the more tempting it becomes to reuse it for purposes that were not part of the original pitch.

"We only keep it for 30 days" sounds reassuring until you ask how many trips one vehicle makes in a month, how many users can query the record, whether query results can be exported, and what happens when another agency requests help.

What responsible guardrails would look like

A city does not have to choose between unlimited surveillance and abandoning every investigative tool. It can impose limits before signing a contract.

Delete scans that do not match a legitimate hot list as quickly as technically possible.
Require a specific case number and a documented legal purpose for every historical search.
Ban searches related to constitutionally protected activity, immigration enforcement, reproductive health care, or religious attendance unless a court order clearly authorizes them.
Restrict data sharing to named agencies and publish those relationships.
Use independent audits instead of relying only on vendor dashboards and internal reviews.
Notify the public before cameras are installed and require elected officials to renew approval regularly.
Publish accuracy data, misuse incidents, search counts, and measurable case outcomes.
Include contract terms that let the city obtain logs, enforce deletion, and leave the network without losing access to its own audit records.

EFF recommends strict retention limits and access controls, and argues that one of the strongest protections is to retain nothing when a passing vehicle does not match a hot list. That approach preserves the real-time alert while reducing the creation of a month-long movement database for everyone else.

What you can ask in your own city

You do not need to be a privacy lawyer to ask useful questions. Search your city council's agenda and procurement records for "Flock Safety," "ALPR," "license plate reader," or "LPR." If the cameras are already installed, ask for the written policy, contract, retention period, approved sharing partners, search audit logs, and any reports about false alerts or misuse.

Then ask the question that procurement documents often avoid: how many people had their movements recorded for every case the system helped solve?

A city may decide that carefully limited plate readers are worth using. But that decision should be public, measurable, and reversible. It should not begin with a camera quietly appearing on a pole and end with residents discovering that their daily movements became searchable.

The most powerful surveillance systems rarely look dramatic. Sometimes they look like a small black box at an intersection, waiting for your next ordinary drive.

References

Originally published at https://blog.jenuel.dev/blog/that-camera-is-building-a-searchable-map-of-your-life

Vibe Coders Aren't Taking Your Job. Developers Who Master AI Are Raising the Bar.

Jenuel Oras Ganawed — Fri, 17 Jul 2026 08:54:16 +0000

I understand why developers are nervous.

You spent years learning how software works. You fought through broken builds, confusing documentation, database migrations, production incidents, and bugs that disappeared whenever you opened the debugger. Then someone opens an AI tool, describes an app in plain English, and has a polished demo before lunch.

That can make even an experienced developer wonder: Did I spend years learning something that AI can now do in seconds?

I do not think you wasted those years. I also do not think software developers are about to disappear. But I do think the job is changing, and developers who refuse to learn AI may have a harder time than developers who learn to use it well.

AI lowered the cost of producing code. It did not lower the cost of understanding what that code will do in the real world.

The fear is real, but the evidence is more complicated

AI adoption among developers is no longer a small experiment. In Stack Overflow's 2025 Developer Survey, 84% of respondents said they were using or planning to use AI tools, and 51% of professional developers said they used them daily.

But the same survey tells a less dramatic story than the social media clips. More developers distrusted the accuracy of AI tools than trusted it: 46% versus 33%. Only 3% highly trusted the output. The most common frustration, reported by 66%, was code that was "almost right, but not quite." Most respondents also said vibe coding was not part of their professional workflow.

That gap matters. Generating code is becoming easy. Knowing whether the code is correct, secure, maintainable, and appropriate is still hard.

The productivity research is mixed too. GitHub reported that Copilot users completed a bounded coding task 55% faster in one controlled experiment. In a different study, METR found that experienced open-source developers working in repositories they knew well took 19% longer with early-2025 AI tools, even though they expected AI to make them faster.

Both results can be true. AI can be excellent at a clear task with a clear finish line. It can also create review overhead, wrong assumptions, and subtle mistakes inside a large system. The useful question is not, "Does AI make coding faster?" It is, "Which work becomes faster, under what conditions, and who can tell when the result is wrong?"

A demo is not the same as owning a system

Vibe coding is impressive. A person with little programming experience can describe an idea and turn it into a working prototype. That is good. More people can test ideas, automate small tasks, and build tools for themselves.

But a prototype that works once is different from software a company can depend on.

Production software has old data, strange users, changing requirements, permission rules, failed payments, network timeouts, race conditions, accessibility needs, security threats, audit requirements, and Friday-night incidents. Someone has to understand why the system failed. Someone has to decide whether a generated migration could delete customer data. Someone has to notice that an API call leaks private information or that a "quick fix" breaks an assumption three services away.

That is engineering. It is not typing syntax from memory. It is making decisions under uncertainty and accepting responsibility for the result.

A vibe coder can build something useful. A professional developer is expected to keep it useful when the happy path ends.

Employers will pay for judgment, not keystrokes

The old version of developer value was sometimes measured by output: how much code you wrote, how quickly you built a feature, or how many tickets you closed. AI makes that measurement even less useful. A machine can produce thousands of lines before a human finishes coffee. Those lines can still be wrong.

The valuable developer is increasingly the person who can:

turn a vague business problem into a precise technical plan;
give an AI assistant enough context to produce relevant work;
review generated code instead of trusting confident explanations;
design boundaries, data models, tests, and failure handling;
debug problems that span multiple files, services, and teams;
protect security, privacy, reliability, and maintainability;
know when the simplest solution is to write less code.

This is why software knowledge does not become worthless when AI gets better. It becomes the filter. If AI increases the amount of code produced, companies need people who can separate useful code from expensive mistakes.

Hiring signals already point toward AI fluency. Microsoft's 2024 Work Trend Index reported that 66% of surveyed leaders would not hire someone without AI skills, while 71% said they would prefer a less experienced candidate with AI skills over a more experienced candidate without them. That does not mean employers want prompt-only developers. It means AI literacy is becoming part of professional literacy.

The developer with the strongest position is not the person who rejects AI, and it is not the person who accepts everything AI generates. It is the developer who understands software and knows how to direct, question, test, and correct the machine.

What should developers learn now?

You do not need to chase every new model or subscribe to every coding tool. Pick one assistant and learn it deeply enough to understand where it helps and where it fails.

Use AI for real work, not only toy prompts

Ask it to explain an unfamiliar module, draft tests, propose a refactor, trace a bug, review a pull request, or compare architecture options. Give it the relevant constraints. Then verify the result yourself.

Keep your engineering fundamentals sharp

Learn data structures, networking, databases, security, testing, version control, observability, and system design. You may write less boilerplate by hand, but you still need the mental model. You cannot review an answer you do not understand.

Practice verification as a first-class skill

Run the tests. Read the diff. Check edge cases. Inspect logs. Measure performance. Threat-model sensitive changes. Ask the assistant what assumptions it made, then check those assumptions against the actual system.

Learn to provide context

Weak AI usage looks like, "Build me an app." Strong usage includes the existing architecture, coding conventions, constraints, acceptance criteria, examples, and commands that prove the work is complete. Better context does not replace judgment, but it reduces random output.

Build things you can explain

If AI helped you build a project, be ready to explain the data flow, tradeoffs, security decisions, test strategy, and failure modes. "The AI wrote it" is not ownership. Understanding it is.

There is still a difficult truth

I do not want to offer fake comfort. Some tasks will be automated. Some teams may hire fewer people for routine work. Entry-level developers may face a harder path if companies expect AI-assisted output without investing in mentorship. Nobody can honestly guarantee that every software role will survive unchanged.

Still, the larger employment picture is not simply "software jobs are ending." The U.S. Bureau of Labor Statistics continues to project strong growth for software development roles, while the World Economic Forum's 2025 Future of Jobs report lists software and application developers among the fastest-growing roles. The work is not vanishing. The definition of being ready for the work is moving.

We have seen this pattern before. Higher-level languages did not eliminate programming. Frameworks did not eliminate web developers. Cloud platforms did not eliminate infrastructure work. Each layer removed some manual effort and created new systems that still needed people who understood them.

AI is a bigger change, and it is moving faster. That is a reason to adapt, not a reason to surrender.

Your experience is not obsolete. It is your advantage.

If you have spent years debugging software, you have something a prompt cannot instantly create: a library of failure patterns in your head. You know that the obvious fix can hide a deeper problem. You have seen clean code fail because the requirement was wrong. You understand that users will do things nobody predicted.

Use that experience with AI.

Let the assistant handle boilerplate, search a codebase, draft tests, summarize documentation, and suggest options. Then bring the part that still matters most: taste, skepticism, context, empathy, and responsibility.

I do not know exactly what software development will look like in ten years. None of us do. But I believe developers will still have careers. We may write less code manually. We may supervise more agents. Our tools and titles may change. The need for people who can understand problems and own reliable solutions will remain.

Do not compete with AI at typing code. Become the developer who can make AI-generated work trustworthy.

References

Originally published at https://blog.jenuel.dev/blog/vibe-coders-arent-taking-your-job-developers-who-master-ai-are-raising-the-bar

China Is Not Banning AI. It May Be Closing the Door on Its Best Models.

Jenuel Oras Ganawed — Tue, 14 Jul 2026 01:38:52 +0000

The headline sounds dramatic: China is banning AI.

That is not what has happened. China has not outlawed artificial intelligence, shut down its model companies, or blocked every foreign developer from using Chinese models. The more accurate story is narrower, but it may matter a lot more to developers: Beijing is reportedly considering restrictions on overseas access to its most advanced AI models.

If those controls become policy, they could change one of the best things about the current AI market. Developers have been able to choose capable, inexpensive Chinese models when the big American providers are too costly, too restricted, or simply unnecessary for the job. That option may become less reliable.

What China is reportedly considering

Reuters reported on July 7 that Chinese authorities had met with major technology companies, including Alibaba, ByteDance, and Z.ai. The discussions covered possible limits on overseas access to advanced models, including models that have not yet been released.

The ideas under discussion reportedly include security reviews for advanced open models, domestic-only access for the most sensitive frontier models, and national-security penalties for leaking proprietary AI technology. Officials also discussed restrictions on who can fund Chinese AI startups.

None of this is a final ban. Reuters reported that the scope is still being debated, that the rules may apply only to future models, and that it is unclear whether they will be implemented at all.

That distinction matters. A proposal is not a policy, and a restriction on a small class of frontier models is not a ban on Chinese AI. The easy headline is wrong. The direction of travel, however, is hard to miss.

AI models are becoming strategic exports

For years, the technology fight between China and the United States focused mainly on hardware: GPUs, semiconductor equipment, manufacturing tools, and the materials used to make chips. The software itself often remained widely available.

That line is starting to disappear.

Both governments increasingly treat advanced AI models as strategic assets. The United States has considered controls on access to its most capable systems. China is now discussing its own version of the same idea. Model weights, training methods, and cybersecurity capabilities are being treated less like ordinary software and more like sensitive technology.

This is understandable from a national-security perspective. A powerful model can help discover software vulnerabilities, process intelligence, design autonomous systems, and automate research. Governments do not see those capabilities as neutral anymore.

But developers and smaller companies will pay for the resulting fragmentation.

Why Chinese models became attractive

Chinese models did not gain users in the United States and elsewhere because developers suddenly became interested in geopolitics. They gained users because they became good enough and much cheaper.

CNBC reported that Chinese models accounted for more than 30% of weekly tokens used by U.S. companies through OpenRouter after February 8, 2026, at one point reaching 46%. The average over the previous twelve months was 11%.

Cost is a major reason. OpenRouter told CNBC that open Chinese models can be 60% to 90% cheaper than leading models from Anthropic and OpenAI. Lindy reportedly moved all of its traffic from Claude to DeepSeek and expected to save millions of dollars. Z.ai's GLM 5.2 also saw rapid adoption through Vercel after its release.

That is a hard economic argument to ignore. Many application tasks do not need the most expensive frontier model. If a cheaper model can classify a ticket, summarize a document, call a tool, or generate a routine block of code reliably, routing the task to it is sensible engineering.

Chinese open-weight models also give teams more control. They can run the model through a provider they trust, deploy it on their own infrastructure, inspect its behavior, and avoid sending every request to a single closed API.

Can an open model really be banned?

Future releases can be restricted. Existing downloads are another matter.

Once model weights have been published and copied across repositories, mirrors, private servers, and developer machines, removing them from the internet is close to impossible. A government can stop a company from releasing a new model. It can limit official downloads, funding, support, or cloud access. It cannot make every existing copy vanish.

This is one reason a broad ban on open-weight models would be difficult in the United States too. CNBC quoted Brookings fellow Kyle Chan saying it is ultimately impossible to ban Chinese open-source models because their weights are already freely available online. Such a move could also run into free-speech questions and hurt American startups that rely on inexpensive models.

Procurement rules are more realistic. Governments can prohibit agencies and contractors from using certain models. They can require security reviews, disclose model origins, or warn companies about documented vulnerabilities. Those controls can shape enterprise adoption even when the software remains technically available.

The risk for developers is dependency

I do not think the lesson is to stop using Chinese models. The lesson is to stop assuming that any model, provider, or country will remain permanently available on today's terms.

If an application depends on one model's exact behavior, pricing, context window, or tool-calling format, a policy change can become a product outage. That is true whether the model comes from China, the United States, or anywhere else.

Teams building serious AI products should make model substitution part of the architecture:

Keep prompts and tool definitions portable where possible.
Test important workflows against more than one model family.
Track quality, latency, and cost instead of routing everything to a brand name.
Know where requests and data are processed.
Keep a fallback for restricted, retired, or suddenly expensive models.

This does not eliminate geopolitical risk, but it prevents one policy announcement from breaking the entire application.

This is not a ban, at least not yet

The current story is about discussions, not a completed prohibition. China may eventually restrict only unreleased frontier models. It may create a tiered review process. It may settle on narrower rules than the headlines suggest.

Still, the era when developers could assume that every strong model would spread globally by default may be ending. AI models are now part of trade policy, national security, and strategic competition.

For developers, that means model choice is no longer only a benchmark and pricing decision. Availability, jurisdiction, export rules, and portability now belong in the technical plan.

References

Originally published at https://blog.jenuel.dev/blog/china-not-banning-ai-may-restrict-best-models