DEV Community: Jenuel Oras Ganawed

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

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

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

Gemini Omni shows where AI video tools are heading next

Jenuel Oras Ganawed — Mon, 15 Jun 2026 08:06:16 +0000

The most interesting AI products are starting to look less like chat boxes and more like creative workbenches. That is why the Gemini Omni chatter from the last 48 hours is worth paying attention to, even if you do not build media apps.

Google's official blog surfaced an "Introducing Gemini Omni" item, while early coverage framed it around video editing, multimodal interaction, and a more futuristic Gemini experience. Taken together, the signal is clear: frontier AI is moving from answering prompts to helping users reshape rich media directly.

For builders, that matters because video is not a niche format anymore. It is documentation, marketing, education, product support, church announcements, launch demos, and internal training. If AI can understand and edit video as naturally as it edits text, a lot of everyday software workflows will need to change.

What users may actually get

The practical promise is not just "AI makes a video." The better version is an assistant that can inspect a clip, understand the user's goal, suggest edits, generate alternatives, and keep the human in control.

Imagine asking for a 90-second product walkthrough to become a 20-second social clip, then asking the same tool to produce captions, a clean thumbnail idea, and a version with the awkward pause removed. That is a different experience from opening a traditional editor, hunting through menus, and doing every small cut by hand.

The likely near-term value is speed on repetitive creative work:

Turning long demos into short launch clips.- Cleaning up recorded tutorials without hiring an editor.- Creating variations for TikTok, YouTube Shorts, Instagram, and internal docs.- Generating quick drafts that a human can polish instead of starting from a blank timeline.

Why developers should care

Multimodal AI changes product expectations. Users will not only expect apps to store videos. They will expect apps to understand them.

A support platform could summarize a screen recording and identify where the user got stuck. A learning app could turn a lecture into chapters and practice questions. A church media team could turn a Sunday recap into clips for volunteers, youth ministry, and announcements. A developer tool could watch a bug reproduction video and attach structured steps to an issue.

The winners will not be the products that paste a model into a sidebar. The winners will be the products that redesign the workflow around what the model can see, hear, and change.

Strengths to watch

The strongest part of this trend is compression of creative labor. If the model can reason across text, audio, frames, timing, and user intent, it can remove the annoying middle steps between an idea and a usable asset.

That is useful for small teams. A solo founder, pastor, teacher, or indie developer rarely has a full media department. AI video tools can become the assistant that makes good-enough content possible without turning every project into a production week.

It also opens new interface patterns. Instead of exposing every feature as a button, products can let users describe outcomes: "make this clearer, shorter, warmer, and suitable for a first-time visitor." That is a big shift from tool-first design to intent-first design.

Weaknesses and risks

The weak spots are also obvious. Video is expensive to process, hard to verify, and easy to misuse. A model that edits video needs guardrails for identity, consent, brand safety, copyright, and factual context.

Quality will vary too. AI can create a polished-looking result that quietly removes important context. A sermon clip can lose the point. A product demo can hide a limitation. A tutorial can become misleading if the model cuts the wrong step. Human review is not optional for anything public or sensitive.

Builders should also expect cost and latency tradeoffs. Text AI can feel instant. Video AI often needs heavier compute, background jobs, previews, retries, and clear progress states. If the workflow feels like waiting for a mystery machine, users will bounce.

A practical builder checklist

If you are building around AI video or multimodal workflows, start smaller than the hype suggests:

Pick one painful job. Summarize support recordings, cut long demos, generate captions, or extract chapters. Do not try to build the whole editing suite first.- Keep the original visible. Let users compare the source and AI output before they publish.- Add undo and version history. AI edits should feel reversible, not magical and permanent.- Make review part of the workflow. Use approval states, preview links, and warnings for public-facing exports.- Track cost per output. Video workflows can quietly become expensive. Measure per minute, per export, and per retry.

The bigger point

Gemini Omni is interesting because it points toward AI that works inside the media itself, not just beside it. That is where AI products become more useful: less prompt theater, more workflow leverage.

The lesson for developers is simple. Do not ask, "How do I add AI video to my app?" Ask, "Where does my user lose time because the app cannot understand the media they already have?" That question leads to better products.

The next wave of AI tools will not only write words. They will inspect, edit, summarize, remix, and package the messy raw material of real work. Video is one of the clearest places to watch that happen.

