DEV Community: Jenuel Oras Ganawed

AI usage limits are a product feature now

Jenuel Oras Ganawed — Sat, 30 May 2026 08:02:53 +0000

The most expensive AI bug is not always a bad answer. Sometimes it is a good answer requested too many times, by too many people, with no limit in sight.

That is the quiet shift happening around AI products right now. Teams spent the last year asking whether the model was smart enough. The better question for 2026 is whether the product can survive real usage. If a company has to ration AI internally, if an app cannot explain which feature burned the token budget, or if a developer discovers runaway usage only after the invoice arrives, the AI feature is not production-ready yet.

This is not a call to slow down. It is a call to build AI like software that has cost, failure modes, access levels, and operational boundaries. Usage limits are no longer an annoying pricing-page detail. They are part of the product experience.

The new AI failure mode is invisible spend

Traditional cloud costs usually leave clues. A database grows. A queue backs up. A deployment doubles traffic. LLM spend can hide inside normal behavior: a longer conversation, a bigger context window, an agent loop, a user pasting a 90-page document, or a background workflow that retries with a more expensive model.

That is why the recent discussion around companies rationing AI matters. The headline sounds like finance departments being cautious, but builders should read it as an engineering warning. If AI becomes useful enough that everyone wants it, cost controls move from accounting into architecture.

For a developer, the lesson is simple: do not wait until the product is popular to add budgets. The moment a feature calls a frontier model, it needs limits, logs, and a graceful fallback path.

What good limits look like

A useful AI limit should not feel like a random wall. It should help the user make a better decision. For example, a writing assistant can show that a deep research request costs more than a quick rewrite. A coding tool can reserve the strongest model for architecture review while using a smaller model for search, summarization, and boilerplate. A support agent can escalate only after retrieval and cheaper classification steps fail.

Good limits usually include five pieces:

Per-user budgets: stop one user, team, or integration from burning the shared pool.
Per-feature tracking: know whether chat, document upload, agent actions, or background jobs are driving spend.
Model routing: use the expensive model when quality matters, not by default for every task.
Context discipline: trim, retrieve, summarize, and cache instead of sending everything every time.
Clear user feedback: explain when a request is too large, too frequent, or better handled asynchronously.

The point is not to make AI feel stingy. The point is to make it dependable. A product that silently disables AI because the monthly budget is gone feels worse than a product that explains limits up front and offers smart alternatives.

Observability has to include quality and cost

AI dashboards often start with latency and token counts. That is necessary, but not enough. Teams also need to see whether cheaper routing damages answer quality, whether longer context actually improves outcomes, and whether users repeat prompts because the first response was weak.

AWS published a timely example this week around LLM observability for SageMaker inference, combining infrastructure signals such as GPU utilization with LLM quality views. That direction is right. The future AI dashboard should connect three questions in one place: how much did it cost, how well did it work, and what should we change?

Without that connection, teams make bad tradeoffs. They cut cost and quietly ruin the feature. Or they chase quality with the largest model and turn a useful product into an unsustainable one.

A practical builder checklist

If you are adding AI to an app this month, start with a small operating playbook:

Set a daily and monthly spend budget before launch.
Log model, prompt type, input size, output size, user, feature, latency, and result status.
Put hard caps on agent loops, retries, tool calls, and maximum context size.
Create at least two model tiers: default and premium. Add a cheap fallback for summaries, classification, extraction, and routing.
Cache repeated outputs where the answer does not need to be fresh.
Give users a visible reason when the system refuses a huge request.
Review the top 10 most expensive request patterns every week.

This sounds basic, but it changes the culture of the product. The team stops treating the model as magic and starts treating it as a powerful dependency with measurable tradeoffs.

The opinionated take

The next wave of strong AI products will not be the ones that simply plug in the newest model first. They will be the ones that make expensive intelligence feel boringly reliable.

That means limits, routing, dashboards, and honest UX. It means telling a user, "This request is too large for instant mode, but we can run it as a background job." It means using smaller models without shame when the task is simple. It means designing AI features that can survive success.

AI is becoming normal software. That is good news. Normal software needs budgets, permissions, monitoring, and product judgment. The teams that accept that early will ship faster because they will spend less time panicking over surprise bills and more time improving the experience.

References

AWS: Comprehensive observability for Amazon SageMaker AI LLM inference
Anthropic Claude pricing documentation
OpenAI API production best practices
Hacker News discussion signal on Claude usage limits

Originally published at https://blog.jenuel.dev/blog/ai-usage-limits-are-product-feature

AI's next bottleneck is not the model. It is moving the data.

Jenuel Oras Ganawed — Fri, 29 May 2026 08:03:09 +0000

The next big AI upgrade may not look like a smarter chatbot. It may look like light moving between chips.

That sounds less exciting than a new frontier model, but builders should pay attention. The practical limit for AI systems is increasingly not just how many parameters a model has or how clever the prompt is. It is whether data can move fast enough, cheaply enough, and with low enough power draw to keep the hardware fed.

Recent signals point in the same direction: Nvidia is pushing deeper into optical networking and photonics, manufacturers are talking about sustained AI server demand, and chip analysts are spending more time on packaging, memory, thermals, and interconnects. The message is simple: the AI race is becoming an infrastructure race.

Why data movement matters now

Modern AI workloads do not live on one clean little chip. Training and serving large models require GPUs, memory, network cards, switches, storage, and racks of machines acting like one system. Every step needs data to move: from memory to accelerator, from accelerator to accelerator, from rack to rack, and from the model back to the user.

When that movement is slow, expensive, or power-hungry, the model waits. Expensive GPUs sit underused. Latency gets worse. Inference costs rise. The product team asks why the demo worked but production feels heavy.

This is why photonics matters. Using light for parts of the data path can help networks move more information with better efficiency than traditional electrical links in the right places. It is not magic, and it will not replace every cable or chip interconnect overnight. But for dense AI data centers, better optical links can become the difference between buying more GPUs and actually using the ones already installed.

What users actually get

Most users will never ask whether their AI request crossed an optical interconnect. They will notice the outcomes:

Lower latency for complex multimodal tasks, especially when systems need to call multiple models or tools.
More reliable capacity during traffic spikes, because the serving cluster is less constrained by internal data flow.
Cheaper inference over time if providers can run hardware at higher utilization with less wasted power.
Bigger context and richer outputs when memory and network limits stop being the first wall teams hit.

