Forem: Touhidul Islam Protik

Google’s Gemini Coding Demos Revealed the Slow Death of “Blank Page Programming”

Touhidul Islam Protik — Sun, 24 May 2026 07:54:17 +0000

The most revealing programming demo at Google I/O 2026 wasn’t about code generation quality.

It was about hesitation.

Or more specifically:

removing the moment where developers stop to figure out how to begin.

That hesitation has quietly shaped software development for decades.

Open editor.
Blank file.
Cursor blinking.
Mental reconstruction begins.

Even experienced engineers spend huge amounts of time rebuilding local context before writing anything meaningful:

understanding architecture,
tracing dependencies,
locating relevant files,
reconstructing intent,
remembering implementation history,
mapping unfamiliar abstractions.

Typing code was never the real bottleneck.

Context acquisition was.

And Google’s recent Gemini coding demos increasingly seem designed around eliminating exactly that friction.

For years, developer tooling evolved around acceleration primitives.

Better autocomplete.
Faster builds.
Smarter refactors.
Improved debugging.

Those optimizations mattered, but they still assumed something fundamental:

the developer already understood the surrounding system.

Gemini changes the assumption entirely.

The demos repeatedly showed workflows where the system participates directly in contextual reconstruction itself.

Not just generating functions.

Explaining architectural relationships.
Tracing execution paths.
Summarizing unfamiliar modules.
Connecting scattered implementation logic across repositories.

That’s a much more important shift than “AI writes code.”

Because most real engineering work does not happen inside isolated functions.

It happens inside accumulated complexity.

One thing stood out repeatedly during the demos.

The assistant rarely behaved like a code completion engine.

Instead, it behaved more like an adaptive systems navigator.

That distinction matters.

Autocomplete predicts syntax.

Contextual assistants increasingly predict intent under architectural uncertainty.

And honestly, those are completely different cognitive tasks.

Most programming education accidentally overemphasizes writing.

But experienced engineering often revolves around:

reading systems,
understanding abstractions,
reconstructing decisions,
identifying constraints,
preserving consistency,
navigating legacy behavior.

Large codebases are rarely difficult because individual lines are complicated.

They become difficult because context fragments across:

files,
teams,
commits,
services,
APIs,
historical assumptions,
undocumented decisions.

Humans spend enormous mental energy stitching those fragments together manually.

That stitching process is where developer fatigue quietly accumulates.

Google’s demos kept targeting exactly that layer.

Not:

“write sorting algorithm.”

But:

“understand this project,”
“trace this workflow,”
“explain this implementation,”
“find where state changes,”
“locate the authentication boundary,”
“summarize architectural intent.”

Those are much closer to real software work.

And honestly, I think the industry still understates how psychologically expensive contextual reconstruction becomes inside mature systems.

This is why I think modern AI coding systems are less about replacing programmers and more about reducing architectural orientation cost.

Because software complexity compounds faster than human working memory scales.

A senior engineer joining an unfamiliar repository still experiences:

uncertainty,
search overhead,
dependency confusion,
hidden assumptions,
invisible coupling.

The intelligence bottleneck is often environmental, not syntactic.

Gemini’s demos repeatedly exposed that reality indirectly.

The interesting part is that this changes what “programming assistance” even means.

Historically, IDEs helped developers manipulate code.

AI-native systems increasingly help developers model systems mentally.

That’s a very different relationship.

The assistant is no longer acting purely as:

autocomplete,
linting,
formatting,
syntax support.

Instead, it increasingly behaves like:

contextual scaffolding,
architectural memory,
repository interpreter,
systems explainer.

And honestly, I think this transition matters more than raw generation quality long term.

Because most production engineering bottlenecks emerge from understanding failure, not typing speed.

One subtle but important pattern across recent demos:

The AI rarely started from zero.

Instead, it operated against existing environments:

repositories,
documentation,
project structures,
APIs,
workflows,
organizational conventions.

That’s important because real-world software development is overwhelmingly incremental.

Most engineers do not spend their days building greenfield projects from scratch.

They inherit systems.

And inherited systems contain history.

History is where software becomes cognitively expensive.

Every mature codebase accumulates:

abandoned abstractions,
partial migrations,
compatibility layers,
defensive workarounds,
inconsistent naming,
undocumented edge cases,
architectural scars.

Humans infer these patterns gradually through exposure.

AI systems attempt to compress that orientation process dramatically.

And honestly, that may become the most valuable capability of all.

Not writing code faster.

Understanding systems sooner.

I also think these demos revealed a deeper shift happening underneath software engineering itself.

Programming is slowly moving away from pure implementation labor toward contextual supervision.

That doesn’t mean engineers disappear.

It means their cognitive role changes.

Less energy goes toward:

remembering syntax,
reconstructing APIs,
locating boilerplate,
manually traversing systems.

More energy shifts toward:

evaluating tradeoffs,
defining constraints,
verifying correctness,
preserving coherence,
shaping architecture,
identifying hidden failure conditions.

In other words:
the scarce resource increasingly becomes judgment rather than production.

There’s also a strange paradox hiding underneath all this.

The easier AI makes implementation,
the more dangerous shallow understanding becomes.

Because generated code can create the illusion of comprehension very quickly.

Especially inside systems already too large for individual humans to model completely.

A developer may successfully modify behavior without deeply understanding:

downstream coupling,
performance implications,
concurrency assumptions,
infrastructure constraints,
edge-case interactions.

That risk compounds as generation quality improves.

And honestly, I think the industry still talks far less about verification psychology than generation capability.

What fascinated me most about Google’s coding demos wasn’t the speed.

It was the reduction of cognitive startup friction.

The assistant continuously worked to preserve momentum:

surfacing context,
maintaining continuity,
reconstructing architecture,
reducing orientation overhead.

That’s not merely automation.

It’s cognitive load redistribution.

And I suspect that shift may reshape programming more deeply than code generation itself.

Because historically, software engineering has always been constrained less by typing ability and more by how much complexity humans can actively hold in their heads at once.

Google’s demos quietly suggested a future where developers increasingly outsource that reconstruction layer to machines.

Not because humans stop programming.

But because modern software systems have already exceeded what unaided human contextual memory handles comfortably at scale.

Android XR Felt Like the Future Until You Notice the Catch

Touhidul Islam Protik — Sun, 24 May 2026 02:25:42 +0000

The most interesting part of Google I/O 2026 wasn’t Gemini.

It was the moments where screens disappeared entirely.

Google’s Android XR demos showed assistants:

seeing environments
remembering visual context
responding conversationally
interpreting physical surroundings
maintaining continuity across movement and time

Most reactions focused on the hardware.

I think the real story was something else entirely:

ambient computing only works if systems can understand incomplete human behavior continuously without becoming exhausting.

And that turns out to be an incredibly difficult design problem.

Previous Smart Assistants Mostly Waited

Older digital assistants were reactive by design.

You activated them.
You asked something.
They responded.
The interaction ended.

That structure created clear boundaries.

The system remained dormant until explicitly invoked.

Android XR changes that relationship.

The assistant increasingly exists as:

persistent perception
continuous contextual awareness
low-friction conversational presence

The system isn’t waiting for isolated prompts anymore.

It’s monitoring environments continuously for relevance.

That sounds futuristic.

It also creates a very strange UX challenge.

Contextual Awareness Sounds Better Than It Feels

In demos, ambient AI appears almost magical.

You glance at a building.
The assistant identifies it instantly.

You ask about an object.
The system remembers earlier visual context.

You continue a conversation while walking between environments.
The assistant maintains continuity naturally.

The interaction feels fluid because demos remove the hardest part:

human unpredictability.

Real life contains:

interruptions
sarcasm
fragmented speech
changing intentions
social ambiguity
unfinished thoughts
overlapping priorities

Humans navigate this instinctively.

Persistent AI systems cannot rely on instinct.

They rely on inference.

That difference matters enormously.

Android XR Quietly Depends on Perpetual Interpretation

This is the architectural shift I don’t think enough people are discussing.

Traditional apps mostly interpret direct input.

Buttons.
Text.
Gestures.

Ambient systems interpret:

gaze
spatial positioning
conversational timing
environmental context
object relationships
behavioral continuity

continuously.

That creates a much denser inference problem than standard interaction models.

The system must constantly estimate:

what matters
what can be ignored
when to interrupt
when to remain silent
whether context is still relevant
whether ambiguity requires clarification

Poor judgment here doesn’t merely feel buggy.

It feels socially intrusive.

The Biggest Problem Isn’t Intelligence

It’s Restraint

Most AI discussions still revolve around capability.

Better reasoning.
Better memory.
Better generation.