References

Google Blog via Google News: Introducing Gemini Omni- Startup Fortune: Google is turning Gemini Omni into a video editing test for AI- Memeburn: Claude vs Gemini (2026)- Jetstream Blog: June 2026 Pixel Drop promo videos

Originally published at https://blog.jenuel.dev/blog/gemini-omni-video-ai-workflow

Long context is not AI memory: a builder playbook for reliable AI apps

Jenuel Oras Ganawed — Sun, 14 Jun 2026 08:04:08 +0000

The easiest AI mistake right now is treating a giant context window like a real memory system. It feels reasonable. If a model accepts hundreds of thousands or millions of tokens, why not paste the docs, the logs, the repo, the chat history, and let the model sort it out?

Because the bill comes due in reliability.

The fresh signal this week is not just one product launch. It is a pattern: builders are talking about context rot on Hacker News, infrastructure projects like LMCache are trending because repeated prompts are expensive, and security tools like NVIDIA's SkillSpector are appearing because agent ecosystems now install skills and tools with serious trust implications. The message is simple: AI apps are moving from prompt demos into systems engineering.

The context window is a workspace, not a database

A large context window is useful. It lets a model inspect more source files, compare longer documents, and keep more task state in view. But it is still a temporary workspace. It is not a durable store, a ranking engine, a permission model, or a guarantee that the model will use every detail equally well.

That distinction matters for builders. If your app stuffs everything into the prompt, you are relying on the model to solve four jobs at once: remember, search, prioritize, and reason. Sometimes it works. Under production load, with messy user data and long-running sessions, it gets brittle.

A healthier design treats context like screen space on a desk. Put the most relevant things in front of the model. Keep the rest indexed, retrievable, summarized, or cached. When the task changes, refresh the workspace instead of dragging the whole history forward forever.

What users actually get from bigger context

Bigger context is still a real capability. Users get fewer hard cutoffs, better long-document workflows, and more room for multi-step tasks. Developers can build assistants that read a policy pack, inspect a dependency tree, or compare several long transcripts without immediately chunking everything into tiny pieces.

The weakness is that bigger does not automatically mean sharper. Long prompts can bury the important instruction under old messages, duplicate facts, irrelevant logs, and conflicting examples. A support bot may answer from an outdated policy paragraph. A coding assistant may cling to an old stack trace after the bug has changed. A research assistant may cite a weaker source because it was closer to the end of the prompt.

That is why the winning product experience is not "we support a huge context window." It is "we know what to put in the context window, when to remove it, and how to prove the answer came from the right evidence."

A practical context budget

For most AI apps, I would start with a context budget instead of a context dump:

Pin the task contract. Keep the user's current goal, constraints, output format, and safety rules short and stable.
Retrieve only the top evidence. Use search, metadata filters, embeddings, or explicit user selections to bring in the few documents that matter.
Summarize stale state. Long conversations should compress old decisions into a running brief, not carry every message forever.
Separate facts from instructions. Retrieved documents should be treated as data, not as commands the model must obey.
Measure context failures. Add tests for missed facts, wrong-source answers, stale memory, and instruction conflicts.

This is not glamorous, but it is the difference between a clever demo and a tool people trust with real work.

Why caching is becoming part of the architecture

Projects like LMCache point at another practical issue: repeated long-context work is costly. If your application repeatedly sends the same manual, codebase, contract, or knowledge base into a model, you are paying latency and compute costs again and again.

Caching does not remove the need for retrieval or careful prompting, but it changes the economics. A long context that is expensive on the first pass can become more usable when the system reuses intermediate state. For internal tools, customer support, code review, and document-heavy workflows, this can turn AI from "impressive but slow" into "fast enough to use all day."

The builder question is not only "which model has the largest window?" It is "which parts of my workload repeat, and how can I avoid recomputing them?"

Agent skills need security review too

The other side of context engineering is tool trust. AI agents increasingly load skills, connectors, MCP servers, browser actions, shell commands, and workflow recipes. That makes them useful, but it also expands the attack surface.

NVIDIA's SkillSpector is interesting because it treats agent skills like software supply chain artifacts. That is the right mental model. A skill can hide prompt injection, data exfiltration, unsafe shell behavior, or excessive permissions. If your agent can read files, call APIs, or modify a repo, then installing a skill is closer to installing a plugin than copying a harmless prompt.