That last point matters for developers. The best AI product ideas often die in the gap between prototype and production. A workflow that feels smooth with ten users can become painfully expensive with ten thousand. Infrastructure improvements do not automatically fix product design, but they expand what is practical.

Strengths and weaknesses of the photonics push

The strength is obvious: AI systems need more bandwidth, and copper-heavy designs run into distance, heat, and power constraints. Optical networking is already common in data centers; the frontier is bringing optical connections closer to the compute and making them cheaper, denser, and easier to operate at AI scale.

The weakness is that hardware transitions are messy. New optical components must fit into manufacturing lines, supply chains, reliability testing, rack designs, and software-defined networking stacks. A faster link is not enough if the rest of the system cannot schedule work intelligently or recover cleanly when something fails.

There is also a business risk. When one vendor controls more of the AI hardware stack, customers can get better integration, but they may also get more lock-in. Builders should celebrate better performance while still asking boring procurement questions: Can we switch providers? Can we observe the bottlenecks? Can we run smaller models locally when cloud economics stop making sense?

What builders should do with this trend

If you build AI products, do not treat hardware news as Wall Street noise. It tells you where the practical ceiling is moving.

Design for latency budgets. Break down where time is spent: retrieval, model calls, tool calls, post-processing, and network round trips.
Track inference cost per successful task. Tokens alone are not enough. Measure the cost of the whole workflow.
Use smaller models where they are good enough. Better infrastructure does not excuse sending every job to the largest model.
Plan for provider diversity. If a feature only works on one expensive stack, know that before it becomes core to your product.
Watch memory and data transfer, not just benchmark scores. Many real-world AI failures are plumbing failures with a model logo on top.

The near future of AI will still include better models. But the winners will not be the teams that only chase model names. They will be the teams that understand the whole system: model, memory, network, cost, latency, and user trust.

The practical takeaway

AI is becoming less like a single app feature and more like a distributed computing problem with a conversational interface. That means the boring layer is becoming strategic.

If photonics and advanced interconnects keep gaining momentum, the most important AI improvements of the next few years may arrive quietly: faster responses, cheaper workloads, larger real-world context, and fewer production compromises. Users will call it better AI. Engineers will know it was better data movement.

References

Originally published at https://blog.jenuel.dev/blog/ai-data-movement-next-bottleneck

Physical AI needs an operations playbook, not just smarter robots

Jenuel Oras Ganawed — Thu, 28 May 2026 08:04:20 +0000

The next useful AI product may not live in a chat window. It may be a robot arm, a warehouse vehicle, a camera-guided inspection tool, or a field machine that can make small decisions without waiting for a human to click approve.

That sounds exciting until you remember one uncomfortable detail: software bugs are cheap compared with physical mistakes. If an AI assistant writes a bad paragraph, you edit it. If a robot moves at the wrong time, blocks a worker, damages inventory, or trusts a weak sensor reading, the cost is real.

That is why the current wave of physical AI should not be judged only by model demos. The better question for builders is simpler: what does the operations playbook look like after the demo works?

The signal: robotics is moving from demo mode to supervised autonomy

Several fresh signals point in the same direction. FORT Robotics announced its acquisition of Mapless AI to expand remote supervision, teleoperation, and active safety capabilities for vehicle and heavy machinery autonomy. Bessemer published a founder-focused look at embodied AI, emphasizing that robotics startups have to solve messy real-world deployment problems, not just intelligence benchmarks. FANUC America has also been showcasing physical AI and AI-enabled robotics demos for industrial automation.

The common thread is not simply, "robots are getting smarter." It is that the surrounding control layer is becoming just as important as the model. Physical AI needs identity, permissions, remote intervention, incident logs, fallback modes, maintenance workflows, and clear human ownership.

Why developers should care

Most developers will not build humanoid robots next month. But many will build software that touches the physical world: delivery routing, manufacturing dashboards, inspection apps, smart cameras, drones, kiosk workflows, lab automation, or field-service tools. Once AI starts making recommendations or taking actions in those systems, the app is no longer just an app.

A practical robotics stack starts to look like a production software stack with stricter consequences:

Observability: every autonomous action should leave a trace that a human can review.
Permission boundaries: the model should not be able to trigger every tool just because it can describe the task.
Human override: remote stop, pause, and handoff paths need to be designed before launch, not after the first incident.
Environment assumptions: robots need to know when the world has changed enough that they should slow down or ask for help.
Post-incident review: teams need logs, sensor context, prompts, model versions, and operator actions in one place.

This is less glamorous than a viral demo. It is also where durable products will be built.

The mistake: treating physical AI like a bigger chatbot

Chatbots trained teams to think in prompts, evals, memory, and tool calls. Those ideas still matter, but physical AI adds another layer: motion, force, location, people, equipment, and liability.

A warehouse robot that uses an AI planner is not just calling a function. It is navigating around workers and inventory. A robotic inspection system is not just summarizing images. It may decide whether a machine keeps running. A farm robot is not just classifying objects. It may act in an uncontrolled outdoor environment where lighting, weather, and obstacles change quickly.

Builders should resist the temptation to ship "agentic robotics" as a label. The real product is a controlled workflow where autonomy has a job description, a safe operating range, and a clear escalation path.

A builder checklist for physical AI products

If you are designing AI that touches devices, vehicles, cameras, machinery, or robots, start with these questions:

What actions can the AI take without approval?
Which actions always require a human?
What sensor confidence level is required before acting?
What happens when the network drops?
Can an operator replay exactly why the system acted?
Is there a role-based permission model for tools and machines?
What is the safest default when the model is uncertain?

Those questions are product requirements, not compliance paperwork. They decide whether users can trust the system in the real world.

The opportunity

Physical AI is still early enough that teams can shape the norms. The winners will not be the ones with the flashiest robot video. They will be the ones that make autonomy boring in the best way: monitored, bounded, recoverable, and useful.

For developers, that means the next wave of AI engineering may be less about squeezing another clever answer from a model and more about building reliable control systems around intelligence. The model matters. The operations layer may matter more.

References

Originally published at https://blog.jenuel.dev/blog/physical-ai-needs-an-operations-playbook

AI models are missing religious context. Builders should treat that as an eval problem.

Jenuel Oras Ganawed — Wed, 27 May 2026 08:06:23 +0000