But ambient systems fail differently.

An assistant doesn’t become useful simply because it can respond.

It becomes useful when it understands:

when not to respond.

That’s much harder.

Because conversational timing contains enormous invisible social complexity:

attention signaling
interruption tolerance
emotional context
cognitive load
environmental appropriateness

Humans calibrate this subconsciously.

Machines don’t.

At least not reliably.

Smart Glasses Create “Attention Competition”

Phones already compete aggressively for attention.

XR systems risk becoming even more psychologically invasive because they exist directly inside perceptual space.

Notifications no longer sit in pockets.

They exist near vision itself.

That changes cognitive dynamics entirely.

Every ambient interface decision suddenly affects:

focus fragmentation
conversational presence
social engagement
visual fatigue
mental recovery cycles

The UI stops being separated from reality.

It overlays reality directly.

And honestly, I think the industry still lacks mature design language for handling that responsibly.

Google’s Demos Felt Extremely Carefully Choreographed

Not because the technology was fake.

Because ambient interaction only feels smooth under narrow behavioral conditions.

The demos consistently involved:

cooperative users
short conversational loops
clean environments
obvious intent
minimal ambiguity

Real environments are messier.

People hesitate mid-sentence.
Change goals halfway through.
Forget what they asked.
Reference things indirectly.

That’s where ambient systems become difficult.

Not at recognition.

At interpretation persistence.

The Interface Is Starting to Behave More Like a Social Actor

This is the deeper shift underneath XR assistants.

Traditional software behaves mechanically.

Ambient assistants increasingly behave relationally.

The system remembers previous interactions.
Tracks continuity.
Adjusts responses.
Maintains conversational flow.

That creates subtle psychological effects.

Users stop perceiving the interface purely as software.

It starts feeling behaviorally present.

Even when the underlying mechanics remain probabilistic.

That tension becomes important because humans instinctively anthropomorphize continuity.

Especially conversational continuity.

Constant Awareness Creates New Privacy Geometry

Phones already collect enormous contextual information.

XR systems intensify this dramatically.

Because contextual understanding increasingly depends on:

spatial mapping
visual environments
object recognition
conversational history
behavioral timing
gaze direction
environmental continuity

That’s not just data collection.

It’s behavioral modeling embedded into perception systems themselves.

And unlike traditional apps,
ambient systems require constant passive intake to remain useful.

Which means:
privacy boundaries become harder to visualize clearly.

Invisible systems create invisible uncertainty.

Android XR Revealed a Different Computing Direction Than Phones

Smartphones optimized around:

app switching
explicit interaction
focused sessions

Ambient systems optimize around:

continuity
persistence
interruption minimization
contextual adaptation

That sounds subtle until you realize it changes the role of software entirely.

Apps become secondary.

Context becomes primary.

And once systems continuously interpret environments,
the interface stops feeling like a destination.

It starts behaving like an invisible behavioral layer sitting beside reality itself.

I Don’t Think Google Was Really Showing Hardware

I think it was testing tolerance.

Tolerance for:

persistent machine presence
continuous contextual inference
conversational overlays
low-friction behavioral monitoring

Because ambient computing only succeeds if users stop noticing the mediation layer entirely.

That’s the paradox.

The more successful the system becomes,
the less visible the interface becomes.

And historically, invisible systems tend to become psychologically influential long before society fully understands their effects.

That may end up being the real story behind Android XR.

Using Gemma 4 to Analyze Bitcoin’s Next 5, 15, and 60 Minutes

Touhidul Islam Protik — Fri, 22 May 2026 21:16:59 +0000

Crypto prediction markets are weirdly addictive.

Not just because people are betting on price movement — but because they turn market sentiment into something visible in real time.

Platforms like Kalshi and Polymarket have created an entirely different way of looking at Bitcoin.

Instead of asking:

“What is Bitcoin doing right now?”

people are increasingly asking:

“What does the market believe Bitcoin will do next in the next few minutes?”

That difference became the starting point for this project.

So I built SatoshiSignal — an AI-powered Bitcoin market analysis platform focused on short-term prediction markets using Gemma 4.

The system helps traders analyze:

market momentum
technical indicators
sentiment shifts
prediction market behavior

to estimate possible Bitcoin movement over:

5 minutes
15 minutes
60 minutes

The idea behind SatoshiSignal

Most crypto dashboards today suffer from one of two problems:

they overwhelm users with raw charts and indicators
or they oversimplify everything into meaningless “BUY/SELL” signals

Neither actually helps traders think better.

I wanted to build something that sits somewhere in the middle:

AI-assisted
data-aware
sentiment-driven
prediction-market focused

The goal wasn’t:

“Let AI trade for you.”

The goal was:

“Help traders interpret short-term market signals faster.”

Why prediction markets are fascinating

Prediction markets are one of the most interesting financial experiments happening right now.

Platforms like Kalshi and Polymarket essentially turn public belief into tradable probability.

For example:

Will Bitcoin rise in the next 15 minutes?

The market price itself becomes a live probability estimate.

And that creates something really interesting:

market psychology
crowd sentiment
volatility expectations
fear/optimism cycles
narrative momentum

all compressed into a single number.

That’s incredibly useful context for short-term traders.

What SatoshiSignal does

SatoshiSignal combines:

technical indicators
market sentiment
prediction market trends
AI reasoning
historical context

to generate clearer insights around Bitcoin movement.

Instead of just showing indicators, the system tries to explain:

why sentiment is shifting
what signals matter
how narratives evolve
where uncertainty exists

The focus is specifically on:

ultra-short-term market behavior
prediction market probabilities
rapid market momentum changes

Core features

AI-powered Bitcoin market analysis

The platform analyzes:

price momentum
technical indicators
volatility trends
prediction market movement
short-term sentiment shifts

Then Gemma helps contextualize the signals into readable insights.

5 / 15 / 60 minute prediction analysis

One of the main goals of the system is helping traders understand:

immediate momentum
near-term trend continuation
rapid sentiment reversals

Instead of focusing on:

“Where will Bitcoin be next year?”

the project focuses on:

intraday movement
short-term probabilities
rapid market behavior

which is much closer to how active prediction market traders actually operate.

AI-generated market explanations

A lot of trading tools assume users already understand:

RSI
MACD
market structure
liquidity sweeps
volatility compression

But many traders don’t.

So instead of dumping raw indicators onto the screen, SatoshiSignal uses AI to explain what’s happening in human language.

For example:

“Short-term momentum remains bullish, but prediction market confidence is weakening despite upward price action.”

That kind of contextual explanation is much more useful than:

RSI = 71

alone.

Why I used Gemma 4

The project uses Gemma 4 31B Instruct through the Gemini ecosystem.

After testing multiple models, Gemma stood out because it handled:

financial context
structured reasoning
summarization
nuanced explanations
signal interpretation

surprisingly well.

Financial data is noisy.

Crypto sentiment is even noisier.

You’re dealing with:

Twitter hype cycles
contradictory narratives
fear-driven volatility
macroeconomic uncertainty
trader emotion disguised as analysis

What mattered most was not raw generation quality.

It was:

contextual reasoning.

Gemma performed especially well at combining:

structured indicators
sentiment interpretation
readable analysis

without sounding robotic.

One thing I learned quickly

Market prediction is messy.

Very messy.

You can have:

bullish technical indicators
bearish macro sentiment
optimistic prediction markets
sudden liquidation cascades

all at the same time.

And that’s exactly why rigid rule-based systems often fail.

The interesting part wasn’t building:

“an AI predictor”

It was building a system capable of handling uncertainty without pretending certainty exists.

That became a huge design principle for the project.

The hardest part wasn’t the AI

Honestly?

The hardest part was signal interpretation.

Financial indicators often contradict each other.

For example:

RSI may signal overbought conditions
while momentum continuation remains strong
while prediction markets continue pricing upside probability

There’s no perfect answer.

So instead of trying to create:

“magic predictions”

the platform focuses on:

probability
context
sentiment shifts
risk interpretation

which feels much more realistic.

Another challenge: avoiding fake confidence

AI-generated financial tools can become dangerous very quickly.

Especially when they sound overly certain.

I spent a lot of time tuning prompts to avoid:

absolute predictions
fake certainty
exaggerated confidence
misleading financial language

The system intentionally frames outputs around:

probability
uncertainty
scenario analysis

instead of pretending to know the future.

Why this project interested me

Crypto markets are one of the few environments where:

technology
psychology
economics
internet culture
geopolitics

all collide in real time.

Prediction markets amplify that even further.

I wanted to explore whether AI could help traders process information more clearly without reducing everything into simplistic “buy” or “sell” outputs.

