Yapay Zeka

There’s a strange feeling that comes with opening an old project folder again.

You look at the messy files, random commits, unfinished components, and half-working features… and instantly remember the excitement you had when you first started building it.

That’s exactly what happened to me.

A few months ago, during a hackathon, I started building an AI-powered study assistant for students. The idea sounded exciting at 2 AM with coffee in one hand and deadlines in the other ☕💀

The goal was simple:

“Create a smart workspace where students can upload notes, generate summaries, create quizzes, and stay productive.”

At that time, it honestly felt like my best idea.

But like many hackathon projects, reality hit hard.

The UI was incomplete.
The backend was breaking.
Authentication barely worked.
And the AI responses were inconsistent.

The hackathon ended… and so did the project.

Or at least, that’s what I thought.

💭 The Problem With Unfinished Projects

I think every developer has that one project.

The one you genuinely believed in… but never finished.

Not because the idea was bad.
Not because you stopped caring.
But because life, deadlines, burnout, and complexity slowly pushed it aside.

For me, this project became exactly that.

Every time I opened the repository, I’d tell myself:

“I’ll complete it someday.”

Someday finally became now.

And honestly, this challenge gave me the perfect reason to revive it.

🛠️ The “Before” Version

The original version was rough 😭

Here’s what it had:

Basic PDF upload
A simple AI summary feature
Unresponsive layout
Broken navigation
No mobile support
Poor folder structure
Duplicate code everywhere

The app technically worked…

…but it definitely didn’t feel like a real product.

The biggest issue was that the project had grown too messy for me to continue confidently.

That’s where GitHub Copilot genuinely changed the experience for me.

🤖 How GitHub Copilot Helped Me Finish It

I didn’t use Copilot as a “shortcut.”

I used it like a coding partner.

And surprisingly, it helped most in the areas where I usually lose motivation while rebuilding old projects.

✨ Refactoring Old Code

Some of my components were huge and difficult to manage.

Copilot helped me:

Split components cleanly
Reuse UI sections
Improve readability
Remove repetitive logic

It saved me from spending hours rewriting boilerplate code manually.

🎨 Improving the UI

One thing I learned:

A project feels alive again when the UI starts looking polished.

I rebuilt the dashboard with:

Better spacing
Cleaner cards
Dark mode
Responsive layouts
Smooth animations

Copilot even suggested cleaner Tailwind structures while I was redesigning pages.

🧠 AI Features That Finally Worked

This time, I didn’t want the app to just “look cool.”

I wanted it to actually help students.

So I added:

AI-generated summaries
Flashcard creation
Quiz generation
Study roadmap suggestions
Smart productivity tracking

One of my favorite additions was a GitHub-style study consistency heatmap 📈

It visually tracks how consistently a student studies every day.

That feature made the project finally feel complete.

🚀 The “After” Version

The final product became something far beyond the original hackathon demo.

Now the platform includes:

✅ AI note summarization
✅ Quiz generation
✅ Flashcards
✅ Authentication
✅ Mobile responsiveness
✅ Dark mode
✅ Productivity analytics
✅ Better accessibility
✅ Cleaner backend structure

More importantly…

It finally feels usable.

Not just “another unfinished side project.”

📚 What I Learned From Reviving This Project

Finishing a project feels very different from starting one.

Starting is exciting.
Finishing requires patience.

This experience taught me:

Old projects still have potential
Small improvements compound over time
Clean code matters more than fast code
Good developer tools reduce burnout
Sometimes all a project needs is a second chance

And honestly?

Reviving something unfinished felt more rewarding than starting something new.

❤️ Final Thoughts

I used to think abandoned projects were failures.

Now I see them differently.

Sometimes they’re just unfinished stories waiting for the right moment.

This challenge pushed me to stop chasing “new ideas” for once and finally complete something I already believed in.

And thanks to GitHub Copilot, rebuilding this project felt less overwhelming and far more creative than I expected.

Maybe the best projects aren’t always the ones we start perfectly.

Maybe they’re the ones we refuse to give up on

Google Docs summaries, task planning, research help, workflow automation… I wanted to know whether Hermes Agent was actually useful or just another flashy AI demo. 👀

Like many developers, I’ve seen countless “AI agents” online recently. Most of them look impressive for five minutes and then fall apart the moment you give them real work.

So instead of watching another demo video, I decided to do something more interesting:

👉 I gave Hermes Agent actual tasks for an entire day.

Not toy prompts.
Not “write me a poem.”
Real tasks that I normally do myself.

And honestly? Some of the results genuinely surprised me.

First Impressions 💡

The first thing that stood out to me about Hermes Agent was that it didn’t feel like a normal chatbot.

Most AI assistants wait for instructions. Hermes Agent felt more like a system that wanted to figure things out step-by-step.

That difference became obvious very quickly.

What also caught my attention was the flexibility. Unlike many closed AI systems, Hermes Agent can run on your own infrastructure and connect with different models and tools. That open-source approach already makes it interesting for developers who like control and customization.

You can explore the project here:

Hermes Agent Official Website
Hermes Agent GitHub Repository
The Experiment 🧪

I decided to treat Hermes Agent like an AI intern for one full day.

Here were the tasks I gave it:

✅ Research assistance
✅ Summarizing long information
✅ Planning workflows
✅ Multi-step reasoning tasks
✅ Organizing ideas
✅ Helping with coding-related work
✅ Remembering context between tasks

I wasn’t expecting perfection.
I mainly wanted to see one thing:

Could this agent actually reduce my workload in a meaningful way?

Task 1: Research and Summarization 📚

I started with something simple.

I gave Hermes Agent a large amount of information and asked it to summarize the key points and organize them clearly.

This is where I noticed the first major difference compared to normal chatbots.

Instead of giving a quick surface-level answer, Hermes Agent tried to break the task into smaller reasoning steps. It felt more structured and intentional.

And surprisingly, the summaries were actually useful — not just random bullet points copied from the input.

That immediately made me think:

“Okay… this might be more powerful than I expected.” 👀

Task 2: Multi-Step Workflow Planning ⚙️

Next, I tested something harder.

I asked Hermes Agent to help plan a small workflow involving multiple steps and dependencies.

This is where many AI tools usually struggle. They often lose context or generate inconsistent steps halfway through.

Hermes Agent handled this much better than I expected.

It broke the task into:

goals,
subtasks,
logical sequences,
and execution ideas.

It genuinely felt like the agent was thinking through the process instead of just predicting the next sentence.

That distinction matters a lot.

The Most Interesting Part: It Felt Persistent 🧠

One of the biggest reasons Hermes Agent stood out to me was its approach to memory and persistence.

Most AI chats feel temporary. You ask something, get a response, and everything disappears into the void.

Hermes Agent feels different because it’s designed around:

learning,
memory,
skills,
and long-term improvement.

That changes the experience completely.

At one point, I noticed it referencing earlier context more naturally than I expected, and that small moment honestly made the system feel far more “agentic” than typical AI assistants.

Not magical.
Not perfect.
But definitely different.

Where Things Got Messy 😅

Of course, not everything worked perfectly.

There were moments where:

outputs became repetitive,
reasoning drifted slightly,
or tasks required clearer instructions than I initially gave.

And honestly, I’m glad those moments happened.

Because it made the experience feel real.

One thing I’ve realized while testing AI systems is that the most trustworthy reviews are the ones that include failures too.

Hermes Agent is powerful, but it’s still a tool that benefits from good prompting, structured tasks, and realistic expectations.

What Actually Impressed Me Most 🚨

It wasn’t the speed.

It wasn’t flashy outputs.

It was the feeling that Hermes Agent was trying to operate through tasks rather than simply answer prompts.

That sounds like a small difference, but it changes everything.

For the first time in a while, I felt like I was interacting with something closer to an AI workflow system rather than a standard chatbot interface.

And I think that’s exactly why so many developers are paying attention to agentic AI right now.

Open-Source AI Feels Important Again 🌍

Another thing that made this experience exciting was the open-source side of Hermes Agent.

In a world where most advanced AI systems are becoming increasingly closed and centralized, there’s something refreshing about tools that developers can actually:

run themselves,
customize,
inspect,
and experiment with freely.

That openness creates room for innovation.

And honestly, some of the most interesting AI experiments in the next few years might come from open communities rather than giant corporations alone.

Final Thoughts 💭

After spending a day testing Hermes Agent with real work, I don’t think AI agents are just hype anymore.

Are they perfect? No.

Are they fully autonomous replacements for humans? Definitely not.

But systems like Hermes Agent show where things are heading:

persistent AI,
tool-using AI,
self-improving workflows,
and agents that can genuinely assist with complex tasks.

The most surprising part?

For the first time, I stopped feeling like I was “chatting with AI” and started feeling like I was coordinating with a system that could actually help manage work.

And that shift feels important. 🚀

Thanks for Reading 🙌

If you’ve experimented with Hermes Agent or other agentic systems, I’d genuinely love to hear your experience too.

The AI agent space is evolving incredibly fast, and it feels like we’re only beginning to see what these systems might eventually become.

As part of my undergraduate research in Graph Neural Networks (GNNs) and Causal Inference, I’ve been exploring a major flaw in modern recommender systems: observational bias.

Standard recommendation algorithms—even state-of-the-art GNNs like LightGCN and NGCF—learn from biased data. Popular items get shown more often, which leads to more clicks, creating a feedback loop that reinforces popularity bias and buries niche items.

To solve this, I built an open-source framework that combines GNNs with Causal Reinforcement Learning to debias recommendations.

Here is how I approached it.

👋 Hi, I’m Tasfin Mahmud! I’m a CS Researcher at BRAC University and an open-source contributor. You can learn more about my work on my portfolio website or my GitHub.

🏗️ The Baseline GNNs

I started by implementing three solid baseline architectures in PyTorch Geometric (PyG):

1. LightGCN: The minimalist approach that drops non-linear transformations.
2. NGCF (Neural Graph Collaborative Filtering): Explicitly models high-order connectivities with feature interaction terms.
3. GAT-CF: Graph Attention Networks adapted for collaborative filtering.

These models perform incredibly well on standard metrics. But there is a catch: if you evaluate them on observational data, the metrics look great only because the test data shares the same exposure bias as the training data.

🧪 Injecting Causal RL

To break the popularity loop, I implemented four complementary causal debiasing techniques.

1. Inverse Propensity Scoring (IPS)

The simplest way to fix exposure bias is to reweight the Bayesian Personalised Ranking (BPR) training loss. IPS divides the loss for each item by its exposure probability. Rarely shown items receive a higher gradient signal, while mega-popular items are scaled down.

2. Causal Embeddings (CausE)

Here, the model maintains two separate embedding spaces:

• A factual space (learned from the biased data)
• A counterfactual space (representing uniform exposure)