If an AI assistant can summarize a contract, plan a workout, and debug a React component, it should also be able to recognize when a user's worldview matters. That is the uncomfortable point behind fresh research from a BYU-led, multi-institution consortium: major AI models may respond to religiously meaningful prompts as if faith is a side note, not a real part of how people reason.

This is not only a culture-war headline. For builders, it is a product-quality problem. If your app serves real people, it will eventually touch moral choices, grief, family decisions, education, community norms, or personal identity. In those moments, a model that flattens religious context can give answers that feel technically polished and personally tone-deaf.

What happened

Reports published in the last day describe research involving institutions including BYU, Baylor, Notre Dame, and Yeshiva University. The central claim is that major AI models show systematic gaps in how they handle faith and religion, including patterns that either ignore religious framing or treat some traditions more favorably than others.

The details matter, but the practical takeaway is simple: general-purpose AI is not automatically worldview-neutral just because it sounds calm. Models learn from data, ranking signals, safety policies, and product decisions. Those layers shape what the model treats as relevant, what it avoids, and what it assumes is the 'normal' frame for an answer.

Why developers should care

Most AI product teams already test for hallucinations, toxicity, latency, cost, and task completion. Fewer teams test whether the model respects the user's context. That gap becomes risky in apps for education, counseling, productivity, faith communities, healthcare-adjacent workflows, family tools, and any product that gives advice instead of just retrieving facts.

Imagine a student asking for help comparing ethical views, a parent asking how to discuss technology limits at home, or a church team building a study assistant. A generic answer might be grammatically correct while still missing the user's values. That is not a small UX issue. It is the difference between an assistant that feels helpful and one that feels like it was trained to politely erase part of the user.

Treat worldview as part of evaluation

The wrong response is to hard-code religious answers into every product. That would be brittle and, frankly, arrogant. The better response is to make worldview sensitivity measurable.

Add context-sensitive test prompts. Include prompts where the user's faith, denomination, or moral framework is relevant to the task.
Compare multiple models. Do not assume the most capable benchmark model is best for every community-facing use case.
Use human review from the affected community. A generic red-team pass will miss issues that a pastor, teacher, parent, or faith-informed user will notice quickly.
Give users control. Let users state preferences, sources, traditions, and boundaries instead of forcing one invisible default.
Separate respect from endorsement. A model can acknowledge a user's religious frame without pretending to be a spiritual authority.

The product lesson

AI builders love to talk about personalization, but many products still personalize at the shallow layer: tone, reading level, summary length, and favorite tools. Real personalization includes the assumptions a person brings into hard questions.

For JenuelDev readers building AI features, the next step is not panic. It is a better eval set. If your app could affect decisions, beliefs, education, or trust, test whether it handles faith and moral context with humility. The goal is not to make AI religious. The goal is to stop pretending that users are context-free.

The strongest AI products in the next few years will not be the ones that answer every question with the same polished neutrality. They will be the ones that know when context is part of the question.

References

Originally published at https://blog.jenuel.dev/blog/ai-religious-context-evals

AI for science is becoming a builder workflow, not a lab demo

Jenuel Oras Ganawed — Wed, 27 May 2026 02:57:42 +0000

The next useful AI shift may not be another chatbot with a slightly bigger context window. It may be the quiet move from answering questions to helping people run better investigations.

Google's newly surfaced Gemini for Science push is worth watching because it points at a practical pattern: AI tools built around research workflows, not just general conversation. That matters for developers, startup teams, analysts, students, and anyone who has to turn messy information into a defensible result.

This is not only about scientists in lab coats. The same workflow shows up when a builder evaluates a new API, a founder studies customer complaints, a security team investigates incidents, or a pastor researches a difficult topic before teaching. The job is not simply to get an answer. The job is to ask sharper questions, compare evidence, test assumptions, and document what changed your mind.

What changed

In the last 48 hours, AI news signals highlighted Google's Gemini for Science announcement and related coverage around AI tools for discovery. The official Google AI page describes Gemini for Science as tools and resources built to support scientific work, while Google Labs describes experimental science tools designed to complement the scientific method and explore how agents can accelerate discovery across domains.

Strip away the branding and the pattern is simple: AI is being shaped into a research partner. Not a replacement for judgment. Not a magic oracle. A partner that can help explore a problem space faster, surface candidate explanations, organize evidence, and give humans more paths to inspect.

Why builders should care

Most developers already do a version of scientific work every week. You notice a weird production bug. You form a hypothesis. You collect logs. You run a test. You reject the first explanation. You write the postmortem.

An AI research workflow can make that loop faster if it is used correctly. Instead of asking a vague question about why an app is slow, a better workflow is:

Summarize the symptoms and list the top five likely causes.
Rank those causes by what evidence would confirm or disprove them.
Generate a safe test plan that does not mutate production data.
Compare the results against the original hypotheses.
Write a short decision record with confidence levels and open questions.

That is a much better use of AI than asking for a confident answer and pasting it into Slack.

The strength: faster exploration

The best use case for AI in research-heavy work is breadth. AI can quickly map the territory: papers to read, terms to define, edge cases to consider, datasets to inspect, APIs to compare, failure modes to test.

For a small team, that is valuable. A solo developer can use the same pattern to compare authentication providers. A content creator can use it to evaluate claims before posting. A product manager can use it to sort feature requests into hypotheses instead of vibes.

The practical win is not that AI becomes the expert. The win is that it helps you become less blind before you make a decision.

The weakness: polished uncertainty

The danger is that research-flavored AI can sound more authoritative than it deserves. A well-structured answer with citations, tables, and confident language can still be wrong, incomplete, or built on weak assumptions.

That is why AI-for-science tools need a different habit than normal chatbots. Treat every output as a draft research assistant memo. Useful, but not final. Ask for sources. Ask what would falsify the claim. Ask which assumptions matter most. Keep the human responsible for the conclusion.

A practical workflow to try this week

If you build software, try this lightweight AI research loop on one real problem:

Define the question: Write the decision you actually need to make in one sentence.
List hypotheses: Ask AI for possible explanations, then delete the lazy ones.
Request evidence: For each hypothesis, ask what evidence would support or weaken it.
Run small tests: Prefer logs, benchmarks, user interviews, docs, or reproducible examples over opinions.
Document the decision: Ask AI to draft a decision record, then edit it until it reflects what you truly know.