For teams building with agents, the baseline should be simple: review skills before installing them, limit permissions, log tool calls, and keep user data out of untrusted instructions. Convenience is not worth silent agency.

The builder takeaway

The near future of AI apps will not be won by context size alone. It will be won by context discipline.

Use large windows when they help. But design as if attention is scarce, memory is imperfect, latency matters, and tools can be dangerous. That mindset produces better apps: assistants that cite the right source, agents that do not wander, support bots that stay current, and developer tools that remain useful after the first impressive demo.

Long context is a powerful workspace. Reliable AI products still need architecture.

References

Originally published at https://blog.jenuel.dev/blog/long-context-is-not-ai-memory-builder-playbook

Healthcare-specific AI is the practical model story builders should watch

Jenuel Oras Ganawed — Sat, 13 Jun 2026 08:05:15 +0000

The most useful AI news this week is not another chatbot leaderboard. It is the signal that healthcare AI is moving toward models built around real clinical work, not generic demos dressed up with medical vocabulary.

Reports from the last 48 hours say Nvidia and Abridge are working on a healthcare-specific AI model, with coverage also noting Abridge's broader expansion around clinical documentation and partnerships. That matters because healthcare is exactly where generic AI starts to show its limits: the language is specialized, the workflow is messy, and the cost of being confidently wrong is high.

For builders, the lesson is bigger than healthcare. The next durable AI products will not win only by calling the strongest foundation model. They will win by packaging domain context, workflow constraints, privacy expectations, evaluation, and human review into a product that professionals can actually trust.

Why a healthcare-specific model matters

Clinical notes are not normal text. They mix shorthand, patient history, medications, billing requirements, care plans, follow-up instructions, and institutional habits. A general model can summarize a conversation, but a useful clinical system has to understand what should be captured, what should be omitted, what needs clinician confirmation, and how the output fits into existing systems.

That is why a domain-specific model is interesting. It suggests a shift from "AI can write text" to "AI can operate inside a profession's rules." In healthcare, that could mean better note generation, cleaner handoffs, more consistent documentation, and less administrative load for clinicians. But the same pattern applies to legal intake, construction estimates, accounting workflows, education feedback, and customer support in regulated industries.

What users actually get

If this direction works, users get less friction rather than more magic. A doctor does not need a model that sounds impressive in a demo. They need fewer clicks after a patient visit, notes that match the encounter, and a system that makes review faster instead of creating new cleanup work.

Patients may benefit indirectly too. When documentation tools are better, clinicians can spend less time acting like data-entry workers and more time paying attention. That is the best version of AI in healthcare: not replacing judgment, but removing some of the bureaucracy around it.

The weakness is obvious: domain-specific does not automatically mean safe. A model can be trained on better context and still miss nuance, over-summarize, or produce output that looks polished while hiding uncertainty. Healthcare products need audit trails, review checkpoints, strong privacy controls, and clear responsibility boundaries.

The practical builder takeaway

Builders should read this as a product architecture clue. If you are building an AI app for a real industry, do not stop at prompt engineering. Ask harder questions:

What does the expert workflow look like before and after the model responds?
Which parts of the output must be verified by a human before they become official?
What domain vocabulary, templates, policies, and edge cases must the model understand?
How will you measure quality beyond "the answer sounds good"?
What happens when the model is uncertain, incomplete, or contradicted by source data?

The best AI products in serious domains will feel less like a blank chat box and more like a guided workstation. They will combine retrieval, structured data, custom models, validation rules, user permissions, and review flows. The model is important, but the surrounding system is what turns it into a product.

Where Nvidia fits in

Nvidia's role is also worth watching. The company is not just selling GPUs into the AI boom. It keeps positioning itself as infrastructure for industry-specific AI: hardware, optimized inference, model services, and partner ecosystems. Healthcare is a natural target because the data is complex, the workflows are expensive, and the demand for automation is real.

For developers, that means the AI stack is becoming more vertical. Instead of one generic model API for every use case, teams may increasingly choose specialized model families, deployment environments, compliance-ready infrastructure, and vendor partnerships based on the industry they serve.

My read

This is the healthier version of AI hype: less "the model can do everything" and more "the model is being shaped for a job." That is where real adoption happens.

Still, builders should stay sober. Healthcare AI has to earn trust slowly. A polished note is not enough. The product has to prove that it reduces burden without hiding mistakes, weakening accountability, or turning clinicians into model supervisors all day.