Tech stack

Built using:

React
TypeScript
Tailwind CSS
Node.js
Gemma 4 31B
market data APIs
prediction market feeds

How to run the project

Clone the repository

git clone https://github.com/Protik49/SatoshiSignal.git

Move into the project directory

cd SatoshiSignal

Install dependencies

Frontend

cd frontend
npm install

Backend

cd ../backend
npm install

Quick start

I also created a convenient:

start.bat

file that automatically starts both:

frontend
backend

with a single click.

So instead of manually opening multiple terminals, you can simply run:

start.bat

and the full application boots up automatically.

That made local testing much easier during development.

API key setup

Before running the project, you’ll need to configure your API keys.

Create a .env file inside the backend directory and add your required keys:

GEMINI_API_KEY=your_gemini_api_key
NEWSDATA_API_KEY=your_market_api_key
GEMINI_MODEL=gemma-4-31b-it

Depending on your setup, you may also need:

prediction market API keys
crypto market data provider keys

Replace the placeholder values with your actual credentials.

Running the application

After configuring the environment variables, simply run:

start.bat

This will automatically:

start the backend server
launch the frontend
initialize the local development environment

without needing multiple terminals.

Repository

👉 GitHub Repo:

https://github.com/Protik49/SatoshiSignal

What’s next

A few things I’m exploring next:

real-time sentiment clustering
whale wallet movement tracking
AI-generated market scenarios
anomaly detection
macro news correlation
portfolio risk explanations
multi-market comparison dashboards

Important disclaimer

SatoshiSignal is an educational and analytical tool.

It is not financial advice.

Crypto markets are highly volatile, and AI-generated analysis should never replace personal research or risk management.

Always verify information independently.

Final thoughts

One of the most interesting things about crypto markets isn’t the charts.

It’s the narratives.

Markets move because humans collectively believe something:

fear
optimism
panic
hype
uncertainty

Prediction markets expose those beliefs directly.

And AI becomes interesting when it helps interpret those signals more clearly — not when it pretends to predict the future perfectly.

That’s ultimately what SatoshiSignal tries to do.

Not replace traders.

Just help them think a little more clearly in chaotic markets.

Google’s AI Search Demos Revealed a Ranking Crisis Hiding Inside the Web

Touhidul Islam Protik — Fri, 22 May 2026 18:12:13 +0000

The most revealing part of Google I/O 2026 wasn’t the AI.

It was what quietly disappeared from the search result.

Links.

Not completely.
Not yet.

But enough to expose a growing tension Google rarely addresses directly:

AI-native search changes the economic structure of the web itself.

And I don’t think the industry fully understands the consequences yet.

Search Results Used to Be Destinations

Classic Google Search operated on a relatively stable exchange.

Websites created information.
Google indexed and ranked it.
Users clicked through.

Everyone benefited differently:

users got discovery
publishers got traffic
Google got engagement
creators got visibility

The ecosystem depended on referral flow.

That flow shaped:

SEO
publishing
blogging
affiliate systems
journalism
tutorials
documentation
even startup growth models

Search visibility became distribution infrastructure for the internet itself.

That’s why ranking mattered so much.

AI Overviews Quietly Alter the Incentive Structure

Google’s recent AI search experiences increasingly collapse:

retrieval
summarization
synthesis
recommendation

into a single interface layer.

The user asks something complex.

The system:

interprets intent
extracts information
synthesizes responses
generates follow-up reasoning
sometimes completes the task directly

without requiring navigation across multiple websites.

From a user perspective, this feels efficient.

From a web ecosystem perspective, it changes everything.

Because the moment answers stop requiring visits,
traffic dynamics change fundamentally.

The Important Shift Isn’t “Better Search”

It’s Search Becoming an Execution Layer

This distinction matters.

Traditional search engines helped users locate destinations.

AI-native search increasingly attempts to complete objectives internally.

That sounds subtle until you realize how much software architecture depends on outbound interaction.

Historically:

search → website → action

Now the pipeline increasingly becomes:

search → synthesis → completion

That bypass layer is economically significant.

Especially for:

publishers
forums
educational sites
independent blogs
comparison platforms
long-tail creators

The web was built around referral behavior.

AI-native retrieval compresses that behavior aggressively.

Google’s Demos Kept Prioritizing Completion Over Navigation

This pattern appeared repeatedly throughout recent I/O showcases.

The system wasn’t merely finding information.

It was:

planning trips
comparing products
summarizing research
scheduling actions
organizing decisions
maintaining conversational continuity

The interaction goal shifted from:

“show relevant pages”

to:

“reduce interaction friction entirely.”

That’s a very different philosophy of search.

And honestly, it starts resembling an operating environment more than a discovery engine.

AI Summarization Creates an Attribution Compression Problem

This is where things become structurally uncomfortable.

Large models depend heavily on web-scale information ecosystems.

But synthesized outputs compress visibility dramatically.

Ten websites may contribute signal.
One interface delivers the answer.

The user experiences coherence.

The ecosystem experiences invisibility.

That creates a strange imbalance:
the systems benefiting most from the open web may gradually reduce the visibility incentives sustaining that same web.

And unlike earlier search evolution,
this compression happens conversationally.

Which makes source boundaries feel psychologically weaker.

Reddit Became Valuable for a Reason

One fascinating trend across Google’s AI search evolution:

Human discussion suddenly became premium data.

Especially:

Reddit
forums
niche communities
long-tail expertise
experience-heavy content

Why?

Because heavily SEO-optimized content became increasingly homogeneous.

A huge portion of the web started sounding structurally identical:

optimized headings
repeated keywords
templated formatting
rewritten summaries
affiliate-driven language

LLMs exposed that sameness brutally.

Human unpredictability became useful again.

Messy opinions.
Specific experiences.
Contradictions.
Actual personality.

Ironically, AI may have accidentally increased the value of authentic human context.

AI Search Quietly Weakens Traditional SEO Assumptions

For years, SEO mostly optimized around:

ranking position
click-through rates
keyword relevance
structured metadata
backlink authority

AI-native search introduces new dynamics:

chunk retrieval
semantic relevance
synthesis quality
conversational usefulness
citation selection
answer extraction

The unit of visibility shifts from:

“page ranking”

toward:

“extractable informational utility.”

That’s a much stranger optimization target.

Especially because users may consume the information
without ever visiting the original source.

This May Create a “Visibility Without Audience” Problem

A website can influence AI-generated answers heavily
while receiving almost no direct user interaction.

That’s historically unusual.

Previously:
visibility and audience were tightly connected.

Now they may separate.

A creator’s knowledge might shape millions of AI interactions invisibly while generating:

fewer visits
weaker branding
lower subscriber growth
reduced monetization opportunities

The web has never really operated under those conditions before.

And I honestly don’t think we know what sustainable incentives look like there yet.

Google Seems to Be Optimizing for Cognitive Efficiency

This became increasingly obvious during the demos.

The system’s goal wasn’t:

exploration
browsing
wandering
discovery depth

It was compression.

Fewer tabs.
Fewer clicks.
Less reconstruction effort.
Less navigation overhead.

From a usability perspective, that’s compelling.

From an internet ecosystem perspective, it’s destabilizing.

Because the open web historically depended on friction-driven exploration.

Curiosity often emerged accidentally:

related articles
side links
forum tangents
rabbit holes
unexpected creators

AI synthesis compresses those pathways aggressively.

The experience becomes efficient.

Potentially too efficient.

The Web May Slowly Split Into Two Layers

I keep coming back to this possibility.

One layer becomes:

machine-readable
retrieval-optimized
structured for AI synthesis

The other becomes:

personality-driven
experiential
community-based
difficult to compress cleanly

Because purely informational content is increasingly vulnerable to summarization abstraction.

But:

perspective
identity
lived experience
trust
humor
voice
interpretation

still resist compression much more effectively.

That may explain why personal writing suddenly feels more valuable again.

Google Isn’t Just Rebuilding Search

It’s renegotiating the relationship between information and interaction.

That’s a much larger transition than “AI answers.”

Because once search engines stop functioning primarily as traffic routers,
the structure of the web itself changes with them.

And honestly, I don’t think the final outcome depends on model intelligence nearly as much as incentive design.

Historically, the internet grew because visibility rewarded contribution.

AI-native search quietly weakens that exchange.

The difficult question now is whether the web can remain generative
after the referral loop starts collapsing underneath it.

Google I/O 2026 Quietly Confirmed That Prompt Engineering Is Dying

Touhidul Islam Protik — Fri, 22 May 2026 13:26:08 +0000

Last year, everybody wanted the perfect prompt.

This year, Google barely cared about prompts at all.