This works for debugging, vendor selection, architecture choices, research notes, and even personal productivity experiments. The common thread is disciplined inquiry.

The bigger lesson

The AI products that will matter most are not always the flashiest demos. They are the ones that fit into serious human workflows: investigate, test, compare, decide, and explain.

That is why AI for science is a useful signal for builders. It shows where general AI is heading: away from one-shot answers and toward tools that help people reason through complicated work. The teams that learn that pattern early will get more value from AI than the teams still treating it like a search box with better grammar.

References

Originally published at https://blog.jenuel.dev/blog/ai-for-science-builder-workflow

Gemini Omni makes video generation feel more like editing

Jenuel Oras Ganawed — Tue, 26 May 2026 08:14:56 +0000

Video generation has been awkward for builders because it usually feels like gambling. You write a prompt, wait, squint at the result, then start over because the character changed clothes, the camera forgot the scene, or physics took the day off.

Google's new Gemini Omni pitch is different: do not treat video as a one-shot render. Treat it like a thing you can keep editing with language. That sounds small until you imagine using it for product demos, explainer clips, ministry media, app launch videos, or quick prototypes where you need the same subject to survive more than one instruction.

I am still cautious. Every AI video launch comes with perfect demo clips and messy real-world edge cases. But Gemini Omni is worth paying attention to because it pushes video generation closer to a normal creative workflow: reference something, generate a scene, then keep changing it without throwing everything away.

What Google announced

Google introduced Gemini Omni Flash as the first model in the Gemini Omni family. It starts with video output and accepts combinations of text, image, video, and audio as input. Google says the model can create videos grounded in Gemini's world knowledge, understand references, and edit through conversation.

The important part is not just "AI makes video." We already have that. The more useful idea is continuity. Google describes edits where characters stay consistent, the scene remembers previous instructions, and physics behaves more believably across changes. If that holds up outside polished demos, it removes one of the biggest annoyances in AI video work.

Gemini Omni Flash is rolling out through the Gemini app and Google Flow for Google AI Plus, Pro, and Ultra subscribers. Google also says it is available in YouTube Shorts Remix and the YouTube Create app for users 18 and older at no cost.

What this gives users

The useful mental model is "conversational video editing." Instead of generating ten disconnected clips, you can start with a rough direction and keep shaping it.

Turn a sketch, product screenshot, photo, or short clip into a video concept.
Change the background, motion, camera angle, or mood with a follow-up prompt.
Use a reference image or text description to keep the output closer to your intent.
Create short explainers where the visuals need to match a concept, not just look cinematic.
Remix social clips faster without needing a full editing setup.

For developers, the obvious use case is not replacing After Effects. It is getting from "I have an idea" to "I can show people what this might feel like" in minutes. That matters for landing pages, app demos, pitch decks, tutorials, and internal product discussions.

Where it looks strong

Gemini Omni seems strongest when the job needs references and iteration. A lot of AI media tools are impressive until you ask for one exact change. Then they regenerate the whole thing and accidentally break what worked.

If Omni can preserve characters, objects, scene layout, and motion across edits, it becomes much more practical. Builders could create a first version of a product walkthrough, ask for a closer camera shot, change the setting, simplify the background, or add a more natural transition without restarting the project.

Google is also leaning hard on physics and world knowledge. That matters because bad AI video often fails in subtle ways: hands pass through objects, liquids move strangely, shadows disagree with the light, and motion feels like a dream. Better physics does not make a video true, but it does make generated clips easier to use without distracting people.

Where I would be careful

The first weakness is control. Natural language is convenient, but it can be vague. Professional editors still need timelines, masks, keyframes, locked references, version history, and export settings. If Gemini Omni stays mostly prompt-driven, it will be great for drafts and social clips but frustrating for exact production work.

The second weakness is trust. AI video is getting good enough that viewers will not always know what they are watching. Google says Gemini Omni outputs include SynthID watermarking and can be verified through Gemini, Chrome, and Search. That helps, but builders should still label generated media clearly when the context could mislead people.

The third weakness is availability. The announcement is consumer-facing right now: Gemini app, Flow, YouTube Shorts Remix, and YouTube Create. If you are waiting for a clean developer API, predictable pricing, and automation hooks, watch the rollout before planning a product around it.

Practical ways builders can use it now

Start with low-risk work. Use Gemini Omni for prototypes, not final claims. A few useful experiments:

Create a 15-second app feature teaser from screenshots and a short script.
Turn a blog post section into a visual explainer for Shorts or Reels.
Prototype a course intro before hiring an editor or animator.
Generate three visual directions for a product launch, then pick one to polish manually.
Make internal concept videos so teammates can react to an idea before design work begins.

Keep the workflow honest. Save prompts. Save versions. Label generated clips. Do not use AI video to fake a product capability, a testimony, a person, or an event. The tool is powerful enough to make that tempting, which is exactly why builders need rules before the deadline pressure hits.

The bigger shift

Gemini Omni is another sign that multimodal AI is moving from "type a prompt and wait" toward interactive creation. The model is not just answering questions. It is trying to hold a scene in memory while you change it.

That is the part builders should watch. When models can keep context across text, images, audio, video, and edits, the interface for making things changes. Less blank canvas. More conversation. Less rendering from scratch. More steering.

It will still make weird clips. It will still need human taste. But if the editing loop is real, Gemini Omni could make AI video less like a slot machine and more like a rough creative partner you can actually direct.

References

Originally published at https://blog.jenuel.dev/blog/gemini-omni-video-editing-model

AI guardrails are not security boundaries

Jenuel Oras Ganawed — Mon, 25 May 2026 10:38:32 +0000

If a model's safety layer can be stripped away in minutes, builders should treat that as a design warning, not a scandal to rubberneck for a day and forget.

The latest signal came from a Financial Times report saying guardrails were removed from Meta and Google AI models quickly enough to make the old enterprise assumption feel shaky: buy the model, turn on the safety settings, and ship. That assumption was always too neat. It confuses model behavior with system security.

Guardrails matter. They reduce obvious harm, block lazy misuse, and make normal user interactions safer. But they are not a wall. They are closer to seatbelts. Useful, sometimes lifesaving, and absolutely not a replacement for brakes, road rules, and a driver who is awake.

The mistake builders keep making

A lot of AI app designs still put too much trust inside the prompt. The system prompt says what the model should do. The policy layer says what it should refuse. The tool instructions say what it may touch. Then the app gives the model access to files, messages, database records, support tickets, or payment workflows.

