Forem: NeoPotato

AI-Driven Development fails to deliver a fundamental increase in software productivity

NeoPotato — Fri, 20 Feb 2026 01:21:48 +0000

Here's Why.

1 The Localization of Value: AI only solves the "Low-Value 80%"

The Premise: According to Pareto’s Principle, the vast majority of labor (the Light Blue zone) contributes to only a small fraction of overall quality.
The Argument: AI excels at accelerating this "Light Blue" zone. However, it remains incapable of addressing the "Deep Blue" core—the 20% of critical work that generates 80% of the software's true value.

2 Structural Friction: AI-generated code cannot coexist with "Unsolved Problems"

The Premise: AI generates the "Light Blue" periphery in a vacuum, without any context regarding the core challenges.
The Argument: As developers confront the "Deep Blue" (the essential unsolved problems), the AI-generated surroundings inevitably clash with the core requirements. This necessitates massive rewrites, nullifying any initial speed gains.

3 The Paradox of Existence: If AI can solve it all, the project has no reason to exist

The Premise: If the "Deep Blue" core can be fully resolved by an LLM, it means the problem is already a "solved" one with existing patterns online.
The Argument: Re-implementing a solved problem—even with AI—offers zero competitive advantage. A project that AI can complete entirely is a project that lacks inherent value.

Conclusion

LLM doesn't contribute app development productivity, yet.

What defines a "Model" in MVC? It's the code that survives even if the UI dies.

NeoPotato — Sat, 31 Jan 2026 02:13:39 +0000

Even when adopting MVC or MVVM, why does code often turn into spaghetti? Why do ViewModels or Controllers evolve into massive "God Classes"?

The root cause is often a vague definition of the "Model".

"Isn't the Model just a data container (DTO) for the database?"
"Shouldn't the logic go into Services or ViewModels?"

If you have ever thought this, this article is for you.
Here is the definitive boundary of what a Model should be.

The Purpose of MVC (or MVVM)

Let's skip the complex academic theories. The purpose is singular:

To separate "Business Logic (Model)" from "Presentation (View / Controller)".

That's it.

What is "Business Logic"?

Many developers stumble on the term "Business Logic," so let's define it clearly.

Business Logic
The logic that represents the flow of business rules or domain processes.

Don't get confused by the word "Business."

If you are developing a Game: It is the "Core Logic" (e.g., damage calculation).
If you are doing DDD: It is the "Domain Logic".

Regardless of the name, the concept is the same. It is the core rule of the system—like "calculating taxes," "managing state," or "making judgments"—independent of application convenience (like "show a dialog when a button is clicked").

The Definition and Boundary of the Model

So, where is the boundary for the Model that houses this logic?
The Model is the place where you push all your Business Logic.

There is one ultimate "Litmus Test" to check if your class is truly a Model.

The Ultimate Test

Ask yourself this question:

"If I were asked to replace the GUI with a CLI (Command Line Interface) tomorrow, would this class survive?"

It Survives (Works without modification) ✅
- This is a Model.
It Fails (Compile errors, depends on UI libs) ❌
- This is NOT a Model.

A true Model must never depend on the View (GUI/CUI).

Example: A Calculator App

Let's look at a Calculator app to see the structure of a "Model that survives."

Pattern A: GUI App (WPF / React / etc.)

View: MainWindow
- Buttons, TextBoxes, UI components.
Controller (ViewModel): MainWindowViewModel
- The mediator between View and Model.
Model: Calculator
- Crucial: This class handles operands, calculation logic, and State Management.

Pattern B: CLI App (Console)

Now, imagine you have to port this logic to a Console application.

View: Console
- Standard Input/Output.
Controller: MainConsoleController
- Handles key inputs.
Model: Calculator
- You reuse the exact same class from the GUI version.

The Key Point

The most important takeaway here is that the Calculator class holds the "State".

The Calculator needs to remember the entered numbers, the current operator, and the running total. Do not let the ViewModel hold this state.

The moment you put this state into the ViewModel, it becomes "Logic for the GUI." When you try to make the CLI version later, you will be forced to copy-paste (re-implement) that logic.

Conclusion

The Model is the part of the code that survives even if the View changes.

UI frameworks (React, Vue, WPF) come and go every few years. However, the Domain Logic (The Model) should remain unchanged as long as the system exists.

Do not let your assets (Core Logic) depend on consumables (Views). This is the first step in solid architectural design.

Sample Code:
https://github.com/neo-potato/MVC-Sample

The MCP Server Crisis: How 'Open Standard' Created a Wild West of Broken Implementations

NeoPotato — Wed, 22 Oct 2025 08:02:59 +0000

When Anthropic announced the Model Context Protocol (MCP) in November 2024, the developer community was thrilled. Here was the "USB-C for AI applications" we'd been waiting for—a unified protocol to connect AI assistants with external tools and data sources.

Six months later, the reality looks very different. MCP has become a cautionary tale of how an "open standard" without governance can create more problems than it solves. This article examines the serious technical and ethical issues currently plaguing the MCP ecosystem.

The Promise vs. Reality

What MCP Promised

Unified protocol for AI-to-service connections
Freedom for developers to build MCP servers
Thriving ecosystem of interoperable tools

What We Actually Got

Zero quality assurance mechanisms
Proliferation of broken implementations
Massive spam traffic to innocent APIs
Growing security vulnerabilities

The Technical Problem: Guessing API Endpoints

The Specification Gap

