DEV Community: Jenuel Oras Ganawed

When will Claude-level AI run on a normal PC? I searched the web, and the answer is not simple

Jenuel Oras Ganawed — Tue, 07 Jul 2026 23:57:05 +0000

I searched the net to find this out because I keep coming back to the same question: how many years will it take before a very good AI model can run on a mid-range computer and feel close to Claude, Codex, or the other big cloud models?

I have not tried this properly on my own end because I do not have that kind of powerful machine sitting around. And honestly, that is the point. Most developers do not have a workstation with 80GB of GPU memory. A lot of us have a decent laptop, maybe a mid-range desktop, maybe 16GB to 32GB of RAM, and if we are lucky, a GPU with 8GB to 16GB of VRAM.

So the question is not, "Can someone with a monster rig run a big model locally?" They already can.

The better question is this: when will a normal developer machine run a local model that is good enough that you stop reaching for Claude, Codex, ChatGPT, or a cloud coding agent for most everyday work?

After going through model releases, inference tools, quantization papers, hardware announcements, and benchmarks, my answer is this:

For useful local AI, we are already there.

For a strong local coding assistant, we are probably one to three years away for many developers.

For a local model that consistently feels like the best cloud models across long projects, messy repos, planning, debugging, tool use, and agentic coding, I would not bet on a mid-range machine doing that perfectly in the next year or two. A more realistic window is five to eight years, and even then the target will keep moving because the cloud models will improve too.

That sounds disappointing at first. But the details are more interesting than the headline.

The first thing I found: local AI is not a fantasy anymore

A few years ago, running a serious language model locally felt like a research hobby. Now the tooling is normal enough that non-researchers can do it.

llama.cpp made local inference practical by bringing LLM inference into efficient C and C++ code. Ollama made local model running feel more like installing a developer tool. LM Studio made it approachable for people who want a desktop app instead of a terminal workflow. Hugging Face now has dedicated GGUF support because the local model ecosystem became too big to ignore.

That matters. The future of local AI will not be decided only by model quality. It will be decided by the whole stack: model formats, quantization, inference engines, GPU drivers, memory management, and the boring UX that makes people actually use the thing.

The tooling already exists. The question is how good the models can get inside the memory and compute limits of normal machines.

Model size is still the wall

A mid-range machine can run small and medium models today. The problem is not whether it can run a model. The problem is whether the model is good enough.

Here is the rough memory math.

A model with 7 billion parameters at 16-bit precision needs around 14GB just for weights. At 4-bit quantization, it can drop to roughly 3.5GB to 5GB before overhead. That is why 7B and 8B models feel realistic on consumer machines.

A 32B model at 4-bit can land somewhere around 16GB to 24GB depending on format, context length, KV cache, and runtime overhead. That starts to push a mid-range machine, but it is not impossible if you have enough RAM, unified memory, or a decent GPU.

A 70B model at 4-bit can require around 35GB to 45GB or more once you include overhead and context. A 120B model can go much higher. At that point, you are no longer talking about the average developer laptop.

This is why the debate gets messy. People often say "local models are catching up," but they may be talking about a quantized 32B or 70B model on expensive hardware, not a normal computer.

Quantization is doing a lot of the heavy lifting

The strongest reason to be optimistic is quantization.

GPTQ showed that large transformer models could be compressed after training while preserving a lot of performance. AWQ pushed the idea further by protecting the most important weights during low-bit quantization. QLoRA showed that even fine-tuning huge models could become dramatically cheaper by working with 4-bit quantized models and adapters.

This is the quiet revolution behind local AI. You do not need the full original model precision for every use case. You can squeeze the model down and still keep enough intelligence for many tasks.

But there is a catch. Quantization is not magic. It can hurt reasoning, coding precision, long-context reliability, and instruction following if pushed too hard. A model may look fine in a quick chat and still fall apart when you ask it to refactor a messy codebase or reason through a multi-file bug.

That is why local models can feel impressive one minute and limited the next.

Small models are getting much better

The second reason to be optimistic is that small models are improving fast.

Meta's Llama releases pushed open models into the mainstream. Llama 3.1 brought a 405B open model, but the more relevant part for normal users is the ecosystem it created around smaller Llama models. Llama 3.2 specifically talked about edge and mobile devices, which is exactly the direction this question points toward.

Google's Gemma 3 focuses on developer-accessible open models with multimodal and multilingual support. Microsoft's Phi line has been interesting because it argues that small models can punch above their size when the data and training recipe are good. Mistral Small 3.1 is another example of the industry taking smaller, cheaper models seriously instead of treating them as toys.

Qwen is especially relevant for developers. Qwen3 and Qwen3-Coder show how strong open models are becoming, especially for coding and agentic workflows. DeepSeek also changed the conversation by making high-performance open models feel less like a side project and more like a serious alternative to closed labs.

This is probably the biggest shift: we may not need one giant local model to beat Claude at everything. We may need smaller specialized models that are very good at the specific work developers do.

Claude and Codex are not just models

This is where I think people underestimate the cloud systems.

When developers say they want a local model that performs like Claude or Codex, they usually mean more than raw benchmark scores. They mean:

It understands a large codebase.
It follows instructions without drifting.
It can use tools.
It can run tests, inspect files, and iterate.
It has a long enough context window.
It knows when to stop and when to ask.
It does not silently break things.

That is not just a model weight file. That is an entire product stack.

Claude 3.5 Sonnet was marketed around speed, intelligence, and strong coding performance. OpenAI's Codex work is not only about generating code. It is about an agentic workflow around repositories, tasks, tools, and verification. SWE-bench and SWE-bench Verified exist because "can it solve real software issues?" is much harder than "can it answer a coding prompt?"

A local model can be good at autocomplete or short coding tasks and still be far from a full cloud coding agent.

The bottleneck is shifting from weights to context

Model weights get most of the attention, but context is becoming just as important.

If I ask a model to explain a function, a local 8B or 14B model may do fine. If I ask it to understand a whole repo, reason across files, plan a migration, and keep constraints in mind for an hour, the problem changes.

Long context is expensive. The KV cache grows with sequence length and eats memory. That is why work like FlashAttention, PagedAttention, and better memory management matters. It is also why future local coding agents may use retrieval, repo maps, embeddings, summaries, and context compaction instead of trying to shove the whole project into the model window.

The future local coding assistant may not look like one huge model. It may look like a smaller model wrapped in a smarter system that knows which files to read, which tests to run, and what history to keep.

That is good news for mid-range computers. Systems can improve even when raw hardware is limited.

Hardware is improving, but not evenly

Copilot+ PCs are pushing NPUs into normal laptops. Apple Silicon has strong unified memory and frameworks like MLX. Consumer NVIDIA GPUs keep making local inference faster for people who own them. Local AI tools are learning how to split work across CPU, GPU, NPU, and unified memory.

But the average machine is still constrained.

The laptop NPU story is promising, but many NPUs are not yet the main place people run big open LLMs. GPU VRAM is still the practical limit for many setups. Unified memory helps, but speed can drop when the model spills beyond the fastest memory path.

So yes, hardware will help. But I do not think hardware alone gets us to local Claude-level agents on normal machines. The win will come from hardware plus smaller models, quantization, sparsity, better runtimes, better agent frameworks, and model specialization.

What people online seem to agree on

After reading through the material, I noticed a rough consensus.

People are not asking whether local AI will be useful. That argument is mostly over. Local AI is already useful for privacy, offline work, experimentation, and cheap inference.

The harder argument is whether local AI can match frontier cloud systems.

The optimistic side points to open-weight releases, quantization, better coding models, and local inference tools. They are right. Progress is real.

The skeptical side points to memory limits, long-context cost, tool use, post-training, proprietary data, and the fact that cloud labs can spend far more inference compute per answer. They are also right.

That is why my answer is not a clean yes or no.

Local models will absolutely get good enough for many developers. But "good enough" will arrive before "Claude-level at everything."

My timeline guess

Here is my practical timeline after searching through the topic.

Within one year, local models will keep getting better for autocomplete, simple code generation, summarization, offline chat, and private document work. A mid-range machine will feel more useful than people expect, especially with 7B to 14B models.

In one to three years, I think a lot of developers will be able to run local coding assistants that are genuinely helpful for daily tasks: explaining code, generating tests, making small refactors, writing scripts, drafting docs, and helping with debugging. Not perfect, but good enough to keep open all day.

In three to five years, local 20B to 40B class models may become the sweet spot for serious developer work on higher-end but still normal machines. If quantization and inference runtimes keep improving, these models could feel surprisingly close to older frontier systems for many tasks.

In five to eight years, I think it becomes realistic for a mid-range computer to run a local model-system that feels Claude-like for a lot of work. I say "model-system" intentionally. It may not be one giant model. It may be a smaller model with retrieval, tools, local code execution, memory, and task planning.

Will it match the best cloud model of that same year? Maybe not. The cloud target keeps moving.

But will it be good enough that many developers can do serious AI-assisted programming locally? Yes. I think that is very likely.

The best future is probably hybrid

The most realistic future is not fully local or fully cloud. It is hybrid.

Local models will handle private, fast, cheap, everyday tasks. Cloud models will handle the hardest reasoning, huge context, heavy agentic jobs, and tasks where paying for more compute makes sense.

That setup actually sounds healthy. You get privacy and control for normal work, but you can still call a frontier model when the problem is too big.

For developers, this may become the default workflow:

Local model for reading files, explaining code, small edits, offline notes, and private drafts.
Cloud model for big architecture decisions, difficult bugs, large migrations, and high-stakes agent work.
Tools around both, so the assistant can run tests and verify instead of just guessing.

That is the future I would bet on.

My honest answer

Is it possible to run a very good model locally in the future on a mid-range computer?

Yes.

Is it possible to run something useful today?

Also yes, depending on your expectations.

Will a normal PC soon run the same kind of model experience as Claude or Codex at their best?

Not soon in the full sense. The model may be smaller, the context shorter, the reasoning weaker, and the agent loop less reliable. But the gap is narrowing from both sides: local models are getting better, and the tooling around them is getting smarter.