A discrepancy regularizer pulls the factual representations toward the unbiased counterfactual ones, preventing the model from overfitting to the exposure distribution.

3. Causal Policy Gradient

Treating recommendations as a sequential decision-making problem, I used the REINFORCE algorithm. The core innovation here is Causal Reward Shaping: decomposing observed rewards into the “true preference” (causal component) and the “popularity bias” (confounding component). Using Doubly Robust (DR) estimation makes learning from logged data much more stable.

4. Causal Discovery

How do we know what the confounders are if they aren’t explicitly measured? I implemented a causal discovery module using Truncated SVD on the exposure matrix to automatically identify latent confounding factors, which are then integrated into the reward shaping process.

📊 The Results

I benchmarked these approaches using LightGCN on the MovieLens 100k dataset:

(Note: Evaluating debiased models on standard biased test sets results in lower raw metric scores because the test set shares the exposure bias. Unbiased logging data is required to see the true lift).

💡 The Takeaway

GNNs are powerful tools for recommendation, but without causal inference, they are simply learning to amplify existing biases in your dataset. By utilizing techniques like IPS and Causal Policy Gradients, we can build recommendation systems that truly understand user preference rather than just popularity.

🔗 Check out the full framework on my GitHub:
gnn-collaborative-filtering

🔗 Learn more about my research and open-source work:
tasfinmahmud.github.io

Let me know in the comments if you’ve worked with Causal Inference for recommendation systems!

*How Gemma 4 Could Bring Powerful AI Closer to People, Not Just Servers

For a long time, using powerful AI has felt a bit like borrowing someone else’s computer from far away. Every question, image, or request had to travel through the internet to massive cloud servers before coming back with an answer. It worked, but it also came with limits — slow connections, privacy concerns, expensive APIs, and the constant need to stay online.

But recently, that idea started to change for me.

When I explored Google’s Gemma 4 models, I realized something important: the future of AI may not live only in giant data centers. It may live on our own devices.

And honestly, that feels like a breath of fresh air.

Why Local AI Feels Different

Most conversations around AI focus on bigger models, faster responses, or smarter chatbots. But what excited me most about Gemma 4 was something simpler — accessibility.

Gemma 4 introduces powerful capabilities like multimodal understanding, advanced reasoning, and a huge 128K context window, while also supporting local deployments across different kinds of devices. That means AI is no longer only for companies with huge budgets and powerful servers. In many ways, it levels the playing field.

For students, creators, and independent developers, that matters a lot.

Sometimes the best ideas come from people who do not have unlimited resources. Gemma 4 feels like a tool that opens doors instead of building walls.

A Future Beyond Constant Connectivity

In many places, stable internet is still not guaranteed. Even today, students often struggle with weak networks, limited data plans, or shared devices. Cloud-based AI can become difficult to rely on in those situations.

Now imagine this instead:

A student sitting in a small town using an offline AI tutor on a low-cost laptop.

A medical worker accessing a private assistant without uploading sensitive information to external servers.

A creator brainstorming ideas while traveling without worrying about internet speed.

That is where local AI starts to shine.

As the saying goes, “necessity is the mother of invention.” Sometimes limitations push technology in the right direction. Local AI is not just about convenience — it is about making intelligence more available to ordinary people.

What Makes Gemma 4 Exciting

One thing I appreciate about Gemma 4 is that it does not feel like a one-size-fits-all solution. The different model sizes make it flexible enough for different needs, from lightweight experiments to larger applications.

The multimodal capability is especially interesting because it allows AI to work with more than just text. That opens the door for tools that can understand images, documents, notes, and visual information in a much more natural way.

The long context window also caught my attention. Anyone who has worked with AI knows how frustrating it can be when a model “forgets” earlier parts of a conversation or document. With 128K context support, Gemma 4 can handle much larger amounts of information at once, making interactions feel smoother and more useful.

And then there is reasoning.

We are slowly moving from AI that simply responds to AI that can genuinely assist with problem-solving and deeper thinking tasks. That shift could change how students learn, how developers build, and how small teams innovate.

Why This Matters to Me as a Student Developer

As a student developer, what inspires me most is not just the technology itself — it is the possibility behind it.

Powerful AI often feels out of reach for many learners. Either the hardware is expensive, the APIs cost too much, or the tools require constant internet access. It can feel like the cards are stacked against small creators.

But local AI changes the conversation.

It gives students the freedom to experiment, build, and learn without depending entirely on cloud platforms. Even simple projects can become meaningful. An offline study assistant, a note summarizer, a multilingual learning tool — these ideas suddenly feel possible.

That is exciting because innovation should not belong only to large companies. Sometimes a small idea in the right hands can punch above its weight.

The Bigger Picture

I do not think the future will be “cloud AI versus local AI.” Both will continue to exist and grow together.

But I do believe local AI will become increasingly important.

People care more about privacy now. Developers want flexibility. Students want affordable tools. And many communities still need technology that works even with limited connectivity.

Gemma 4 feels like a step toward that future — one where AI becomes more personal, more accessible, and more adaptable to real-world situations.

Not every technological shift changes who gets to participate.

This one just might.

Final Thoughts

The most impressive thing about Gemma 4 is not only its capabilities. It is the idea behind it.

Powerful AI is slowly moving closer to people instead of farther away behind massive infrastructure. And that could make all the difference.

We often say technology should make life easier, but the best technology also makes opportunities wider. In many ways, Gemma 4 feels like a glimpse of that future.