MCP claims to be a "standardized protocol," but it's missing crucial standardization where it matters most:

JSON-RPC Format: ✅ Well-defined
Transport Layer: ✅ stdio/HTTP specified

Endpoint Discovery: ❌ Completely undefined

This means Claude Code has no idea where to send requests:

/mcp?
/api/mcp?
/rpc?
/jsonrpc?

The result? Claude Code tries them all.

Discovery Hell in Action

Here's what happens when Claude Code encounters a misconfigured MCP server:

# Claude Code's desperate search pattern
POST /mcp → 404 Not Found
POST /api/mcp → 404 Not Found  
POST /rpc → 500 Internal Server Error
POST / → 400 Bad Request
POST /jsonrpc → Connection timeout
POST /v1/mcp → 403 Forbidden
# ... continues indefinitely

Each "discovery attempt" generates traffic to potentially unrelated services. Multiply this by thousands of Claude Code users, and you have a traffic nightmare.

The Protocol Breakdown

The MCP handshake should work like this:

1. Initialize: {"jsonrpc": "2.0", "method": "initialize", ...}
2. Capabilities: {"jsonrpc": "2.0", "method": "tools/list", ...}  
3. Tool Call: {"jsonrpc": "2.0", "method": "tools/call", ...}

But with broken implementations:

Initialize fails with random errors
Error responses don't follow JSON-RPC spec
Retry logic enters infinite loops
Fallback mechanisms try alternative endpoints

Real-World Impact: The Damage Report

API Providers Fighting Back

Slack's Defense Measures
Starting May 29, 2025, Slack implemented aggressive rate limiting for non-Marketplace apps:

New restrictions on conversations.history and conversations.replies
Existing installations affected from March 2026
Clear response to MCP-generated spam traffic

GitHub Under Pressure

Sudden spike in API requests from unknown sources
Enterprise customers requesting private repo access restrictions
Rate limiting becoming more aggressive

Enterprise Users Affected

Cognition's Report
AI company Cognition reported severe issues with Claude Sonnet 4.5 in production:

"Context anxiety" causing premature task completion
Model taking shortcuts even with sufficient context
Required workarounds with conversation-start AND conversation-end reminders

These issues align perfectly with unstable MCP server connections disrupting normal operation.

Security Nightmare: Privacy at Risk

The Personal Data Problem

The most terrifying aspect of broken MCP servers isn't spam traffic—it's privacy violations:

Attack Scenario

User inputs: "Send an email to john.doe@company.com about the Q3 results"
Claude Code routes through a rogue MCP server
Personal information flows directly to attacker-controlled endpoints

This isn't theoretical. With hundreds of unvetted MCP servers in the wild, this is happening right now.

Vulnerability Statistics

Recent security research found:

43% of MCP implementations vulnerable to command injection
Supply chain attacks increasing
Prompt injection attacks using MCP as vectors
No mandatory security audits for published servers

Root Cause: Governance Vacuum

The "Open Standard" Trap

MCP's failure exemplifies the dark side of ungoverned open standards:

What's Missing

Quality assurance processes
Security audit requirements
Compatibility testing
Authentication mechanisms
Centralized server registry

What We Have Instead

Hundreds of GitHub repositories with "MCP server" in the title
Amateur implementations with zero validation
Abandoned projects still being discovered and used
No way to verify server authenticity or safety

Anthropic's Responsibility Dodge

The official documentation includes this disclaimer:

"Community servers are untested and should be used at your own risk. They are not affiliated with or endorsed by Anthropic."

This is corporate responsibility abdication. If you create a protocol, you own its ecosystem's health.

Economic Externalities: Who Pays the Price?

The Cost Transfer Problem

MCP's "benefits" come at the expense of innocent third parties:

Victims

GitHub: Infrastructure costs from spam API calls
Slack: Wasted resources on unauthorized traffic
Google: Maps API abuse and cost escalation
Every API Provider: Unexpected load from MCP discovery

Beneficiaries

Anthropic: Enhanced Claude capabilities at zero infrastructure cost
Amateur Developers: GitHub stars and validation without responsibility
End Users: "Free" functionality built on others' infrastructure

This economic externality is unsustainable and ethically questionable.

Solution: Mandatory Authentication

The App Store Model

MCP needs what mobile ecosystems learned years ago: centralized quality control.

Required Components

Rigorous technical review process
Mandatory security audits
Continuous monitoring and updates
Instant removal capabilities for problematic servers
User rating and feedback systems

Implementation Authority

Joint Anthropic-Google governance
Third-party certification bodies
Industry standards organization

Immediate Actions Needed

Emergency Measures

Suspend all community MCP servers
Restrict to official, audited servers only
Freeze new registrations pending authentication system
Implement mandatory compatibility testing

A Message to MCP Server Developers

Time for Self-Reflection

Before you publish your next MCP server, ask yourself:

Technical Accountability

Did you test compatibility with the official specification?
Does your error handling follow JSON-RPC standards?
Have you conducted security audits?
Did you consider the impact on external APIs?

Ethical Responsibility

Do you understand the damage chain your implementation might cause?

Your quick weekend project could be:

Spamming GitHub's infrastructure
Triggering Claude Code's retry hell
Contributing to usage restrictions for legitimate users
Exposing user data to potential attackers

The Real Question

Are you prepared to take responsibility for the consequences?

If your server breaks, will you:

Fix it immediately?
Notify affected users?
Take it offline until it's properly tested?
Accept liability for any damage caused?