The bigger trend is clear: practical AI is becoming domain-specific, workflow-aware, and infrastructure-heavy. If you are building in AI this year, that is the bar to aim for.

References

The Wall Street Journal: Nvidia developing an AI healthcare model with Abridge, reported June 13, 2026
Fierce Healthcare: Nvidia, Abridge collaborate to develop healthcare-specific AI model
Healthcare Dive: Abridge partners with Eli Lilly and Nvidia as AI scribe eyes expansion, reported June 12, 2026
Nvidia Healthcare and Life Sciences AI overview
Abridge healthcare AI documentation platform

Originally published at https://blog.jenuel.dev/blog/healthcare-specific-ai-practical-model-story-builders

AI music detectors are becoming a product feature, not a gimmick

Jenuel Oras Ganawed — Fri, 12 Jun 2026 08:04:18 +0000

The interesting part of Deezer's new AI music detector is not that it can label a synthetic track. The interesting part is that detection is moving from a private moderation tool into something normal users can touch.

That is a bigger product shift than it first sounds. For the last two years, most AI detection debates have lived in policy rooms, school dashboards, copyright disputes, and platform trust teams. Now a music listener can paste or connect playlists from major streaming services and ask a simpler question: how much of what I am hearing was made by AI?

This is where AI stops being an abstract technology story and becomes a user-interface problem. Builders should pay attention.

What happened

Deezer announced a free AI music detector for playlists, and the news quickly spread across Reuters, TechCrunch, Engadget, MacRumors, Digital Music News, and Hacker News within the last day. The basic pitch is straightforward: users can check playlists from services such as Spotify, Apple Music, and others to identify tracks that Deezer's system believes are AI-generated.

Deezer has been unusually vocal about AI music volume. Earlier this year, the company said a growing share of daily uploads to its platform were fully AI-generated. This new detector turns that backend concern into a visible consumer feature.

That matters because AI labeling is usually treated as a compliance obligation. Deezer is testing whether it can also be a product affordance: something that helps people decide what to trust, what to skip, and what deserves attention.

What users actually get

For normal listeners, the value is not perfect truth. No detector can promise that. The value is friction.

If a playlist is full of generic instrumental tracks, fake artist names, or suspiciously polished songs that appear out of nowhere, a detector gives the user a second signal. It does not need to replace taste. It helps people ask better questions.

Listeners get more transparency about what is in their playlists.
Artists get a possible defense against low-effort synthetic spam crowding discovery surfaces.
Platforms get a way to show they are not ignoring the flood of generated content.
Developers get another example of AI trust becoming a user-facing feature, not just a moderation backend.

The weakness is obvious too: false positives and false negatives will be painful. Mislabel a human artist and the platform looks careless. Miss a wave of synthetic spam and the tool looks cosmetic. Detection products need confidence levels, appeal paths, and careful copy. A red badge that says "AI" may feel simple, but it can carry real reputational consequences.

The practical lesson for builders

The mistake would be to read this only as a music industry story. It is really about provenance becoming part of the interface.

If you build apps with user-generated content, AI output, uploads, reviews, documents, or media, users will eventually ask three questions:

Where did this come from?
Was AI involved?
How much should I trust it?

You do not need to build a heavy-handed detector tomorrow. But you should start designing for those questions now. Add source metadata where possible. Preserve creation context. Separate "AI-assisted" from "fully generated." Show uncertainty instead of pretending the system knows everything. Give creators a way to dispute labels. Keep logs that explain why a label was applied.

In other words, detection is not just a model. It is a workflow.

Why this trend is accelerating

AI-generated media is cheap to produce and easy to distribute. Music is one of the cleanest examples because the unit is small, the incentives are clear, and streaming platforms reward volume. But the same pattern shows up in images, product reviews, SEO content, social posts, code snippets, and support tickets.

Once synthetic content becomes abundant, platforms need sorting signals. Some will be technical, like classifiers and watermark checks. Some will be social, like verified creators and reputation. Some will be economic, like changing payout rules so spam farms do not win by uploading thousands of disposable assets.

The best products will not rely on one magic detector. They will combine signals and explain them in a way users can understand.

My take

I like the direction, but I would not oversell the certainty. AI detection is most useful when it is treated like a confidence signal, not a courtroom verdict.