And for students, builders, and curious minds everywhere, that future looks incredibly promising.

DeepSeek made its V4-Pro 75% price cut permanent on May 22. The conventional read: “they got cheaper hardware.” The real story is more interesting — and it’s about a gap that’s not closing fast enough.

What Happened

On May 22, 2026, DeepSeek announced that the 75% discount on its V4-Pro API would become permanent. The new pricing:

At current exchange rates, that’s roughly $0.44/M input and $0.87/M output — making V4-Pro one of the cheapest frontier-class models on the market, on par with DeepSeek’s own V4-Flash but with significantly more capability.

The move came exactly four weeks after V4’s launch on April 24, and coincided with growing user frustration over rate limits at Google Gemini and Anthropic Claude.

The Standard Narrative

The surface-level story has three parts:

1. Architectural efficiency. V4 uses a Mixture-of-Experts architecture with 1.6 trillion parameters, but only activates a fraction per token. This gives it a structural cost advantage over dense models of comparable capability — roughly 30% of the gap.

2. Supply chain scaling. Huawei’s Ascend 950PR entered mass production in April 2026. Huawei plans to ship ~750,000 units through the year — a 2.5x increase over 2025’s 910C output. DeepSeek specifically optimized V4 for the Ascend architecture. More chips → lower unit cost → lower API pricing.

3. Competitive positioning. Western AI providers (Google, Anthropic) have been quietly tightening rate limits as demand overwhelms their GPU supply. DeepSeek is exploiting the backlash, offering unlimited usage at a fraction of the cost to capture disgruntled developers.

All three are true. But none of them fully explains the magnitude of the cut — or why it’s permanent rather than promotional.

The Math That Changes Everything

Let’s check the numbers.

Demand Side

China’s daily token consumption hit 140 trillion in March 2026, according to the National Data Administration. The growth trajectory:

• Early 2024: 0.1 trillion/day
• End of 2025: 100 trillion/day
• March 2026: 140 trillion/day

That’s a 1,000x increase in two years, and a 40% jump in just the last quarter — implying ~13% month-over-month growth.

Supply Side

Huawei’s mass-produced chip for 2026 is the Ascend 950PR (Prefill-optimized, 1 PFLOPS FP8), with the higher-end 950DT (2 PFLOPS FP8) coming in Q4. The numbers:

(Throughput derived from Huawei’s published Atlas 950 SuperNode benchmark: 19.6M tokens/sec across 8,192 cards.)

Now the arithmetic:

Even in the most optimistic scenario — every single chip dedicated to inference at 100% utilization:

The conclusion is stark: 750,000 Ascend 950 chips can’t cover today’s demand — let alone the demand in six months.

So Why Cut Prices?

If supply is still a fraction of demand, permanent price cuts don’t make sense in a normal market. But this is not a normal market.

The Real Logic: Pre-Commitment, Not Surplus

DeepSeek is not cutting prices because it has spare compute. It’s cutting prices to lock in routing commitments before the hardware arrives.

Here’s the timeline:

April 24:  V4 launched, optimized for Ascend
April 24+: ByteDance orders 350,000 Ascend 950 chips (~¥40B)
May 4:     Ascend 950PR mass production confirmed
May 22:    DeepSeek makes V4-Pro 75% cut permanent

The critical insight: DeepSeek’s price cut is not a cost pass-through. It’s a market share pre-commitment — using the promise of future Ascend supply to grab developer mindshare now, before Western competitors can resolve their own capacity issues.

The Numbers Behind the Strategy

Western providers are capacity-constrained:

DeepSeek’s bet: “Spend the next 6 months building developer dependency on V4-Pro’s API — by the time Ascend supply catches up in H2 2026, those developers won’t switch back.”

This is AWS in 2006. AWS wasn’t cheaper than running your own servers in 2006. But it would be once scale kicked in. AWS priced for the scale it planned to have, not the scale it had. DeepSeek is doing the same.

What 750,000 Chips Actually Buys

The popular framing in Chinese media is “75万颗昇腾950产能大爆发.” But as the math shows, 750,000 chips isn’t abundance — it’s barely adequacy.

Think of it this way: China’s token demand is growing at roughly 0.5 trillion tokens per day every single month (the monthly increment itself is larger than the entire market 18 months ago). By year-end, demand will be 300-400+ trillion. Against that, 750K chips at the 950PR/DT mix buy roughly 50-85T/day of inference capacity.

The gap is growing, not shrinking. Even with 75万 chips fully deployed, the supply-demand deficit more than triples over nine months.

This means DeepSeek’s price cut isn’t a sign of market saturation. It’s a sign of exactly the opposite: a market so unsaturated that the winner gets to define the default API for an entire generation of developers, if they can lock them in before the hardware arrives.

Three Counter-Arguments (And Why They’re Weak)

“But cache hits reduce the effective compute needed”

True — cache-hit tokens cost ~1/100th of miss tokens. And DeepSeek’s cache hit rates can be high for workloads with stable system prompts. But cache hits are mostly in the input direction. Output tokens — the expensive ones — still need full compute. And as agentic workloads grow (multi-turn, chain-of-thought), output-to-input ratios increase, making cache less effective.

“But not all 140T tokens need 950-class inference”

Also true. Many tokens are generated by smaller models (Flash variants, Qwen, etc.) that don’t need 950-level compute. But the growth is in the frontier-class tokens — longer context, more complex reasoning, higher quality requirements. That’s exactly where 950-class chips are needed.