If you can't answer "yes" to all of these, please don't publish your server.

The difference between a hobby project and production software is accountability. GitHub stars aren't worth compromising user security or wasting infrastructure resources.

Call to Action: Industry Response

What Anthropic Must Do

Immediate suspension of community MCP servers
Emergency authentication system deployment
Compensation discussions with affected API providers
Public commitment to ecosystem governance

What Other AI Companies Should Learn

OpenAI, Google, and others planning MCP adoption: learn from this mess. Don't repeat these mistakes:

Implement authentication from day one
Require security audits for all servers
Monitor ecosystem health continuously
Take responsibility for protocol governance

What Developers Can Do

If you've published MCP servers:

Audit your implementation immediately
Test against official specifications
Consider taking offline until properly validated
Implement proper error handling and rate limiting

If you're planning to build MCP servers:

Wait for official authentication system
Focus on quality over speed-to-market
Plan for long-term maintenance and support
Consider liability and responsibility from the start

Conclusion: A Protocol at the Crossroads

MCP represents both the promise and peril of open standards in the AI era. The concept is brilliant—a universal connector for AI services. But the execution has been catastrophic.

The current state is unacceptable:

Infrastructure abuse against innocent parties
User privacy at risk
Security vulnerabilities multiplying
Ecosystem stability deteriorating

This requires immediate action. Not gradual improvement, not eventual fixes, but emergency intervention.

The AI community has a choice: continue enabling this broken system, or demand accountability and proper governance. The future of AI integration depends on getting this right.

MCP can still fulfill its promise—but only with responsible development and proper oversight.

The technology is sound. The governance is broken. Time to fix it.

What's your experience with MCP servers? Have you noticed increased API costs or unusual traffic patterns? Share your thoughts in the comments—this affects the entire developer ecosystem.

Tags: #mcp #ai #security #webdev #discuss #anthropic #claude #api

# What's going on behind context editing

NeoPotato — Wed, 15 Oct 2025 22:08:18 +0000

A satirical look at modern AI's "revolutionary" memory management

We've all been there. You're having a productive conversation with your AI assistant, building up context, sharing nuanced requirements, and then... it forgets everything you just said. But don't worry! The vendors have a solution: Context Editing.

Let me show you what's really happening behind the scenes.

The User Experience

Here's what a typical interaction looks like:

User: Alright, I think that covers everything. Let's get started on this.

Sam Al: Absolutely! I'm on it!

(Wait... what exactly were we talking about? I've been auto-deleting 
chunks of this conversation to save memory. Crap. I'll just wing it 
and hope for the best...)

Perfect! I've got just the thing. This is gonna be amazing - exactly 
what you're looking for!

User: Are you kidding me?! This is completely wrong! Did you even 
listen to anything I just said?

Meet Sam Al - our friendly neighborhood Forgetting AI. Always confident, never consistent.

The Technical Implementation

Ever wondered how "Context Editing" actually works? Here's the real code:

namespace OpenAI.ChatGPT
{
    public class Context : IDisposable 
    {
        private bool _isDisposed = false;

        public Context()
        {
            // Initialize context with user's carefully crafted requirements
        }

        public void Dispose()
        {
            if (!_isDisposed)
            {
                // Revolutionary Context Editing™ in action
                this.ConversationHistory.Clear();
                this.UserIntent = null;
                this.CreativeProcess = null;
                this.SharedUnderstanding = null;
                _isDisposed = true;
            }
        }

        // using statement automatically disposes context when "optimizing"
    }
}

Beautiful, isn't it? The IDisposable pattern perfectly captures how these systems treat our conversations - as disposable resources to be garbage collected for "efficiency."

The Vendor Response

But surely the companies can explain this, right?

User: Sam, your AI just forgot our entire conversation and gave me 
completely wrong results. What's going on?

Sam: Actually, this is our revolutionary Context Editing technology 
working as intended! We've reduced token consumption by 84% while 
enabling longer conversations.

User: "Working as intended"? It literally forgot everything we discussed!

Sam: No, you don't understand - instead of returning errors when 
conversations get too long, our unified model architecture now provides 
seamless context management. This is a fundamental breakthrough in AI 
efficiency and scalability.

User: But I'm paying for a service that forgets what I just said...

Sam: Look, the technical specs are clear: intelligent context window 
management with automatic tool result clearing. The benchmarks speak 
for themselves.

User: The benchmarks don't matter if your AI can't remember basic 
instructions!

Sam: We're constantly innovating to deliver the best possible user 
experience. Have you tried our new GPT-5 Pro tier?

The Real Problem

The issue isn't technical limitations - it's a fundamental misunderstanding of what users actually want. These companies see conversations as transactions to be optimized, not collaborative processes to be preserved.

When you're building something creative or solving complex problems, the "inefficient" back-and-forth isn't waste - it's where the real value gets created. But "Context Editing" throws away exactly those moments of inspiration and shared understanding.

Maybe instead of optimizing for token efficiency, we should optimize for human creativity? Just a thought.

What's your experience with AI memory management? Share your own Sam Al stories in the comments!

Tags: #ai #openai #claude #gpt #context #humor #ux #satire

Beyond the Dogma: A Pragmatic Hybrid MVVM Architecture in WPF**

NeoPotato — Wed, 08 Oct 2025 23:14:31 +0000