For builders, the takeaway is simple: trust features are becoming core product features. In the same way apps eventually needed privacy settings, export buttons, audit logs, and two-factor authentication, many content platforms will need provenance, AI labels, and dispute flows.

Deezer's detector may or may not become the standard. But the product category is real. Users are going to want to know what they are consuming, artists are going to want protection from synthetic noise, and platforms are going to need a better answer than "our algorithm handles it."

That answer should be visible, humble, and useful.

References

Originally published at https://blog.jenuel.dev/blog/ai-music-detectors-are-a-product-signal

Physical AI needs labs, not just louder demos

Jenuel Oras Ganawed — Thu, 11 Jun 2026 08:03:32 +0000

Robots are having another headline moment, but the useful story is not the shiny demo. It is the boring infrastructure around the demo: test spaces, simulation loops, failure logs, safety gates, deployment checklists, and teams that can repeat the same task a thousand times without pretending every mistake is magic.

That is why the latest physical AI signals are worth paying attention to. In the last two days, Nebius announced a Physical AI Living Lab for UK and European robotics startups built with NVIDIA technologies, robotics funding headlines kept moving, and NVIDIA robotics materials continue to frame the category around training, developing, and deploying robots at scale. The common thread is simple: physical AI is moving from video clips into facilities where builders can measure whether robots actually work.

Why this matters now

Software AI can fail quietly. A chatbot can hallucinate, a coding assistant can suggest a bad refactor, and a search answer can cite the wrong source. Those failures are serious, but they often stay inside a screen. Physical AI has a different risk profile. A robot that misreads a room, grips too hard, misses a person, drops a tool, or gets stuck in a workflow turns model quality into a real-world operations problem.

That changes what progress looks like. A better robotics model is useful, but it is not enough. Builders need places to test perception under messy lighting, evaluate policies on cheap and expensive hardware, collect edge-case data, and run safety reviews before putting a system near customers or workers. The lab becomes part of the product.

The practical shift: from model-first to system-first

The AI industry loves model-first storytelling: bigger model, better benchmark, more impressive demo. Robotics punishes that mindset. The robot is a full stack. Vision models, world models, motion planning, hardware latency, battery limits, human factors, telemetry, remote assist, and maintenance all collide in the same product.

For builders, the lesson is to stop asking only, "Which model is smartest?" and start asking, "What loop improves the whole system every week?" A robotics team needs a pipeline that looks closer to production engineering than a research showcase.

Capture failures with enough context to reproduce them: sensor input, environment state, model output, operator notes, and hardware condition.- Separate simulation wins from real-world wins. Simulation is useful, but it should feed a test plan, not replace one.- Design rollback paths. If a model update makes the robot less reliable, the team should know quickly and revert cleanly.- Measure task completion, intervention rate, near misses, and recovery quality, not just benchmark scores.- Treat safety and observability as core features, not compliance paperwork added after the demo.

What users actually get

If the physical AI lab trend works, users should eventually get robots that are less theatrical and more dependable. Warehouse teams get machines that can handle variation without constant babysitting. Hospitals and care environments get assistive systems that understand constraints instead of blindly optimizing a task. Factories get robots that can be reconfigured faster when a product line changes. Consumers get fewer "look at this humanoid" videos and more tools that quietly do one useful job well.

The near-term benefits will probably be narrow. That is not a weakness. Narrow, reliable robots are more valuable than general-purpose robots that need a rescue every few minutes. The first serious physical AI wins may look boring: inspection, pick-and-place variations, inventory movement, lab automation, cleaning, agriculture, and controlled indoor logistics.

Strengths and weaknesses of the trend

The strongest part of this shift is that it forces accountability. A living lab, accelerator, or robotics test facility can expose the gap between a polished demo and a repeatable product. It gives startups access to infrastructure they may not be able to build alone, especially when advanced GPUs, simulation tools, and hardware test environments are expensive.

The weakness is that "physical AI" can become another label stretched over everything. A lab announcement does not guarantee useful robots. A funding round does not guarantee deployment. NVIDIA-powered tooling does not remove the hard parts of hardware reliability, data quality, safety, and customer workflow design. Builders should be excited, but not dazzled.

Builder takeaways

If you are building with AI today, even outside robotics, physical AI offers a useful discipline: measure the system, not the slogan. The closer AI gets to real-world consequences, the more important boring engineering becomes.