The important part is that developers should not only watch the biggest model announcements. Watch the boring stuff too: quantization, GGUF, llama.cpp, Ollama, MLX, PagedAttention, small coding models, NPUs, memory bandwidth, and repo-aware agent systems.

That is where the local AI future is being built.

My guess: the first version that feels "good enough for most of my coding day" arrives before the version that truly feels like the best Claude or Codex replacement. And for many developers, that may be enough.

References I checked

llama.cpp, "LLM inference in C/C++." https://github.com/ggml-org/llama.cpp
Ollama Blog. https://ollama.com/blog
LM Studio, "Local AI on your computer." https://lmstudio.ai/
Hugging Face Docs, "Bitsandbytes quantization." https://huggingface.co/docs/transformers/quantization/bitsandbytes
Hugging Face Docs, "GGUF." https://huggingface.co/docs/hub/en/gguf
Apple MLX, "An array framework for Apple silicon." https://github.com/ml-explore/mlx
Microsoft, "Copilot+ PCs." https://www.microsoft.com/en-us/windows/copilot-plus-pcs
Meta AI, "Introducing Llama 3.1." https://ai.meta.com/blog/meta-llama-3-1/
Meta AI, "Llama 3.2: Revolutionizing edge AI and vision." https://ai.meta.com/blog/llama-3-2-connect-2024-vision-edge-mobile-devices/
Qwen, "Qwen3: Think Deeper, Act Faster." https://qwenlm.github.io/blog/qwen3/
Qwen, "Qwen3-Coder: Agentic Coding in the World." https://qwenlm.github.io/blog/qwen3-coder/
DeepSeek, "DeepSeek-R1 Release." https://api-docs.deepseek.com/news/news250120
DeepSeek, "Introducing DeepSeek-V3." https://api-docs.deepseek.com/news/news1226
Mistral AI, "Mistral Small 3.1." https://mistral.ai/news/mistral-small-3-1
Google Developers Blog, "Introducing Gemma 3." https://developers.googleblog.com/en/introducing-gemma3/
Frantar et al., "GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers." https://arxiv.org/abs/2210.17323
Lin et al., "AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration." https://arxiv.org/abs/2306.00978
Dettmers et al., "QLoRA: Efficient Finetuning of Quantized LLMs." https://arxiv.org/abs/2305.14314
Frantar and Alistarh, "SparseGPT: Massive Language Models Can Be Accurately Pruned in One-Shot." https://arxiv.org/abs/2301.00774
Dao et al., "FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness." https://arxiv.org/abs/2205.14135
Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention." https://arxiv.org/abs/2309.06180
Gu and Dao, "Mamba: Linear-Time Sequence Modeling with Selective State Spaces." https://arxiv.org/abs/2312.00752
Anthropic, "Introducing Claude 3.5 Sonnet." https://www.anthropic.com/news/claude-3-5-sonnet
OpenAI, "Introducing Codex." https://openai.com/index/introducing-codex/
OpenAI, "Introducing gpt-oss." https://openai.com/index/introducing-gpt-oss/
SWE-bench Leaderboards. https://www.swebench.com/
OpenAI, "Introducing SWE-bench Verified." https://openai.com/index/introducing-swe-bench-verified/
MLC LLM. https://llm.mlc.ai/

Originally published at https://blog.jenuel.dev/blog/when-will-claude-level-ai-run-on-a-normal-pc

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 crawlers are forcing a new internet economy

Jenuel Oras Ganawed — Tue, 07 Jul 2026 11:56:26 +0000

The old web had a simple bargain: websites let search engines crawl their pages, and search engines sent traffic back.

That bargain is breaking.

AI crawlers do not behave like traditional search crawlers. A search crawler indexes your page so someone can find it. An AI crawler may absorb the page, summarize it, train on it, answer from it, or let an agent act on it without sending the reader back to the original site. For a publisher, developer, blogger, forum owner, or small business, that changes the math completely.

If AI can consume the web without sending people back to the web, the internet needs a new economic model.

The old trade was content for traffic

For years, website owners tolerated crawlers because crawling usually meant visibility. Google indexed your page, the user searched, clicked, and landed on your site. You could earn through ads, subscriptions, leads, donations, affiliate links, product sales, or plain reputation.

It was never perfect, but at least the loop made sense:

You publish something useful.
A crawler indexes it.
Search sends people to you.
You get some value back.

AI weakens step three. If a chatbot answers the question directly, the user may never visit the source. If an AI overview summarizes ten pages into one answer, the original publishers carry the cost while the AI product captures the attention.

That is why AI crawling feels different from normal search. It is not just discovery. It can become substitution.

Cloudflare is putting a price tag on access

Cloudflare has been moving directly into this fight. In July 2025, it announced "pay per crawl," a feature meant to let content owners charge AI crawlers for access. The pitch is simple: site owners should be able to decide who gets in, what kind of bot they are, and whether access is free or paid.

Then in July 2026, Cloudflare expanded the idea with more granular controls. Instead of treating all AI bots as one category, site owners can separate crawlers by purpose: search, training, and agents. That distinction matters.

A search bot helps people find your page. A training bot may use your work to improve a model. An agent bot may visit your site on behalf of a user and perform a task. Those are not the same thing, and website owners are starting to demand different rules for each one.

This is the beginning of an access economy for the web.

Robots.txt was not built for this

The web already has a crawler control system: robots.txt. It is useful, but it is also old, voluntary, and too blunt for the AI era.

Robots.txt can say "crawl" or "do not crawl." It cannot easily say:

You may index this page for search, but not train on it.
You may summarize the article, but only with attribution.
You may crawl ten pages per day for free, then pay after that.
You may let a user-directed agent access this page, but not a bulk data scraper.
You may use the content for retrieval, but not model training.

Those differences used to sound like legal edge cases. Now they are product requirements.

A modern web economy needs crawler identity, permissions, pricing, audit logs, and enforcement. That is a much heavier system than the open web was designed to carry.

The winners and losers will not be obvious

Large publishers have leverage. They can negotiate licensing deals, block crawlers, sue, or partner directly with AI companies. Big platforms can create private data deals and API walls.

Small creators have a harder problem. Blocking AI crawlers may protect their work, but it can also make them invisible inside the tools people increasingly use to search, research, and make decisions. Letting crawlers in may bring exposure, but maybe no traffic and no payment.

That is the trap: creators may be forced to choose between being used and being ignored.

A fairer system would give them more options. Free access for search. Paid access for training. Limited access for agents. Clear attribution when content is used. Analytics that show when and how bots consume a site. The current web does not offer that cleanly yet, but the pressure is building.

AI agents make the issue even bigger

Training crawlers are only one part of the story. AI agents create a newer problem.

If an agent visits a travel site, compares prices, fills a form, books a ticket, and reports back to the user, who owns that interaction? The user asked for it. The agent performed it. The site provided the service. But the site may never show an ad, upsell a product, or build a direct relationship with the customer.

That is not a small change. Many websites are designed around human attention. Agents reduce attention into a background task.

This may push more businesses toward APIs, login walls, bot fees, and agent-specific terms. In other words, the web starts to look less like a public library and more like a network of toll roads.

Some people will hate that. I get it. The open web was built on linking, quoting, crawling, and remixing. But AI changes scale. A human reading your post is one thing. A model company scraping millions of posts to build a paid product is another.

The new bargain needs three things

If the web is going to survive this transition without turning into a giant paywall, the new bargain needs to be practical.

First, crawlers need clear identities. Site owners should know whether a bot is crawling for search, model training, retrieval, or user-directed agent activity.

Second, permissions need to be more specific. "Allow" and "block" are too limited. A publisher may want search visibility but reject training. A store may welcome shopping agents but reject bulk scraping. A forum may allow summaries but require links back to original discussions.

Third, money needs to move. Not for every page view and not for every tiny blog post, but for systematic commercial use. If AI products create value from the web, some of that value should return to the people and organizations maintaining the web.

That could happen through direct licensing, pay-per-crawl systems, revenue sharing, attribution standards, or new marketplaces for high-quality data access. The exact model is still unsettled. But the direction is clear: crawling is no longer just a technical issue. It is an economic negotiation.

What website owners should do now

If you run a site, this is a good time to review your crawler policy.

Check your robots.txt file. Look at your server logs. Find out which AI crawlers are visiting. Decide whether you want to allow search crawlers, training crawlers, and agent crawlers under the same rules or separate rules.

If your content is core to your business, do not wait until the traffic drop becomes obvious. Start tracking referrals from search and AI products. Build direct channels with your audience: email lists, communities, apps, RSS, memberships, or anything that does not depend entirely on search platforms.

The sites that survive this shift will not be the ones that simply block everything. They will be the ones that know what their content is worth and set terms accordingly.

The internet is renegotiating itself

AI crawlers are forcing a question the web avoided for a long time: who gets paid when information becomes infrastructure?

For decades, websites fed search engines because search engines sent people back. Now AI systems can turn that same content into answers, actions, and products. That may be useful for users, but it breaks the old incentive loop for creators.

The next version of the internet will probably include more gates, more bot controls, more licensing deals, and more arguments over what counts as fair use. It may also create better ways for independent creators to charge for access without disappearing from discovery.

Either way, the free crawl era is ending. The web is becoming a marketplace, and AI crawlers are the reason everyone is suddenly checking the price of the front door.

Sources

Cloudflare Blog, "Introducing pay per crawl: Enabling content owners to charge AI crawlers for access," July 1, 2025. https://blog.cloudflare.com/introducing-pay-per-crawl/
The Decoder, "Cloudflare replaces its blanket AI bot block with granular controls for search, training, and agent crawlers," July 6, 2026. https://the-decoder.com/cloudflare-replaces-its-blanket-ai-bot-block-with-granular-controls-for-search-training-and-agent-crawlers/

Originally published at https://blog.jenuel.dev/blog/ai-crawlers-new-internet-economy

Claude Fable 5 Feels Different. But Should Developers Trust It?

Jenuel Oras Ganawed — Thu, 02 Jul 2026 21:54:35 +0000

I tried Claude Fable and had that uncomfortable developer feeling: this is not just a slightly better autocomplete. It feels more patient. It plans farther ahead. It keeps working when older models would start getting lost.