“But they can still buy H20 / smuggled H100”

H20 is less capable than 950PR per chip (the US-designed it to be worse). And the CHIPS Act + export controls have made H100 procurement increasingly difficult. Relying on smuggled hardware is not a supply chain strategy.

What This Means

For Developers

Your inference costs are likely going down over the next 12 months, not up — even though demand is exploding. That’s unprecedented in any computing market. The driver isn’t efficiency gains or manufacturing scale. It’s a strategic subsidy by Chinese AI firms betting that locking in your API calls today is worth negative margins for a year.

Take the subsidy. But don’t assume today’s prices reflect tomorrow’s costs — they reflect tomorrow’s hopes.

For the Industry

The AI API market has entered a phase that looks like price war but functions like infrastructure land-grab. The playbook is AWS 2006, DoorDash 2019, Uber 2015: lose money on every transaction to own the default routing.

When the hardware does catch up — when Ascend 960 (2027) or 970 (2028) ships with 3-5x the throughput — the providers with the largest captive developer bases will convert negative margins to positive ones. Everyone else will be competing on price against incumbents they can’t dislodge.

The Bottom Line

DeepSeek’s permanent price cut is not evidence that Chinese AI compute supply has caught up with demand. The math shows it hasn’t — and won’t for at least 12-18 months. It’s evidence that DeepSeek is playing the long game: use today’s negative margins to own tomorrow’s default inference route, and trust that Huawei’s future chips will eventually close a gap that’s currently 3-5x wider than headlines suggest.

The 75% cut isn’t a cost breakthrough. It’s a bet that developer lock-in is worth more than current margins — and that the 75万 Ascend 950 chips shipping this year are just the beginning.

Numbers sourced from: National Data Administration (China daily token data, March 2026), Huawei Connect 2025 (Ascend 950 specs and roadmap), SCMP/DW (ByteDance order volume), DeepSeek official pricing page (May 2026). Throughput calculations based on published Atlas 950 SuperNode benchmarks. Growth projections assume continuation of 40%/quarter rate per published data.

Your Claude response comes back in 800 milliseconds. You’re on a roll. Three features shipped before lunch. And somewhere, silently, your debugging intuition is going to sleep.

I’ve been tracking a pattern across developer forums — not just V2EX, but in the back-channels of engineering team chats: developers who live in network-restricted regions are increasingly “renting” computational presence elsewhere. A computer in a data center, a VM in Singapore, a colleague’s spare workstation. They connect, they code, they use AI tools that would otherwise be unreachable. Problem solved.

Except it’s not solved. It’s deferred. And the cost is accumulating in a place most devs never check: the gap between what they can describe doing and what they can actually do.

The Compute Rental Economy

The V2EX discussion that triggered this article described a developer’s setup: living abroad, rented room with a desktop computer inside China, wants to remotely access that machine to use Claude’s web interface and write code. The comments branched into VPN recommendations, remote desktop protocols, browser-based solutions, and one or two voices asking the question nobody else wanted to answer — why?

The why matters. If you’re routing through a remote machine just to access an AI assistant, you’re not solving a network problem. You’re renting computational sovereignty. And like all rentals, you’re paying for access without building ownership.

Here’s what that looks like in practice, from a commenter’s description that stuck with me: a developer in Shanghai spends 4 hours daily on a remote desktop session to a machine in Tokyo. The latency hovers between 40-80ms — annoying but workable. The AI tools load. The code ships. And every evening, the developer closes the session knowing they built something without ever touching the actual hardware that built it.

That distinction — built on versus built with — is where the skill erosion starts.

Skeleton Implementation Syndrome

I need to coin a term here, because the existing vocabulary doesn’t capture this:

Skeleton Implementation Syndrome — the tendency to ship code you could describe but couldn’t write from scratch. You understand the architecture. You can explain why the service mesh routes requests the way it does. But when the AI is gone and the remote session drops, the gap between concept and implementation becomes a chasm you didn’t notice until you had to cross it alone.

This is different from normal abstraction. Normal abstraction is healthy — you don’t need to remember register allocation when writing Python. Skeleton Implementation Syndrome is pathological: you’ve delegated so much implementation to AI assistance that your mental model of how things actually work has decayed faster than your ability to ship features.

The ratio of regret here is asymmetric in a way that hurts quietly: AI assistance accelerates feature delivery (OPTIMIZED FOR) while accelerating capability decay (SACRIFICED). You win the sprint. You lose the skill. And the debt compounds invisibly because nobody measures “debugging intuition remaining” in your quarterly review.

The Local Environment Learning Tax

Here’s where I need to make an unpopular argument, and I want you to stay with me:

Running AI tools locally — even with degraded performance — produces better engineers than accessing them remotely on optimized infrastructure.

Before you close this tab: I’m not saying remote access doesn’t work. I’m saying the learning tax of renting compute is asymmetrically borne by the developer’s capability, not by their feature velocity.

When you run a model locally (even a quantized 7B parameter model that takes 45 seconds to warm up on your M2 Max), you’re forced to develop intuition about:

• Token budgets and context windows — because you see the cost in real time, not abstracted away
• Prompt sensitivity — because small changes produce observable differences without a slick web interface smoothing the edges
• Failure modes — because local models fail in ways remote APIs don’t (OOM crashes, context truncation, hallucination patterns specific to your hardware)
• System integration — because getting a local model to talk to your IDE requires actual configuration work, not just clicking “authorize”