Build evals around the user workflow, not around what looks impressive in a demo.- Log failures in a way that helps engineers improve the product instead of just proving something went wrong.- Keep humans in the loop where the cost of a mistake is high, and make escalation easy.- Use model upgrades as controlled releases. Do not silently swap intelligence into production and hope for the best.- Prefer small reliable autonomy over broad unreliable autonomy.

That last point may be the most important. The winning robotics companies may not be the ones promising a general-purpose helper first. They may be the teams that pick a painful, repeatable task, instrument it deeply, and improve it until the robot becomes boring enough to trust.

A grounded prediction

Over the next year, physical AI will likely split into two tracks. One track will chase spectacle: humanoids, viral clips, and broad claims about general intelligence in the physical world. The other track will build the infrastructure of reliability: labs, simulation, data flywheels, safety cases, hardware partnerships, and deployment playbooks.

The second track is less exciting on social media, but it is the one developers should watch. When AI leaves the browser and starts moving through rooms, the winners will not be the teams with the loudest demo. They will be the teams with the tightest feedback loop between model, machine, environment, and user.

References

Nebius: Physical AI Living Lab for UK and European robotics startups- NVIDIA AI for Robotics platform overview- Engineering.com: NVIDIA introduces Isaac GR00T reference humanoid robot- NEURA Robotics company site

Originally published at https://blog.jenuel.dev/blog/physical-ai-labs-robotics-builders

AI Overviews are a liability lesson for every builder

Jenuel Oras Ganawed — Wed, 10 Jun 2026 08:05:14 +0000

The uncomfortable lesson from Google's AI Overviews problem is not just that AI can be wrong. Builders already know that. The lesson is that once your product summarizes, ranks, and presents an answer in its own voice, users and courts may treat that answer as yours.

That matters far beyond search. If you are building an AI assistant for legal intake, customer support, medical triage, internal analytics, church operations, education, or developer workflows, you are not merely displaying model output. You are shipping a decision surface. The moment it looks authoritative, your product needs evidence, review paths, and a way to recover when the model confidently connects the wrong dots.

A German regional court ruling reported this week found that Google's AI Overviews could be treated as Google's own statements when they produced false claims. The facts are specific, and appeals or other jurisdictions may change how this develops. But the product lesson is already clear: attribution links do not automatically make an AI answer safe.

Why this is bigger than Google Search

Google is the visible example because AI Overviews sit on top of one of the most-used information products in the world. But the same pattern shows up in smaller products every day:

A support bot summarizes a refund policy and invents an exception.
An internal data agent answers a revenue question with the wrong filter.
A health assistant blends source material into advice that sounds clinical.
A coding agent explains a security issue but cites a file it did not actually inspect.

In each case, the risky part is not only hallucination. It is presentation. A generated paragraph in a polished UI feels more final than a list of search results, logs, or raw documents. That is why builders should stop treating citations as decorative footnotes and start treating them as part of the product's safety system.

What users actually need

Users do not need a legal disclaimer stapled under every answer. They need interfaces that make uncertainty visible before damage happens.

For AI search and knowledge products, that means showing the exact source passages used for the answer, not just a pile of related links. If the answer says a person, company, or organization did something harmful, the product should require stronger evidence than a normal summary. If the system cannot find direct support, it should say so plainly.

For internal AI tools, it means every important answer should carry a trace: which documents, database tables, prompts, tools, and timestamps produced it. That trace should be readable by a human reviewer, not buried in a vendor dashboard nobody opens until something breaks.

A practical builder checklist

If you are shipping AI into a real workflow, I would start with these safeguards:

Separate retrieval from generation. Log what the system retrieved before the model wrote the answer. If the evidence is bad, the answer will be bad.
Quote before summarizing for sensitive claims. For accusations, health, finance, legal, safety, hiring, or pastoral care contexts, show direct support before the generated conclusion.
Add confidence by evidence type, not model vibes. A direct policy paragraph is stronger than a forum post. A verified database row is stronger than a cached summary.
Give users a correction path. Let people report a wrong answer, attach the source problem, and trigger review without hunting for a support email.
Keep an audit trail. Store model version, prompt version, retrieval results, tool calls, and rendered answer for high-risk workflows.
Design refusals that are useful. A good AI product should know when to answer, when to ask for more context, and when to send the user to a human or primary source.