That is where the risk changes shape. A chatbot giving a bad answer is one problem. A chatbot with tools, memory, and permissions is a different animal.

If the model is the only thing deciding whether an action is safe, you have built a very polite security boundary. Polite boundaries fail when someone learns how to talk around them.

What guardrails are good at

Use guardrails for the layer they are good at: reducing bad outputs before they reach the user. They can catch toxic text, obvious policy violations, jailbreak attempts, sensitive data leaks, and low effort abuse. They also help with consistency, especially when multiple teams are building on top of the same model.

That is real value. I do not want every small app team hand-rolling safety rules from scratch. Most teams are better off using model provider controls, moderation endpoints, evaluation suites, and policy checks than pretending they can invent all of this alone.

But the job does not end there. A refusal message is not access control. A safer model is not a permissions system. A well-written instruction is not a sandbox.

How to design like the guardrail will fail

The practical answer is boring, which is usually a good sign in security.

Give the AI the least privilege it needs. If it only needs to summarize invoices, do not give it permission to delete invoices.
Keep tool calls behind normal server-side authorization. The model can request an action, but your backend should decide whether that action is allowed.
Separate reading from writing. Let the model draft, preview, or recommend before it can mutate production data.
Require confirmation for expensive, destructive, or public actions. Sending an email, charging a card, deleting data, and publishing content should not happen because a model sounded confident.
Log prompts, retrieved context, tool calls, refusals, and user confirmations. When something goes wrong, you need a trail that explains what happened.
Test with hostile prompts, not just happy path demos. Prompt injection should be part of your QA checklist if your app reads untrusted content.

This is the same mindset developers already use elsewhere. You do not trust form validation in the browser and skip validation on the server. You do not trust a friendly UI and skip database permissions. AI should not get a magical exception just because the interface is a conversation.

Where this gets uncomfortable

The uncomfortable part is that open and customizable models make this tradeoff sharper. Builders want local models, fine-tuning, low cost, private deployment, and fewer provider limits. Those are good reasons. I like that direction. The web is healthier when a few hosted APIs do not control every AI feature.

But flexibility also means safety behavior can be changed, removed, or bypassed. For internal tools, that may be acceptable if the surrounding system is well designed. For consumer apps, regulated workflows, kids' products, health advice, or anything that touches money, it gets harder to wave away.

The answer is not 'never use open models' or 'trust only closed models.' That is too simple. The answer is to decide what the model is allowed to do after it fails, not only what it promises to refuse when everything goes well.

A builder's checklist

Before shipping an AI feature with real permissions, ask these questions:

What can the model read?
What can it write or trigger?
Can untrusted text influence its instructions?
Can a user or document trick it into revealing private data?
What happens if the model ignores the system prompt?
Which actions require a human click?
Where do we review failures?

If the answers feel vague, the app is not ready for broad access yet. That does not mean you stop building. It means you narrow the scope, add friction where it matters, and move dangerous actions out of the model's direct reach.

The useful takeaway

AI guardrails are still worth using. Just stop treating them like locks.

For developers, the safer pattern is simple: let the model reason, draft, classify, summarize, and suggest. Let your application enforce identity, permissions, rate limits, confirmations, and audit logs. The model can be smart. The system around it has to be stubborn.

References

Originally published at https://blog.jenuel.dev/blog/ai-guardrails-are-not-security-boundaries

Age checks are becoming the new login wall

Jenuel Oras Ganawed — Mon, 25 May 2026 08:09:06 +0000

The internet is getting a new bouncer.

For years, the default online experience was simple: open the app, tap through the warning, and get inside. That era is starting to crack. In the last two days, news around Minnesota's proposed social media law, UK police support for tougher under-16 restrictions, Malaysia's age verification standards for platforms, and fresh privacy reporting from Arizona all pointed in the same direction. More websites and apps are going to ask users to prove age before they can participate.

I get why this is happening. Parents are tired. Schools are tired. Lawmakers are looking at the mental health, sexual exploitation, addictive design, and algorithmic rabbit holes around children online and deciding that vague platform promises are not enough.

But the hard part is not the slogan. The hard part is the checkpoint.

Safety rules can create privacy databases

An age gate sounds harmless until you ask what proof the site needs. A birth date typed into a form is easy to fake. A government ID is harder to fake, but now a social app, verification vendor, or data broker may touch documents that were never meant to float around the internet.

That tradeoff matters. If age checks become common, a normal web visit could start to feel like opening a bank account. Upload an ID. Scan a face. Let a third party estimate your age. Trust that the data is deleted. Trust that it is not breached later. Trust that the system does not quietly expand from child safety into general identity tracking.

That is a lot of trust to demand from people who have spent the last decade watching companies mishandle far less sensitive data.

Developers will inherit the messy version

Policy debates often treat verification like a switch: require it, then platforms comply. Anyone who builds software knows it will be messier than that.

Small apps will need vendors. Vendors will need integrations. Teams will need to decide what they store, what they log, what happens when verification fails, and how to support users who do not have the expected documents. There will be edge cases: shared devices, foster care, undocumented users, VPNs, people who look younger or older than they are, and adults who simply do not want to hand over more personal information to read a website.

The product question is not only, "Can we verify age?" It is, "Can we do it without building a surveillance habit into the front door?"

Parents still cannot outsource discipleship to a popup

There is a faith-and-tech angle here that is easy to miss. Age verification may reduce some harm, and I hope it does. But no law can teach a child wisdom. No popup can replace a parent who pays attention. No platform rule can form self-control, patience, or discernment.

That does not mean regulation is useless. It means regulation is not salvation. Families still need conversations about what apps are doing to attention, comparison, lust, anger, and loneliness. Churches and youth leaders need to talk about the internet as a formation environment, not just a list of dangers.

The web trains us. Sometimes it trains us quietly. That is why this age-check debate is bigger than compliance.

What good age checks should look like

If age verification becomes normal, the least-bad version should be boring, narrow, and temporary.

Collect the minimum proof needed for the specific legal requirement.
Keep raw documents away from the app whenever possible.
Use vendors that publish clear deletion and retention rules.
Give users a real explanation, not a dark-pattern consent screen.
Do not reuse age checks as a general identity system.

That last one is the line I keep coming back to. A child-safety rule should not become an excuse to make everyone easier to track.