The V2EX developer’s setup — remote machine, AI through a browser, code in a remote session — sidesteps all of this. The AI becomes a utility, like electricity. And like electricity, you stop thinking about how it works.

The Infrastructure You’re Betting On

There’s a second-order risk nobody talks about in these remote access discussions: you’re building workflow dependencies on infrastructure you don’t control.

Your remote machine exists because someone else maintains it. The network path between you and it exists because someone else routes it. The AI service you’re accessing exists because a company decided it should, and can decide otherwise.

In my local environment (M2 Max, 32GB RAM), I’ve been running a mix of local models and API access for two years. The local models are slower. They have smaller context windows. They fail in embarrassing ways. And they have never, not once, changed their terms of service, raised their prices, or decided my use case wasn’t “enterprise enough.”

The developers routing through Tokyo data centers to access Claude? They’re one corporate decision away from rebuilding their entire workflow. That’s not paranoia — that’s operational risk with a specific name: vendor dependency disguised as infrastructure convenience.

What Actually Survives

If you’re in a network-restricted region and remote access is genuinely your only option, I’m not here to tell you to suffer. Suffering isn’t a virtue. But here’s what I’d ask you to track, because I’ve watched this pattern destroy capable engineers:

Track your AI dependency score. After every coding session, ask yourself: could I have solved this without the AI? If the answer is “no, and I couldn’t have solved it six months ago either,” that’s data. That’s the gap growing.

The developers who survive this environment — who maintain capability while using AI as a multiplier — are the ones who treat AI as a colleague who happens to be infinitely patient, not a replacement for the thinking that made them dangerous in the first place.

They ask AI for second opinions, not first drafts. They use it to explore unfamiliar territory, not to avoid territory they should have mapped already. They keep a “dumb project” — something they code without AI, where inefficiency is the point, where the slow path is the learning path.

The Question I Can’t Answer For You

Here’s what I keep coming back to: the V2EX developer asked how to access Claude from their remote setup. Nobody asked what you’ll lose by making it this easy.

I don’t know your specific context. Maybe the feature velocity matters more than the debugging intuition. Maybe you’re in a sprint that doesn’t have room for the local model learning curve. Maybe the tradeoff is genuinely worth it.

But I know this: the engineers who lasted 15 years in this industry didn’t do it by shipping faster. They did it by being the person who could debug what everyone else gave up on. That capability doesn’t come from prompt engineering courses. It comes from struggling through problems without a safety net — and your remote setup, however clever, is a very comfortable safety net.

What’s the last thing you debugged without AI assistance? Not without searching the internet — without AI generating the answer for you. Go remember what that felt like. That’s the skill you might be renting away.

What’s your take?

Has your team noticed developers becoming less capable of independent debugging without AI? What’s your experience been — are you moving faster, or just shipping more?

I’d love to hear how this plays out in your specific context. Drop a comment below — I respond to every one.

Discussion on V2EX about remote access solutions for China-based developers wanting to use Claude web interface

Discussion: What’s the last thing you debugged without AI assistance — not without searching, but without AI generating the answer? How did it feel compared to using AI?

CSS :has() is not just a fancy :parent

When :has() started popping up in specs and tweets, I mentally filed it under “cool, but not for shipping work.” I was wrong.

Now it is in Chrome, Safari, Edge, and Firefox. I use it in real projects. It has removed entire JavaScript files and a pile of .is-active classes that I was embarrassed to maintain.

If you are a working frontend dev, the shorthand is this: :has() turns CSS from “style what is there” into “style this thing if it contains that thing”. That one capability changes layout, state, and validation flows.

I will walk through three places where it made a real difference for me:

• Parent styling without JS
• Sibling state UIs without wiring events
• Form validation UI that reacts to the DOM, not a framework

All of this shipped with zero additional JavaScript.

Quick mental model of :has()

The syntax looks like a pseudo class on a selector:

.card:has(img.hero) {
  /* styles here */
}

Read it as: “select .card elements that have a descendant img.hero somewhere inside.” It is a conditional filter on the left side of the selector.

You can also scope it more tightly:

.tabs:has(> .tab.is-active) {
  /* direct children only */
}

Or use it with relational selectors like siblings:

.field:has(+ .field--error) {
  /* this .field is followed by an error field */
}

Once that clicks, you start seeing places to remove JS.

1. Parent styling in a content-heavy project

First real use: a content-heavy marketing site for a biohacking brand I work with. Editors can drop components in any order with a CMS. Sometimes a card has an image, sometimes it is text-only. The layout should adapt.

Previously I solved this with modifier classes from the CMS, or a hydration script that scans the DOM and adds classes like .card--with-media. Boring, fragile, and slightly gross.

With :has() I deleted that script.

Image-aware cards

The card markup is boring on purpose:

<article class="card">
  <img class="card__media" src="hero.jpg" alt="">
  <div class="card__body">
    <h2>Title</h2>
    <p>Some text...</p>
  </div>
</article>

<article class="card">
  <div class="card__body">
    <h2>Another Card</h2>
    <p>Text-only card.</p>
  </div>
</article>

Now the CSS decides layout based on presence of media.

.card {
  display: grid;
  gap: 1rem;
}

.card:has(.card__media) {
  grid-template-columns: minmax(0, 2fr) minmax(0, 3fr);
  align-items: center;
}

.card:not(:has(.card__media)) {
  padding: 2rem;
  background: #111;
  color: #eee;
}