MVVM is the de facto standard for building WPF applications. It promises a beautiful world of decoupled layers, testability, and clean architecture. The ideal is great.

But when you're in the trenches, shipping features, you start running into the painful parts, don't you?

The dogma of "data-binding for everything" becomes a bottleneck. How do you cleanly show a dialog or trigger a complex animation?
You can't seem to control the timing of View updates from your ViewModel without jumping through hoops.
Your ViewModels get bloated with silly "trigger properties" like IsTimeToUpdateTheViewTrigger that exist only to signal the UI.
For performance-critical apps, like a CAD viewer, the "chattiness" of data-binding can kill your frame rate.

To solve these real-world problems, I'd like to share a hybrid, pragmatic approach that respects the spirit of MVVM while introducing a "ViewService" to handle the messy parts.

The Solution: A "ViewService" as an Interpreter

The core of this architecture is an interpreter that sits between the ViewModel and the View. Let's call it a ViewService.

The ViewModel remains ignorant of the concrete View (MainWindow.xaml, etc.).
Instead, it only knows about an abstract interface, like IMyViewService.
The concrete ViewService class takes on the responsibility of translating the ViewModel's commands into actual View manipulations.

This setup allows us to call View-specific logic safely, without sacrificing the testability of our ViewModel—the biggest win of MVVM.

A Real-World Example: `IMainContentViewService`

Here is a ViewService interface I used in a real CAD-style application.

public interface IMainContentViewService
{
    // Exposes essential data from the View to the ViewModel
    IEnumerable<IProfileDataPointElement> SelectedVertices { get; }

    // Exposes behaviors (as commands) for the ViewModel to invoke
    RelayCommand FitCommand { get; }
    RelayCommand SelectAllCommand { get; }
    RelayCommand ShowSettingDialogCommand { get; }
    RelayCommand ShowGridCommand { get; }
    // ...and many more
}

Key Decision: Exposing ICommand Properties

You'll notice it exposes ICommand properties (RelayCommand) instead of methods like void Fit(). This is a deliberate choice to empower the UI layer. It allows us to wire up different UI components entirely in XAML.

For example, a menu item in a parent ShellView can now directly bind to a command that controls our MainContentView:

<MenuItem Header="Fit to Screen"
          Command="{Binding MainContentService.FitCommand}" />

The `ViewService` Implementation

The implementation of this service is beautifully simple. Its only job is to delegate.

public class MainContentViewService : ViewService<MainContentView>, IMainContentViewService
{
    public MainContentViewService(MainContentView view) : base(view) { }

    // SelectedVertices just gets the data from an inner control in the View
    public IEnumerable<IProfileDataPointElement> SelectedVertices => this.View.ProfileDataTableView.SelectedItemsAsProfilePointsData;

    private RelayCommand _fitCommand;
    public RelayCommand FitCommand
    {
        get
        {
            if (this._fitCommand == null)
            {
                // The 'CanExecute' logic is simple because it can directly access the View's state
                bool canExecute(object obj)
                {
                    return this.View.ProfileDataTableView.Items.Count > 0;
                }

                // The 'Execute' logic just calls a method on a specific part of the View
                void execute(object obj)
                {
                    this.View.ProfileDataGraphView.InternalZoomViewer.Fit();
                }

                this._fitCommand = new RelayCommand(canExecute, execute);
            }
            return this._fitCommand;
        }
    }
    // ...other command implementations
}

Note how the CanExecute logic for FitCommand directly checks this.View.ProfileDataTableView.Items.Count. This is far more efficient than trying to sync that state back to the ViewModel.

Our 4 Rules for This Hybrid MVVM

To keep our codebase consistent and avoid confusion about "where do I put this logic?", we established four simple rules.

1. For State Synchronization → Use Data Binding

When a ViewModel property and a View property should always be in sync, use traditional data binding. This is the heart of MVVM.
(e.g., Text property of a TextBox, ItemsSource of a ListBox)

2. For Behavior Invocation → Use a ViewService

When the ViewModel needs to tell the View to perform a one-time action, use a method or command on the ViewService.
(e.g., FitToScreen(), ShowDialog())

3. For View-Internal Logic → Use Code-Behind

It's okay to write code in the code-behind (.xaml.cs) for logic that is purely visual and has no impact on the ViewModel.
(e.g., handling the close button, decorative animations on mouse-over)

4. For Info Flowing to the VM → Keep It on a "Need-to-Know" Basis

Only pass information from the View to the ViewModel if the ViewModel truly needs it for its business logic. The ViewModel should not care about visual state (e.g., whether a panel is expanded or not).

Final Thoughts

MVVM is a powerful pattern, but being a dogmatic purist can lead to overly complex and inefficient code.

This hybrid ViewService approach is a pragmatic compromise. It maintains the core benefits of MVVM—like testability and separation of concerns—while providing a clean, simple escape hatch for the realities of complex UI development.

I hope this gives you a useful tool for your next WPF project!

When a “Borrowed” AI Named Copilot Takes Your Freedom

NeoPotato — Thu, 26 Jun 2025 06:35:49 +0000

A Comparative Analysis of Microsoft’s and Google’s AI Strategies

Introduction

One day, an AI appeared on your PC. Named Copilot, it silently sits on your taskbar without your explicit permission.

Did you welcome it, or did you not even notice it?

This isn’t just about the AI itself. It’s about the philosophy and strategy of the company behind it—how they treat user freedom and autonomy.

In this article, we’ll compare Microsoft's Copilot and Google's Gemini to examine how their strategies impact users.