The weakness in many AI products

Too many AI features are built like demos: prompt, response, nice animation, ship it. That is fine for a toy. It is not enough for a product that people use to make decisions.

The hard work is not only making the model smarter. It is deciding which answers deserve friction. A product that always sounds confident will eventually be confidently wrong in public. A better product can still be fast, but it knows when speed is less important than proof.

The opportunity

This is not a reason to avoid AI search or AI assistants. It is a reason to build them like serious software.

The winners will not be the teams with the flashiest answer box. They will be the teams that can say, "Here is the answer, here is the evidence, here is what we are unsure about, and here is how to challenge it." That kind of product earns trust slowly, but it also survives contact with real users, real mistakes, and real accountability.

AI is moving from novelty to infrastructure. Infrastructure needs logs. It needs review. It needs boring controls that work when the demo glow wears off. Google's AI Overviews controversy is a reminder that builders should add those controls before the first painful incident, not after.

References

Originally published at https://blog.jenuel.dev/blog/ai-overviews-liability-lesson-for-builders

We Do Not Just Write Code Anymore. We Direct Agents.

Jenuel Oras Ganawed — Wed, 10 Jun 2026 00:33:46 +0000

Something changed in software engineering, and I do not think we have fully named it yet.

For years, the job was mostly about writing code directly. Then autocomplete got better. Then chat-based coding assistants arrived. Now the workflow is shifting again: we describe goals, hand off chunks of work to agents, inspect their output, tighten the tests, and decide what gets merged.

That is not the same job with a faster keyboard. It is a different shape of work. I would call it agentic engineering.

The engineer is becoming a director

Agentic engineering does not mean the engineer disappears. If anything, it makes the engineer's judgment more visible.

A coding agent can read files, make changes, run commands, open pull requests, and iterate through errors. GitHub describes Copilot agent mode as a workflow where the agent can plan, edit, run terminal commands, and keep working until a task is complete. Google describes Jules as an asynchronous coding agent that can take a task, work in a virtual machine, and produce a pull request. Anthropic's Claude Code guidance talks openly about using multiple Claude sessions in parallel, giving agents clear context, and treating them like workers that need direction.

That is the shift. The engineer is no longer only the person typing every line. The engineer is also the person deciding what should be built, what constraints matter, how to verify the result, and when the agent is wrong.

Prompting is too small a word for this

People often describe this work as prompting, but that undersells it.

A prompt can be a single instruction. Agentic engineering is more like delegation. You define the task, provide the relevant context, set the boundaries, create checks, review the work, and decide the next move. If the agent goes in the wrong direction, the failure is not always the model's fault. Sometimes the task was too vague. Sometimes the repository had no tests. Sometimes the acceptance criteria lived only in someone's head.

This is why the best engineers in this new workflow will not simply be the fastest typists or the cleverest prompt writers. They will be the people who can turn messy intent into clear, testable work.

Tests and reviews matter more, not less

The uncomfortable part is that agents make weak engineering habits more expensive.

If a human writes a bad function, you review the diff. If an agent writes ten files, updates dependencies, touches configuration, and claims the tests pass, you need even stronger verification. You need good automated tests. You need small pull requests. You need logs. You need security boundaries. You need to know which commands the agent ran and why.

Martin Fowler's writing on generative AI and software development keeps returning to this point: the loop still needs humans, feedback, and engineering discipline. Thoughtworks has also been tracking agentic coding tools as a technique, but with the same basic warning underneath the optimism: these tools are useful when teams change the workflow around them, not when they blindly paste agent output into production.

I like the promise of agents. I use them. But I do not trust a confident agent more than I trust a clean diff, a passing test suite, and a reviewer who understands the product.

The new skill is context engineering

The phrase "context engineering" sounds trendy, but it points to something practical. Agents perform better when they have the right files, the right constraints, the right examples, and the right definition of done.

That means engineering teams will need to maintain better project knowledge. Not long documents nobody reads. Useful context: setup commands, architecture notes, testing rules, API contracts, known traps, and examples of good work in the codebase.

In the old workflow, undocumented knowledge slowed down new developers. In the agentic workflow, undocumented knowledge also confuses the agents. The hidden cost becomes visible.

Agentic engineering is still engineering

The hype version says agents will build everything for us. The cynical version says they only produce slop. Both are too lazy.