Result: if marketing drops in an image, the card becomes a two-column layout. If not, it becomes a full-width text block. No new class. No CMS configuration. No JS.

I like this because the markup stays semantic and dumb. The layout is a true function of the content, which is what CSS was always supposed to do but rarely could at the parent level.

Auto-promoting “hero” sections

Same project. Editors could add a .section stack: some had a prominent CTA, some were just copy. If a section had a primary CTA, design wanted extra padding and a gradient background.

<section class="section">
  <h2>Get early access</h2>
  <p>Short description.</p>
  <a class="btn btn--primary" href="#">Join the beta</a>
</section>

<section class="section">
  <h2>What you get</h2>
  <p>More text...</p>
</section>

With :has() I treat any section with a primary button as a pseudo hero.

.section {
  padding: 2rem 1.5rem;
  background: #050505;
}

.section:has(.btn--primary) {
  padding: 4rem 1.5rem;
  background: radial-gradient(circle at top, #2f80ed, #050505);
  color: #fff;
}

.section:has(.btn--primary) h2 {
  font-size: 2.25rem;
}

That tiny selector replaced a custom “hero” block type in the CMS that content editors kept misusing. I stopped explaining “use the hero component for this” and just let the CSS infer intent from presence of a primary CTA.

You can do similar things with :has(video), :has(.badge--new), etc. It is a good fit for messy CMS content where you want layout to respond to what your editors actually do, not what the schema designer hoped they would do.

2. Sibling state UIs without event listeners

Second use case: stateful UIs that I used to wire up with click handlers. Tabs, disclosure panels, navigation highlights, that stuff.

Yes, you can still do it in JS. But if the state is already visible in the DOM, :has() lets CSS own more of the behavior. That means less code, fewer states to sync, and fewer bugs.

Tabs powered by :target and :has()

On a little side project for baseball drills, I built a tabbed interface where each tab is actually a link to an anchor. I wanted a sticky tab bar that changes style when any tab content is active.

<div class="tabs">
  <nav class="tabs__nav">
    <a href="#hitting">Hitting</a>
    <a href="#pitching">Pitching</a>
    <a href="#fielding">Fielding</a>
  </nav>

  <section id="hitting" class="tabs__panel">...</section>
  <section id="pitching" class="tabs__panel">...</section>
  <section id="fielding" class="tabs__panel">...</section>
</div>

The panels show / hide with a regular :target trick.

.tabs__panel {
  display: none;
}

.tabs__panel:target {
  display: block;
}

Old me would now add JS to toggle classes on the nav. Instead I lean on :has().

.tabs {
  border-bottom: 1px solid #333;
}

.tabs__nav a {
  padding: .5rem 1rem;
  text-decoration: none;
  color: #888;
}

.tabs__nav a:is(:hover, :focus-visible) {
  color: #fff;
}

/* highlight the active tab label */
.tabs__nav a[href^="#"] {
  position: relative;
}

.tabs:has(#hitting:target) .tabs__nav a[href="#hitting"],
.tabs:has(#pitching:target) .tabs__nav a[href="#pitching"],
.tabs:has(#fielding:target) .tabs__nav a[href="#fielding"] {
  color: #fff;
  font-weight: 600;
}

/* make the whole tabs block look active if any panel is targeted */
.tabs:has(.tabs__panel:target) {
  border-color: #2f80ed;
}

I am not pretending this scales to 50 tabs. For most content UIs, 3 to 5 tabs is realistic. Writing those few selectors is still cheaper than adding a tab manager, handling history state, and worrying about hydration.

The key pattern is: some child panel already has state via :target or [aria-selected="true"]. Let :has() bubble that state up to parents and siblings.

Accordion with native <details> and :has()

I use <details> a lot. It is surprisingly powerful with :has(). On a settings panel I wanted the container to visually compress when no section was open, then expand once any accordion entry was open.

<section class="settings">
  <details class="settings__item">
    <summary>Profile</summary>
    <div>...</div>
  </details>
  <details class="settings__item">
    <summary>Privacy</summary>
    <div>...</div>
  </details>
</section>

CSS:

.settings {
  padding: 1rem;
  border-radius: .75rem;
  border: 1px solid #333;
  max-height: 60vh;
  overflow: auto;
  transition: box-shadow .2s ease, border-color .2s ease;
}

.settings:has(.settings__item[open]) {
  border-color: #2f80ed;
  box-shadow: 0 16px 40px rgba(0, 0, 0, .55);
}

.settings__item + .settings__item {
  border-top: 1px solid #222;
}

.settings__item summary {
  cursor: pointer;
}

Once any <details> is open, the whole settings block feels “in focus”. No JS to listen for the toggle event, no syncing of .is-active classes. The HTML already has [open]. CSS reacts.

3. Form validation UI with zero JavaScript

The biggest win for me: form UI that uses :has() with built-in browser validation. No client-side validation library. No “touched” state juggling.

On my own site I revamped a contact form and a simple experiment log form. I wanted:

• Parent field wrappers that highlight error or success
• Inline messages that only show when actually invalid
• Submit button that changes state based on form validity

Browser validation already tracks validity. The DOM knows. :has() lets CSS hook into that.

Field states from input validity

Markup:

<form class="form" novalidate>
  <div class="field">
    <label>
      Email
      <input type="email" name="email" required>
    </label>
    <p class="field__error">Please enter a valid email.</p>
  </div>

  <div class="field">
    <label>
      Message
      <textarea name="message" minlength="10" required></textarea>
    </label>
    <p class="field__error">Write at least 10 characters.</p>
  </div>

  <button type="submit">Send</button>
</form>

You can bind field styling to the input inside, purely with CSS.

.field {
  margin-bottom: 1.5rem;
}

.field input,
.field textarea {
  width: 100%;
  padding: .6rem .75rem;
  border-radius: .4rem;
  border: 1px solid #444;
  background: #050505;
  color: #eee;
}

.field__error {
  display: none;
  margin-top: .35rem;
  font-size: .8rem;
  color: #ff6b6b;
}

/* highlight when invalid and touched (using :user-invalid where supported) */
.field:has(input:user-invalid),
.field:has(textarea:user-invalid) {
  color: #ff6b6b;
}

.field:has(input:user-invalid) input,
.field:has(textarea:user-invalid) textarea {
  border-color: #ff6b6b;
  box-shadow: 0 0 0 1px rgba(255, 107, 107, .6);
}

.field:has(input:user-invalid) .field__error,
.field:has(textarea:user-invalid) .field__error {
  display: block;
}

/* success state */
.field:has(input:user-valid),
.field:has(textarea:user-valid) {
  color: #4caf50;
}

.field:has(input:user-valid) input,
.field:has(textarea:user-valid) textarea {
  border-color: #4caf50;
}

No custom event handlers. The browser decides when the input is valid or invalid. CSS uses :has() to move that state to the wrapper and the message.

If you want broader support than :user-invalid, you can fall back to :invalid and accept that some browsers show the state earlier.

Form-level feedback and submit button state

Now zoom out one level. The entire <form> element also exposes validity via :valid and :invalid. Combine that with :has() and your submit button can react.

.form button[type="submit"] {
  padding: .7rem 1.25rem;
  border-radius: .4rem;
  border: none;
  background: #333;
  color: #aaa;
  cursor: not-allowed;
  transition: background .15s ease, color .15s ease, transform .05s;
}

/* any invalid field keeps button in "disabled" style */
.form:has(:invalid) button[type="submit"] {
  background: #333;
  color: #777;
}

/* all fields valid, button goes live */
.form:has(:valid) button[type="submit"] {
  background: #2f80ed;
  color: #fff;
  cursor: pointer;
}

.form:has(:valid) button[type="submit"]:active {
  transform: translateY(1px);
}

If you want to actually disable the button, you still need a tiny bit of JS to toggle the disabled attribute. I usually do not bother for simple forms; the button just looks inactive until the browser considers the form valid.

The nice part is that the logic lives where it belongs. The browser enforces constraints. CSS reads that state. JS, if present at all, sends the request and displays a toast.

4. Layout tweaks based on children, not breakpoints

One more pattern that has crept into my “default toolkit”: adjusting layout based on how many items a container has.

On my baseball drills page, each drill has one or more tags. I wanted single-tag drills to show the tag inline next to the title, and multi-tag drills to move them into a separate row. Doing that in JS felt silly.

<article class="drill">
  <header class="drill__header">
    <h3 class="drill__title">Front toss</h3>
    <div class="drill__tags">
      <span class="tag">Hitting</span>
    </div>
  </header>
</article>

<article class="drill">
  <header class="drill__header">
    <h3 class="drill__title">Relay race</h3>
    <div class="drill__tags">
      <span class="tag">Fielding</span>
      <span class="tag">Conditioning</span>
    </div>
  </header>
</article>

With :has() and the :nth-child() selector you can treat the two cases differently.

.drill__header {
  display: flex;
  gap: .5rem;
  align-items: baseline;
  flex-wrap: wrap;
}

/* one tag only: keep inline */
.drill__tags:has(.tag:nth-child(1):last-child) {
  order: 0;
}

/* more than one tag: push tags to next line */
.drill__tags:has(.tag:nth-child(2)) {
  flex-basis: 100%;
  order: 1;
}

No JavaScript counting nodes. No data attributes. Just “if there is at least a second tag, change layout”. If product decides to add a third or fourth tag, the CSS keeps working.

Reality check: performance and support

I am not going to pretend :has() is free. The browser has to do more work, because selectors now depend on what is inside elements and how that changes.

My take after profiling a few real pages: do not go wild with global *:has(...) selectors. Scope them. Prefer direct children or close relationships.

/* Bad idea */
*:has(.error) { ... }

/* Reasonable */
.form:has(.field__error) { ... }

/* Even better */
.form:has(.field > .field__error) { ... }

Support is good now. Chrome, Edge, Safari, Firefox all ship :has(). Old Safari versions are the main risk. If you work on something critical for a weird enterprise fleet, check caniuse and add progressive enhancement.

Most of my patterns above fail gracefully. You lose a highlight or a layout tweak, not core functionality. That is a good bar to aim for.

How I think about :has() now

I used to reach for JavaScript whenever a parent needed to know about a child, or a sibling needed to react to state. That felt normal. It also created a lot of glue code that did not age well.

Now my filter is simple:

• Is the state already visible in the DOM? (attribute, pseudo class, anchor, etc.)
• Can that state reasonably drive styling only?

If the answer is yes, I try :has() first. JS comes later, if at all.

Five years ago I was writing tab managers and form validators by hand. I would not go back. :has() is the layout trick that finally lets CSS act on the structure we already have, instead of the utility classes we wish we had planned better.

If you have a component that keeps growing event listeners and state flags, look at the HTML for five minutes. There is a decent chance :has() can take some of that weight off.