That realization hit me halfway through Google I/O 2026.

Not because Google explicitly said “prompt engineering is dead.”

They didn’t.

But because almost every major demo quietly moved away from prompt craftsmanship and toward something much bigger:

systems that understand intent without needing prompt rituals.

And honestly?

That changes the entire mental model of building with AI.

We Accidentally Built an Industry Around AI Translation Layers

For the past two years, prompt engineering became the interface between humans and models.

People learned:

chain-of-thought tricks
XML formatting
role prompting
delimiter patterns
recursive prompting
emotional prompting
token optimization
jailbreak-resistant phrasing

Entire startups emerged around:

prompt libraries
prompt marketplaces
prompt optimization
reusable prompt templates

But watching Google I/O 2026 felt strange because Google’s demos increasingly removed the need for users to do any of that manually.

Not through announcements.

Through product design.

That distinction matters.

The Most Important Line at I/O Was Hidden Inside a Game Demo

During the Infinite Scaler segment, creators described how players could type extremely simple prompts while Gemini automatically “polished” them behind the scenes before generation.

Most people probably ignored that detail.

They shouldn’t have.

Because it reveals something fundamental about where AI interfaces are going.

The system architecture now increasingly looks like this:

Human Intent
    ↓
Intent Expansion Layer
    ↓
Contextual Interpretation
    ↓
Model Orchestration
    ↓
Execution

Not this:

Human writes perfect prompt
    ↓
Model responds

That older workflow increasingly looks temporary.

Prompt Engineering Was Always a Symptom

This is the uncomfortable part.

Prompt engineering only became important because models lacked:

contextual awareness
memory
environmental understanding
workflow continuity
intent abstraction
adaptive reasoning

So humans compensated manually.

We became the orchestration layer.

We translated messy human intent into machine-readable precision.

That worked.

But Google’s 2026 demos repeatedly showed systems trying to remove that translation burden entirely.

AI Studio Quietly Demonstrated the Shift

One of the most revealing demos at I/O wasn’t even framed as revolutionary.

A presenter sketched a rough 3D concept on a napkin-like drawing and asked Gemini 2.5 Pro to transform an existing web application into a dynamic 3D experience.

No advanced prompting.

No giant instruction chain.

No carefully engineered context setup.

The model:

interpreted the sketch
understood the visual intent
analyzed the existing codebase
planned modifications
updated multiple files
deployed the experience

That matters more than people realize.

Because historically, prompt engineering emerged precisely because models struggled with ambiguity.

But multimodal systems fundamentally reduce ambiguity.

A sketch contains:

spatial information
design intent
structure
visual hierarchy
relationships

Far richer than text alone.

And once models understand multimodal context deeply enough, prompts stop being “commands.”

They become:

lightweight expressions of intent.

Google Is Building Systems That Infer More Than They’re Told

This pattern appeared repeatedly across I/O.

Agent Mode

Instead of:

manually searching listings
rewriting queries
filtering websites
scheduling tours

Users simply describe goals.

The system handles:

browsing
filtering
form interaction
scheduling
persistence
continued monitoring

The prompt becomes the starting condition.

Not the workflow itself.

Project Mariner

Mariner’s “Teach and Repeat” capability might be one of the most important AI interaction shifts nobody is talking about.

You show the system a workflow once.

It learns the operational pattern.

That completely changes interaction design.

Because now:

demonstration becomes prompting
behavior becomes reusable context
workflows become trainable through interaction

That is dramatically different from traditional prompting.

Gemini Personal Context

Another huge signal.

Google repeatedly emphasized:

Gmail context
Docs context
Drive context
behavioral understanding
tone adaptation
historical awareness

Why?

Because the more context systems have, the less explicit prompting users need to provide.

Prompt engineering thrives in context-poor environments.

Context-rich systems reduce prompt complexity naturally.

The Future Interface Is Probably Not Text

This is where things become even more interesting.

Google’s demos increasingly relied on:

voice
video
screen sharing
sketches
browser state
environmental awareness
interaction history
live visual input

Text prompting starts looking less like “the future” and more like:

a temporary bridge between humans and machine reasoning.

Even Project Astra reflects this transition.

You’re no longer describing the world to the model.

The model sees the world directly.

That changes everything.

The Real Shift Is From Instructions to Intent

This is the deeper architectural transition underneath all of this.

Old AI interaction:

Tell the model exactly HOW to do something.

Emerging AI interaction:

Tell the system WHAT outcome you want.

That sounds subtle.

It’s not.

Because those are fundamentally different computing paradigms.

The first requires:

explicit human orchestration
deterministic instructions
precision formatting

The second requires:

adaptive systems
environmental reasoning
tool selection
contextual planning
autonomous execution layers

Prompt engineering belongs mostly to the first era.

Agents belong to the second.

Ironically, Better Models Are Destroying Prompt Engineering

This is the paradox.

The better models become:

the less scaffolding they need
the less prompt micromanagement matters
the more natural interaction becomes
the more interfaces disappear

Google’s own demos reinforced this repeatedly:

sketch-to-app generation
auto-polished prompts
multimodal understanding
persistent context
workflow continuation
agentic browsing
adaptive planning

All of these reduce the importance of handcrafted prompting.

Not completely.

But directionally.

And direction matters more than snapshots.

This Doesn’t Mean Prompt Engineering Fully Disappears

There’s nuance here.

Advanced prompting will still matter for:

researchers
developers
system architects
evaluation pipelines
edge-case workflows
deterministic production systems

Just like SQL still matters despite abstractions.

But average users?

They are increasingly moving away from prompt construction entirely.

Most people won’t become elite prompt engineers.

For the same reason most drivers never became combustion engineers.

The abstraction layer improved.

The Bigger Story Is That AI Is Becoming an Environment

This was the real theme hidden across Google I/O 2026.

Not chatbots.

Not prompts.

Environments.

Systems that:

observe context
maintain continuity
coordinate tools
remember state
infer goals
execute workflows
adapt dynamically

That’s why Google talked so much about:

MCP
agent ecosystems
browser control
persistent tasks
multimodal interaction
personal context
orchestration

These are not “prompt features.”

They are infrastructure for intent-driven computing.

We Might Look Back at Prompt Engineering Like Command-Line Computing

Important.

Not obsolete.

But transitional.

A necessary interface layer before systems became more ambient, adaptive, and context-aware.

Prompt engineering solved a real problem:

models originally needed humans to think like machines.

But increasingly, the models are learning to think more like humans instead.

And once that happens at scale, the interaction layer changes entirely.

That’s what Google I/O 2026 quietly revealed.

Not through a single announcement.

But through the direction every major demo was pointing toward.

The future of AI may not belong to the people who write the best prompts.

It may belong to the people who design the best intent-driven systems.

Google’s Agent Demos Have a Hidden Dependency Problem Nobody Is Talking About

Touhidul Islam Protik — Fri, 22 May 2026 12:56:42 +0000

The most interesting part of Google I/O 2026 wasn’t the models.

It was the assumptions.

Because almost every major demo quietly depended on something fragile:

the AI correctly understanding intent across multiple independent systems without breaking context halfway through.

That sounds manageable in a keynote.

In production, it becomes a completely different engineering problem.

The Demos Looked Effortless

Open Gemini.
Ask for something complex.
Watch the system orchestrate everything automatically.

Searches.
Tabs.
Calendar.
Maps.
Docs.
Email.
Purchases.
Research.
Summaries.

The interaction feels smooth because the demos compress complexity into a single conversational layer.

But underneath that layer, something much messier is happening.

The system is coordinating:

multiple APIs
permission scopes
state transitions
context windows
retrieval systems
ranking systems
fallback logic
memory layers
UI synchronization
asynchronous execution

That’s not “a chatbot.”

That’s distributed systems orchestration wearing a conversational mask.

Agent Mode Introduced a New Failure Surface

The apartment-hunting workflow from Google’s demos looked genuinely impressive.

Gemini could:

search listings
evaluate constraints
compare options
monitor updates
schedule visits
continue tasks asynchronously

Most people focused on capability.

I kept thinking about state consistency.

Because the moment AI systems begin operating across long-running workflows, traditional interaction assumptions stop applying.

A failed search query is recoverable.

A partially completed autonomous workflow is harder.

What happens if:

a permission expires mid-task?
ranking results shift dynamically?
APIs return conflicting states?
context truncation drops earlier constraints?
asynchronous actions race each other?
the system loses priority ordering?

These aren’t theoretical edge cases.

They’re normal distributed systems problems.

Except now they’re hidden behind natural language.

Natural Language Creates the Illusion of Reliability

This is the part I think the industry still struggles to communicate honestly.