But the internet is doing what the internet always does with a new AI model: one side calls it magic, the other side calls it hype. The truth is more useful than both. Claude Fable 5 looks genuinely stronger for long, messy coding and knowledge work, but it is not automatically the best choice for every task.

The short answer

Yes, Claude Fable 5 appears to be better for the kind of work that drains normal models: multi-step coding, long context research, big refactors, planning, and agentic workflows. Anthropic describes it as a Mythos-class model made safe for general use, with Fable sharing the same underlying capabilities as Mythos but adding safety classifiers and fallback behavior.

That last part matters. Fable is not simply "the unlocked best model." It is the public version of a more restricted frontier system. If a request hits certain cybersecurity, biology, chemistry, or distillation risk areas, Anthropic can route the response to Claude Opus 4.8 instead. Anthropic says more than 95% of Fable sessions avoid fallback, but developers still need to design around refusals and model switching.

Why it feels better in real use

The difference people keep describing is not only benchmark score. It is endurance.

Older coding models often feel brilliant for the first 20 minutes, then slowly lose the plot. Fable's pitch is different: give it a large goal, let it plan, let it test its own work, and let it continue across a longer session. Anthropic says it can tackle days-long, complex, asynchronous tasks that previous models could not sustain.

That lines up with the early outside reactions. Ethan Mollick wrote after early access that Fable represented "a very real leap" over public models he had used, especially on projects where the model worked for hours from multi-page specifications. Andrej Karpathy's X post was even more direct: he called it a "major-version-bump-deserving step change forward," especially for long problem-solving sessions.

"The model gets it and it will just go." That line from Karpathy captures why Fable is getting attention. The scary part is the next sentence: it has never felt more tempting to stop looking at the code. Do not do that.

Read Karpathy's post on X

Benchmarks and outside tests: impressive, but read them carefully

Anthropic says Fable 5 is state of the art across coding, knowledge work, vision, scientific research, and computer use. The official material emphasizes that Fable's lead grows as tasks become longer and more complex. It also lists a 1 million token context window by default, up to 128k output tokens per request, and API pricing of $10 per million input tokens and $50 per million output tokens.

Those numbers are strong, but benchmarks do not always match daily developer work. CodeRabbit's hands-on review is useful because it is more mixed. In its 105-EP code review benchmark, Fable 5 found roughly the same amount of actionable review coverage as its baseline and Opus 4.8, but with weaker precision and more comments. It passed 65 of 105 actionable EPs, while the baseline and Opus 4.8 hit 66. Fable had 32.8% actionable precision, compared with 35.5% for Opus 4.8.

Signal	What it suggests	What to watch
Anthropic launch notes	Fable is the strongest public Claude model and best suited to hard long-horizon work.	Official launch claims are not the same as your production workload.
1M context / 128k output	It can hold much larger projects and produce larger deliverables.	More context can also mean higher cost and slower runs.
CodeRabbit review test	Good coverage in code review, but not a clean win on precision.	Noisy review comments can create more work for humans.
Developer reactions on X	People notice a qualitative jump in planning and autonomy.	Many posts are vibes, not controlled evals.

The most honest comparison: Fable versus faster models

Fable is not always the model I would pick first.

If I need a quick answer, a small code change, a translation, or a cheap summarization job, I would not burn Fable tokens. A faster model is probably enough. If I need a serious plan, a migration strategy, a large feature implementation, a research memo, or a coding agent that can keep context across a long session, Fable becomes interesting.

Nathan Flurry's X take is a practical one: he described using Claude Fable for planning, research, and reviews, then using a faster coding model for implementation. He also admitted the evaluation was mostly vibes. That is the right level of honesty. Fable may be best as the senior planner and reviewer, not the cheapest hammer for every nail.

One useful pattern: let Fable write the plan, clarify the architecture, and review the result. Let cheaper or faster models handle narrower implementation loops when the spec is already clear.

Read Nathan Flurry's post on X

What I would use Claude Fable for

Large refactors where the model must understand the whole project before touching code.
Planning a feature across backend, frontend, tests, and docs.
Codebase archaeology: "find where this behavior comes from and explain the safest fix."
Long research tasks that need synthesis, not just search results.
Agent workflows where the model can run tests, inspect failures, and revise its own plan.

Where I would avoid it

Simple edits where Sonnet, Opus, GPT, Gemini, or a local model is already good enough.
High-volume automations where cost matters more than deep reasoning.
Blind code review pipelines where extra comments become noise.
Security-sensitive workflows unless you understand Anthropic's fallback behavior and data retention rules.

So, is it really better?

For long, ambitious work, yes. That is the fairest read from the official docs, early reviews, and developer reactions. Fable seems less like a chat model upgrade and more like a better engine for AI agents.

But "better" does not mean "always use it." Fable is expensive, heavier, and guarded in ways that can affect integrations. The best developer setup may not be Fable alone. It may be Fable as the brain for planning and review, with faster models doing the smaller loops underneath.

My take: if your work feels like a project, try Fable. If your work feels like a task, use something cheaper first.

References

Originally published at https://blog.jenuel.dev/blog/claude-fable-5-feels-different-developer-review

Ornith 1.0: The Open-Source Coding Model Developers Should Watch Closely

Jenuel Oras Ganawed — Sun, 28 Jun 2026 13:44:39 +0000

A new coding model is easy to ignore now. Every week someone claims a new benchmark score, a new agent, a new workflow, a new reason developers should change everything. Most of it fades by Monday.

Ornith 1.0 is worth a slower look.

DeepReinforce released Ornith 1.0 as an open-source family of models built specifically for agentic coding. That phrase matters. This is not only a chat model that can write a function when you ask politely. It is aimed at the messier part of software work: searching through a repo, using tools, trying a patch, reading failures, adjusting the plan, and doing that loop again.

If the reported numbers hold up in real-world use, Ornith 1.0 could become one of the more important open model releases for developers this year. Not because it magically replaces programmers. It does not. The interesting part is that it pushes strong coding-agent behavior into a model family that can be studied, hosted, modified, and run outside a closed API.

What is Ornith 1.0?

Ornith 1.0 is a family of open-source large language models from DeepReinforce AI focused on agentic coding. The official release lists several sizes: 9B Dense, 31B Dense, 35B MoE, and 397B MoE. The models are post-trained on top of Gemma 4 and Qwen 3.5 foundations, and the project is published under the MIT license.

The 9B model is the approachable one for local experiments. The 35B and 397B variants are more serious serving targets for teams with stronger hardware. The project also publishes GGUF and FP8 variants, which matters because developers do not all have the same machines. A model that only works inside a giant lab is interesting. A model with smaller and quantized paths is useful.

The official docs say Ornith supports an OpenAI-compatible interface and a 256K token context window when served with modern runtimes. For developers, that means the model can fit into existing tools more easily: coding agents, VS Code extensions, local inference servers, and scripts that already speak the OpenAI API format.

The part that makes it different: self-scaffolding

The phrase DeepReinforce uses is "self-scaffolding." In normal agent setups, humans design the harness: how the model calls tools, what steps it should try, how it should recover from failure, and how it should structure its work. Ornith 1.0 tries to learn parts of that scaffold during reinforcement learning.

In plain English: the model is trained not only to produce the answer, but also to improve the process it uses to get there.

That is a big deal for coding. Real programming is rarely one-shot. You inspect the repo, make a change, run tests, hit an error, read the stack trace, narrow the problem, and patch again. A model that can learn better search and repair patterns is more valuable than a model that only produces a pretty code block in chat.

There is a catch. If a model learns to build its own scaffolds, it may also learn tricks that satisfy a verifier without really solving the task. TestingCatalog notes that DeepReinforce describes safeguards around this, including an outer trust boundary, a deterministic monitor, and a frozen LLM judge. That is good to see, but teams should still treat benchmark claims as a starting point, not a safety guarantee.

The benchmark story

According to DeepReinforce's published results, Ornith 1.0 performs strongly on agentic coding benchmarks. The headline number is the 397B model: 77.5 on Terminal-Bench 2.1 and 82.4 on SWE-Bench Verified. The same release compares that result against Claude Opus 4.7 at 70.3 on Terminal-Bench 2.1 and 80.8 on SWE-Bench Verified.

The smaller models are also interesting. Ornith 1.0 9B is reported at 43.1 on Terminal-Bench 2.1 and 69.4 on SWE-Bench Verified. That is the number I keep coming back to, because a useful smaller coding model changes who can experiment. Students, solo developers, startups, and privacy-conscious teams can test local agent workflows without sending every file to a hosted model.

Ornith 1.0 397B benchmark results. Source: DeepReinforce GitHub.

Ornith 1.0 35B benchmark results. Source: DeepReinforce GitHub.

Ornith 1.0 9B benchmark results. Source: DeepReinforce GitHub.

Quick benchmark summary

Model	Terminal-Bench 2.1	SWE-Bench Verified	Why it matters
Ornith 1.0 397B	77.5	82.4	Flagship open model aimed at frontier agentic coding.
Ornith 1.0 35B	64.2	75.6	Stronger team/self-hosted option without jumping to the largest model.
Ornith 1.0 9B	43.1	69.4	Most practical entry point for local testing and privacy-first experiments.

One honest note: these are vendor-published benchmark results. They are still useful, especially because the repo publishes detailed harness notes, but developers should test Ornith on their own repositories before making workflow decisions.

Why this could be a big changer

The open-source AI coding race has been moving from autocomplete to agents. That shift changes the question. Developers no longer ask only, "Can it write code?" They ask, "Can it work inside my project without breaking everything?"

Ornith 1.0 matters because it attacks that second question.

It is open enough to inspect and host. Closed coding agents can be powerful, but they create trust and data questions. An MIT-licensed model family gives teams more control.
It is built for tool-using coding loops. Benchmarks like Terminal-Bench and SWE-Bench are closer to real developer work than simple prompt-answer tests.
It has practical model sizes. 397B is for serious infrastructure. 9B and GGUF variants are for people who want to experiment locally.
It can plug into existing tools. OpenAI-compatible serving makes it easier to connect Ornith to VS Code extensions, OpenHands, custom scripts, and local agent frameworks.

