Original Chinese article:
https://www.cnblogs.com/shanyou/p/21309486
TL;DR
Bun’s migration from Zig to Rust demonstrates a broader infrastructure trend: as software moves from experimentation into production, compiler-enforced correctness becomes more valuable than conventions that depend on developers always being careful.
The same transition may now be happening in AI infrastructure.
Python remains excellent for research, training and rapid prototyping. However, production AI systems also need lifecycle management, API contracts, observability, dependency injection, database integration, deployment tooling, concurrency and predictable resource usage.
The article argues that C# is unusually well positioned for this layer.
Its central piece of evidence is TensorSharp, a native C# inference engine whose reported Qwen Image Edit 2511 benchmark results outperform stable-diffusion.cpp in several pipeline stages.
The broader thesis is not simply that C# can run AI workloads. It is that C# can combine near-C++ inference performance with the application and infrastructure capabilities of the .NET ecosystem.
The article then extends this technical argument into a philosophical one:
Builder → AI Agent Leader → Taste
As AI makes implementation increasingly accessible, human value shifts from writing every line of code toward defining problems, coordinating agents, evaluating results and deciding what is worth building.
1. The lesson from Bun: infrastructure benefits from compiled languages
At the end of 2025, the Bun team described migrating approximately 535,000 lines of Zig code to Rust using 64 Claude instances over an 11-day period.
Bun is a JavaScript runtime, which creates an inherently difficult boundary:
- JavaScript relies on garbage collection.
- Runtime internals often require manual memory control.
- Re-entrant callbacks can invalidate assumptions about object lifetimes.
- Bugs may emerge only under unusual concurrency or callback sequences.
The article highlights examples such as use-after-free failures, invalidated hash maps, out-of-bounds writes and reference-counting problems.
These were not presented as isolated coding mistakes. They were symptoms of a structural problem: when garbage-collected code and manually managed memory interact, lifecycle correctness may depend heavily on conventions, testing, fuzzing and developer discipline.
Rust changes the feedback loop.
Instead of discovering a lifetime problem after a crash, the compiler can reject an invalid ownership relationship before the program runs. In that model, rules that would otherwise live in a style guide become enforceable properties of the type system.
The equivalent problem in AI infrastructure
The article argues that production AI systems are encountering a similar transition.
| Runtime-infrastructure problem | Comparable AI-infrastructure problem |
|---|---|
| Manual memory combined with JavaScript GC | Python’s dynamic runtime, GIL and native-library boundaries |
| Large codebases that depend on conventions | Growing collections of difficult-to-maintain AI “glue code” |
| Memory and concurrency failures discovered at runtime | Production crashes, leaks and concurrency bottlenecks |
| Rapid AI-assisted rewrites | Increasing maintenance costs as infrastructure expands |
The conclusion is not that Python should disappear. Python remains highly valuable for algorithms, research and training.
The claim is narrower: AI inference services are becoming production infrastructure rather than laboratory scripts, and the infrastructure layer increasingly benefits from compiled languages and stronger contracts.
2. TensorSharp as evidence for native C# inference
Before arguing that C# is a good infrastructure language, the article asks a more fundamental question:
Can C# compete with C++ at the inference-engine level?
Its answer is based on reported results from TensorSharp, a deep-learning inference engine implemented in C#.
The benchmark compared its Qwen Image Edit 2511 pipeline with stable-diffusion.cpp.
Test configuration
- CUDA
- Resolution:
544 × 1184 - Four inference steps
- Q2_K DiT
- Lightning four-step LoRA
- Identical input image
- Identical prompt
- Identical CFG
- Identical seed
Reported benchmark
| Metric | TensorSharp, C# | stable-diffusion.cpp, C++ | Reported C# advantage |
|---|---|---|---|
| Warm total time | 40.44 seconds | 48.16 seconds | 1.19× faster |
| Time per step | 7.57 seconds | 9.43 seconds | 1.25× faster |
| Sampling | 30.27 seconds | 37.73 seconds | 1.25× faster |
| VAE encoding | 0.54 seconds | 1.92 seconds | 3.56× faster |
| VAE decoding | 1.51 seconds | 2.57 seconds | 1.70× faster |
The data is attributed to TensorSharp PR #81 and its author, Zhongkai Fu.
Why the result matters
The article’s argument is not merely that one C# implementation won one benchmark.
Its more important claim is that C# can reach C++-class inference performance while remaining integrated with a managed production stack.
A C++ inference engine may provide excellent low-level performance, but a complete production system still needs capabilities such as:
- Type-safe API contracts
- Dependency injection
- Model-lifecycle management
- Background and hosted services
- Database persistence
- Distributed tracing
- Structured configuration
- Compile-time analyzers
- Container and Kubernetes deployment
- Application-level authentication and authorization
With C#, these capabilities can exist in the same runtime and programming model as the inference engine.
This is why the article describes TensorSharp not as “C# glue around a native engine,” but as evidence that C# can be used to build the engine itself.
3. C# versus Rust and Go for AI infrastructure
The article does not argue that C# is universally superior.
Different languages occupy different optimization points.
Rust
Rust is a strong choice when the system requires:
- Precise ownership
- Zero-cost memory abstractions
- Safety without garbage collection
- Browser-engine or operating-system-level control
- Deep interoperability with native components
Bun’s choice of Rust therefore makes sense.
Go
Go is exceptionally strong for:
- Kubernetes-native services
- Small binaries
- Fast compilation
- Simple concurrency
- Gateways, operators and control-plane services
- Straightforward cloud deployment
The article characterizes Go as the native language of cloud infrastructure.
C
C# occupies a different position. It combines managed memory and high-level application development with increasingly capable low-level primitives:
Span<T>Memory<T>ref struct- Hardware intrinsics
- NativeAOT
- Source generators
-
unsafecode where necessary - Asynchronous programming and the Task Parallel Library
Its central advantage is described as full-lifecycle coverage.
C# can be used for:
- Domain modeling
- API development
- Compile-time validation
- Database access and migrations
- Distributed tracing
- Background processing
- Agent orchestration
- Deployment composition
- Inference-engine implementation
Simplified comparison
| Area | Go | Rust | C# |
|---|---|---|---|
| Memory model | Simple GC | Ownership and borrow checking | GC plus low-level memory APIs |
| Concurrency | Goroutines | Tokio and async ecosystems |
async/await, TPL and runtime integration |
| Compilation | Extremely fast | Generally slower | Moderate and practical |
| Binary footprint | Usually very small | Potentially very small | Larger, but still compact with NativeAOT |
| Kubernetes | Excellent | Improving | Strong, especially with Aspire |
| Observability | Usually configured manually | Usually configured manually | Strong OpenTelemetry integration |
| ORM and migrations | Multiple external options | Several emerging options | EF Core and Code First |
| Dependency injection | Usually external or manual | Usually manual | Native framework integration |
| API development | Lightweight frameworks | Strong modern frameworks | ASP.NET Core and source generation |
| AI integration | Community-driven | Emerging native ecosystem | ONNX Runtime, Semantic Kernel, agent frameworks and TensorSharp |
| Lifecycle coverage | Strongest near deployment | Strongest near system control | Broad coverage from application design to operation |
The article summarizes the trade-off this way:
- Go helps teams get cloud services running quickly.
- Rust gives maximum control over system behavior.
- C# aims to manage the entire journey from requirements and domain models to inference, deployment, observability and long-term evolution.
4. NativeAOT, deployment and performance
The article provides several additional benchmarks to support the broader C# infrastructure argument.
These numbers should be treated as the article’s reported comparisons rather than universal results for every workload.
Cold-start comparison
| Language | Reported AWS Lambda cold start, 1,024 MB |
|---|---|
| Python | 325 ms |
| Go | 45 ms |
| Rust | 30 ms |
| C# NativeAOT | 35 ms |
Deployment size
| Deployment | Reported image size |
|---|---|
| Python AI inference stack | 1,200 MB |
| Minimal Go service | 15 MB |
| C# NativeAOT service | 45 MB |
The article argues that Go’s smaller binary is impressive, while the C# deployment includes a much broader application stack, potentially including dependency injection, observability and production-service infrastructure.
ONNX Runtime and DeepSeek R1
The article also cites the following throughput figures on an RTX 4090:
| Model | PyTorch | ONNX Runtime through C# | Reported advantage |
|---|---|---|---|
| DeepSeek 1.5B Int4 | 49.7 tok/s | 313.3 tok/s | 6.3× |
| DeepSeek 7B Int4 | 43.5 tok/s | 161.0 tok/s | 3.7× |
Reported concurrent-request comparison
| Concurrent users | Python RPS | C# RPS |
|---|---|---|
| 100 | 3,200 | 9,500 |
| 500 | 4,200 | 42,000 |
| 1,000 | 4,500 | 78,000 |
For 1,000 concurrent users, the article reports approximately:
- Python memory usage: 25,000 MB
- C# memory usage: 1,600 MB
General JSON processing
For a one-gigabyte JSON-processing workload on AWS Lambda, it lists:
| Language | Reported processing time |
|---|---|
| Python | 12,000 ms |
| Go | 3,200 ms |
| Rust | 2,050 ms |
| C# NativeAOT | 2,050 ms |
Again, these results are workload-specific. The intended point is that modern C# should not automatically be treated as a slow enterprise runtime.
5. Compile-time feedback as an infrastructure advantage
The Bun discussion returns here.
Dynamic languages frequently discover certain classes of errors only when a code path is executed:
- Type mismatches
- Missing fields
- Invalid configuration combinations
- Unexpected null values
- Incorrectly shaped API payloads
C# cannot eliminate every runtime failure, but it can move many problems earlier through:
- Static typing
- Nullable reference types
- Generic constraints
- Roslyn analyzers
- Source-generated serialization
- Strongly typed configuration
- Compile-time API contracts
This matters because production infrastructure becomes expensive when errors appear only after deployment.
Go also catches many type errors at compile time, but the article emphasizes that C# combines these checks with a richer application framework and lifecycle model.
6. Microsoft’s agent ecosystem and C# as a first-class language
The article presents C# as a recurring first-class language across Microsoft’s AI and agent stack.
Its timeline includes:
- 2023: Semantic Kernel introduced, with C# as an initial primary implementation
- 2024: Semantic Kernel agent capabilities continued to mature
- May 2025: Azure AI Foundry reached general availability
- October 2025: Microsoft Agent Framework entered public preview, combining ideas from AutoGen and Semantic Kernel
- Q1 2026: The article lists Microsoft Agent Framework 1.0 as production-ready
- Q2 2026: It lists the Process Framework as generally available for deterministic workflows
It also states that more than 10,000 organizations use Azure AI Foundry Agent Service, citing examples such as KPMG, BMW and Fujitsu.
The larger point is that C# developers are not accessing the Microsoft AI ecosystem through an afterthought or secondary binding. They are participating through one of the stack’s primary languages.
7. Token economics and hidden infrastructure costs
The article defines total inference cost as more than model computation:
A system that generates tokens quickly may still be expensive if it requires:
- Large images
- Slow cold starts
- Multiple worker processes
- Excessive memory
- Complex deployment configuration
- Manual observability
- Frequent production debugging
Cost comparison presented by the article
| Cost area | Python | Go | C# |
|---|---|---|---|
| Container image | About 1.2 GB | About 15 MB | About 45 MB |
| Cold start | 3–10 seconds in larger stacks | Under 100 ms | Under 100 ms |
| Concurrency | Often uses multiple processes around the GIL | Goroutines | Async runtime and thread pool |
| Runtime errors | Frequently discovered in production | Explicit error handling | More opportunities for compile-time detection |
| Observability | Often assembled from third-party components | Usually configured manually | OpenTelemetry and Aspire integration |
| Kubernetes deployment | Commonly hand-maintained YAML | Commonly hand-maintained YAML | Aspire can generate deployment resources |
The article argues that TensorSharp changes the image-generation cost model by placing inference inside a smaller and more manageable C# service stack.
It specifically contrasts:
- A large Python environment with longer cold starts and less predictable memory behavior
- A compact C# service with managed lifecycle handling
- Reusable DiT construction and graph-capture behavior
- Integrated deployment and operational tooling
This is presented as the economic foundation for a proposed component called TokenHub, which would track and manage the cost of AI operations.
8. OpenClaw.NET as a C# AI-native infrastructure layer
The article proposes a layered architecture rather than rewriting every AI algorithm in C#.
Python algorithm layer
- PyTorch training
- Jupyter experimentation
- Existing research ecosystem
↓
MCP protocol boundary
- Cross-language service interface
↓
C# AI-native infrastructure layer
- TensorSharp for image and text inference
- MetaSkill DAG for workflow orchestration
- Harness runtime for execution
- TokenHub for cost tracking
- AxonHub for data collection and CDC
- Semantic Kernel for LLM orchestration
- Microsoft Agent Framework for agent lifecycle
- ONNX Runtime C# APIs for general inference
↓
.NET runtime
- NativeAOT
- Managed memory
- Low-level performance APIs
↓
Lifecycle-management layer
- .NET Aspire
- OpenTelemetry
- EF Core
The architecture follows three principles.
Keep Python where Python is strongest
The proposal does not attempt to rewrite PyTorch training, research notebooks or every scientific package.
Instead, Python capabilities can be exposed as services across an MCP boundary.
Use native C# for production infrastructure
The C# layer handles orchestration, persistence, observability, deployment, lifecycle management and selected inference engines.
Treat C# as an engine language, not only as glue
TensorSharp is used as the primary example of C# implementing a performance-critical engine rather than merely calling a separate C++ executable.
9. From Builder to AI Agent Leader to Taste
The second half of the article moves beyond language selection.
It asks what happens when AI and modern frameworks make engine construction accessible to many more developers.
The proposed progression is:
Builder → AI Agent Leader → Taste
Builder: implementation becomes widely accessible
Historically, building an inference engine required knowledge of:
- CUDA kernels
- Tensor layouts
- Quantization
- Graph execution
- Device synchronization
- Diffusion-transformer internals
- Native memory management
The article argues that projects such as TensorSharp, combined with Aspire, Semantic Kernel and Microsoft Agent Framework, reduce the amount of specialized knowledge required to turn an idea into a working AI service.
The important shift is not that engineering disappears.
It is that writing code becomes a means rather than the defining identity of the role.
AI Agent Leader: humans move from execution to coordination
As AI generates more implementation code, humans increasingly focus on:
- Defining the actual problem
- Selecting the right tools and models
- Designing the collaboration process between agents
- Establishing budgets and operational limits
- Evaluating whether outputs match the original intent
For example, an AI marketing-image system might use:
- TensorSharp for image generation
- Semantic Kernel for prompt refinement
- TokenHub for cost tracking
- A MetaSkill DAG for workflow coordination
- A quality-evaluation agent for output scoring
The human role is not merely to fix generated code.
The human decides whether the system solves the correct business problem, follows the intended brand style and remains within acceptable cost and risk boundaries.
Taste: the final human moat
The article defines Taste as more than personal preference.
Taste is structured judgment about quality, value and boundaries.
Technical Taste
When an AI system can propose many architectures, human judgment selects the design that balances:
- Clarity
- Performance
- Memory use
- Complexity
- Maintainability
- Ability to evolve
The article uses TensorSharp PR #81 as an example: decisions about DiT reconstruction and CUDA Graph Capture are not simply binary matters of right and wrong. They involve trade-offs among speed, memory and complexity.
Product Taste
When AI can generate unlimited features, someone still has to decide:
- Whether the user problem is real
- Whether the proposed solution is simple enough
- Whether a feature justifies the team’s attention
- Which metrics matter
- How much complexity the product should absorb
Ethical Taste
When AI can generate almost any content or action, humans must define boundaries around:
- Deepfakes
- Privacy
- Copyright
- Explainability
- Auditability
- Social consequences
- User autonomy
The article’s position is that automation can free humans from repetitive execution, but it cannot eliminate the need to decide what should exist.
10. Design proposal: moving from passive auditing to active Taste gates
This is one of the article’s most important disclaimers:
The Taste-gate system described below is a design proposal. It has not yet been implemented in the OpenClaw.NET repository.
According to the article, OpenClaw.NET already contains passive or safety-oriented governance capabilities such as:
- Harness Contracts
- Evidence Bundles
- A Governance Ledger
- Plan-Execute-Verify mode
-
user_inputpause points
These mechanisms can expose plans, evidence, risks and approval records for inspection.
However, most of them do not actively stop an agent workflow based on product quality, aesthetics or broader value judgments.
Proposed active Taste layer
The article proposes adding concepts such as:
- An active
TasteGate - A generic
ITasteGate<TInput, TOutput>interface - A
TasteDecisionresult - Domain-specific constraints such as
BrandTaste,EthicalTasteandTechnicalTaste
The gate would produce one of three outcomes:
- Pass: continue to the next stage
- Retry: return to an earlier agent for improvement
- Abort: stop the workflow and request human intervention
This is more useful than a simple approve/reject model because many AI outputs are not fundamentally invalid; they merely need another iteration.
11. Three-layer Taste architecture
Layer 1: constraint definition
The Agent Leader translates business intent into explicit constraints.
Possible outputs include:
- Domain models
- Brand rules
- Approved color palettes
- Cost ceilings
- Privacy requirements
- Ethical restrictions
- Copyright rules
- Quality thresholds
Layer 2: agent execution
The AI system performs the work through an orchestrated workflow:
- Prompt-refinement agent
- Image-generation agent
- Quality-scoring agent
- Cost-accounting agent
- Workflow runtime
- Failure recovery
Layer 3: Taste validation
Key outputs are evaluated against:
- Technical quality
- Product value
- Brand consistency
- Economic constraints
- Ethical boundaries
The final result is Pass, Retry or Abort.
12. Example: an AI marketing-image workflow
The article presents a conceptual workflow like this:
Natural-language user request
↓
Brand-Taste constraints
- Technology-oriented blue palette
- Minimalist visual language
- No human figures
↓
Cost constraint
- No more than $0.50 per generation
↓
Agent workflow
- Prompt optimization through Semantic Kernel
- Image generation through TensorSharp and CUDA
- CLIP or aesthetic-quality evaluation
- TokenHub cost calculation
↓
Taste gate
- Technical review
- Product and brand review
- Ethical and copyright review
↓
Pass → return the image and cost report
Retry → revise the prompt and regenerate, up to a fixed limit
Abort → record the failure, raise an alert and request human review
The proposal suggests placing gates according to two factors:
- Potential impact
- Degree of uncertainty
Low-impact, low-uncertainty decisions can remain autonomous.
High-impact, high-uncertainty decisions should require direct human involvement.
13. Encoding Taste into the type system
The article proposes expressing some constraints as C# types rather than keeping everything in prompts or informal documentation.
A conceptual BrandTaste record could contain fields such as:
- Allowed colors
- Whether human faces are permitted
- Maximum cost per image
- Ethical constraints
- Style guidelines
- Minimum quality scores
A generic Taste-gate interface could require both its input and output to implement an auditable contract.
This would not make aesthetic judgment fully compile-time enforceable. A compiler cannot objectively determine whether an image is beautiful.
However, the type system can enforce that:
- Required audit data is present
- Cost information exists
- Applicable constraints are supplied
- Every workflow stage returns an auditable output
- Validation decisions use a known set of outcomes
The article describes this philosophy as “Taste as types.”
The goal is to move as much governance as possible away from undocumented runtime behavior and into explicit, inspectable contracts.
14. The Agent Leader capability model
The article presents the following illustrative comparison:
| Capability | Current AI agent | Human Agent Leader | Expected relationship |
|---|---|---|---|
| Technical execution | 9/10 | 7/10 | AI executes; human decides |
| Product insight | 7/10 | 9/10 | AI assists; human leads |
| Ethical sensitivity | 4/10 | 9/10 | AI assists; human leads |
| Systems thinking | 8/10 | 9/10 | AI assists; human leads |
| Aesthetic intuition | 3/10 | 9/10 | AI assists; human leads |
| Risk awareness | 6/10 | 9/10 | AI assists; human leads |
| Ability to anticipate evolution | 5/10 | 8/10 | AI assists; human leads |
These numbers are conceptual rather than scientific measurements.
They express the article’s belief that AI may exceed humans at implementation while remaining weaker at value judgments that depend on culture, responsibility, long-term context and lived experience.
15. Career progression in an agent-driven engineering world
The proposed progression is:
| Level | Role | Primary capability | Typical tools | Main output |
|---|---|---|---|---|
| Level 1 | Builder | Coding, debugging and optimization | IDE, Git and CI/CD | Features |
| Level 2 | Agent Operator | Prompting and agent configuration | Semantic Kernel and AutoGen | Agent efficiency |
| Level 3 | Agent Leader | Problem definition, tool selection, orchestration and review | MetaSkill DAG, Harness and TokenHub | System-level value |
| Level 4 | Taste Architect | Domain modeling, values, ethics and evolutionary direction | DDD, ontologies and typed Taste constraints | Organizational judgment |
The transition is described as:
- From writing code to defining problems
- From debugging individual failures to reviewing system judgment
- From optimizing isolated performance to evaluating total value
- From producing features to shaping the organization’s standards
16. Practical language-selection guide
The article concludes with a simple division of responsibilities.
Choose Python for:
- Algorithm research
- PyTorch training
- Jupyter experiments
- Paper reproduction
- Rapid prototyping
Choose Go for:
- Kubernetes operators
- Small cloud services
- Gateways
- Monitoring and logging components
- High-concurrency infrastructure services
Choose Rust for:
- Browser engines
- Operating-system components
- Safety-critical software
- Low-level runtimes
- Precise, zero-cost memory control
Choose C++ for:
- Existing native engines
- Hardware drivers
- Legacy high-performance libraries
- Extremely specialized optimization
Consider C# for:
- Production inference services
- Agent orchestration
- API and domain layers
- Token and cost management
- Image and text generation
- Observability
- Database-backed AI applications
- Integrated deployment
- Native inference through projects such as TensorSharp
Conclusion
Bun chose Rust because a JavaScript runtime requires strict memory control and deep native interoperability.
Go remains an excellent language for cloud-native infrastructure.
Python remains indispensable for AI research and training.
The article’s argument is that C# is increasingly occupying another high-value layer: the productionization, servicing, orchestration and operation of AI systems.
TensorSharp is presented as evidence that C# can also move downward into the inference-engine layer without giving up the broader lifecycle capabilities of .NET.
But the most important argument is ultimately not about language performance.
As implementation becomes easier, the human role changes:
- Builders turn ideas into systems.
- Agent Leaders define and coordinate the work.
- Taste determines which systems deserve to be built and what boundaries they must respect.
The future is therefore not simply about replacing Python, Go, Rust or C++ with C#.
It is about using each language where it provides the most leverage—and using C# to build an integrated AI infrastructure layer that allows people to spend less time assembling operational plumbing and more time exercising judgment.
The long-term human advantage is not merely the ability to build. It is the ability to decide what is worth building.
Original Chinese article:
https://www.cnblogs.com/shanyou/p/21309486
TL;DR
Bun’s migration from Zig to Rust demonstrates a broader infrastructure trend: as software moves from experimentation into production, compiler-enforced correctness becomes more valuable than conventions that depend on developers always being careful.
The same transition may now be happening in AI infrastructure.
Python remains excellent for research, training and rapid prototyping. However, production AI systems also need lifecycle management, API contracts, observability, dependency injection, database integration, deployment tooling, concurrency and predictable resource usage.
The article argues that C# is unusually well positioned for this layer.
Its central piece of evidence is TensorSharp, a native C# inference engine whose reported Qwen Image Edit 2511 benchmark results outperform stable-diffusion.cpp in several pipeline stages.
The broader thesis is not simply that C# can run AI workloads. It is that C# can combine near-C++ inference performance with the application and infrastructure capabilities of the .NET ecosystem.
The article then extends this technical argument into a philosophical one:
Builder → AI Agent Leader → Taste
As AI makes implementation increasingly accessible, human value shifts from writing every line of code toward defining problems, coordinating agents, evaluating results and deciding what is worth building.
1. The lesson from Bun: infrastructure benefits from compiled languages
At the end of 2025, the Bun team described migrating approximately 535,000 lines of Zig code to Rust using 64 Claude instances over an 11-day period.
Bun is a JavaScript runtime, which creates an inherently difficult boundary:
- JavaScript relies on garbage collection.
- Runtime internals often require manual memory control.
- Re-entrant callbacks can invalidate assumptions about object lifetimes.
- Bugs may emerge only under unusual concurrency or callback sequences.
The article highlights examples such as use-after-free failures, invalidated hash maps, out-of-bounds writes and reference-counting problems.
These were not presented as isolated coding mistakes. They were symptoms of a structural problem: when garbage-collected code and manually managed memory interact, lifecycle correctness may depend heavily on conventions, testing, fuzzing and developer discipline.
Rust changes the feedback loop.
Instead of discovering a lifetime problem after a crash, the compiler can reject an invalid ownership relationship before the program runs. In that model, rules that would otherwise live in a style guide become enforceable properties of the type system.
The equivalent problem in AI infrastructure
The article argues that production AI systems are encountering a similar transition.
| Runtime-infrastructure problem | Comparable AI-infrastructure problem |
|---|---|
| Manual memory combined with JavaScript GC | Python’s dynamic runtime, GIL and native-library boundaries |
| Large codebases that depend on conventions | Growing collections of difficult-to-maintain AI “glue code” |
| Memory and concurrency failures discovered at runtime | Production crashes, leaks and concurrency bottlenecks |
| Rapid AI-assisted rewrites | Increasing maintenance costs as infrastructure expands |
The conclusion is not that Python should disappear. Python remains highly valuable for algorithms, research and training.
The claim is narrower: AI inference services are becoming production infrastructure rather than laboratory scripts, and the infrastructure layer increasingly benefits from compiled languages and stronger contracts.
2. TensorSharp as evidence for native C# inference
Before arguing that C# is a good infrastructure language, the article asks a more fundamental question:
Can C# compete with C++ at the inference-engine level?
Its answer is based on reported results from TensorSharp, a deep-learning inference engine implemented in C#.
The benchmark compared its Qwen Image Edit 2511 pipeline with stable-diffusion.cpp.
Test configuration
- CUDA
- Resolution:
544 × 1184 - Four inference steps
- Q2_K DiT
- Lightning four-step LoRA
- Identical input image
- Identical prompt
- Identical CFG
- Identical seed
Reported benchmark
| Metric | TensorSharp, C# | stable-diffusion.cpp, C++ | Reported C# advantage |
|---|---|---|---|
| Warm total time | 40.44 seconds | 48.16 seconds | 1.19× faster |
| Time per step | 7.57 seconds | 9.43 seconds | 1.25× faster |
| Sampling | 30.27 seconds | 37.73 seconds | 1.25× faster |
| VAE encoding | 0.54 seconds | 1.92 seconds | 3.56× faster |
| VAE decoding | 1.51 seconds | 2.57 seconds | 1.70× faster |
The data is attributed to TensorSharp PR #81 and its author, Zhongkai Fu.
Why the result matters
The article’s argument is not merely that one C# implementation won one benchmark.
Its more important claim is that C# can reach C++-class inference performance while remaining integrated with a managed production stack.
A C++ inference engine may provide excellent low-level performance, but a complete production system still needs capabilities such as:
- Type-safe API contracts
- Dependency injection
- Model-lifecycle management
- Background and hosted services
- Database persistence
- Distributed tracing
- Structured configuration
- Compile-time analyzers
- Container and Kubernetes deployment
- Application-level authentication and authorization
With C#, these capabilities can exist in the same runtime and programming model as the inference engine.
This is why the article describes TensorSharp not as “C# glue around a native engine,” but as evidence that C# can be used to build the engine itself.
3. C# versus Rust and Go for AI infrastructure
The article does not argue that C# is universally superior.
Different languages occupy different optimization points.
Rust
Rust is a strong choice when the system requires:
- Precise ownership
- Zero-cost memory abstractions
- Safety without garbage collection
- Browser-engine or operating-system-level control
- Deep interoperability with native components
Bun’s choice of Rust therefore makes sense.
Go
Go is exceptionally strong for:
- Kubernetes-native services
- Small binaries
- Fast compilation
- Simple concurrency
- Gateways, operators and control-plane services
- Straightforward cloud deployment
The article characterizes Go as the native language of cloud infrastructure.
C
C# occupies a different position. It combines managed memory and high-level application development with increasingly capable low-level primitives:
Span<T>Memory<T>ref struct- Hardware intrinsics
- NativeAOT
- Source generators
-
unsafecode where necessary - Asynchronous programming and the Task Parallel Library
Its central advantage is described as full-lifecycle coverage.
C# can be used for:
- Domain modeling
- API development
- Compile-time validation
- Database access and migrations
- Distributed tracing
- Background processing
- Agent orchestration
- Deployment composition
- Inference-engine implementation
Simplified comparison
| Area | Go | Rust | C# |
|---|---|---|---|
| Memory model | Simple GC | Ownership and borrow checking | GC plus low-level memory APIs |
| Concurrency | Goroutines | Tokio and async ecosystems |
async/await, TPL and runtime integration |
| Compilation | Extremely fast | Generally slower | Moderate and practical |
| Binary footprint | Usually very small | Potentially very small | Larger, but still compact with NativeAOT |
| Kubernetes | Excellent | Improving | Strong, especially with Aspire |
| Observability | Usually configured manually | Usually configured manually | Strong OpenTelemetry integration |
| ORM and migrations | Multiple external options | Several emerging options | EF Core and Code First |
| Dependency injection | Usually external or manual | Usually manual | Native framework integration |
| API development | Lightweight frameworks | Strong modern frameworks | ASP.NET Core and source generation |
| AI integration | Community-driven | Emerging native ecosystem | ONNX Runtime, Semantic Kernel, agent frameworks and TensorSharp |
| Lifecycle coverage | Strongest near deployment | Strongest near system control | Broad coverage from application design to operation |
The article summarizes the trade-off this way:
- Go helps teams get cloud services running quickly.
- Rust gives maximum control over system behavior.
- C# aims to manage the entire journey from requirements and domain models to inference, deployment, observability and long-term evolution.
4. NativeAOT, deployment and performance
The article provides several additional benchmarks to support the broader C# infrastructure argument.
These numbers should be treated as the article’s reported comparisons rather than universal results for every workload.
Cold-start comparison
| Language | Reported AWS Lambda cold start, 1,024 MB |
|---|---|
| Python | 325 ms |
| Go | 45 ms |
| Rust | 30 ms |
| C# NativeAOT | 35 ms |
Deployment size
| Deployment | Reported image size |
|---|---|
| Python AI inference stack | 1,200 MB |
| Minimal Go service | 15 MB |
| C# NativeAOT service | 45 MB |
The article argues that Go’s smaller binary is impressive, while the C# deployment includes a much broader application stack, potentially including dependency injection, observability and production-service infrastructure.
ONNX Runtime and DeepSeek R1
The article also cites the following throughput figures on an RTX 4090:
| Model | PyTorch | ONNX Runtime through C# | Reported advantage |
|---|---|---|---|
| DeepSeek 1.5B Int4 | 49.7 tok/s | 313.3 tok/s | 6.3× |
| DeepSeek 7B Int4 | 43.5 tok/s | 161.0 tok/s | 3.7× |
Reported concurrent-request comparison
| Concurrent users | Python RPS | C# RPS |
|---|---|---|
| 100 | 3,200 | 9,500 |
| 500 | 4,200 | 42,000 |
| 1,000 | 4,500 | 78,000 |
For 1,000 concurrent users, the article reports approximately:
- Python memory usage: 25,000 MB
- C# memory usage: 1,600 MB
General JSON processing
For a one-gigabyte JSON-processing workload on AWS Lambda, it lists:
| Language | Reported processing time |
|---|---|
| Python | 12,000 ms |
| Go | 3,200 ms |
| Rust | 2,050 ms |
| C# NativeAOT | 2,050 ms |
Again, these results are workload-specific. The intended point is that modern C# should not automatically be treated as a slow enterprise runtime.
5. Compile-time feedback as an infrastructure advantage
The Bun discussion returns here.
Dynamic languages frequently discover certain classes of errors only when a code path is executed:
- Type mismatches
- Missing fields
- Invalid configuration combinations
- Unexpected null values
- Incorrectly shaped API payloads
C# cannot eliminate every runtime failure, but it can move many problems earlier through:
- Static typing
- Nullable reference types
- Generic constraints
- Roslyn analyzers
- Source-generated serialization
- Strongly typed configuration
- Compile-time API contracts
This matters because production infrastructure becomes expensive when errors appear only after deployment.
Go also catches many type errors at compile time, but the article emphasizes that C# combines these checks with a richer application framework and lifecycle model.
6. Microsoft’s agent ecosystem and C# as a first-class language
The article presents C# as a recurring first-class language across Microsoft’s AI and agent stack.
Its timeline includes:
- 2023: Semantic Kernel introduced, with C# as an initial primary implementation
- 2024: Semantic Kernel agent capabilities continued to mature
- May 2025: Azure AI Foundry reached general availability
- October 2025: Microsoft Agent Framework entered public preview, combining ideas from AutoGen and Semantic Kernel
- Q1 2026: The article lists Microsoft Agent Framework 1.0 as production-ready
- Q2 2026: It lists the Process Framework as generally available for deterministic workflows
It also states that more than 10,000 organizations use Azure AI Foundry Agent Service, citing examples such as KPMG, BMW and Fujitsu.
The larger point is that C# developers are not accessing the Microsoft AI ecosystem through an afterthought or secondary binding. They are participating through one of the stack’s primary languages.
7. Token economics and hidden infrastructure costs
The article defines total inference cost as more than model computation:
A system that generates tokens quickly may still be expensive if it requires:
- Large images
- Slow cold starts
- Multiple worker processes
- Excessive memory
- Complex deployment configuration
- Manual observability
- Frequent production debugging
Cost comparison presented by the article
| Cost area | Python | Go | C# |
|---|---|---|---|
| Container image | About 1.2 GB | About 15 MB | About 45 MB |
| Cold start | 3–10 seconds in larger stacks | Under 100 ms | Under 100 ms |
| Concurrency | Often uses multiple processes around the GIL | Goroutines | Async runtime and thread pool |
| Runtime errors | Frequently discovered in production | Explicit error handling | More opportunities for compile-time detection |
| Observability | Often assembled from third-party components | Usually configured manually | OpenTelemetry and Aspire integration |
| Kubernetes deployment | Commonly hand-maintained YAML | Commonly hand-maintained YAML | Aspire can generate deployment resources |
The article argues that TensorSharp changes the image-generation cost model by placing inference inside a smaller and more manageable C# service stack.
It specifically contrasts:
- A large Python environment with longer cold starts and less predictable memory behavior
- A compact C# service with managed lifecycle handling
- Reusable DiT construction and graph-capture behavior
- Integrated deployment and operational tooling
This is presented as the economic foundation for a proposed component called TokenHub, which would track and manage the cost of AI operations.
8. OpenClaw.NET as a C# AI-native infrastructure layer
The article proposes a layered architecture rather than rewriting every AI algorithm in C#.
Python algorithm layer
- PyTorch training
- Jupyter experimentation
- Existing research ecosystem
↓
MCP protocol boundary
- Cross-language service interface
↓
C# AI-native infrastructure layer
- TensorSharp for image and text inference
- MetaSkill DAG for workflow orchestration
- Harness runtime for execution
- TokenHub for cost tracking
- AxonHub for data collection and CDC
- Semantic Kernel for LLM orchestration
- Microsoft Agent Framework for agent lifecycle
- ONNX Runtime C# APIs for general inference
↓
.NET runtime
- NativeAOT
- Managed memory
- Low-level performance APIs
↓
Lifecycle-management layer
- .NET Aspire
- OpenTelemetry
- EF Core
The architecture follows three principles.
Keep Python where Python is strongest
The proposal does not attempt to rewrite PyTorch training, research notebooks or every scientific package.
Instead, Python capabilities can be exposed as services across an MCP boundary.
Use native C# for production infrastructure
The C# layer handles orchestration, persistence, observability, deployment, lifecycle management and selected inference engines.
Treat C# as an engine language, not only as glue
TensorSharp is used as the primary example of C# implementing a performance-critical engine rather than merely calling a separate C++ executable.
9. From Builder to AI Agent Leader to Taste
The second half of the article moves beyond language selection.
It asks what happens when AI and modern frameworks make engine construction accessible to many more developers.
The proposed progression is:
Builder → AI Agent Leader → Taste
Builder: implementation becomes widely accessible
Historically, building an inference engine required knowledge of:
- CUDA kernels
- Tensor layouts
- Quantization
- Graph execution
- Device synchronization
- Diffusion-transformer internals
- Native memory management
The article argues that projects such as TensorSharp, combined with Aspire, Semantic Kernel and Microsoft Agent Framework, reduce the amount of specialized knowledge required to turn an idea into a working AI service.
The important shift is not that engineering disappears.
It is that writing code becomes a means rather than the defining identity of the role.
AI Agent Leader: humans move from execution to coordination
As AI generates more implementation code, humans increasingly focus on:
- Defining the actual problem
- Selecting the right tools and models
- Designing the collaboration process between agents
- Establishing budgets and operational limits
- Evaluating whether outputs match the original intent
For example, an AI marketing-image system might use:
- TensorSharp for image generation
- Semantic Kernel for prompt refinement
- TokenHub for cost tracking
- A MetaSkill DAG for workflow coordination
- A quality-evaluation agent for output scoring
The human role is not merely to fix generated code.
The human decides whether the system solves the correct business problem, follows the intended brand style and remains within acceptable cost and risk boundaries.
Taste: the final human moat
The article defines Taste as more than personal preference.
Taste is structured judgment about quality, value and boundaries.
Technical Taste
When an AI system can propose many architectures, human judgment selects the design that balances:
- Clarity
- Performance
- Memory use
- Complexity
- Maintainability
- Ability to evolve
The article uses TensorSharp PR #81 as an example: decisions about DiT reconstruction and CUDA Graph Capture are not simply binary matters of right and wrong. They involve trade-offs among speed, memory and complexity.
Product Taste
When AI can generate unlimited features, someone still has to decide:
- Whether the user problem is real
- Whether the proposed solution is simple enough
- Whether a feature justifies the team’s attention
- Which metrics matter
- How much complexity the product should absorb
Ethical Taste
When AI can generate almost any content or action, humans must define boundaries around:
- Deepfakes
- Privacy
- Copyright
- Explainability
- Auditability
- Social consequences
- User autonomy
The article’s position is that automation can free humans from repetitive execution, but it cannot eliminate the need to decide what should exist.
10. Design proposal: moving from passive auditing to active Taste gates
This is one of the article’s most important disclaimers:
The Taste-gate system described below is a design proposal. It has not yet been implemented in the OpenClaw.NET repository.
According to the article, OpenClaw.NET already contains passive or safety-oriented governance capabilities such as:
- Harness Contracts
- Evidence Bundles
- A Governance Ledger
- Plan-Execute-Verify mode
-
user_inputpause points
These mechanisms can expose plans, evidence, risks and approval records for inspection.
However, most of them do not actively stop an agent workflow based on product quality, aesthetics or broader value judgments.
Proposed active Taste layer
The article proposes adding concepts such as:
- An active
TasteGate - A generic
ITasteGate<TInput, TOutput>interface - A
TasteDecisionresult - Domain-specific constraints such as
BrandTaste,EthicalTasteandTechnicalTaste
The gate would produce one of three outcomes:
- Pass: continue to the next stage
- Retry: return to an earlier agent for improvement
- Abort: stop the workflow and request human intervention
This is more useful than a simple approve/reject model because many AI outputs are not fundamentally invalid; they merely need another iteration.
11. Three-layer Taste architecture
Layer 1: constraint definition
The Agent Leader translates business intent into explicit constraints.
Possible outputs include:
- Domain models
- Brand rules
- Approved color palettes
- Cost ceilings
- Privacy requirements
- Ethical restrictions
- Copyright rules
- Quality thresholds
Layer 2: agent execution
The AI system performs the work through an orchestrated workflow:
- Prompt-refinement agent
- Image-generation agent
- Quality-scoring agent
- Cost-accounting agent
- Workflow runtime
- Failure recovery
Layer 3: Taste validation
Key outputs are evaluated against:
- Technical quality
- Product value
- Brand consistency
- Economic constraints
- Ethical boundaries
The final result is Pass, Retry or Abort.
12. Example: an AI marketing-image workflow
The article presents a conceptual workflow like this:
Natural-language user request
↓
Brand-Taste constraints
- Technology-oriented blue palette
- Minimalist visual language
- No human figures
↓
Cost constraint
- No more than $0.50 per generation
↓
Agent workflow
- Prompt optimization through Semantic Kernel
- Image generation through TensorSharp and CUDA
- CLIP or aesthetic-quality evaluation
- TokenHub cost calculation
↓
Taste gate
- Technical review
- Product and brand review
- Ethical and copyright review
↓
Pass → return the image and cost report
Retry → revise the prompt and regenerate, up to a fixed limit
Abort → record the failure, raise an alert and request human review
The proposal suggests placing gates according to two factors:
- Potential impact
- Degree of uncertainty
Low-impact, low-uncertainty decisions can remain autonomous.
High-impact, high-uncertainty decisions should require direct human involvement.
13. Encoding Taste into the type system
The article proposes expressing some constraints as C# types rather than keeping everything in prompts or informal documentation.
A conceptual BrandTaste record could contain fields such as:
- Allowed colors
- Whether human faces are permitted
- Maximum cost per image
- Ethical constraints
- Style guidelines
- Minimum quality scores
A generic Taste-gate interface could require both its input and output to implement an auditable contract.
This would not make aesthetic judgment fully compile-time enforceable. A compiler cannot objectively determine whether an image is beautiful.
However, the type system can enforce that:
- Required audit data is present
- Cost information exists
- Applicable constraints are supplied
- Every workflow stage returns an auditable output
- Validation decisions use a known set of outcomes
The article describes this philosophy as “Taste as types.”
The goal is to move as much governance as possible away from undocumented runtime behavior and into explicit, inspectable contracts.
14. The Agent Leader capability model
The article presents the following illustrative comparison:
| Capability | Current AI agent | Human Agent Leader | Expected relationship |
|---|---|---|---|
| Technical execution | 9/10 | 7/10 | AI executes; human decides |
| Product insight | 7/10 | 9/10 | AI assists; human leads |
| Ethical sensitivity | 4/10 | 9/10 | AI assists; human leads |
| Systems thinking | 8/10 | 9/10 | AI assists; human leads |
| Aesthetic intuition | 3/10 | 9/10 | AI assists; human leads |
| Risk awareness | 6/10 | 9/10 | AI assists; human leads |
| Ability to anticipate evolution | 5/10 | 8/10 | AI assists; human leads |
These numbers are conceptual rather than scientific measurements.
They express the article’s belief that AI may exceed humans at implementation while remaining weaker at value judgments that depend on culture, responsibility, long-term context and lived experience.
15. Career progression in an agent-driven engineering world
The proposed progression is:
| Level | Role | Primary capability | Typical tools | Main output |
|---|---|---|---|---|
| Level 1 | Builder | Coding, debugging and optimization | IDE, Git and CI/CD | Features |
| Level 2 | Agent Operator | Prompting and agent configuration | Semantic Kernel and AutoGen | Agent efficiency |
| Level 3 | Agent Leader | Problem definition, tool selection, orchestration and review | MetaSkill DAG, Harness and TokenHub | System-level value |
| Level 4 | Taste Architect | Domain modeling, values, ethics and evolutionary direction | DDD, ontologies and typed Taste constraints | Organizational judgment |
The transition is described as:
- From writing code to defining problems
- From debugging individual failures to reviewing system judgment
- From optimizing isolated performance to evaluating total value
- From producing features to shaping the organization’s standards
16. Practical language-selection guide
The article concludes with a simple division of responsibilities.
Choose Python for:
- Algorithm research
- PyTorch training
- Jupyter experiments
- Paper reproduction
- Rapid prototyping
Choose Go for:
- Kubernetes operators
- Small cloud services
- Gateways
- Monitoring and logging components
- High-concurrency infrastructure services
Choose Rust for:
- Browser engines
- Operating-system components
- Safety-critical software
- Low-level runtimes
- Precise, zero-cost memory control
Choose C++ for:
- Existing native engines
- Hardware drivers
- Legacy high-performance libraries
- Extremely specialized optimization
Consider C# for:
- Production inference services
- Agent orchestration
- API and domain layers
- Token and cost management
- Image and text generation
- Observability
- Database-backed AI applications
- Integrated deployment
- Native inference through projects such as TensorSharp
Conclusion
Bun chose Rust because a JavaScript runtime requires strict memory control and deep native interoperability.
Go remains an excellent language for cloud-native infrastructure.
Python remains indispensable for AI research and training.
The article’s argument is that C# is increasingly occupying another high-value layer: the productionization, servicing, orchestration and operation of AI systems.
TensorSharp is presented as evidence that C# can also move downward into the inference-engine layer without giving up the broader lifecycle capabilities of .NET.
But the most important argument is ultimately not about language performance.
As implementation becomes easier, the human role changes:
- Builders turn ideas into systems.
- Agent Leaders define and coordinate the work.
- Taste determines which systems deserve to be built and what boundaries they must respect.
The future is therefore not simply about replacing Python, Go, Rust or C++ with C#.
It is about using each language where it provides the most leverage—and using C# to build an integrated AI infrastructure layer that allows people to spend less time assembling operational plumbing and more time exercising judgment.
The long-term human advantage is not merely the ability to build. It is the ability to decide what is worth building.
Top comments (0)