Conversational interfaces feel more intelligent than they actually are because language compresses uncertainty extremely well.

When users type:

“Find me an apartment near work with natural light under my budget.”

the request feels singular.

Internally, it explodes into dozens of unstable subproblems:

defining “near”
estimating commute relevance
interpreting aesthetic preference
handling incomplete listing metadata
ranking tradeoffs
resolving contradictory constraints

Humans tolerate ambiguity naturally.

Software systems usually don’t.

That tension becomes dangerous once systems start acting autonomously.

Tool Calling Is Quietly Becoming the Entire Product

One subtle shift across recent I/O demos:

The model itself is no longer the full experience.

The orchestration layer matters just as much.

Potentially more.

Because modern agents increasingly depend on:

retrieval pipelines
browser control
tool execution
memory persistence
state management
cross-platform coordination

Without those systems, even strong models feel limited.

This is why Google emphasized protocols and interoperability so heavily:

MCP
Agent-to-Agent communication
tool ecosystems
multimodal grounding
persistent context systems

The real competition is no longer:

“Which model writes better paragraphs?”

It’s increasingly:

“Which system coordinates complexity more reliably?”

That’s a very different engineering race.

Long-Running Context Is Much Harder Than Chat

Most AI products still operate inside short interaction loops.

Prompt.
Response.
Done.

Agent systems break that structure entirely.

Now the system must maintain:

goals
priorities
permissions
memory
intermediate outputs
unresolved dependencies
user intent consistency

sometimes across hours or days.

That’s difficult.

Not because models are weak,
but because state drift compounds over time.

A small misunderstanding early in a workflow can silently propagate downstream into increasingly incorrect behavior.

Traditional software avoids this through rigid deterministic flows.

Agents intentionally loosen those constraints.

Which creates flexibility.

And instability.

At the same time.

The Browser Is Becoming an Execution Environment Again

One thing that stood out during Google’s demos:

Agents increasingly interact with software the same way humans do.

Through browsers.

Not direct backend integration alone.

That’s important.

Because browsers are messy environments:

dynamic DOMs
changing layouts
popups
authentication interruptions
anti-bot systems
race conditions
accessibility inconsistencies

Humans adapt instinctively.

Agents need inference loops to recover.

Which means:
future software reliability may depend less on clean UI design
and more on how recoverable interfaces are for machine reasoning systems.

That’s an unusual design constraint.

And I don’t think frontend development has fully processed what that implies yet.

Invisible Failure Is Worse Than Visible Failure

Traditional software usually fails loudly.

Buttons break.
Pages crash.
Forms reject inputs.

Agent systems can fail quietly.

That’s much more dangerous.

An agent might:

misunderstand intent
skip an important step
use stale context
hallucinate task completion
mis-prioritize objectives
continue operating after partial failure

while still sounding completely confident conversationally.

This creates a strange UX problem:
the interface appears smoother precisely when system complexity becomes harder to inspect.

And honestly, I think observability will become one of the defining challenges of AI-native products.

We May Need “AI Reliability Engineering”

The industry already has:

Site Reliability Engineering
Platform Engineering
DevOps
Observability stacks

Agent systems may require something adjacent but entirely new.

Because reliability now involves:

reasoning stability
context preservation
memory correctness
tool coordination
permission integrity
fallback orchestration
hallucination containment

Those aren’t traditional frontend problems.

They’re not purely backend problems either.

They sit awkwardly between:

distributed systems
UX
machine learning
infrastructure
human behavior

Which is exactly why these demos feel simultaneously impressive and fragile.

Google’s Demos Felt Less Like Apps and More Like Runtime Environments

That’s the thought I couldn’t shake during I/O.

The company isn’t simply building smarter assistants.

It’s building execution layers for reasoning systems.

And once software starts:

planning
delegating
recovering
coordinating
reprioritizing

the product stops behaving like a normal app.

It starts behaving more like an operating environment.

That’s exciting.

But it also means the hardest problems ahead probably won’t be model intelligence.

They’ll be reliability under ambiguity.

And historically, distributed systems have never handled ambiguity gracefully.

Everyone Was Focused on Gemini, But Infinite Scaler Was the Real Twister

Touhidul Islam Protik — Fri, 22 May 2026 12:27:16 +0000

Most people left Google I/O 2026 talking about Gemini.

Reasonable.

There were bigger models, better agents, deeper integrations, more autonomous workflows, and enough AI announcements to overload an entire industry for months.

But the demo I kept thinking about afterward wasn’t the flagship keynote reveal.

It was a weird little browser game called Infinite Scaler.

And honestly, I think it quietly revealed something important about where interactive software is heading next.

At First Glance, It Looked Like a Throwaway Demo

The concept sounded almost silly.

A multiplayer climbing game.
Players bounce upward through randomly generated worlds.
Every level is created from prompts submitted live by users.

That’s it.

During the demo, creators Valkyrae and CourageJD generated things like:

cyberpunk cities
capybaras
spaghetti slides
disco snails
ships in bottles
pets
floating burgers
animals with sweaters

The environments were generated dynamically through Gemini-powered pipelines while thousands of people played simultaneously. :contentReference[oaicite:0]{index=0}

On the surface, it looked like:

“Haha look, AI-generated game worlds.”

But I think the deeper implication was much more important than the demo itself.

Infinite Scaler Wasn’t Really a Game Demo

It was a prototype for generative interaction systems.

That’s the part I don’t think enough people noticed.

Traditionally, games are built around:

predefined assets
handcrafted environments
static mechanics
finite content pipelines

Even procedural generation usually operates within tightly constrained systems.

Minecraft seeds.
Roguelike maps.
No Man’s Sky terrain generation.

Still algorithmic.
Still bounded.

Infinite Scaler felt different.

Because the generation layer wasn’t only procedural.

It was conversational.

Language Became the Level Editor

That changes everything.

The game wasn’t asking players to:

pick a map
choose a biome
customize presets
browse assets

Instead, users described imagination directly.

A player types:

“a jellyfish DJ underwater rave”

The system interprets:

semantic meaning
style
objects
composition
visual depth
thematic relationships

Then generates a playable environment around it in real time.

That’s not traditional game interaction anymore.

That’s intent-driven generation.

And honestly, I think this is one of the clearest examples yet of AI changing interfaces at the infrastructure level instead of the feature level.

The Most Important Part Wasn’t the Graphics

It was the speed.

This entire loop happened:

inside a browser
at scale
multiplayer
with thousands of concurrent participants
while generating entirely new content continuously

That’s technically insane.

Especially because the pipeline wasn’t simple image generation.

According to the demo:

prompts were refined through Gemini
assets were generated
depth maps were created
sprite layers were separated
pseudo-3D environments were assembled dynamically :contentReference[oaicite:1]{index=1}

All while users kept playing.

That’s not just an AI gimmick.

That’s a real-time generative rendering pipeline operating interactively.

And I honestly think this matters more than most flashy model benchmark announcements.

This Changes the Relationship Between Players and Games

Historically, games are experiences developers create for players.

Infinite Scaler blurred that boundary.

Players became:

participants
co-creators
world designers
prompt engineers
interaction drivers

The gameplay loop wasn’t only movement.

It was imagination itself.

That creates a fundamentally different creative dynamic.

And weirdly, this feels closer to:

Roblox
Minecraft
VRChat
modding communities
meme culture
TikTok creativity loops

than traditional AAA game design.

The game becomes a platform for generative expression instead of a fixed experience.

We Might Be Entering the Era of “Playable AI”

For years, AI in games mostly existed as:

NPC behavior
procedural enemies
pathfinding
recommendation systems
balancing systems

But generative AI introduces something different entirely.

The game world itself becomes fluid.

Not just visually.

Structurally.

And Infinite Scaler accidentally showcased what that could look like at scale.

Imagine:

multiplayer games generating live events from player conversations
educational worlds adapting to curiosity in real time
AI-generated social spaces
dynamic storytelling environments
personalized exploration systems
infinite user-generated game loops

Suddenly, content pipelines start looking very different.

Developers May Need to Rethink What “Content” Even Means

One thing I kept thinking about after the demo:

What happens when content stops being handcrafted objects
and becomes generated possibility space instead?

That changes:

level design
asset pipelines
moderation systems
memory management
multiplayer synchronization
rendering optimization
interaction design
gameplay balancing

Traditional game development relies heavily on predictability.

Generative systems are probabilistic.

That creates entirely new engineering challenges.

Especially around:

safety
consistency
coherence
performance
abuse prevention
thematic stability

And honestly, I think most of the industry still underestimates how difficult this becomes at scale.

The Moderation Problem Is Massive