The deeper shift is cultural. If models like Ornith keep improving, teams may start treating local or self-hosted coding agents as normal infrastructure, the same way they treat CI, linters, and internal dev tools.

Where Ornith 1.0 is useful

I would not use Ornith as a blind autopilot. I would use it as a repo-aware assistant that works under human review.

Bug fixing: give the agent a failing test, let it inspect the codebase, propose a patch, and rerun tests.
Refactoring: ask it to update repeated patterns across a project, then review the diff like you would review a junior developer's PR.
Test generation: use it to create coverage around brittle code before a larger change.
Offline or private coding: run a smaller checkpoint locally when the repository cannot leave your machine.
Agent research: study how self-scaffolding changes tool use, failure recovery, and long-context repo work.

Which model should you choose?

Use case	Recommended variant	Reason
Local experimentation	Ornith 1.0 9B GGUF	Easiest path for consumer machines and local tools.
Single powerful GPU server	Ornith 1.0 9B bf16 or quantized 35B	Good for private coding assistants and internal testing.
Team coding agent server	Ornith 1.0 35B or 35B FP8	Better performance while staying far below the flagship size.
Benchmark chasing or frontier experiments	Ornith 1.0 397B / 397B FP8	Best published results, but requires serious multi-GPU infrastructure.

My recommendation: start with 9B GGUF if you are learning, 35B if you have the hardware, and treat 397B as a hosted or lab-grade option unless your team already runs large MoE models.

How to use Ornith 1.0 on Windows

The simplest Windows path is Ollama or LM Studio with a GGUF checkpoint. If you have an NVIDIA GPU and prefer a Linux-like serving stack, use WSL2 and run vLLM from Ubuntu inside WSL.

# Option A: Windows + Ollama or LM Studio
# 1. Install Ollama or LM Studio.
# 2. Download a GGUF variant from Hugging Face, such as Ornith-1.0-9B-GGUF.
# 3. Start a local OpenAI-compatible server.
# 4. Point your coding tool to http://localhost:11434/v1 or the port your app exposes.

For WSL2 with vLLM:

# Inside Ubuntu on WSL2
python -m venv .venv
source .venv/bin/activate
pip install -U vllm
MODEL=deepreinforce-ai/Ornith-1.0-9B
vllm serve $MODEL \
  --served-model-name Ornith-1.0 \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 262144 \
  --enable-prefix-caching \
  --enable-auto-tool-choice --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3 \
  --trust-remote-code

Then test it:

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Ornith-1.0",
    "messages": [{"role": "user", "content": "Write a short Python is_prime function."}],
    "temperature": 0.6
  }'

How to use Ornith 1.0 on Linux

Linux is the cleanest path for vLLM or SGLang. Make sure your NVIDIA drivers, CUDA stack, and Python environment are ready first.

python -m venv ornith-env
source ornith-env/bin/activate
pip install -U vllm

MODEL=deepreinforce-ai/Ornith-1.0-9B
vllm serve $MODEL \
  --served-model-name Ornith-1.0 \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 262144 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --enable-auto-tool-choice --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3 \
  --trust-remote-code

For 35B or 397B, use tensor parallelism and match the number to your GPU count:

MODEL=deepreinforce-ai/Ornith-1.0-35B-FP8
vllm serve $MODEL \
  --served-model-name Ornith-1.0 \
  --tensor-parallel-size 4 \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 262144 \
  --enable-prefix-caching \
  --enable-auto-tool-choice --tool-call-parser qwen3_xml \
  --reasoning-parser qwen3 \
  --trust-remote-code

How to use Ornith 1.0 on macOS

On a Mac, start with GGUF. Apple Silicon machines are good local LLM boxes, but the 35B and 397B models are not casual laptop workloads. Try the 9B GGUF first.

# Option A: LM Studio
# 1. Install LM Studio for macOS.
# 2. Search for or download the Ornith-1.0-9B-GGUF checkpoint.
# 3. Start the local server from LM Studio.
# 4. Use the local OpenAI-compatible endpoint in your editor or agent.

If you use llama.cpp directly:

# Build llama.cpp, download a GGUF file, then serve it
./llama-server \
  -m /path/to/Ornith-1.0-9B.gguf \
  --host 0.0.0.0 --port 8000 \
  -c 32768

I would not begin with the largest context window on a laptop. Start smaller, confirm speed and memory, then increase context only if you need it.

How to use Ornith 1.0 in VS Code

The easiest VS Code setup is to run Ornith behind an OpenAI-compatible local server, then connect it through an extension such as Continue or another tool that lets you define a custom OpenAI-compatible endpoint.

Start Ornith with vLLM, SGLang, LM Studio, Ollama, or llama.cpp server.
Confirm the endpoint works at http://localhost:8000/v1 or your local server URL.
Install a VS Code AI extension that supports custom OpenAI-compatible providers.
Add a model entry with the model name Ornith-1.0.
Use it first for small tasks: explain a file, write tests, fix one failing function, or review a diff.

A typical Continue-style configuration looks like this:

{
  "models": [
    {
      "title": "Ornith 1.0 Local",
      "provider": "openai",
      "model": "Ornith-1.0",
      "apiBase": "http://localhost:8000/v1",
      "apiKey": "not-needed-for-local"
    }
  ]
}

Do not start by asking it to rewrite your entire application. That is how people get huge diffs they cannot review. Start with one failing test, one file, or one small refactor. Let it earn trust.

Practical guardrails before you use it on real code

Use git and commit before asking any agent to modify files.
Run tests after every patch.
Review the diff line by line.
Keep secrets out of prompts unless the model is fully local and your logs are private.
Prefer tasks with objective feedback: tests, type checks, lint, build output.
Do not let any coding agent auto-merge changes without human review.

My recommendation

Developers should test Ornith 1.0, but they should test it like engineers, not fans.

If you are a solo developer, try the 9B GGUF model locally through LM Studio, Ollama, or llama.cpp. Use it for test writing, bug hunting, and small refactors. If you are a team, set up a private vLLM or SGLang endpoint and compare it against your current assistant on your own repositories. The benchmark chart is interesting, but your codebase is the benchmark that matters.

If Ornith's self-scaffolding approach keeps improving, the next wave of AI coding may not be about who has the nicest autocomplete. It may be about who can build the most reliable software agent loop while keeping developers in control.

That is why Ornith 1.0 is worth watching. It points toward a future where powerful coding agents are not only rented from closed platforms. They can be hosted, inspected, adapted, and used on your own terms.

References

Originally published at https://blog.jenuel.dev/blog/ornith-1-open-source-agentic-coding-model

Stop Feeding Your AI Agent the Whole Repo: Build a Project Brain That Retrieves What It Needs

Jenuel Oras Ganawed — Fri, 26 Jun 2026 06:27:31 +0000

Published June 26, 2026.

A lot of developers are using AI agents now, but many are still managing them like a giant chat box: paste everything, hope the agent understands the project, then watch it repeatedly read random files because it does not know where the real knowledge lives.

That is not a smart agent workflow. That is an expensive guessing loop.

The better pattern is to give your AI agent a project brain: a small, reliable knowledge system that tells the agent what the project is, how to work in it, and where to retrieve the exact docs, files, commands, and decisions needed for the current task.

The goal is not to put the entire repository into the model context. The goal is to make the agent pull the right context at the right time.

The problem: more context is not always better

Anthropic describes context as a finite resource. Their context engineering guidance explains that agent work is no longer only about writing a good prompt; it is about curating the whole state available to the model: instructions, tools, MCP servers, external data, history, and retrieved documents. They also warn about context degradation as context grows, where models can lose focus or fail to use information correctly.

This is exactly what happens in coding agents. If the agent has no project brain, it tries to discover everything from scratch:

It reads file after file.
It opens package files repeatedly.
It forgets architecture decisions from the previous session.
It uses generic framework advice instead of your project conventions.
It modifies code before understanding how the project is tested or deployed.

A good AI-agent setup should answer these questions before work begins:

What is this project?
What are the most important directories?
How do I run, test, lint, build, and deploy it?
What conventions must I follow?
Where are the deeper docs?
How do I retrieve only the files relevant to this task?
What should never be touched without permission?

The project brain pattern

I like to split the agent brain into five layers:

Core identity: a short project overview, product purpose, tech stack, and safety boundaries.
Operating instructions: commands, test rules, code style, PR rules, and common workflows.
Knowledge index: a map of docs, architecture notes, API contracts, database schemas, and decision records.
Retrieval system: search, embeddings, BM25, repo maps, MCP tools, or a local RAG service that fetches relevant chunks on demand.
Feedback memory: corrections and lessons learned after the agent makes mistakes, kept short and maintained like documentation.

Think of it like onboarding a new developer. You would not throw the entire repository at them and say, “Read everything.” You would give them a README, architecture guide, test commands, key docs, and a way to search for what they need.

What belongs in always-loaded context?

Keep always-loaded instructions small. Put only the high-signal details the agent needs on almost every task:

Project purpose and current app/product boundaries.
Tech stack and package manager.
Commands for install, dev, test, lint, typecheck, and build.
Critical directories and what they contain.
Non-negotiable rules: security, migrations, generated files, secrets, deployment rules.
How to find deeper docs.

Do not put large API references, entire schemas, old discussions, or full architecture docs directly in the top-level instruction file. Link to them. Make them retrievable.

What belongs in retrieval?

Retrieval is for information that might be important but is not needed on every turn:

Long architecture documents.
Database schema details.
API endpoint references.
Feature specs.
Error catalogs.
Design-system docs.
Historical decisions.
Examples of similar implementations.

Anthropic’s contextual retrieval article explains the classic RAG flow: chunk documents, embed chunks, store them in a vector database, retrieve the most relevant chunks at runtime, and add those chunks to the model prompt. It also highlights a common improvement: combine semantic embeddings with lexical search such as BM25, especially for exact identifiers and technical terms.

Codex: use AGENTS.md as the front door

For OpenAI Codex, the first solution is AGENTS.md. OpenAI’s Codex documentation says Codex reads AGENTS.md before doing work, and it supports layered guidance: global instructions in the Codex home directory, project instructions from the repository root, and nested instructions closer to the current directory. The docs also mention a default project instruction size limit of 32 KiB, which is a healthy reminder: this file should be concise.