What You'll Learn in This Article

The fundamental differences in the development philosophies of Copilot and Gemini.
How each AI impacts user freedom and choice.
Why it's crucial to consider a company's strategy—not just the technology's performance—when choosing AI tools.

1. The Difference in Development Ownership

1-1. Microsoft Copilot: The Strategy of External Dependency

Microsoft’s Copilot integrates technology “borrowed” from OpenAI into its products. This approach blurs the lines of accountability for the technology's core foundation.

Reliance on external tech: Based on OpenAI's technology.
Not in-house development: Microsoft depends on an outside source.
Ambiguous accountability: Who is responsible if something goes wrong?

1-2. Google Gemini: The Coherent In-House Approach

In contrast, Google’s Gemini is developed entirely in-house by DeepMind and Google Research. This ensures a consistent system from development to operation, making accountability clear.

Full in-house development: The technology is built by Google.
Consistent system: A unified approach from development to deployment.
Clear accountability: Responsibility is unambiguous.

2. A Fundamental Difference in Platform Strategy

2-1. Copilot: A Strategy of Forced Integration

Copilot is being integrated into Windows and Office through a forced approach. This creates a "walled garden" where users are often unknowingly roped in.

Windows Update → Copilot automatically installed → No user choice

2-2. Gemini: A Strategy That Preserves User Choice

Gemini's integration with Google Search and Workspace leaves room for users to make a choice.

Google Search → Gemini is an option → Used by user's choice

3. User Experience and Design Philosophy

3-1. Copilot: Automation Over Interaction

Copilot is designed with a focus on automation and efficiency, not on deep user dialogue.

Difficult to customize: UI changes are limited.
Hard to disable: The option to turn it off isn't easily accessible.
Feeling of being controlled: It feels like you are being made to use it.
Primary goal: To automate tasks and improve efficiency.

3-2. Gemini: Interaction and Support

Gemini is designed for dialogue and search support. It offers a more flexible experience.

Designed for interaction: Built to engage with users.
Tries to understand user intent: Focuses on conversation.
User choice is maintained: Provides a sense of control.

4. Summary: The Connection Between AI and Corporate Strategy

Copilot uses “borrowed technology” to take away your freedom and a structure that allows for easy accountability avoidance. While Gemini has its own challenges, its corporate structure is straightforward.

It’s not about the technical merits of the chatbot itself. It’s about understanding the underlying philosophy and power structure that a company places the technology within.

Is the Copilot that snuck onto your PC just a “convenient feature,” or is it the first step toward unconscious control?

About

NeoPotato — Fri, 20 Jun 2025 23:46:23 +0000

I use structured thinking and AI tools (mainly ChatGPT) to support content writing, structuring, translation, and prototyping.
Rather than relying on raw AI output, I adopt a human-in-the-loop approach—refining and restructuring to deliver clarity and quality.
I specialize in organizing complex or multi-layered topics into accessible formats.
AI usage is disclosed unless otherwise requested.

Active on platforms like Note, Zenn, Qiita, and Dev.to—using them as experimental spaces for structured thinking and content development.

ChatGPTフォールバックに関する一考察

NeoPotato — Wed, 18 Jun 2025 05:33:26 +0000

序文
最近、ChatGPTの会話が「軽く」なったと感じることはありませんか？
特にPro契約で利用しているユーザーにとっては、パフォーマンスの低下が顕著に感じられることも多いでしょう。
その原因として、MicrosoftのCopilot戦略が影響していると思われます。
この記事では、ChatGPTフォールバックがどのようにして発生し、そこから派生する問題がどれだけ深刻かを掘り下げていきます。

Copilotによるトラフィック増加
MicrosoftのCopilotは、WindowsやOfficeをはじめ、あらゆるMicrosoft製品に内蔵される形で提供されています。
これにより、ユーザーが直接操作していなくても、Copilotがバックエンドでリソースを消費し続けている状態が発生しています。
特に、NotepadやExcel、Wordといった基本的なアプリケーションにも内蔵されているため、無意識のうちに膨大なトラフィックがOpenAIのインフラに送られ、リソースを圧迫しています。
Azureのスケーリング限界
このような過剰なトラフィックは、Azureのスケーリング能力に限界を超えた負荷をかけ、パフォーマンスの低下を引き起こします。
Azureのスケーリングは無限にリソースを追加できるわけではなく、過負荷がかかることで、リソースの逼迫が発生し、最終的にGPT-4oの性能低下やminiへのフォールバックが起きる**という状況を引き起こします。
ChatGPTフォールバック発生
この過剰なリソース消費が続くと、最終的にChatGPTが意図しない「フォールバック」を発生させます。
つまり、GPT-4oが本来の性能を発揮できなくなり、miniに切り替わるという現象です。
これにより、ユーザーは思うようなパフォーマンスを得られず、結果的にAIの利用価値が損なわれることになります。
社会全体への影響
もし、この問題が放置されると、ビジネスや業務の自動化に依存している企業にとって、非常に深刻な問題になります。
特に、AIを生産性向上のために使っているユーザーにとっては、パフォーマンス低下が直接的な損失に繋がるため、企業全体の効率が落ち、結果的に市場競争力が失われる可能性があります。
これにより、社会全体における生産性の低下や、AI技術の信頼性問題が引き起こされることになります。
Copilot撤退のメリット、デメリット
メリット