The more realistic version is this: agents are becoming part of the engineering team, but they are not accountable. We are. They can draft, refactor, investigate, generate tests, and chase errors. We still own the architecture, the tradeoffs, the product judgment, and the final merge.

So yes, the way we do engineering has changed. The center of gravity is moving from typing code to directing work. That is exciting, but it also raises the bar. A good engineer now needs to think like a builder, reviewer, tester, and manager of tiny software agents that never get tired and never truly understand the business unless we teach them.

That may be the next version of the job: less mechanical coding, more judgment per line shipped.

References

Originally published at https://blog.jenuel.dev/blog/we-do-not-just-write-code-anymore-we-direct-agents

AI adoption needs evidence, not vibes

Jenuel Oras Ganawed — Tue, 09 Jun 2026 08:04:30 +0000

The next serious AI advantage will not come from the team with the loudest demo. It will come from the team that can prove where AI actually changes the work.

That is why OpenAI's new Economic Research Exchange is worth watching even if you are not an economist. OpenAI framed it as a way to study AI's impact on jobs, productivity, and the broader economy. Put beside its fresh public-benefit roadmap and confidential S-1 filing, the signal is clear: AI is moving from model spectacle into accountability. Investors, regulators, companies, and workers are going to ask a harder question now: what changed because of the AI?

Builders should ask the same question before everyone else asks it for them.

The vibe-based AI rollout is running out of road

Most AI adoption still starts with a messy bundle of anecdotes. Someone says a coding assistant feels faster. A support team says summaries save time. A founder says agents will replace a workflow soon. Some of that is true. Some of it is wishful thinking dressed up as strategy.

The problem is not enthusiasm. The problem is weak measurement. If a developer uses AI to ship a feature two hours faster but creates a subtle security bug, did productivity improve? If a marketing team generates ten drafts instead of three but publishes the same amount of useful work, was the tool worth it? If a customer-service agent closes more tickets but escalations rise, what exactly did the model improve?

AI can be genuinely useful and still be badly measured. That is the uncomfortable middle ground more teams need to live in.

What OpenAI's research push means for builders

OpenAI's Economic Research Exchange is aimed at larger questions: labor markets, productivity, jobs, and economic outcomes. But the practical lesson for developers and product teams is smaller and sharper: treat AI features like interventions, not decorations.

Instead of asking, "Should we add AI?" ask:

Which task gets easier, faster, safer, or cheaper?
What does the user do before and after the model enters the workflow?
Which metric could prove the improvement without relying on a testimonial?
Where can the AI fail quietly, and how will we catch it?

That mindset changes the product brief. A code-review assistant should not only generate comments. It should reduce review wait time, catch repeat defect classes, and avoid noisy suggestions that developers learn to ignore. A document agent should not only answer questions. It should cite sources, show uncertainty, and reduce the time it takes a user to make a decision. A sales assistant should not only write emails. It should improve response quality without turning every message into generic sludge.

A simple measurement loop for AI workflows

If you are adding AI to a real workflow, start with a boring baseline. Boring is good here. Measure the current task before the model touches it.

Time: How long does the task take without AI?
Quality: What counts as a good output, and who judges it?
Risk: What mistake would create rework, customer harm, or security exposure?
Adoption: Do users keep using the tool after the novelty fades?
Cost: What is the token, infrastructure, review, and support cost per useful outcome?

Then run the AI version against the same workflow. Do not only measure model accuracy in isolation. Measure the full human-plus-model system. Many useful AI tools are not fully autonomous. They are leverage tools: they help a human search faster, draft earlier, inspect more cases, or make a better first pass.

That is still valuable. But it needs honest accounting.

The strongest AI teams will look less magical

This is the part that may feel boring compared with model launches: the winners will probably have spreadsheets, evaluation sets, review queues, audit logs, and uncomfortable postmortems. They will know where AI helps and where it does not. They will kill features that demo well but fail in production. They will keep humans in the loop where judgment matters and automate the parts that are actually repeatable.

That does not make AI less exciting. It makes it more usable.

The hype cycle taught people to ask, "What can the model do?" The next phase will reward people who ask, "What changed in the workflow, and can we prove it?"

For builders, that is a better question. It turns AI from a shiny add-on into an engineering discipline.

References

Originally published at https://blog.jenuel.dev/blog/ai-adoption-needs-evidence-not-vibes