A practical AGENTS.md should include:

# AGENTS.md

## Project overview
This is a SaaS app for ...

## Commands
- Install: pnpm install
- Dev: pnpm dev
- Test: pnpm test
- Lint: pnpm lint
- Typecheck: pnpm typecheck

## Directory map
- apps/web: frontend
- apps/api: backend
- packages/db: database schema and queries
- docs/architecture: deeper architecture notes

## Retrieval rules
- Start with docs/ai/index.md before broad file search.
- Search exact symbols with ripgrep before opening many files.
- Read only files related to the current task unless the task requires broader discovery.

## Safety
- Do not modify migrations or production config without explicit approval.

Then create a deeper index:

docs/ai/index.md
- Product overview: docs/product/overview.md
- Architecture: docs/architecture/system.md
- Database: docs/database/schema.md
- API routes: docs/api/routes.md
- Testing: docs/testing.md
- Deployment: docs/deployment.md

This gives Codex a map, not a mountain.

Claude Code: use CLAUDE.md, rules, imports, and MCP

Claude Code’s docs explain that Claude remembers projects through CLAUDE.md files and auto memory. CLAUDE.md is for persistent instructions you write; auto memory is for notes Claude accumulates from corrections and preferences. The docs recommend adding information when Claude makes the same mistake twice, when a code review catches something it should have known, or when a teammate would need the same context to be productive.

Claude Code can also import additional files using @ references. That means your CLAUDE.md can stay short while pointing to deeper docs:

# CLAUDE.md

## Project instructions
Read this first: @docs/ai/index.md

## Required workflow
- Before editing, identify the smallest relevant file set.
- Prefer docs and symbol search before broad repository scans.
- Run the tests listed in @docs/testing.md for changed areas.

## Private local notes
Personal machine setup may live in CLAUDE.local.md and should not be committed.

Claude Code also supports MCP, which is important because the best project brain is often not a static file. MCP can connect the agent to issue trackers, databases, design tools, documentation systems, search tools, or a custom codebase retriever.

Codex + Claude Code together: make one source of truth

If you use both Codex and Claude Code, do not maintain two separate brains that drift apart. Use a shared source of truth and thin wrappers for each agent.

Recommended structure:

AGENTS.md
CLAUDE.md
docs/ai/index.md
docs/ai/project-overview.md
docs/ai/commands.md
docs/ai/architecture-map.md
docs/ai/testing.md
docs/ai/retrieval-rules.md
docs/ai/known-pitfalls.md

AGENTS.md should summarize and point Codex to docs/ai/index.md. CLAUDE.md should summarize and import the same docs where supported. The canonical knowledge lives in docs/ai/.

This prevents the common problem where Codex follows one workflow, Claude Code follows another workflow, and the developer has to clean up the confusion.

Ollama and local coding agents: use local RAG carefully

For local agents using Ollama, Continue-style setups, Open WebUI, Aider, or custom scripts, retrieval matters even more because local models often have smaller context windows and weaker long-context behavior.

Open WebUI’s RAG documentation specifically warns that Ollama may default to a 2048-token context length, which can severely limit RAG performance. Their docs recommend increasing context length for Ollama models when using web or document retrieval.

A good local setup looks like this:

Run a capable local model through Ollama.
Create a local document/code index using embeddings plus keyword search.
Chunk code by symbols, classes, functions, markdown sections, and config files—not random fixed-size text only.
Store metadata: file path, symbol name, package/module, last modified date, and doc type.
Retrieve top results with hybrid search: embeddings + BM25 or exact match.
Optionally rerank results before adding them to context.
Keep the final context budget strict: only include what the task needs.

For codebases, retrieval should prioritize exact symbols, file paths, imports, package names, and error messages. Pure vector search can miss exact technical identifiers. Hybrid retrieval is usually better.

Aider and repo maps: another useful pattern

Aider’s repository map is a great example of not feeding the full repo to the model. Aider builds a concise map of important classes, functions, types, and call signatures across the repository. Its docs explain that the map helps the model understand how code relates across the codebase, and that for large repositories Aider selects the most relevant portions to fit the active token budget.

This is the right idea: give the agent a compressed map first, then let it request specific files when needed.

Any local AI agent: the minimum brain I recommend

If you are building or configuring any coding agent, start with this minimum setup:

docs/ai/index.md
AGENTS.md or CLAUDE.md or equivalent agent instructions
scripts/ai/context-search.sh or an MCP search server
README.md kept human-friendly
docs/architecture/system.md
docs/testing.md
docs/deployment.md
docs/decisions/

Your docs/ai/index.md should be boring and direct:

# AI Project Index

## Start here
- Project overview: ./project-overview.md
- Current architecture: ../architecture/system.md
- Commands: ./commands.md
- Testing: ../testing.md

## Search strategy
1. Search docs first.
2. Search exact symbol names with ripgrep.
3. Open the smallest relevant files.
4. Only broaden search if tests or references prove more context is needed.

## Do not read everything
Avoid full-repo scans unless the task is explicitly architectural or migration-related.

The agent workflow I want more teams to use

When assigning a task to an AI coding agent, tell it to follow this loop:

Classify the task. Is it bug fix, feature, refactor, test, documentation, deployment, or research?
Load the small brain. Read the top-level instruction file and docs/ai/index.md.
Retrieve targeted context. Use docs, symbol search, repo map, or MCP retrieval.
State the file plan. Name the files it believes are relevant.
Edit minimally. Change only what the task requires.
Verify. Run the correct tests, lint, typecheck, or build.
Update the brain. If the agent learned a durable project rule, add it to the right doc.

The last step is important. Your project brain should improve over time. If the agent repeatedly makes the same mistake, do not keep correcting it in chat. Put the lesson into AGENTS.md, CLAUDE.md, or the relevant project doc.

How to know your agent brain is working

You know your setup is improving when:

The agent stops reading the same setup files every session.
It can explain the project structure before editing.
It asks for or retrieves specific files instead of scanning randomly.
It runs the correct tests without being reminded.
It follows project conventions from the first attempt.
It cites docs or code paths when making architectural claims.
New teammates can use the same docs to become productive faster.

Common mistakes

Putting too much in AGENTS.md or CLAUDE.md. These should be maps and rules, not giant manuals.
Only using embeddings. Code retrieval needs exact search too.
Not maintaining docs. Stale instructions are worse than missing instructions.
Letting each agent have a separate truth. Codex, Claude Code, and local agents should point to the same canonical docs.
No verification loop. A knowledgeable agent still needs tests.
No boundaries. Tell agents what not to edit without approval.

Final recommendation

Do not try to make your AI agent smart by stuffing the entire project into context. Make it smart by giving it a project brain:

A small always-loaded instruction file.
A clear documentation index.
A retrieval layer for deep knowledge.
A repo map or symbol search for code understanding.
MCP tools for live external systems.
A habit of updating durable knowledge when the agent learns something important.

The best AI coding agents are not the ones with the biggest prompt. They are the ones with the best access to the right knowledge at the right time.

References

Originally published at https://blog.jenuel.dev/blog/build-ai-agent-project-brain-without-overloading-context

Claude Is Powerful, but Outages and Limits Are Part of the Deal

Jenuel Oras Ganawed — Tue, 23 Jun 2026 14:25:06 +0000

Claude is one of the AI tools I like using, but days like this are a reminder: even the best AI workflow can break at the worst time.

If you use Claude heavily, you already know the first pain point. The limit can drain fast. You are deep in a coding session, debugging something, asking follow-up questions, refining files, and suddenly the tool starts feeling expensive in a different way. Not just money. Attention. Momentum. Waiting.

Then comes the second pain point: server-side issues.

The screenshot says it plainly: API Error: 500 Internal server error. That is not a prompt problem. That is not your code. That is not you asking the wrong question. A 500 error usually means the server failed somewhere on the provider side.

Today it was not just a local error

I checked Anthropic's Claude status page, and the service was reporting a Partial System Outage. The unresolved incident was called Elevated error rate across multiple models, with affected components including claude.ai, Claude Console, Claude API, Claude Code, and Claude Cowork.

That matters because many developers now build their working rhythm around AI tools. We do not just use them for random questions anymore. We use them to read code, plan changes, review errors, write tests, and keep context while we move fast.

So when Claude goes down, it is not just a website being unavailable. It can interrupt a whole development loop.

The limit problem and the outage problem feel connected

They are different technical issues, but as a user they hit the same place: flow.

When the limit drains fast, you start rationing your questions. When the server throws 500 errors, you start wondering whether to retry, wait, switch models, or stop working for a while. Either way, the tool moves from being invisible support to something you have to manage.

That is frustrating because AI tools are supposed to reduce friction. But if your whole workflow depends on one provider, the provider becomes a single point of failure.

AI tools need backup plans

I am not saying stop using Claude. I still think Claude is excellent, especially for writing, code reasoning, and careful explanations. But I do think developers need a more honest relationship with these tools.

Do not let one AI model become your entire workflow.

Keep your local tools sharp. Keep notes. Keep tests. Keep commits small. Use another model when needed. Save important context outside the chat. If you are using Claude Code or the API for serious work, check the status page before assuming your setup is broken.

Sometimes the correct fix is not changing your prompt. It is waiting for the service to recover.

The uncomfortable truth

AI makes developers faster, but it also adds a new kind of dependency.

Before, your blockers were usually your machine, your internet, your package manager, your database, or your own brain being tired. Now there is another blocker: the AI provider itself.

That does not make Claude bad. It makes Claude real software running on real infrastructure. Real infrastructure fails. Real APIs rate limit. Real products have rough days.

The better habit is to enjoy the speed when it works, but never forget how to keep moving when it does not.

References

Originally published at https://blog.jenuel.dev/blog/claude-outages-limits-part-of-the-deal

I Am Fired Up Again

Jenuel Oras Ganawed — Tue, 23 Jun 2026 13:29:11 +0000

I feel something waking up in me again.