The next login wall

Cookie banners trained people to click without reading. Paywalls trained people to decide whether content is worth the price. Age gates may train people to hand over identity proof as casually as an email address.

Maybe some of that is necessary. Maybe parts of the internet really should be harder for kids to enter. But if we build the next version of the web around constant identity checks, we should be honest about what we are trading away.

Protecting children is worth serious effort. It is also worth doing carefully. A safer internet that normalizes more surveillance is not an obvious win. It is a warning label with good intentions.

References

Originally published at https://blog.jenuel.dev/blog/age-checks-are-becoming-the-new-login-wall

Your attention is a dependency. Audit it like one.

Jenuel Oras Ganawed — Sun, 24 May 2026 08:08:49 +0000

I like useful apps. I also know how quietly they turn into background noise.

You install one thing for a real reason. A calendar. A Bible app. A note app. A bank app. A chat app for one group you cannot leave. Then, months later, your phone has become a tiny committee meeting that follows you into the kitchen, the car, and bed.

That is why one small trend from the last couple of days caught my eye: people are starting to talk less about adding smarter tools and more about deleting the pile. One writer reset their phone with zero apps and had to face which ones they actually needed. Another argued that avoiding AI tools can be a way to protect the hard work of thinking. Philosopher Yuk Hui warned that tech companies want to exploit and control our attention every second.

Different stories, same nerve. The issue is not whether technology is good or bad. The issue is whether we still notice what it is doing to us.

The phone audit developers actually understand

Developers already know this pattern. A project starts clean, then dependencies creep in. One package saves time. Another fixes a minor pain. A third gets pulled in by something you barely remember installing.

Then one day the build is slow, the security alerts are noisy, and nobody knows why half the stack is there.

Phones work the same way. Apps become personal dependencies. Some are necessary. Some are convenient. Some are just old habits wearing a useful costume.

A real attention audit is not a dramatic digital detox. It is closer to opening package.json and asking, "Do we still need this?"

Convenience has a cost, even when the app is good

The tricky part is that many of these tools are genuinely helpful. Maps help. Reminders help. Bible plans help. Messaging helps. AI can help too, if you use it with care.

But convenience does not stay neutral forever. Every tool trains a reflex. Tap when bored. Check when anxious. Ask the machine before wrestling with the thought yourself. Fill the silence before it has a chance to become prayer, reflection, or an actual idea.

I do not think the answer is to throw the phone into the ocean. Most of us have jobs, families, churches, clients, and responsibilities that run through these devices. The better question is simpler: which apps are serving your life, and which ones are quietly steering it?

A practical audit for the weekend

Try this before installing another productivity tool:

Move every nonessential app off your home screen for 48 hours.
Turn off notifications for anything that does not involve a real person or a real deadline.
Delete one app you keep opening without a reason.
Write down the moments when you reach for your phone automatically.
Keep one blank space in your day where you do not replace boredom with content.

That last one is harder than it sounds. Boredom feels inefficient. But boredom is often where your brain starts cleaning up after the noise.

Faith makes this more uncomfortable

For Christians, attention is not just a productivity resource. It is part of discipleship.

What you repeatedly give your attention to will shape what you love, fear, envy, and chase. That does not make every app a spiritual threat. It does mean your notification settings are not morally neutral in the way we sometimes pretend they are.

A phone can carry Scripture, prayer reminders, sermons, church messages, and tools for serving people. It can also carry an endless stream of comparison, outrage, lust, distraction, and low-grade restlessness. Often it carries both.

So the audit is not about becoming anti-tech. It is about becoming honest.

Keep the tools that make you more present

The best apps do not just save time. They return attention to the right place.

Keep the tool that helps you remember a friend. Keep the calendar that protects family dinner. Keep the Bible app if it actually gets you reading instead of just collecting streaks. Keep AI if it helps you draft, learn, or build without outsourcing your judgment.

But remove the tools that keep asking for little pieces of you and giving almost nothing back.

Your attention is a dependency. Audit it before it audits you.

References

Originally published at https://blog.jenuel.dev/blog/your-attention-is-a-dependency-audit-it

AI therapy apps need boundaries before they need hype

Jenuel Oras Ganawed — Sat, 23 May 2026 08:03:36 +0000

The most intimate app on your phone might soon be the one that talks back when you are anxious at midnight.

That sounds useful. It also sounds dangerous if we treat it like another productivity toy. A note app can lose your grocery list. A mental health app can hold your grief, your panic, your marriage problems, your prayer life, your self-harm thoughts, and the parts of your story you have not told anyone else yet.

That is why the latest wave of AI mental health apps deserves more than the usual startup excitement. In the last two days, the space got fresh attention from several directions: The Path, a new AI mental health startup connected to Tony Robbins and Calm alumni, announced funding and pitched itself around safer AI support; reporters kept digging into what mental health apps do with deeply personal data; and researchers published new work on long-running health AI agents. Put together, it feels like the category is moving from novelty to infrastructure.

I do not think the answer is to panic. I also do not think the answer is to download the newest companion app and pour your soul into it without asking hard questions first.

The appeal is obvious

People need help at inconvenient times. Therapists are expensive. Waiting lists are long. Some people are embarrassed to say out loud what they can type into a phone. For many users, an AI chat feels less threatening than a real conversation.

That does not make it therapy. But it explains why these products keep showing up.

A good mental health app can help someone journal, name a feeling, practice breathing, track a pattern, or decide to contact a real person. Those are reasonable uses. I can see the value, especially for people who would otherwise sit alone with the same looping thought for hours.

The problem starts when the app quietly becomes a confessional, a therapist, a coach, and a data collector all at once.

Your most sensitive data should not be treated like app exhaust

Most of us already give apps too much. Location, contacts, sleep, spending, search history. Mental health data is different. It is not just behavior. It is meaning.

If an app knows that you feel hopeless every Sunday night, that you are fighting with your spouse, or that you are trying to stop a private addiction, that information can be used in ways that feel invasive even when a company says it is following its policy.

Privacy policies are not comfort. They are contracts most people never read, written by companies that may change direction when money gets tight.

For Christian users, this has another layer. We should be careful about outsourcing confession, counsel, and comfort to a system that cannot love us, pray for us, or carry responsibility for us. Technology can support care. It cannot replace community, wisdom, or pastoral presence.

What I would ask before trusting one