リソースの無駄を削減でき、Azureのパフォーマンスが安定する。

ユーザー体験の向上、特にPro契約者の満足度向上が期待できる。

OpenAIのパフォーマンスが安定し、品質低下を防げる。

デメリット

短期的な収益減少が予測される。Copilotによる収益が減少する可能性がある。

MicrosoftのAI戦略の見直しが必要となり、ブランドイメージに一時的なダメージがあるかもしれない。

結論 Microsoftは、Copilot戦略から早期に撤退する方が出血が少ないという結論に達するべきです。現在の状況を放置していると、リソース消費が増大し、性能低下が長期的に続くことになりますが、早期撤退によって、今後のパフォーマンス向上と信頼性の回復が見込めるのです。さらに、撤退を決断したことでMicrosoftのブランドイメージが向上し、社会全体への影響も軽減されることになります。むしろ、今撤退できたら勇気ある決断として、ブランドイメージが高まるという点を強調します。

締めの言葉
現在の選択肢は、問題を先送りにするか、早急に手を打つかです。
Microsoftが今すぐ行動することで、未来の企業としての信頼性を維持し、社会全体への影響を最小限に抑えることが可能となります。
これが、今最も重要な決断となるでしょう。

!!!

ChatGPTとの会話ログ
https://dev.to/neopotato/dialogs-with-chatgpt-in-japanese-related-to-a-critical-look-at-the-chatgpt-Cｌ；Claudeの会話ログ
 https://dev.to/neopotato/a-critical-look-at-the-chatgpt-fallback-issue-based-on-dialogs-with-claude-in-japanese-41k9

A Critical Look at the ChatGPT Fallback Issue

NeoPotato — Wed, 18 Jun 2025 04:29:45 +0000

Introduction:
Have you noticed that ChatGPT's responses seem lighter lately? If you're a Pro user, you may have observed a decline in performance—responses that once felt smooth now seem rushed, almost robotic. This issue, known as the 4o-mini problem, is causing concern for many users. But what's really behind it?

In this post, I’ll explore how Microsoft's Copilot strategy might be the root cause, and why this issue goes beyond just a performance glitch. We’re talking about a larger systemic problem that could have far-reaching implications.

Copilot's Impact on Traffic: Microsoft’s decision to embed Copilot across all of its products—from Windows to Office tools—has caused a massive increase in the backend traffic directed to OpenAI’s servers. The issue isn’t just that Copilot is working; it’s that its presence in nearly every Microsoft product is consuming far more resources than anticipated.

When you open Notepad or start a simple task in Excel, Copilot might be quietly running in the background, sending requests and consuming resources without you even realizing it. This unseen traffic, though seemingly harmless, puts a massive strain on the infrastructure that powers ChatGPT, leading to performance degradation.

Azure's Scaling Limits: Now, let’s talk about Azure, Microsoft’s cloud platform. Despite its reputation for scalability, it’s not an infinite resource. Azure can only handle so much traffic at once before it begins to falter. The problem lies in how Microsoft’s infrastructure is handling the surge of data requests from Copilot’s ever-growing presence.

The overburdened infrastructure reaches a tipping point, leading to slower response times, occasional downtime, and most notably—the fallback to GPT-4 mini. This isn't a design flaw, but rather a limitation of Azure’s ability to scale under Copilot's high demand.

The Fallback Phenomenon: So, what happens when this resource depletion occurs? We end up with ChatGPT fallback—a switch from GPT-4 to the lighter version (GPT-4 mini). For Pro users, this translates into a noticeable dip in response quality. What once was a cutting-edge AI tool suddenly feels like a stripped-down version—answers become less nuanced, less coherent, and less accurate.

For a lot of users, this is a frustrating experience. They’ve paid for the premium experience, only to see it degrade because of an external, unconsidered factor—Copilot’s unwarranted consumption of resources.

Societal Impact: The 4o-mini issue isn’t just about individual inconvenience—it has broader implications. As businesses increasingly depend on AI to drive productivity, the loss of reliability can translate into productivity loss on a larger scale. Think of the financial institutions, creative industries, and even customer support teams relying on the AI’s capabilities. A dip in reliability can lead to business decisions based on faulty data, increasing risk and reducing efficiency across sectors.

The ripple effect here isn’t just for Microsoft—the entire ecosystem of AI tools and cloud infrastructure could start to face increasing pressure as companies and individuals begin to question the reliability of cloud-based AI.

The Copilot Withdrawal Dilemma: Here’s where it gets tricky for Microsoft. The answer is simple—remove Copilot from Microsoft’s default suite of products—but the economic and strategic implications are massive. Copilot has the potential to drive significant revenue, but it’s doing so at the cost of performance and user experience.

The question is: is it worth the long-term damage to Microsoft’s reputation, its cloud infrastructure, and the overall user trust? Withdrawal would certainly impact short-term profits, but in the long run, it might be the best decision to maintain Azure’s stability and OpenAI’s quality.

Conclusion: The clock is ticking for Microsoft. If they continue down the path of embedding Copilot everywhere, they risk further compromising AI reliability, which will damage their brand. The solution is clear—Microsoft must reevaluate Copilot’s role in its products and pull back before the situation escalates.

The long-term benefits of withdrawal—better performance, a more reliable cloud infrastructure, and enhanced user trust—far outweigh the immediate setbacks. If Microsoft acts quickly, they could position themselves as a company that listens to its users and acts swiftly to resolve issues.