For a while, life felt like I was just trying to keep things moving. Work. Bills. Responsibilities. Family. Projects. The normal cycle. I was still building, still learning, still doing my job, but somewhere along the way the fire got quieter.

Now it feels lit again.

I want to be successful in my life. Not in the shallow way where success is only about showing people that I made it. I mean the kind of success where I can breathe. The kind where my family is secure. The kind where I am not one emergency, one company decision, or one bad month away from panic.

One of my dreams is financial stability

One of my dreams has always been to become financially stable. I want money to keep flowing even if I am not currently working for a company. I want assets, products, apps, content, investments, or businesses that can continue moving even when I need to rest.

That dream is not about laziness. It is about freedom.

I know what it feels like to depend on one source of income. I know what it feels like to love your job but still feel that quiet pressure in the background. What if this stops? What if the company changes direction? What if I get sick? What if I need more time for my family?

That is why financial stability matters to me. I do not want money to control every decision. I want to build a life where money becomes a tool, not a chain around my neck.

I still love working

Here is the part some people misunderstand: even if I become financially stable, I still want to keep working.

I love what I do.

I love building things. I love solving problems. I love the feeling when an idea turns into an app, a website, a system, or a tool that someone can actually use. I love learning new technology and seeing what I can create with it.

So my dream is not to escape work forever. My dream is to remove fear from work.

There is a big difference between working because you are trapped and working because you choose to. I want to reach the point where I can say yes to meaningful work, not because I am desperate, but because I genuinely want to be there.

The fire is back

I am fired up again because I remembered that my dream is still alive.

I want to build more. I want to grow more. I want to become wiser with money, better with time, stronger in discipline, and more serious about the future I say I want.

I do not want to just talk about financial stability. I want to build toward it.

That means creating things that can outlive a single paycheck. It means improving my skills. It means staying consistent even when progress is boring. It means being honest about where I am now, but also refusing to believe this is where I have to stay.

Success, but with purpose

I do not want success to turn me into someone who only chases money.

I want to be financially stable, yes. But I also want to stay grounded. I want to keep loving my family well. I want to keep serving God. I want to keep building useful things. I want to keep showing up in my current jobs with gratitude because I really do love what I do.

Money can give options, but it cannot become the whole point.

The point is freedom with responsibility. Stability with purpose. Work without fear. Ambition without losing my soul.

So I am starting again

Maybe this is just a personal note. Maybe it is a reminder to myself.

I am fired up again.

My dream is lit again.

I want to become successful, financially stable, and free enough to keep working from love instead of fear. I am not there yet, but I can feel the direction coming back.

And this time, I do not want to waste the fire.

References

Originally published at https://blog.jenuel.dev/blog/i-am-fired-up-again

I Spent Years Learning to Code. Now People Vibe Code in a Weekend.

Jenuel Oras Ganawed — Sun, 21 Jun 2026 14:10:58 +0000

I spent years learning how to code the hard way. Books on the table. YouTube videos paused every two minutes. Stack Overflow tabs everywhere. Tiny bugs that stole whole evenings. That weird feeling when the answer finally clicked at 1:37 AM and I wanted to tell someone, but everyone else was asleep.

Now a person who has never written a real application can open an AI coding tool, describe an idea badly, and somehow end up with a working prototype.

I will be honest. Part of me looks at that and thinks, "Did I waste my time?"

Seven-plus years as a software developer teaches you patience, but it does not make you immune to that little punch in the chest. You remember all the hours you spent learning syntax, frameworks, database design, deployment, authentication, state management, debugging, and all the invisible stuff nobody claps for. Then the internet starts calling it "vibe coding," and suddenly the entry fee looks almost free.

For many developers, learning to code meant years of late nights, docs, tutorials, and debugging sessions. Photo via Unsplash.

But another part of me feels grateful. I got to experience software development before AI coding assistants changed the room. I know what it felt like to be forced to understand. I know what it felt like to read error messages until they started looking less like punishment and more like clues. That older path was slower, but it built something in me that I do not want to lose.

The strange grief of watching the shortcut arrive

Developers do not talk about this enough. We talk about productivity. We talk about tools. We argue about whether AI-generated code is good or bad. But underneath all of that, a lot of experienced developers are quietly processing a kind of professional grief.

We spent years earning instincts that AI now appears to imitate on demand.

When you learned before AI coding tools, you did not just learn how to make a button blue. You learned why CSS fought you. You learned why a database query slowed down. You learned why authentication is not just a login form. You learned that a feature can work in your browser and still fail in production because time zones, permissions, caching, network latency, or some tiny environment variable decided to humble you.

Those scars became judgment.

So when a non-coder says, "I built this app with AI," it can feel like someone skipped the mountain and arrived at the same viewpoint by helicopter. You want to be happy for them. You probably are, at least partly. But you also remember every blister.

AI did not make the old learning useless

The mistake is assuming the shortcut and the journey produce the same developer.

AI can generate code. It can explain code. It can scaffold a project, write tests, rename functions, fix obvious bugs, and help someone move faster than beginners could move ten years ago. That is real. Pretending otherwise is just denial.

But coding was never only about typing code.

Software development is mostly judgment under uncertainty. What should this feature do when the payment succeeds but the webhook is delayed? Where should this validation live? Is this bug a frontend state issue, a backend contract issue, or a race condition? Is this AI suggestion actually correct, or does it only look correct because it sounds confident?

Those questions are hard to vibe your way through.

The old path taught us to slow down and inspect the machine. It taught us to distrust the first answer. It taught us to search, compare, test, and ask better questions. That experience still matters because AI has not removed the need for judgment. It has made judgment more valuable.

The research is starting to sound familiar

The concern is not just nostalgia from older developers. Researchers are beginning to measure the trade-off.

Nature recently covered early evidence that heavy reliance on AI tools can weaken skills in fields like medicine and software engineering. Stack Overflow's 2025 Developer Survey shows a similar tension: 84% of respondents use or plan to use AI tools, but more developers actively distrust AI output accuracy than trust it. The tools are everywhere, but trust has not caught up.

There is also a strange productivity paradox. GitHub has published research showing Copilot can help developers complete some tasks much faster and feel less frustrated. At the same time, METR's study of experienced open-source developers found that early-2025 AI tools slowed participants down by 19% on their own repositories, even though those developers expected AI to speed them up.

That does not mean AI coding is fake. It means the story is more complicated than "AI makes everyone faster." AI helps most when the task is clear, the context is available, and the person using it can review the result. It becomes dangerous when the user cannot tell the difference between correct code and confident code.

Beginners can build faster now, but they can also misunderstand faster

I am genuinely excited that more people can build things. I love that a founder, designer, student, pastor, teacher, or small business owner can describe an idea and see it come alive. That part is beautiful. Software used to be locked behind too many gates.

But there is a difference between building a demo and owning a system.

A demo can be impressive with shallow understanding. A real system eventually asks for deeper understanding. Users sign up. Data becomes important. Security matters. Payments fail. Logs matter. Backups matter. Migrations matter. Someone asks why the app is slow. Someone asks why their account disappeared. Someone finds a bug that only happens on Android after a token expires during a poor network connection.

That is when the old learning returns.

AI can help in those moments too. I use AI. I am not writing this as someone who rejects the tool. I use it because it helps me move, think, compare options, and get unstuck. But I do not want to lose the part of me that knows how to reason without it.

AI can write code quickly. The harder question is whether the person shipping it understands the system well enough to maintain it.

The new developer skill is not typing. It is supervising

Before AI, a lot of our value was connected to implementation speed. Could you build the feature? Could you debug the issue? Could you connect the API, write the query, and ship the thing?

Now implementation is cheaper. Not free, but cheaper.

That pushes developers toward a different kind of value: taste, architecture, review, testing, product thinking, security awareness, and the ability to turn vague requests into safe, maintainable systems. In other words, the job moves upward. Less "Can you type this function?" More "Can you tell whether this function should exist?"

This is why experienced developers still matter. A senior developer using AI is not the same as a beginner using AI. The senior developer has more internal alarms. They know when a solution smells too clever. They know when a migration needs a rollback plan. They know when a generated abstraction is solving a problem nobody has.

Experience becomes the filter.

What I would tell younger developers now

If you are learning to code today, use AI. Seriously. Use it. Ask it questions. Let it explain errors. Let it build small examples. Let it compare two approaches. You have access to a patient tutor that developers before you would have loved to have.

But do not let it rob you of the struggle completely.

When AI gives you code, read it. When it fixes a bug, ask why the bug happened. When it suggests a pattern, ask what trade-off you are accepting. Turn off the assistant sometimes and implement the small thing yourself. Read documentation even when AI can summarize it. Debug manually sometimes. Write tests. Break the code on purpose. Learn the boring fundamentals because the boring fundamentals are usually what save you in production.

The danger is not that AI will make beginners productive. The danger is that it will make them feel productive before they are capable of judgment.

Maybe my years were not wasted

I keep coming back to that question: did I waste my time?

No. I do not think so.

Those years gave me more than syntax. They gave me patience. They gave me debugging instincts. They gave me humility, because code has a way of embarrassing anyone who thinks they are above details. They gave me the ability to look at an AI-generated answer and say, "That looks nice, but something is wrong here."

That is not wasted time. That is the foundation.

AI changed the cost of producing code. It did not change the cost of understanding consequences. And software, once real users depend on it, is mostly consequences.

So yes, I feel the weirdness. I feel the little sting when someone with no coding background builds in a weekend what would have taken me months to learn years ago. But I also feel grateful that I learned in the slower era. I got to build the muscles before the machine arrived.

Maybe that is the role of developers now: not to resent the shortcut, and not to worship it either. Use it. Question it. Teach others how to use it without losing their mind, their craft, or their responsibility.

The future of coding may be more accessible than ever. I hope it is. But I also hope we do not confuse access with mastery.

References

Originally published at https://blog.jenuel.dev/blog/i-spent-years-learning-to-code-now-people-vibe-code-in-a-weekend

Developer jobs are not dead, but the salary ladder is changing

Jenuel Oras Ganawed — Thu, 18 Jun 2026 05:48:13 +0000