One line from the demo stood out to me immediately.

Before generating worlds, the hosts joked:

“As long as it’s safe for work.”

That tiny comment actually hints at one of the biggest unsolved problems in generative systems.

Because once users generate environments through language:

moderation becomes real-time
abuse becomes dynamic
edge cases explode exponentially

Unlike static games, generative systems can produce combinations developers never explicitly created.

That changes moderation entirely.

And I think this is exactly why companies like Google care so much about:

guardrails
policy layers
prompt filtering
classifier systems
constrained generation pipelines

The infrastructure challenge becomes just as important as the model itself.

Infinite Scaler Also Quietly Demonstrated AI-Native UX

This part fascinated me the most.

The interface was almost invisible.

Players weren’t navigating:

creation panels
asset libraries
editing tools
environment builders

They simply expressed ideas naturally.

The system handled translation into interaction.

That’s a huge UX shift.

Because historically, software required humans to learn system logic.

AI-native systems increasingly learn human intent instead.

And I think Infinite Scaler accidentally demonstrated that transition better than many “serious” enterprise AI demos.

This Didn’t Feel Like a Finished Product

It felt like an early glimpse of a new category.

Messy.
Experimental.
A little chaotic.

But genuinely new.

And honestly, that’s what made it interesting.

Not because it was polished.

But because it exposed a direction.

The same way early touchscreen phones felt incomplete before the industry fully understood what they would become.

I Think Google Showed More Than It Intended To

Most people probably saw Infinite Scaler as:

a fun audience activity
an AI showcase
a lightweight keynote break

I think it was accidentally much bigger than that.

Because underneath the spectacle was a very important idea:

language is starting to become a real-time creative interface.

Not just for writing.
Not just for chatbots.
Not just for search.

For interactive systems themselves.

And once that happens, software stops feeling static.

It starts feeling generative.

That’s a very different future than the one most apps were originally designed for.

Google Quietly Changed What “Apps” Mean at I/O 2026

Touhidul Islam Protik — Fri, 22 May 2026 12:00:16 +0000

Last year, I thought Google was building better AI tools. After watching the event from Google I/O 2024 to 2026, I don’t think that anymore. I think Google is slowly redefining what an “app” even is.

And the shift is much bigger than Gemini.

For years, software followed a predictable structure.

You open an app, navigate interfaces, click buttons, fill forms, search menus, and manually orchestrate workflows yourself. AI usually sat on top of that experience as an enhancement layer. A chatbot in the corner. An autocomplete feature. A smarter search bar.

But across the last three Google I/Os, something quietly changed.

The interface itself started disappearing.

The Shift Started Earlier Than Most People Noticed

Back in Google I/O 2024, the focus still looked heavily model-centric.

Most headlines revolved around:

bigger context windows
multimodality
reasoning improvements
Gemini integrations everywhere

At first glance, it felt like the same race the entire industry was already running:
better models, faster outputs, larger benchmarks.

But hidden inside many of those demos was a different idea entirely.

Not:

“How do we improve apps with AI?”

But:

“What if the app is no longer the center of the experience?”

That distinction matters more than it initially sounds.

A lot more.

The First Clue Was Ask Photos

One of the most overlooked demos from I/O 2024 was actually Google Photos.

Not because of image generation.
Not because of editing.

Because of how interaction itself changed.

Instead of navigating folders, albums, timestamps, and filters manually, users could simply ask:

“When did Lucia learn to swim?”

Gemini would:

analyze images
identify progression over time
connect contexts
summarize memories
return a narrative answer

Traditional software required users to adapt to interface structures.

This interaction reversed the relationship completely.

The system adapts to human intent instead.

That’s a fundamentally different computing model.

Search Was Quietly Changing Too

Google Search evolved in a similar direction.

Throughout the keynotes, Google repeatedly emphasized that people were beginning to search differently:

longer queries
conversational prompts
multimodal inputs
exploratory reasoning

That may sound obvious now, but it fundamentally changes the architecture of interaction design.

Classic search focused on:

keyword retrieval
indexed ranking
explicit query matching

AI-native search focuses on:

intent interpretation
contextual understanding
synthesized responses
adaptive interaction

The UI becomes secondary.

The conversation becomes primary.

Then Google Started Removing Workflow Friction Entirely

By I/O 2025, the transition became much harder to ignore.

Especially with:

Project Astra
Project Mariner
Agent Mode
Personal Context
Gemini Live

At this point, Google wasn’t just augmenting interfaces anymore.

It was experimenting with replacing manual orchestration itself.

And that’s where things became genuinely interesting.

Agent Mode Is Not Just “AI Automation”

The apartment-hunting demo from I/O 2025 looked simple on the surface.

Gemini:

searched listings
applied filters
checked requirements
scheduled tours
continued monitoring results in the background

But the important part wasn’t the demo itself.

It was the interaction model behind it.

The user no longer operated the software step-by-step.

Instead, they defined:

goals
constraints
preferences
outcomes

The system handled execution.

That’s not traditional software interaction anymore.

That’s delegated intent.

And honestly, I think that phrase explains almost the entire direction of modern AI products right now.

We’re Moving From “Using Software” to “Directing Systems”

This became the biggest pattern I noticed across all three I/O events.

The old software model looked like this:

users execute workflows manually

The emerging model increasingly looks like this:

users describe objectives

The software layer doesn’t disappear entirely.

It just becomes abstracted away.

In many ways, this feels similar to earlier shifts in computing history:

command line → GUI
desktop → mobile
navigation → feed-based computing

Now we may be entering:

interface → intent

And Google seems fully committed to accelerating that transition.

Infinite Scaler Accidentally Revealed the Future

Oddly enough, one of the clearest examples came from a demo that looked almost unserious.

Infinite Scaler at Google I/O 2026.

A browser-based multiplayer climbing game where players generated live game worlds using prompts.

At first, it looked like a fun crowd experiment.

But underneath the spectacle was something much more important.

Players weren’t selecting predefined assets or environments anymore.

They were generating worlds dynamically through language.

The game itself became:

partially procedural
partially collaborative
partially generative
partially conversational

That’s a completely different relationship between humans and software systems.

And I honestly think this demo was far more important than most people realized.

The Interface Is Becoming Adaptive Instead of Static

Traditional apps are designed around fixed structures:

menus
screens
navigation trees
predefined workflows

AI-native systems behave differently.

The interaction layer becomes:

contextual
reactive
generative
personalized
stateful

NotebookLM demonstrated this surprisingly early.

Users could upload huge amounts of material and receive dynamically generated:

summaries
conversations
quizzes
audio discussions
contextual explanations

Not fixed outputs.

Adaptive outputs.

The experience changes depending on:

context
memory
history
user behavior
modality
intent

That feels much closer to an operating layer than a traditional app.

Personal Context Changes the Entire Equation

I think the most important long-term concept Google introduced wasn’t multimodality.

It was Personal Context.

Because once AI systems can securely access:

emails
documents
preferences
schedules
workflows
browsing behavior
writing patterns

the interface no longer needs constant explicit instruction.

The system already understands situational context.

That’s incredibly powerful.

And honestly, slightly uncomfortable too.

Google’s personalized Smart Reply demo showed Gemini analyzing:

past emails
Drive notes
itineraries
tone preferences
vocabulary patterns

to generate responses that sounded personally authentic.

This goes far beyond autocomplete.

The software is beginning to model behavior itself.

Apps Are Starting to Behave More Like Collaborators

One thing became increasingly clear across these I/O presentations:

Google wants software to feel less like tools
and more like active participants.

Not assistants waiting passively for commands.

Systems continuously reasoning in the background.

That changes:

UX design
frontend architecture
state management
workflow assumptions
interaction patterns
even product thinking itself

Because if AI handles orchestration dynamically, many traditional interface decisions suddenly become less important.

Why design deeply nested navigation systems if users can simply express intent directly?

That question alone could reshape huge parts of frontend development over the next few years.

This Creates New Problems Too

I don’t think this transition will be smooth.

Actually, I think it introduces difficult questions the industry still hasn’t solved:

trust
transparency
hallucinations
over-delegation
permission boundaries
cognitive dependency
interface predictability
behavioral modeling

The more invisible software becomes,
the more important reliability becomes.

A broken button is annoying.

A misaligned autonomous workflow is something else entirely.

And I think the industry still underestimates how difficult that challenge is going to be.

Developers May Need to Rethink Product Design Entirely

A lot of current frontend development assumes:

deterministic flows
predictable navigation
explicit user actions

But AI-native systems are probabilistic.

The interface may no longer be fully predefined.

Instead of designing:

screens
menus
static pathways