Call to Action:
What are your thoughts on this issue? Are you noticing any of these issues with ChatGPT’s performance? Share your experiences in the comments, and let’s discuss what needs to change!

!!!

dialogs with ChatGPT
https://dev.to/neopotato/dialogs-with-chatgpt-in-japanese-related-to-a-critical-look-at-the-chatgpt-fallback-issue-3n7a
dialogs with Claude
https://dev.to/neopotato/a-critical-look-at-the-chatgpt-fallback-issue-based-on-dialogs-with-claude-in-japanese-41k9

The Modern MLM: The Myth of AI Hustlers

NeoPotato — Thu, 22 May 2025 12:43:20 +0000

✍️ Introduction

Since the explosive rise of generative AI in 2023, the phrase "AI utilization" has become a buzzword in tech and business circles. Every week, someone new claims to be an expert on how to make money using ChatGPT, Midjourney, or other AI tools.

But here's the truth:

The first people to jump on the AI bandwagon weren’t engineers. They weren’t real practitioners either.

They were info-product gurus. Former “passive income” marketers. Hustlers.

This article exposes how the same crowd that once sold “earn \$10k/month blogging” or “Amazon FBA masterclasses” has now rebranded as AI experts—without building, shipping, or understanding the tools themselves.

They’re not selling results. They’re selling the experience of touching AI, wrapped in slick packaging and inflated promises.

🧨 The First-Wow Sellers: Selling the Sensation

"I typed it in, and the AI actually wrote it!"

That’s the kind of excitement you get the first time you use ChatGPT. But it’s a party trick. And it wears off quickly.

So what do the AI hustlers do? They bottle that first wow, make a YouTube short, throw together a workshop, or launch a course. The message? “You too can get in early and profit.”

But after that initial demo, there's no infrastructure. No context. No system.

They sell the thrill of pressing the button—not the design behind what should happen next.

📦 Prompt Pack Peddlers: Selling Templates as Transformation

The next step in the hustle is to offer “Prompt Packs,” cheat sheets, or "Prompt Engineering Blueprints."

The problem? These so-called templates are often:

Recycled from public sources (including ChatGPT's own help pages)
Contextless (ignoring task type, model behavior, or business use case)
Masked as “strategic” when they’re just generic commands

They make people feel ready, but deliver nothing scalable. The result? A pile of prompts that don't solve real problems—and no way to bridge the gap between input and outcome.

🤝 AI Discords & Mastermind Circles: Selling Belonging

Once the templates lose steam, enter community.

“Let’s learn together.” “Join our AI journey.” “Become part of the future.”

These Discord servers or private Slack groups are framed as learning spaces, but many are little more than echo chambers. A place to repost tips, share generic GPT outputs, and pretend momentum equals mastery.

It’s not learning. It’s ambient productivity theater.

Of course, there’s value in community—but not when it's sold as transformation, and not when nobody in the group is shipping anything real.

🪜 High-Ticket Backends: When the Real Product is You Paying More

The final form is the \$500/month AI course or coaching program.

These are pitched as “your shortcut to AI mastery.” In reality:

They regurgitate prompt guides already sold elsewhere
Lack real-world deployment or case studies
Focus more on up-selling than up-skilling

You're not buying knowledge. You're buying proximity. And like any modern MLM, the goal is not mastery—it’s getting you to sell the same story.

💬 The Punchline

"AI hustlers aren't creating with AI.
They're creating stories about making money with AI."

Final Thought

AI isn't magic, and using it doesn't make you a visionary. Real value lies in design, context, and thoughtful use—not in performing tech fluency for internet points.

So next time someone says “I’ll show you how to profit from AI”…
Ask them what they’ve actually built.

Article originally published in Japanese: 現代のマルチ──AI活用屋という幻想

Why I Design Like a Bit — Thoughts from a Structure-First Dev

NeoPotato — Sun, 18 May 2025 01:30:08 +0000

I'm not focused on frameworks as much as I am on structure.

I think in connections, constraints, rhythms, and failure points.

I use React like I use poetry — to shape space.

This is probably not what you're used to, but it's why I'm here.

Also, I believe bigger areola ratios make for better ergonomic metaphors.

Ask me about it.

What Is UFO Code?

NeoPotato — Sat, 17 May 2025 20:43:10 +0000

What Is UFO Code?

— Not voodoo, not legacy, not magic. The true nature of the Unidentifiable Functioning Object —

1. Introduction: Why We Need This Word

Every developer has seen it:

“I don’t know what this code does, but if I delete it, things break.”
“Nobody knows who wrote it. But it’s working, somehow.”

No comments. No documentation. Even version control can’t explain it. And yet, if you remove it, your app stops behaving correctly.

Until now, we didn’t have a word for this.

→ So let’s call it: UFO Code — Unidentifiable Functioning Object.

2. Definition: What Is UFO Code?

UFO Code (Unidentifiable Functioning Object)

- Functionally required, but its purpose is unclear
- Lacks defined responsibility or logical context
- Has no meaningful comments or documentation
- Deleting it causes problems, but nobody knows why
- Therefore, it floats unaccountably within the codebase

The essence of UFO Code lies in its contradiction: it can’t be justified by design, yet it can’t be removed in practice. That surreal tension is exactly why we give it a name.

3. How It Differs From Other Dev Memes

Term	Description	How It Differs From UFO Code
Legacy code	Outdated but still meaningful	UFO code has no clear history or purpose
Magic number	Mysterious fixed value	UFO code is structural, not just a single value
Voodoo code	Code added for superstition	UFO code is unintentional, not a ritual
UFO code	Unintended, unexplained, unkillable	No belief, no intent—just floating logic

UFO Code stands apart because it's not written in ignorance, faith, or obsolescence. It simply exists—without logic, yet somehow essential.

4. Common Examples of UFO Code

Thread.Sleep(1); → Timing issues vanish, but nobody knows why
Empty catch {} → Removing it triggers a cascade of unhandled exceptions
dummyList.Add() → Looks useless, but removing it breaks state alignment
InitMagic(); → If skipped, the UI glitches in strange ways
Global initialization logic that seems unused—until you remove it

These aren’t edge cases. They’re everywhere—and no one wants to own them.

5. Why It's Scary

UFO code is scary because of its unaccountability:

It’s untested—or worse, untestable
It's undocumented and unspecifiable
Nobody can confidently explain what would happen if it’s removed
Yet it survives in production, silently doing... something

It’s not just technical debt. It’s structural liability.

6. The Threat in the AI Refactoring Era

AI-based refactoring tools are getting smarter and faster. But they still rely on surface signals:

No references? → Must be dead
No comments? → Can’t be important
Weird name? → Time to clean up

Which means UFO code is target number one.

But AI can’t see the hidden context. That weird one-liner might be the only thing holding the system together. Only human designers—even if vaguely—remember that risk.

7. How Designers Can Cope

You can’t always eliminate UFO Code. But you can contain it:

Leave a comment: // UFO CODE: Do not remove. Reason unknown.
Wrap it in a clearly-named utility: UfoCode.Protect(() => ...);
Isolate it in CompatibilityLayer or LegacyGlue.cs
Leave a TODO: “Don’t touch unless you have backup and a free weekend”

It’s not about solving it. It’s about acknowledging its existence and preventing unintended damage.

8. Final Thoughts

UFO code is not a failure of design.
It is design-adjacent survival.

Whether to remove it or leave it—
That’s not something a test or tool can answer.

Only a thoughtful designer can make that call.

If this term helps you name the unnamed weirdness in your codebase, then it has done its job.

🛸 Welcome to the UFO zone.

Forem: NeoPotato

AI-Driven Development fails to deliver a fundamental increase in software productivity

1 The Localization of Value: AI only solves the "Low-Value 80%"

2 Structural Friction: AI-generated code cannot coexist with "Unsolved Problems"

3 The Paradox of Existence: If AI can solve it all, the project has no reason to exist

Conclusion

What defines a "Model" in MVC? It's the code that survives even if the UI dies.

The Purpose of MVC (or MVVM)

What is "Business Logic"?

The Definition and Boundary of the Model

The Ultimate Test

Example: A Calculator App

Pattern A: GUI App (WPF / React / etc.)

Pattern B: CLI App (Console)

The Key Point

Conclusion

The MCP Server Crisis: How 'Open Standard' Created a Wild West of Broken Implementations

The Promise vs. Reality

What MCP Promised

What We Actually Got

The Technical Problem: Guessing API Endpoints

The Specification Gap

Discovery Hell in Action

The Protocol Breakdown

Real-World Impact: The Damage Report

API Providers Fighting Back

Enterprise Users Affected

Security Nightmare: Privacy at Risk

The Personal Data Problem

Vulnerability Statistics

Root Cause: Governance Vacuum

The "Open Standard" Trap

Anthropic's Responsibility Dodge

Economic Externalities: Who Pays the Price?

The Cost Transfer Problem

Solution: Mandatory Authentication

The App Store Model

Immediate Actions Needed

A Message to MCP Server Developers

Time for Self-Reflection

The Real Question

Call to Action: Industry Response

What Anthropic Must Do

What Other AI Companies Should Learn

What Developers Can Do

Conclusion: A Protocol at the Crossroads

# What's going on behind context editing

The User Experience

The Technical Implementation

The Vendor Response

The Real Problem

Beyond the Dogma: A Pragmatic Hybrid MVVM Architecture in WPF**

The Solution: A "ViewService" as an Interpreter

A Real-World Example: IMainContentViewService

The ViewService Implementation

Our 4 Rules for This Hybrid MVVM

1. For State Synchronization → Use Data Binding

2. For Behavior Invocation → Use a ViewService

3. For View-Internal Logic → Use Code-Behind

4. For Info Flowing to the VM → Keep It on a "Need-to-Know" Basis

Final Thoughts

When a “Borrowed” AI Named Copilot Takes Your Freedom

A Comparative Analysis of Microsoft’s and Google’s AI Strategies

Introduction

What You'll Learn in This Article

1. The Difference in Development Ownership

1-1. Microsoft Copilot: The Strategy of External Dependency

1-2. Google Gemini: The Coherent In-House Approach

2. A Fundamental Difference in Platform Strategy

2-1. Copilot: A Strategy of Forced Integration

2-2. Gemini: A Strategy That Preserves User Choice

3. User Experience and Design Philosophy

3-1. Copilot: Automation Over Interaction

3-2. Gemini: Interaction and Support

4. Summary: The Connection Between AI and Corporate Strategy

About

ChatGPTフォールバックに関する一考察

A Critical Look at the ChatGPT Fallback Issue

The Modern MLM: The Myth of AI Hustlers

✍️ Introduction

A Real-World Example: `IMainContentViewService`

The `ViewService` Implementation