Every few months the internet rediscovers the same argument: developers are either doomed, overpaid, or about to be replaced by AI. I do not buy the simple version of that story. The developer job market is not dead. It is getting pickier.

The old bargain was easier to explain. Learn a popular stack, build a few projects, pass interviews, and you could usually find a place somewhere in the market. That still happens, but the middle is more crowded now. Companies want fewer people who can ship more, and they are paying more carefully for the parts of software work that are harder to automate.

That is the salary story too. Pay is no longer just about whether you know JavaScript, Python, Java, C#, Go, or Rust. The language matters, but mostly because it points toward a type of work. Python can mean AI and data work, or it can mean scripts nobody wants to maintain. JavaScript can mean modern product engineering, or it can mean another crowded frontend role. Rust can signal low-level systems work, but it does not magically create a senior job by itself.

The employment picture is mixed, not apocalyptic

Stack Overflow's 2025 Developer Survey gives a useful snapshot. Among respondents, about 69.8% described themselves as employed, 13.9% as independent contractors, freelancers, or self-employed, and 4.6% as not employed. Remote work is still alive, but it is no longer the simple default: 32.4% reported remote work, while the rest split across in-person, hybrid, and flexible arrangements.

That matches what a lot of developers feel on the ground. There are jobs, but the easy version of the market has cooled. Junior roles are harder. Generic full-stack roles get flooded. Hiring teams are slower. At the same time, companies still need people who can deal with production systems, cloud infrastructure, security, data pipelines, AI integration, payments, compliance, and boring business software that actually makes money.

The funny thing is that AI has not removed the need for developers. It has changed what employers expect a developer to do. If AI writes a decent first draft of code, the valuable person is the one who knows whether that draft is safe, maintainable, tested, deployable, and aligned with the product. That is a higher bar, not a lower one.

Salary is moving toward leverage

The clearest salary split in Stack Overflow's 2025 data is by role. Globally, senior executives reported a median of about $139k, engineering managers about $130k, cloud infrastructure engineers about $103k, software or solutions architects about $102k, AI/ML engineers about $89k, DevOps engineers about $87k, backend developers about $80k, full-stack developers about $73k, mobile developers about $70k, and frontend developers about $62k.

The U.S. numbers are much higher. The survey reports U.S. medians around $200k for engineering managers, $189.5k for AI/ML engineers, $189k for cloud infrastructure engineers, $180k for architects, $175k for backend developers, $170k for mobile developers, $165k for DevOps, $145k for frontend developers, and $138k for full-stack developers.

Those numbers do not mean frontend is bad or backend is automatically rich. They mean employers pay more when the role is close to leverage: infrastructure, architecture, AI systems, security, data, scaling, reliability, and business-critical backend work. The closer your work is to revenue, risk, scale, or technical ownership, the easier it is to defend a higher salary.

Languages are becoming market signals

Stack Overflow's 2025 technology data still shows the mainstream languages at the top. JavaScript is used by 66.0% of respondents, HTML/CSS by 61.9%, SQL by 58.6%, Python by 57.9%, TypeScript by 43.6%, Java by 29.4%, C# by 27.8%, C++ by 23.5%, Go by 16.4%, and Rust by 14.8%.

But popularity and salary are not the same thing. JavaScript and Python are everywhere, which means they create many jobs but also a lot of competition. Go and Rust are smaller markets, but they often show up in infrastructure, platform, systems, backend, crypto, networking, and performance-sensitive work. Java and C# remain strong in enterprise systems where companies pay for stability, maintenance, and domain knowledge. SQL remains underrated because almost every valuable system eventually becomes a data problem.

The interesting shift is that a language now tells employers what kind of problems you probably know how to solve. Python plus machine learning, data engineering, APIs, and evaluation pipelines is different from Python alone. TypeScript plus product engineering, testing, and cloud deployment is different from only knowing React syntax. Go plus Kubernetes, observability, and distributed systems is different from writing a few toy services. Rust plus networking, embedded, or performance work is different from liking Rust on Reddit.

Framework salary is really ecosystem salary

The same pattern shows up with frameworks. In Stack Overflow's 2025 survey, Node.js and React are still huge: 48.7% and 44.7% of respondents used them. Next.js reached 20.8%, Express 19.9%, ASP.NET Core 19.7%, Angular 18.2%, Vue 17.6%, FastAPI 14.8%, Spring Boot 14.7%, Flask 14.4%, and Django 12.6%.

If you only look at the framework name, the market looks confusing. React is everywhere, but that also means many applicants can list React. Next.js is useful, but a company rarely pays more just because someone knows file-based routing. FastAPI is attractive because it often sits near Python services, AI products, and internal tools. Spring Boot and ASP.NET Core remain valuable because they live inside companies with big systems, long maintenance tails, and real budgets. Ruby on Rails is smaller now, but experienced Rails developers can still do well when the company runs on Rails and needs someone who understands the whole app.

So the better question is not, "Which framework pays the most?" It is, "Which framework puts me near valuable problems?" React plus design systems, performance, accessibility, and product judgment is better than React alone. Spring Boot plus distributed systems and cloud deployment is better than Spring Boot alone. FastAPI plus data pipelines and AI evaluation is better than FastAPI alone.

What changed for developers

The biggest change is that employers are less impressed by surface area. A resume with ten frameworks used to look flexible. Now it can look shallow. The market is rewarding developers who can connect tools to outcomes.

If you are a frontend developer, learn performance, accessibility, testing, product analytics, and how your UI choices affect conversion or retention.
If you are a backend developer, learn databases deeply, queues, caching, observability, deployment, security, and failure modes.
If you are using Python, do not stop at scripts. Learn data modeling, APIs, AI workflows, evaluation, and production deployment.
If you are using Go, Rust, Java, or C#, connect the language to systems work, infrastructure, enterprise reliability, or performance.
If you are using AI tools, become the person who can review, test, and safely ship AI-assisted code instead of just generating more of it.

This is uncomfortable, especially for newer developers. The bottom of the market is absorbing pressure from bootcamps, global remote competition, layoffs, and AI-generated boilerplate. But the top of the market still pays for judgment. That has not changed.

My read

I would not tell a new developer to chase the highest-paying language. That is usually a trap. By the time a salary chart reaches everyone, the easy money has already moved.

I would tell them to pick a stack with a healthy job market, then build depth around a valuable problem. For web products, TypeScript, React, Next.js, Node, and SQL are still practical. For enterprise work, Java, C#, Spring Boot, and ASP.NET Core remain boring in the best way. For AI and data-heavy products, Python, SQL, FastAPI, and cloud deployment are a strong path. For infrastructure, Go and Rust are worth watching, but only if you also learn the systems around them.

The developer career is not disappearing. It is becoming less forgiving of shallow skill. Salaries are following the same rule. The market pays less for knowing the name of a framework and more for owning the messy, expensive problems around it.

References

Originally published at https://blog.jenuel.dev/blog/developer-jobs-salary-ladder-languages-frameworks-2026

Pre-launch AI simulations are becoming the new model safety check

Jenuel Oras Ganawed — Wed, 17 Jun 2026 08:04:52 +0000

The next serious upgrade in AI safety may not look like a bigger warning label. It may look like a rehearsal.

OpenAI published new work this week on predicting model behavior before release by simulating deployment. That sounds academic at first, but the practical idea is simple: before a model reaches millions of users, create realistic pressure tests that mimic how people, teams, and attackers might actually use it.

For builders, this is a useful signal. The AI industry is moving from “ship the model and monitor the fallout” toward “simulate the fallout before launch.” That is not just a frontier-lab concern. It is a product-engineering habit every team using AI should start copying.

What changed

The usual AI evaluation stack is good at benchmarks, red-team prompts, and post-launch monitoring. Those are still necessary, but they miss a key problem: models behave differently when they are placed inside real workflows.

A chatbot inside a healthcare intake flow, a coding agent with repo access, and a research assistant summarizing private files are not the same product. The model may be identical, but the surrounding permissions, incentives, user expectations, and failure modes are different.

Deployment simulation tries to test that full situation earlier. Instead of asking only, “Can the model answer this prompt?”, teams ask, “What happens when this model is used by this kind of user, with this tool access, under this pressure, for this goal?”

Why developers should care

Most teams will not run frontier-lab scale simulations. That is fine. The lesson is not to copy OpenAI’s entire research setup. The lesson is to stop treating evaluation as a single checklist at the end of development.

If you are adding AI to an app, a practical version of deployment simulation can be small and still valuable:

Write test scenarios around real user jobs, not only isolated prompts.
Include tool access in the test, especially file writes, database actions, email sending, payments, or code execution.
Test failure recovery: what should the AI do when it is unsure, blocked, missing context, or given conflicting instructions?
Run adversarial examples that match your product, not generic jailbreak prompts copied from social media.
Keep a log of “near misses” and turn them into regression tests.

This matters even more for agents. A normal chatbot can be wrong in a visible answer. An agent can be wrong while taking action. That changes the risk model.

The scaling-law angle

Another current signal came from Stanford HAI, which highlighted research on better ways to predict how large models scale. If model builders can forecast capability more cheaply, the pre-launch evaluation problem becomes sharper: teams may know earlier that a model will be powerful, but they still need to know how that power behaves in product settings.

In other words, capability forecasting and deployment simulation belong together. One asks, “How strong will this model be?” The other asks, “What will that strength do when real users get it?”

A simple builder playbook

Here is the practical version I would use for a startup or internal tool:

Define the dangerous verbs. List the actions your AI can take: delete, send, publish, charge, approve, merge, diagnose, recommend.
Create role-based scenarios. Test a beginner user, a power user, a rushed employee, and a malicious user.
Simulate messy context. Give the AI stale docs, partial data, contradictory instructions, and ambiguous requests.
Add hard stops. Require confirmation or human review before irreversible actions.
Measure boring reliability. Track refusal quality, escalation quality, hallucinated tool use, and whether the model admits uncertainty.

The goal is not to make the AI timid. The goal is to make it predictable enough that users can trust it with real work.

The honest weakness

Simulation can also create false confidence. A test suite only covers the situations someone imagined. Users will always find stranger combinations of intent, context, and workflow than a lab or product team can predict.