developers may increasingly design:

constraints
orchestration layers
memory systems
context boundaries
fallback behaviors
guardrails

That’s a major conceptual shift.

And honestly, I don’t think we fully understand its implications yet.

Google I/O 2026 Didn’t Feel Like a Product Event

It felt like Google slowly exposing a new computing model.

One where:

software becomes conversational
interfaces become adaptive
workflows become delegated
apps become increasingly invisible

The strange part is that this transition isn’t happening through one massive breakthrough.

It’s happening gradually.

One feature at a time.
One workflow at a time.
One interaction at a time.

And I think that’s why many people still see these announcements as isolated AI demos.

But viewed together across multiple years, the pattern becomes difficult to ignore.

We may be watching the early stages of the post-app era.

I Built a Chrome Extension That Teaches Vocabulary While You Browse

Touhidul Islam Protik — Thu, 21 May 2026 14:04:46 +0000

What If Reading Blogs Automatically Improved Your Vocabulary?

A few months ago, I noticed something frustrating about the way most of us read online.

We scroll through articles, blogs, documentation, newsletters, tutorials — constantly running into unfamiliar words — and then do one of two things:

ignore them and keep reading
or open another tab just to search the meaning

Neither feels natural.

And after a while, reading in a new language starts feeling more like work than discovery.

So I built something to change that.

Meet LinguaFlow

LinguaFlow is a Chrome extension that turns normal reading into a lightweight language-learning experience.

Instead of interrupting your reading flow, it quietly helps you build vocabulary while you browse.

When you're reading an article, LinguaFlow automatically underlines words that may be useful to learn. Hover over them, and you instantly get the meaning in your target language — right beside the original word.

No tab switching.

No full-page translation.

No breaking the reading experience.

Just small moments of learning while you naturally browse the web.

The core idea

I didn't want to build another "translate the whole page" extension.

That already exists.

The goal here was different:

Keep the original language intact while making difficult words approachable.

Because language learning works best when context stays preserved.

For example:

"The proposal was rejected due to ambiguity."

Instead of translating the entire sentence, LinguaFlow only helps with:

ambiguity → অস্পষ্টতা

That tiny interaction is surprisingly powerful over time.

You keep reading naturally while slowly absorbing vocabulary in context.

What the extension can do

Smart inline vocabulary assistance

LinguaFlow scans blog posts and articles, then automatically highlights words that may be useful based on the learner's difficulty level.

You can choose:

Beginner
Intermediate
Advanced

So the experience adapts depending on how comfortable you are with the language.

Support for 10+ languages

The extension currently supports more than 10 target languages, including:

Bangla
Spanish
Arabic
English
Japanese
Hindi
French
German
and more

I wanted it to feel useful beyond just English learners.

Save vocabulary while reading

One feature I personally wanted badly:

Sometimes you encounter a really good word while reading and think:

"I should remember this."

But you never do.

So LinguaFlow lets users save vocabulary instantly and build their own mini vocabulary bank over time.

Saved words can later be exported as:

CSV
JSON

which makes it useful for:

Anki imports
flashcard apps
spaced repetition systems
personal study sheets

Why I chose Gemma 4 31B

The extension uses Gemma 4 31B Instruct via OpenRouter & Gemini API.

After testing several models, Gemma felt like the best balance between:

multilingual quality
reasoning
contextual understanding
cost
response speed

One thing I noticed quickly is that vocabulary translation is deceptively difficult.

A word rarely means the same thing everywhere.

Take the word:

"charge"

Depending on context, it could mean:

electrical charge
legal accusation
payment
responsibility

Literal translation systems often fail here.

Gemma performed noticeably better at understanding contextual meaning rather than blindly translating tokens.

That mattered a lot for this project.

Why OpenRouter made sense

I used OpenRouter because it simplified model access and routing significantly.

A few reasons it worked well for this project:

unified API layer
easy model switching during testing
provider fallback support
fast experimentation
lower infrastructure overhead

Since LinguaFlow is an extension, reducing backend complexity mattered a lot.

Something interesting I discovered

While testing multilingual prompts, I noticed Gemma handled mixed-language reasoning surprisingly well.

Especially with:

English ↔ Bangla
English ↔ Arabic
English ↔ Spanish

That made the learning experience feel much more natural compared to rigid dictionary-style translation systems.

The hardest part wasn't AI

Honestly?

The hardest part was DOM handling.

Modern websites are chaotic.

Every platform renders content differently:

Medium
Dev.to
React apps
dynamic infinite-scroll blogs
documentation sites

The extension had to:

avoid breaking layouts
avoid modifying code blocks
avoid touching editable inputs
work with dynamic content
remain lightweight

I ended up using:

MutationObserver
TreeWalker
selective text-node processing

instead of brute-force DOM rewriting.

That single decision improved performance massively.

Another challenge: not being annoying

A language-learning tool can become distracting very quickly.

Too many highlighted words and reading becomes exhausting.

Too few and the extension feels useless.

So I spent a lot of time tuning:

difficulty filtering
common-word detection
underline styles
tooltip timing
translation length

The final goal was:

"Helpful enough to learn from, subtle enough to forget it's there."

Why this project matters to me

I'm from Bangladesh, where a huge number of students learn through English-language resources online:

blogs
YouTube
documentation
research papers
tutorials

But vocabulary friction slows people down constantly.

Especially beginners.

I wanted to make online reading feel less intimidating and more rewarding.

Not through aggressive AI automation.

But through small learning moments.

How to use LinguaFlow

Getting started with the extension is pretty straightforward.

1. Clone the repository

git clone https://github.com/Protik49/LinguaFlow.git

2. Install dependencies

npm install

3. Build the extension

npm run build

After building, the compiled extension files will be available inside the dist folder.

Load the extension into Chrome

1. Open Chrome extensions page

Go to:

chrome://extensions

2. Enable Developer Mode

Turn on:

Developer Mode

from the top-right corner.

3. Load unpacked extension

Click:

Load unpacked

Then select the generated dist folder.

4. Pin the extension

After loading the extension:

click the Extensions icon in Chrome
pin LinguaFlow to the toolbar

This makes it easier to access while reading blogs or articles.

Using LinguaFlow on a website

Step 1 — Open any article or blog

Visit:

Dev.to
Medium
documentation sites
tutorials
news articles
or any readable webpage

Step 2 — Activate LinguaFlow

Click the extension icon and press:

Activate on this page

The extension will begin scanning the article for target vocabulary.

Step 3 — Add your API key (one-time setup)

For the first setup, add either:

your OpenRouter API key
or Gemini API key

This only needs to be configured once.

Step 4 — Choose your learning preferences

Now select:

your target language
vocabulary difficulty level

Difficulty modes:

Beginner
Intermediate
Advanced

This controls which words get highlighted.

Reading experience

Once activated, LinguaFlow automatically underlines words that may be useful for learning.

Clicking an underlined word will show:

translation
contextual meaning
optional explanation
save vocabulary option

Example:

ambiguity → অস্পষ্টতা

The goal is to help users learn vocabulary naturally while reading.

Saving vocabulary

Whenever you find a useful word, you can save it instantly.

Saved vocabulary can later be accessed directly from the extension UI.

Users can also export saved vocabulary as:

CSV
JSON

which works nicely for:

flashcard apps
study sheets
spaced repetition systems
Anki imports

Current supported features

AI-powered contextual translation
10+ target languages
difficulty-based vocabulary filtering
smart inline underlining
vocabulary saving system
CSV/JSON export
lightweight reading experience
works across modern blog platforms

Tech Stack

Built with:

React
TypeScript
Tailwind CSS
Chrome Extension Manifest V3
OpenRouter
Gemma 4 31B

What’s next

A few ideas I'm exploring:

AI-generated quizzes from saved vocabulary
pronunciation support
YouTube subtitle integration
spaced repetition mode
offline vocabulary caching
contextual sentence explanations

Final thoughts

Most language tools pull you away from what you're doing.

LinguaFlow tries to stay inside the experience instead.

The best learning moments often happen accidentally:

while reading a blog
exploring a tutorial
scrolling through an article at 2AM

If a tool can turn those moments into vocabulary growth without interrupting curiosity, I think that's genuinely useful.

And honestly, building this made reading online feel fun again.

GitHub Repository

You can check out the full project here:

👉 LinguaFlow GitHub Repository

Feel free to:

explore the code
open issues
suggest features
contribute improvements
fork the project

If you'd like to try the project, contribute ideas, or give feedback, I'd love to hear your thoughts.

Built with ❤️ using Gemma 4 31B .

AquaOS: An open-source mac inspired portfolio template