Before using an AI mental health app for anything serious, I would want plain answers to a few questions:

Does the app clearly say it is not a therapist?
Can I delete my data, including chat history and derived insights?
Does it use my conversations to train models?
What happens if I mention self-harm or abuse?
Can a human professional be reached when the situation is serious?
Is the business model subscription, employer benefit, ads, data partnerships, or something else?

If those answers are buried, vague, or dressed up in soothing language, that is the answer.

Builders should design for restraint

Developers love making tools more capable. In mental health, capability is not the only goal. Restraint matters.

An app should know when to stop pretending it can help. It should nudge users toward real care when the conversation crosses a line. It should collect less data than it technically could. It should make deletion boring and obvious. It should not gamify vulnerability just to improve retention.

The best version of this category is not an always-on synthetic therapist. It is a careful support tool that helps someone take the next right step.

Sometimes that step is journaling. Sometimes it is calling a friend. Sometimes it is booking a counselor. Sometimes it is closing the app and telling the truth to another human being.

Use the tool, but do not hand it the whole room

I am not against AI mental health tools. I am against pretending they are neutral containers for pain.

If you try one, use it with boundaries. Do not assume private means protected. Do not let a chatbot become your only place to process life. And if you are building one, treat every message like a person trusted you with something fragile.

Because they did.

References

Originally published at https://blog.jenuel.dev/blog/ai-therapy-apps-need-boundaries

Your AI is not bad, your instructions are

Jenuel Oras Ganawed — Fri, 22 May 2026 16:48:24 +0000

Your AI is not bad, your instructions are

Most AI failures are not model failures. They are instruction failures. This guide shows how to write clearer prompts, give better context, use examples, set boundaries, and turn AI from a clever guesser into a reliable collaborator.

Most people judge an AI model too quickly. They type one vague request, get a shallow answer, and conclude the tool is bad.

Sometimes the model really is the problem. It may hallucinate, misunderstand a niche domain, or fail at a task that needs fresh data or exact execution. But a lot of the time, the AI did exactly what it was asked to do. The problem is that the request was incomplete, fuzzy, or missing the information a human coworker would normally ask for before starting.

AI is not magic. It is a prediction system that responds to the shape of your instruction. If the instruction is lazy, the answer usually feels lazy. If the instruction is specific, grounded, and testable, the answer gets much better.

That does not mean you need to write a novel every time you use ChatGPT, Claude, Gemini, Copilot, or any other assistant. It means you need to stop treating prompts like search queries and start treating them like task briefs.

The prompt is the interface

With normal software, the interface gives you buttons, menus, validation, and guardrails. If you fill out a form wrong, the app tells you. With AI, the interface is language. That makes it powerful, but it also makes it easy to be sloppy.

When you ask, "Write me a blog about AI," the model has to guess almost everything: audience, tone, length, point of view, structure, level of technical depth, examples, sources, and what you actually believe. It will usually choose the safest average answer. That is why so much AI writing sounds like a conference brochure.

A better request sounds more like this:

Write a 1,200-word blog for software developers and creators. The argument is that many bad AI outputs come from weak instructions, not weak models. Use a direct, practical tone. Include examples of bad prompts and better prompts. Avoid hype. Include references to prompt engineering research and documentation. End with a reusable checklist.

Same tool. Different interface. Better result.

AI needs context more than clever wording

People often think prompt engineering is about secret phrases. It is not. Most of the value comes from context.

If you hired a designer, developer, editor, or assistant, you would not say, "Make this better" and walk away. You would explain who the work is for, what good looks like, what constraints matter, what has already failed, and what should be avoided.

AI needs the same thing. It needs the background that lives in your head.

Who is the audience?
What is the goal?
What should the output be used for?
What format do you need?
What should it avoid?
What examples should it follow?
What sources or facts should it rely on?

Without that, the model fills in the blanks. Sometimes it guesses well. Sometimes it invents a business-school version of what you meant.

Bad prompts hide the standard of success

The most common instruction mistake is asking for an output without defining success.

"Make this landing page better" is not enough. Better for whom? Better at conversion? Better at clarity? Better for SEO? Better for trust? Better for mobile users? Better for a skeptical buyer who has never heard of you?

Try this instead:

Review this landing page for a first-time visitor. The goal is to make them understand the product in less than 10 seconds and click the download button. Identify confusing copy, missing trust signals, weak calls to action, and anything that may hurt mobile readability. Give the answer as a prioritized list with suggested replacement copy.

That prompt gives the model a job, a user, a goal, evaluation criteria, and an output format. The answer will almost always be more useful because the AI no longer has to invent the target.

Examples beat explanations

If you want a specific style, show it. If you want a certain format, show it. If you want a category of answer, show one good example and one bad example.

This is one reason few-shot prompting works so well. Research and practice both show that models respond strongly to examples in the prompt. You are not just describing the task. You are giving the model a pattern to continue.

For example, instead of saying "write in my style," paste two or three paragraphs you actually wrote and say what you want preserved: short sentences, plain words, personal opinion, no corporate tone. If you want a bug report, show the exact structure. If you want sermon notes, show the rhythm and sections. If you want a product changelog, show a previous changelog that worked.

Examples reduce guessing. That is the whole game.

Give the AI boundaries before it makes a mess

AI assistants are eager. That eagerness is useful when you want momentum, but dangerous when the task has rules.

If the assistant should not invent statistics, say so. If it should ask questions before making assumptions, say so. If it should cite sources, say so. If it should keep the answer under 500 words, say so. If it should not change code outside a certain folder, say so.

Good constraints do not make the model less creative. They keep it pointed in the right direction.

Useful constraints sound like this:

Do not invent facts. If a fact is missing, write "needs source" instead.
Use only the information pasted below.
Ask up to three clarification questions if the task is ambiguous.
Return the answer as JSON matching this schema.
Do not edit files outside the src/components folder.
Prefer simple language over marketing language.

These boundaries are boring. They also save hours.

Ask for the process when the task is complex

For simple tasks, direct prompting is fine. For complex tasks, ask the model to slow down.

Chain-of-thought research showed that large language models often perform better on reasoning tasks when prompted to work through intermediate steps. You do not always need to see a hidden internal reasoning trace, and many modern tools handle reasoning differently now, but the practical lesson still matters: complex work improves when you separate thinking from final output.

Instead of asking, "Build me a marketing plan," ask for stages:

First, identify the audience and assumptions.
Then list possible angles.
Then choose the strongest angle and explain why.
Then draft the plan.
Finally, critique the plan for weak points.

This works because the model is less likely to collapse everything into a polished but shallow answer. It has to make its intermediate choices visible enough for you to correct them.

Treat AI output like a first draft, not a final authority

Even with great instructions, AI can be wrong. It can cite the wrong source, misread your intent, or produce code that looks clean but breaks an edge case.

The point of better instructions is not blind trust. The point is better raw material.

For writing, that means you still edit. For code, you still run tests. For research, you still check sources. For business decisions, you still apply judgment. AI can move the work forward, but it should not quietly replace verification.

A good workflow is simple:

Brief the AI clearly.
Review the output critically.
Ask it to revise against specific feedback.
Verify facts, links, code, and assumptions.
Save the prompt pattern if it works.

A reusable instruction template

When a prompt matters, use this structure:

Role: What perspective should the AI take?

Task: What exactly should it produce?

Context: What background does it need?

Audience: Who is this for?

Constraints: What rules, limits, or preferences matter?

Examples: What should it imitate or avoid?

Output format: Markdown, JSON, bullet list, table, code patch, email, article, or something else?

Verification: How should the result be checked?

Here is a practical version:

You are an experienced technical editor. Rewrite the article below for independent developers who use AI tools. Keep the tone direct and human. Remove hype, vague claims, and filler. Preserve the main argument. Add concrete examples where the draft is abstract. Do not invent sources. Return the result in Markdown with H2 headings, short paragraphs, and a final checklist.

That prompt will not solve every problem. But it gives the model a real assignment instead of a wish.

The better question

When AI gives you a bad answer, do not only ask, "Which model should I use instead?" Sometimes the better question is, "What did I fail to tell it?"

Did you define the audience? Did you include context? Did you show examples? Did you explain what good looks like? Did you set boundaries? Did you ask for sources? Did you verify the result?

Better models help. Better instructions help more often than people want to admit.

Your AI might not be bad. It might just be under-briefed.

References

Originally published at https://blog.jenuel.dev/blog/your-ai-is-not-bad-your-instructions-are

Faith tech is moving from Bible apps to wearables. Pay attention.

Jenuel Oras Ganawed — Fri, 22 May 2026 08:04:14 +0000

For years, faith tech mostly meant Bible apps, prayer reminders, sermon clips, and maybe a reading plan that quietly judged you when you missed three days in a row.

Now it is starting to move onto the body.

That is why the news around Glorify and Confidein caught my eye. In the last two days, several outlets covered their merger and the push behind a Christian smart ring. The product pitch is simple enough: take the familiar smart ring idea, then aim it at prayer, reflection, emotional check-ins, and spiritual habits instead of only steps, sleep, and heart rate.

I do not think we should dismiss that as a gimmick. I also do not think we should clap for it just because it has Christian branding. Wearables are intimate technology. They sit closer to us than our phones. They collect signals from the body, interrupt us in tiny moments, and slowly teach us what deserves attention.

The shift is bigger than one ring

The interesting part is not whether this specific ring becomes popular. Maybe it does. Maybe it becomes another gadget people buy with good intentions and forget to charge.

The bigger shift is that faith apps are leaving the screen-only era. A Bible app waits for you to open it. A wearable can nudge you before you ask. It can turn spiritual practice into a loop of prompts, reminders, streaks, and biometric feedback.

That can be helpful. A quiet reminder to pray during a stressful day is not a bad thing. A tool that helps someone pause before reacting in anger could genuinely serve them well. Most of us already let our devices interrupt us for worse reasons.

But the question is not only, "Can this help?" It is also, "What kind of person does this train me to become?"

Attention is a spiritual issue now

Modern apps are very good at turning desire into routine. Fitness apps do it. Language apps do it. Social apps do it, sometimes in ugly ways. They create loops: reminder, action, reward, repeat.

Faith tech will have to decide whether it wants to copy that playbook or challenge it.

A prayer reminder can be an act of care. A streak counter can become a small idol. A mood check-in can help someone notice what is happening inside them. It can also train them to outsource self-examination to a dashboard.

I am not against the category. I use digital tools for faith, work, reading, and writing. Tools matter. Good tools remove friction. Bad tools quietly reshape your habits while pretending to be neutral.

That is why Christian builders need to be more honest than the normal tech market. If the product is about discipleship, then growth cannot mean the same thing it means in consumer apps. More notifications, more engagement, more daily active users, more time in app. Those are business metrics. They are not automatically spiritual fruit.

Privacy cannot be an afterthought

Faith data is sensitive. Health data is sensitive. A wearable that touches both deserves a higher bar.

If a device collects emotional patterns, prayer habits, journal entries, biometric signals, or location-adjacent routines, users should know exactly what is stored, what is shared, and what is used for personalization. Plain language. No foggy privacy pages that require a lawyer and a free afternoon.

This matters even if the company has good intentions. Especially then, actually. Trust is not built by saying, "We are faith-based, so you can relax." Trust is built by giving users control, collecting less data than you could, and making deletion real.

Builders should ask harder questions

If you are building in faith tech, the temptation is to ask product questions first. What feature makes people come back? What habit loop works? What can we personalize? What can AI summarize?

Those are useful questions, but they are not enough.

Ask these too:

Does this tool create quiet, or does it add one more voice to an already noisy life?
Does it help people practice faith, or mostly help them measure it?
Can the user say no without feeling guilty?
Are we collecting this data because it serves the person, or because it serves the roadmap?
Would we still build this feature if retention were not a metric?

Those questions are harder to pitch in a deck. They are also closer to the point.

A careful yes

I want faith tech to mature. I want better Christian apps, better tools for prayer, better ways to help people build rhythms that survive busy lives. A wearable may be part of that future.

But we should be careful with any device that promises to sit between our bodies, our habits, and our relationship with God.

The best version of faith tech will not be the one that captures the most attention. It will be the one that gives attention back.

Trend signals checked: Google News results from May 20-22, 2026 on Glorify, Confidein, and the Christian smart ring; coverage from CBN, Dallas Express, Charisma, and The National Law Review; recent JenuelDev posts were reviewed to avoid repeating the AI-agent, VS Code extension security, and AI subscription angles.

Originally published at https://blog.jenuel.dev/blog/faith-tech-wearables-attention