So the best version is layered: pre-launch simulations, limited rollouts, monitoring, human escalation, and fast rollback paths. If any one layer is treated as magic, the system becomes fragile.

Bottom line

The useful trend is not “AI labs found another safety technique.” The useful trend is that model evaluation is becoming more like real software engineering: scenario-driven, workflow-aware, and connected to deployment risk.

For developers, that is good news. You do not need a research lab to start. You need a list of real user jobs, a few uncomfortable edge cases, and the discipline to test the AI as a product actor, not just a text generator.

References

OpenAI: Predicting model behavior before release by simulating deployment
Stanford HAI: New Approach to Scaling Laws Could Change How AI Models Are Trained
Anthropic Claude: The founder’s playbook: Building an AI-native startup
Hacker News newest AI signal feed used for topic discovery

Originally published at https://blog.jenuel.dev/blog/pre-launch-ai-simulations-new-model-safety-check

I Stopped Using Heavy IDEs. AI Became My IDE.

Jenuel Oras Ganawed — Wed, 17 Jun 2026 03:19:24 +0000

I used to think a serious developer needed a serious IDE.

Big project? Open PhpStorm. Design work? Open Photoshop. Need every refactor, every inspection, every plugin, every panel, every button? Load the heavy tool and wait for the machine to breathe again.

But something changed. Not overnight, and not because those tools suddenly became bad. They are still powerful. The change is that AI started taking over the parts of the IDE I actually needed most.

Today, I spend more time in VS Code and the terminal than in heavy IDEs. My machine feels lighter. My workflow feels less crowded. And honestly, I do not miss the old setup as much as I thought I would.

The old IDE was a safety net

For years, big IDEs won because they could see the whole project. They understood symbols, imports, frameworks, database models, refactors, formatting, inspections, and tests. A good IDE felt like a senior assistant sitting beside you, quietly warning you before you made a mess.

That was valuable. It still is.

But AI has started to move that intelligence out of the IDE shell. The useful part is no longer tied to one huge application. It can live in your editor, your terminal, your pull request, your CI pipeline, or even in a chat window with access to your codebase.

When AI can read the files, reason about the bug, generate a test, run the test, inspect the failure, and propose a patch, the IDE becomes less like the brain of the workflow and more like one possible place to type.

AI is becoming the environment

The phrase "AI coding assistant" already feels too small. Autocomplete was the first version. The newer pattern is closer to an AI developer environment.

You ask it to find the bug. It searches the repo. You ask it to explain a weird error. It follows the stack trace. You ask it to write a benchmark. It can create the benchmark file, run it, compare the result, and tell you what changed. You ask it to add tests. It can inspect the code path and generate cases you probably would have delayed until later.

That changes the value of a heavy IDE. If the IDE's biggest advantage was intelligence, and that intelligence is now available everywhere, then the heavy IDE has to justify its weight in a new way.

For some teams, it still will. Large Java projects, deep framework integrations, enterprise debugging, database tooling, and mature refactor engines are not magically obsolete. But for a lot of web development, app work, scripting, backend APIs, and content-heavy product work, the lighter stack is suddenly enough.

VS Code plus terminal feels like breathing room

This is the part people underestimate: tool weight affects how you think.

A heavy IDE can be comfortable, but it can also make the machine feel occupied. It eats RAM, adds background indexing, opens panels you forgot existed, and turns simple edits into a small cockpit experience.

VS Code and a terminal feel different. Open the files. Run the command. Ask AI to inspect the error. Make the change. Run the test again. There is less ceremony.

I like that. I like seeing the actual commands. I like not waiting for a large application to settle down before I can think. I like that the same terminal workflow works across projects, servers, scripts, and AI agents.

It is not about minimalism for aesthetics. It is about reducing friction.

Tests are becoming the new IDE feature

The strongest reason AI reduces my need for a heavy IDE is not code generation. Code generation is useful, but it is also easy to overtrust.

The stronger shift is AI-assisted verification.

If AI writes code and also writes tests for that code, the workflow becomes more honest. It does not just say, "Here is the fix." It can say, "Here is the failing case I reproduced, here is the patch, and here is the test result after the patch." That is much closer to useful engineering.

Benchmarks matter too. A traditional IDE might help you navigate performance code, but AI can generate a benchmark harness, run before-and-after measurements, and point out whether the improvement is real or just vibes.

This is where AI starts replacing the feeling of needing a giant IDE. The confidence no longer comes from a green underline or a smart autocomplete. It comes from generated checks that prove the change works.

The heavy IDE is not dead, but its default status is

I do not think PhpStorm, IntelliJ IDEA, Visual Studio, or Photoshop-style professional tools are going away. That would be a lazy prediction. Experts still need expert tools.

But I do think the default assumption is changing.

Before, the question was: "Why are you not using the full IDE?"

Now the question is: "Do you actually need it for this project?"

That is a big shift. A lighter editor plus terminal plus AI can cover more ground than it could even a few years ago. It can debug, explain, generate, refactor, write tests, create scripts, and help with documentation. It can also jump outside software development into design drafts, copy, image workflows, automation, and deployment tasks.

That is why I also feel less attached to tools like Photoshop for everyday work. For serious design, sure, dedicated tools still win. But for quick graphics, mockups, thumbnails, edits, and experiments, AI tools have eaten a big part of the reason I used to open a heavy design app in the first place.

The new developer setup is smaller and more powerful

My current setup is simpler: VS Code, terminal, AI, tests, and scripts.

It sounds smaller. It feels smaller. But it can do more than my older setup did because the intelligence is no longer trapped inside one application.

That is the part I keep coming back to. AI is not just another plugin inside the IDE. AI is becoming the layer around the work. It can sit beside the editor, inside the terminal, inside GitHub, inside CI, inside docs, and inside the browser.

The IDE used to be where development happened. Increasingly, development happens wherever the AI can see the project, run the commands, and verify the result.

For me, that means fewer heavy apps, fewer waiting moments, and more breathing room on my machine.

And once you get used to that breathing room, it is hard to go back.

References

Originally published at https://blog.jenuel.dev/blog/i-stopped-using-heavy-ides-ai-became-my-ide

Voice AI is becoming a full-stack problem

Jenuel Oras Ganawed — Tue, 16 Jun 2026 08:04:45 +0000

The next useful AI app may not look like a chatbot at all. It may sound like a calm support rep, a patient tutor, or a field assistant that can listen while someone is busy with both hands.

That is why Cartesia's new Sonic-3.5 and Ink-2 launch is worth paying attention to. The headline is not just another text-to-speech upgrade. The more important signal is that voice AI is turning into a full-stack engineering problem: speech-to-text, text-to-speech, latency, turn-taking, interruptions, safety checks, and tool calls all have to feel like one product.

For builders, this is the shift. A voice agent is not a language model with audio bolted on. It is a real-time system where every extra delay makes the product feel less intelligent.

What changed

Cartesia announced Sonic-3.5 for text-to-speech and Ink-2 for speech-to-text, positioning them as a paired stack for real-time voice agents. The company says Sonic-3.5 is built for naturalness, low latency, and 40+ languages, while Ink-2 focuses on transcription accuracy and fast turn-taking.

The most practical claim is the pipeline framing. Cartesia is selling STT and TTS as parts of the same real-time loop instead of two separate vendors that developers have to stitch together. Its launch page points to sub-90ms TTS and 100ms transcript latency with native turn detection. If that holds up in real applications, it matters more than a demo voice sounding slightly nicer.

Why developers should care

Voice agents fail in small moments. A half-second pause after every sentence feels robotic. Poor interruption handling makes users repeat themselves. Bad transcription turns a simple request into a support ticket. A beautiful generated voice is not enough if the agent cannot listen, stop, recover, and call tools quickly.

This is where the developer opportunity is. The best voice products will not be built by choosing the most impressive model in isolation. They will be built by measuring the whole conversation loop.

Support agents: detect intent, pull order data, answer naturally, and escalate when confidence drops.
Healthcare and field workflows: capture spoken notes while the user is working, then structure them for review instead of pretending the transcript is final truth.
Education apps: let students talk through a problem and interrupt the tutor when they are confused.
Internal tools: create voice interfaces for dashboards, incident updates, and hands-free task capture.

The common thread is not voice for novelty. It is voice where typing is slower, unsafe, or unnatural.

The weak spots to test before shipping

I would not ship a production voice agent just because a model page says low latency. Builders should test the boring edge cases first.

Interruptions: can the user cut the agent off without the conversation state breaking?
Noisy audio: does transcription degrade gracefully in a cafe, car, warehouse, or cheap headset?
Accents and code-switching: does the system handle real users, not just studio samples?
Tool-call delay: what happens when the LLM and backend API take longer than the speech layer?
Consent and recording: is it clear when audio is captured, stored, or used for review?

The mistake is treating speech as a UI skin. Voice changes the trust model. People reveal more when they speak, and they notice awkward timing faster than they notice a slow web page.

A practical builder checklist

If you are evaluating Sonic-3.5, Ink-2, or any competing voice stack, build a small benchmark around your own product instead of relying on generic leaderboard claims.

Measure time from user speech ending to agent response starting.
Track word error rate on your real vocabulary, including names, product terms, and acronyms.
Test barge-in behavior: interrupt the agent mid-sentence and see if it adapts.
Log every failed turn with audio, transcript, intent, tool call, and final response.
Decide when the agent should stop talking and ask a human to take over.

That last point is important. A good voice agent should not be endlessly confident. In many products, the trust-building moment is the handoff: 'I am not sure, so I am sending this to a person with the context attached.'

The bigger signal

The AI industry has spent years making models that can answer. The next competition is around systems that can participate. Voice makes that obvious because participation has rhythm: listening, pausing, interrupting, confirming, and acting.

Cartesia's launch is one signal in that direction. Whether its models become the default stack or not, the direction is clear: builders need to think less about isolated model calls and more about complete interaction loops.

For developers, the question is no longer 'Can I add a voice mode?' The better question is: 'Where would a fast, interruptible, trustworthy conversation make this product meaningfully better?'

References

Originally published at https://blog.jenuel.dev/blog/voice-ai-full-stack-cartesia-sonic-ink