Touhidul Islam Protik — Thu, 29 Jan 2026 18:55:45 +0000

This is a submission for the New Year, New You Portfolio Challenge Presented by Google AI

Bringing back the "Aqua" vibe

Remember the early 2000s? The era of glossy plastic, vibrant colors, and that iconic "Aqua" interface on Mac OS X Tiger? There was something magical about that design — it felt alive, tactile, and fun.

I've always missed that aesthetic in our world of flat, minimal design. So, I decided to see if I could bring it back for the modern web. The result is AquaOS, a portfolio template that turns your personal site into a nostalgic, interactive desktop.

🔗 See it live → | 📦 Fork on GitHub →

A "Built by AI" Experiment

Here's the most interesting part: this entire project was built using Google AI Studio and Claude Code.

I wanted to see if I could take a vision—a specific "vibe" from 2005—and use AI to bring it to life. I guided the design and the features, but the heavy lifting, the complex logic, and the code itself came from these incredible AI assistants.

It's Not Perfect (And that's the point)

I'll be the first to tell you: this isn't a pixel-perfect replica.

While it captures the soul of Mac OS X Tiger, it's not 100% entirely Mac-themed. Some parts are modern, some parts are experimental, and since it was built by AI, there are definitely some uniquely imperfect details.

There are plenty of "Mac clones" out there, but this was my personal attempt to see how far I could push AI-assisted design.

Two Worlds: Mac on Desktop, iPhone on Mobile

One of the coolest features isn't just the desktop view. When you open this on your phone, it doesn't just "shrink" the desktop. It completely transforms.

On Desktop: You get the full Mac experience with a dock, menu bar, and draggable windows.
On Mobile: It shifts into an iPhone-inspired interface.

It's designed to feel natural no matter what device you're holding.

Why Open Source?

I'm releasing AquaOS as an open-source project because I want to see what you can do with it.

The goal is to eventually make this the most realistic, nostalgic Mac experience possible on the web. It's a solid foundation, but it's ready for the community to:

Polish the "Aqua" glass effects
Add more realistic system sounds
Build new "apps" for the desktop
Fine-tune the window management

If you love skeuomorphic design as much as I do, I'd love for you to jump in and help improve it.

How to use it

If you want to use AquaOS for your own portfolio, it's simple:

Fork the repo: github.com/Protik49/aquaos-portfolio
Edit one file: Open portfolio.config.ts and update your name, bio, and projects
Deploy: Push to Netlify, Vercel, or any static host

That's it. No complex setup required.

Credits & Final Thoughts

This project is a testament to how far AI tools have come. A huge thank you to Google AI Studio and Claude for being my "pair programmers" on this journey.

It was a fun experiment to see if we could recreate a piece of tech history using the tech of the future. It's not perfect, but it's a start.

🌐 Live Demo: tiprotikaquaos.netlify.app

📦 GitHub: github.com/Protik49/aquaos-portfolio

Fork it, improve it, and let's make this the best nostalgic Mac experience on the web!

How One Blog Post Became a Thread, Newsletter, and LinkedIn Post with Runner H

Touhidul Islam Protik — Mon, 23 Jun 2025 22:10:47 +0000

This is a submission for the Runner H "AI Agent Prompting" Challenge

🤖 Meet Your AI Content Repurposing Assistant

📌 Turn any blog post or long-form idea into:

A well-structured, hook-driven Twitter thread
A compelling, well-formatted newsletter draft
A thoughtful, engaging LinkedIn post
(Bonus: 3 headline/title variations)

Demo

Browsing Session

🧑‍💻 Who This Is For

This prompt is perfect for:

🧵 Twitter-first thought leaders who also want newsletter growth
🧑‍🏫 Educators repurposing videos or lectures
👩‍💻 Indie hackers and solopreneurs growing in public
🧠 Bloggers who want to squeeze more value from every post
🎥 YouTubers and podcasters who need email content
💼 Professionals and creators building an audience on LinkedIn

Runner H is an autonomous agent that executes full tasks from a single prompt. It can:

Read, analyze, and restructure your writing
Understand audience-specific formats
Draft content in your voice
Create polished, platform-ready deliverables

And with the prompt I’m sharing here, it can do something incredibly powerful:

✅ The Results (Before vs. After)

Let’s say you wrote a blog post titled:

"How I Launched a Chrome Extension in 7 Days (and Got 500 Users)"

Before Runner H:

One-time blog post with ~200 views
Shared once on Twitter, buried in your timeline
No email content
No LinkedIn presence

After Runner H Prompt:

A 🔥 Twitter thread with 8 value-packed tweets
A 📬 newsletter draft with digestible, engaging structure
A 💼 polished, audience-aware LinkedIn post
✍️ 3 suggested titles for future sharing

Your work? Just one input. Everything else — done autonomously.

🧾 The Prompt (Copy & Paste Into Runner H)

I want you to take this original content and professionally repurpose it into high-quality content for Twitter (thread), LinkedIn, and my email newsletter.

Original Content:

(Insert blog post, video transcript, or URL here)

Your tasks:

Write a Twitter Thread (5+ Tweets)

At least 5–10 tweets with a scroll-stopping hook

Highlight the key takeaways or insights from the original content

Use clear, concise formatting and end with a CTA or question

Draft a LinkedIn Post

Professional, reflective, and human tone

Use short paragraphs, highlight personal insights or key lessons

End with a CTA or question to spark engagement

Write a Newsletter Draft

Hook intro, body summary of the main value, and soft CTA at the end

150–250 words, friendly tone, skimmable format

Suggest 2–3 engaging alternative titles/headlines for the same content

Deliver everything in a clean Google Doc with headers for each section

Ensure everything sounds natural, thoughtful, and platform-appropriate — avoid generic AI tones or meaningless buzzwords.

Social Love

Share it on X, LinkedIn, and HackerNews.

This AI Prompt Finds Your Team’s Matches and Plans the Whole Trip for You

Touhidul Islam Protik — Wed, 18 Jun 2025 21:20:16 +0000

This is a submission for the Runner H "AI Agent Prompting" Challenge

What I Built

I built an AI travel assistant with Runner H for sports fans that automatically collects all upcoming matches of their favorite soccer team happening within a chosen time window. It pulls in match info, travel estimates, hotel suggestions, and creates a Google Doc summary along with Google Calendar events and reminders. No spreadsheets involved — just clean, readable planning output and calendar alerts.

Demo

Run

How I Used Runner H

I used Runner H to automate a smart travel planning workflow for sports fans. Here’s how the process works:

Find matches – The agent finds all matches for {Favorite Team} scheduled within the next {Timeframe}.
Collect details – For each match, it gathers the date, opponent, stadium name, and location (city and country).
Estimate costs – It finds the average stadium ticket price, round-trip flight cost from {Your Location}, and one or two affordable, well-reviewed hotels nearby with their per-night rate (assuming a one-night stay).
Create Google Doc – All match and travel details are compiled into a Google Doc titled "{Favorite Team} – Upcoming Matches". Each match includes its own section with the collected details:
- Date
- Opponent
- Stadium & Location
- Ticket Price
- Flight Cost
- Hotel Name + Cost
- Total Estimated Cost
Generate Calendar Events – The workflow creates a Google Calendar event for each match titled "{Favorite Team} vs {Opponent}", scheduled on match date and time, with a 24-hour reminder. The Google Doc link is included in the description.

🔌 Before hitting Run, make sure you’ve connected Google Docs and Google Calendar via the 'Connections' tab.

The Prompt

Find all scheduled matches of {Favorite Team}, happening within next {Timeframe}. For each match, collect the date, opponent team, stadium name, and its location (city and country). Also, research the average stadium ticket price and round-trip flight cost from {Your Location} to the match location. In addition, find one or two affordable, well-reviewed hotels near the stadium and note the estimated per-night cost. Assume a one-night stay per match. Organize all this information in a Google Doc titled "{Favorite Team} – Upcoming Matches", with sections for each match containing: Date, Opponent, Stadium, Location, Ticket Price, Flight Cost, Hotel Name, Hotel Cost per Night, and Total Estimated Cost. Then, create a Google Calendar event for each match with the title “{Favorite Team} vs [{Opponent}]”, scheduled for the match’s date and time. Set a reminder 24 hours before each match.

Use Case & Impact

This workflow is perfect for dedicated soccer fans who want to follow their team on the road — or plan a once-in-a-lifetime sports trip. It saves hours of manual searching, reduces planning errors, and presents all the information in a clean, shareable format (Google Doc) with auto-synced calendar events. It’s also adaptable for concerts, esports tournaments, or conferences.

Social Love

Share it on X, LinkedIn, and HackerNews.