Showing posts with label software development. Show all posts
Showing posts with label software development. Show all posts

Friday

Why does AI still mimic the human “write code → compile → run”

 

                                                        generated by gemini ai


I observed that what AI Coding tools do is only mimic a human programmer. Same way: write code • convert to machine language • execute on a computer.

And it cuts to the heart of a real limitation in most current AI coding agents.


My question is simple:

Why does AI still mimic the human “write code → compile → run” cycle instead of directly translating human intent into computer actions?


Let me break down why this happens, and where real intelligence might eventually break the pattern.

---

1. Current AI coding agents are pattern-matching machines, not understanding machines


Large language models (LLMs) are trained on human-generated data — including billions of lines of code, documentation, and discussions.  

What they learn is statistical regularities in how humans solve problems in code.  

They don’t “understand” computers at a lower level; they just predict the next token in a sequence that looks like a solution.


So naturally, they reproduce the human workflow:  

- Define a function  

- Write loops, conditionals  

- Output source code in Python, Rust, etc.


It’s not because that’s the only way — it’s because that’s what the training data shows.

---

2. Why not skip code and execute directly from natural language?


Instead, I propose something like:  

> Human says: “Copy file X to folder Y and rename it to Z.”  

> AI listens, understands, and directly commands the OS/file system without generating a script.


This is technically possible today — and some systems do it (e.g., voice assistants turning on lights, or GPT with function calling).  

But for general computation, skipping code is extremely hard because:


- Ambiguity – Human language is imprecise. “Backup my important files” — which files? where? versioning? error handling? Code forces you to be explicit.

- Safety – Direct execution of natural language commands can delete, corrupt, or leak data. Code acts as a reviewable, testable intermediate representation.

- Composability – Code can be reused, versioned, debugged, and combined. Direct execution from intent has no intermediate artifact to inspect.

- Tooling – Operating systems, databases, networks expect deterministic instructions (syscalls, API calls), not probabilistic interpretations.


So current AI doesn’t skip code because code is the safest, most precise, and most debuggable bridge from fuzzy human intent to deterministic machine action.

---

3. Is there real intelligence here, or just speed/accuracy?


Maybe I am right: most AI coding agents just replicate the human process faster, with fewer typos, and sometimes better recall of library syntax.  

That’s competence, not intelligence.


True intelligence in this context would mean:  

- Understanding the goal behind the request, not just the literal instruction.  

- Choosing a completely different computational model if it’s more efficient (e.g., not writing a loop but telling the CPU to do vectorized ops directly).  

- Dynamically generating machine code or hardware configurations without human-readable source code.  

- Learning from execution feedback without retraining the whole model.


But current LLMs don’t do that because they have no persistent memory of execution results and no ability to reason about computer architecture from first principles — they only know what humans wrote about it.

---

4. What would direct execution from “ask → do” look like?


A truly intelligent system would:


1. Parse intent – Not just “write a loop,” but “I need to process 1 billion rows of sales data to find average per region.”

2. Plan execution – Choose a path: maybe use a database query, not Python; maybe use GPU or distributed cluster.

3. Generate low-level actions – Direct syscalls, memory maps, or even hardware instructions.

4. Execute and observe – See the result, adjust if wrong, learn for next time.


That’s radically different from writing a Python script.  

We don’t have that today because:

- LLMs can’t safely interact with raw system interfaces.

- They lack a real-time execution loop with memory.

- No training data exists for “direct intent-to-machine-action” at scale.

---

5. Why is the industry not building this?


Partly because the “write code” approach already works well enough for automation.  

Partly because building a safe, general intent-to-execution engine is an unsolved AI-complete problem.  

And partly because the commercial incentive is to sell “AI that helps developers” (a known market), not “AI that replaces the need for explicit programming” (a risky, unproven market).

---

Summary


So you identified a genuine lack of architectural intelligence in AI coding agents.  

They copy the human “code → compile → run” loop not because it’s optimal, but because that’s all they’ve seen.  

True intelligence would skip straight from *human ask* to *computer action*, using the most efficient path — but that requires AI to understand computation itself, not just human descriptions of it.


We’re not there yet, but systems like GPT with function calling, AutoGPT, and language-to-API tools are baby steps toward your vision.

Monday

Who are FDSE?

 

                                                                Generated by Gemini

For the last 28 years and more I have been working as Solutions Engineer / Solutions Architect (SE/SA) + Professional Services / Implementation Engineer + Customer-Facing Software Engineer together combined.

Various companies I have worked on pre-sales technical scoping & integration design resembled SE/SA work or/and FDSEs inherit full production-grade coding responsibilities and Enterprise deployment & customisation tasks.

From understanding requirements from internal domain expert like here in BNY or from pre sales team of a SaaS or AI company. Never thought about what exactly my role or position is. Responsibilities always came first.

Despite being a hard-core computer science student with vast fundamental knowledge, including microprocessor architecture, operating systems, compiler design, various types of networking, protocols, and programming in various environments and languages from mainframes to microcontrollers to IoT applications. I always solve the real problem smartly. Recent years my roles named Forward-Deployed Engineer = Solutions Engineer + Implementation Engineer + Full Software Engineer, merged into one high-ownership role.

According to multiple analyses of the FDE role's evolution, especially the history of Palantir’s “Deltas” (the original forward‑deployed engineers), the modern FDE function grew out of three older roles blended together:

1. Solutions Engineer / Solutions Architect (SE/SA)

Before the FDE concept existed, companies relied heavily on Solutions Engineers or Solutions Architects to scope problems, design integrations, and work with customers during implementation.

  • These roles handled pre‑sales technical scoping, early prototypes, integration discussions, and acted as intermediaries between clients and product teams.
  • They were customer-facing, but rarely wrote large amounts of production code.

This corresponds to the FDE’s product scoping, architecture, and integration responsibilities.

2. Professional Services / Implementation Engineer

Enterprise software companies traditionally used Professional Services Engineers or Implementation Specialists for deployment and custom setup.

  • They installed systems, configured environments, migrated data, and ensured the product worked in a messy customer infrastructure.
  • This is exactly the “embedded implementation” aspect that FDEs now own.

This implementation-heavy model is referenced as the predecessor to the FDE paradigm.

3. Traditional Software Engineer (but customer-aligned)

Palantir explicitly blended full software engineering responsibilities — designing, building, debugging, and deploying production systems — into a customer-embedded role.

  • Traditional SWE: builds “one capability for many customers.”
  • Early Palantir “Delta” / modern FDE: solves “one customer’s many problems” with real production code.

This SWE component became essential because typical Professional Services or Solutions Engineers could not write and ship production-grade code, which Palantir desperately needed for complex government and enterprise deployments.

Due to not came from pure engineering background never got the opportunity or position I deserved. However, I always love the challenges to solve other facing whether customer, client or else. Continue learning and taking on challenges to learn entirely new fields and solve real problems with ownership felt great.

Tuesday

Uber's Architectural Redesigns for Risk Management

Here are the key lessons from Uber's architectural redesigns for risk management, synthesized from their engineering blogs and public case studies.


🚦 Lesson 1: Orchestrate Risk Across Services, Not Just Within Them


The first major lesson came from addressing the "blast radius" problem. In a monorepo architecture, a single bad commit could potentially break thousands of services at once .


- The Problem: Traditional safety checks (pre-commit tests, per-service health metrics) were insufficient. If a change passed initial tests but failed in production, automated deployment pipelines could rapidly propagate the failure to hundreds of critical services before anyone noticed .

- The Solution: Uber introduced a cross-cutting service deployment orchestration layer. This system acts as a global gatekeeper, coordinating rollouts across all services affected by a single commit .

- How It Works:

    - Service Tiering: Services are classified into tiers from 0 (most critical, e.g., core ride-hailing) to 5 (least critical) .

    - Cohort-Based Rollout: A large-scale change is first deployed to a small cohort of low-tier services. The system then monitors their deployment outcomes .

    - Progressive Unblocking: Only after the lower-tier cohorts succeed does the system automatically unblock the next, more critical tier for deployment .

    - Automated Halt: If failures exceed a configured threshold in any cohort, the rollout is automatically halted, and the commit's author is notified to fix or revert the change .


- Key Lesson: Safety signals must be aggregated and acted upon globally. Relying on individual services to detect their own failures is too slow when a change can impact thousands at once. A centralized orchestration layer that understands the relationships between services and can control the rollout based on collective health is essential.


- Data-Driven Tuning for Velocity: Uber initially made their safety parameters too cautious, which slowed down deployments. To fix this, they built a simulator that used historical deployment data to predict how long a rollout would take under different configurations .

- The Goal: They targeted a maximum of 24 hours to unblock all services, balancing the need for a strong safety signal with the need for development velocity . This simulation allowed them to tune the system for a predictable and fast rollout curve, proving that safety and speed don't have to be mutually exclusive .


🤖 Lesson 2: Build a "Safety Net" for ML Models, Not Just Software


Machine learning models introduce a different kind of risk because they are probabilistic and can fail in "silent" ways that traditional software doesn't . Uber's ML platform, Michelangelo, had to evolve to handle this.


- The Problem: A model might perform well in offline tests but fail in production due to data drift, where the real-world data no longer matches the training data. This could degrade service quality or cause financial losses without an obvious system crash .

- The Solution: Uber implemented a comprehensive, end-to-end safety framework for ML models that covers the entire lifecycle .

- How It Works:

    - Pre-Production Validation: This includes shadow testing, where a candidate model runs in parallel with the production model, processing live traffic and logging its outputs for comparison without affecting real user predictions. This is now used by over 75% of critical online use cases .

    - Controlled Rollout: New models are deployed gradually, starting with a small percentage of traffic. If error rates, latency, or prediction quality metrics breach thresholds, the system auto-rolls back to the last known good version .

    - Continuous Monitoring: Uber's observability stack, Hue, continuously monitors live models for operational metrics and, crucially, for data drift (e.g., changes in input data distributions, spikes in null values) .


- Key Lesson: ML models require "data-aware" safety mechanisms. You can't just monitor for crashes; you must monitor for semantic drift and prediction quality in real-time. The goal is to catch the *moment* a model becomes "stale" or is receiving unexpected inputs, and automatically mitigate the risk.


- Safety as a Platform, Not a Burden: Uber found that for safety to work at scale, it had to be easy. They built safeguards directly into the Michelangelo platform (e.g., making shadow testing a default part of the pipeline) and created a transparent Model Safety Scoring System .

- The Scorecard: This score tracks four key indicators for each model family: offline evaluation coverage, shadow-deployment coverage, unit-test coverage, and performance-monitoring coverage. This makes a model's readiness easy to understand and improve, fostering a culture of proactive safety .


🛡️ Lesson 3: Centralize Control Planes for Foundational Risk Functions


The final lesson is about re-architecting the underlying platforms that all risk services depend on. Two key examples stand out: global rate limiting and compliance workflow management.


- Global Rate Limiting (GRL): Uber replaced service-specific rate limiters (like Redis token buckets) with a single, centralized Global Rate Limiter (GRL) .

- How It Works: The GRL uses a three-tier feedback loop (local client decision, regional aggregation, global calculation) to make intelligent, system-wide throttling decisions.

- Key Lesson: Centralizing a control plane like rate limiting improves efficiency, reduces latency, and provides stronger, more consistent protection (e.g., absorbing 15x traffic spikes or mitigating DDoS attacks) across the entire ecosystem .


- Unified Risk & Compliance Platform: Uber replaced a fragmented system of spreadsheets and manual processes for managing compliance, vendor risks, and policy exceptions with a single platform built on ServiceNow .

- The Result: This move provided real-time visibility into controls and risks for a platform serving 70+ countries, standardized over 25 processes, and was adopted by ~5,000 monthly users. It transformed risk management from a reactive, manual chore into a proactive, scalable capability .

- Key Lesson: Non-technical risk (compliance, third-party, policy) is just as critical as technical risk. Treating it with the same architectural rigor—building a unified, scalable, and observable platform—is fundamental to operating a global business.


💡 The Big Picture: From Point Solutions to Systemic Safety


Taken together, the lessons from Uber's architectural redesigns reveal a clear evolution in thinking about risk:


| Dimension of Change | From... | To... | Key Lesson |

| :--- | :--- | :--- | :--- |

| Scope of Safety | Per-service health checks  | Cross-service orchestration  | Think Globally, Act Locally: Aggregate risk signals across your entire graph of services to control the blast radius of changes. |

| Nature of Risk | Code failures and crashes  | Data drift and model staleness  | Models are Different: Monitor for semantic drift and use techniques like shadow testing to validate ML models against live, unpredictable data. |

| Control Plane | Fragmented tools and service-specific logic  | Centralized, platform-level intelligence  | Build Platforms, Not Point Solutions: Centralizing functions like rate limiting or compliance creates a strong, efficient, and observable foundation for all risk-related services. |


I hope this detailed breakdown is helpful.  

Thursday

Combining Open Source Software with Proprietary Software

 

meta ai

The philosophy of combining Open-Source Software (OSS) like Kubernetes and Docker with proprietary offerings like Azure Cosmos DB, while often pragmatic, presents several potential issues, particularly for Azure users:

1. Vendor Lock-in (especially with proprietary services like Cosmos DB):

  • Dependency on a single vendor: When you adopt a proprietary service like Cosmos DB, you become heavily dependent on Microsoft for its functionality, updates, and support. This makes it challenging and costly to switch to another database or cloud provider if your needs change, if Microsoft alters its pricing or features unfavorably, or if you simply want to leverage a different technology.
  • Proprietary APIs and data formats: Cosmos DB uses its own APIs and internal data structures, which are not directly transferable to other databases. Migrating data and refactoring application code built around these proprietary interfaces can be a massive undertaking, incurring significant time and cost.
  • Limited alternatives: While Cosmos DB offers various APIs (e.g., SQL, MongoDB, Cassandra), the underlying service is still proprietary. If you find a better open-source alternative that meets your specific performance or cost requirements, the migration path from Cosmos DB can be complex.
  • Pricing leverage: Once locked in, the vendor (Microsoft) gains leverage over pricing. While current costs might be acceptable, future price increases could significantly impact your budget without easy recourse.

2. Complexity and Integration Challenges:

  • Hybrid expertise: Managing a blend of open-source and proprietary technologies requires a broader skillset within your team. You need experts in Kubernetes and Docker, but also in Azure-specific services and their nuances.
  • Operational overhead: While managed services like Cosmos DB simplify some aspects, integrating them seamlessly with a largely open-source application stack (Kubernetes, Docker) can introduce complexities in monitoring, logging, security, and deployment pipelines.
  • Debugging and troubleshooting: When issues arise, it can be challenging to pinpoint whether the problem lies within your open-source components or the proprietary service, requiring expertise across both domains.
  • Version compatibility: Ensuring compatibility between constantly evolving open-source projects and proprietary cloud services can be a continuous challenge.

3. Cost Implications:

  • Unpredictable proprietary costs: While open-source components often reduce licensing fees, proprietary services like Cosmos DB can incur significant usage-based costs, especially at scale. These costs can be complex to predict and optimize, as seen in some user feedback on Cosmos DB's expense.
  • Migration costs: The cost of potentially migrating away from a proprietary service in the future needs to be factored in. This includes development time, data migration, and potential downtime.
  • Skilled personnel: The need for specialized skills in both open-source and proprietary technologies can lead to higher staffing costs or the need for expensive external consultants.

4. Loss of Flexibility and Customization:

  • Limited control: With proprietary services, you have less control over the underlying infrastructure, features, and customization options compared to open-source alternatives where you can inspect, modify, and contribute to the code.
  • Innovation pace: While Microsoft is constantly innovating, the pace and direction of development for proprietary services are controlled by the vendor, unlike open-source projects which can benefit from community-driven innovation.
  • Compliance and security transparency: While Microsoft invests heavily in security, the "black box" nature of proprietary code means you can't audit the source code for specific vulnerabilities or ensure compliance in the same transparent way as with open-source software.

5. Cultural and Strategic Considerations:

  • Strategic misalignment: If an organization's long-term strategy is to be truly cloud-agnostic or to leverage open-source exclusively, relying on highly proprietary services creates a misalignment that could lead to difficulties in the future.
  • Talent pool: While open-source skills are increasingly abundant, expertise in specific proprietary services might be more niche, impacting talent acquisition and retention.

In essence, while the "best of both worlds" approach can provide immediate benefits (e.g., Cosmos DB's global scale and low-latency capabilities), it requires careful consideration of the long-term implications, especially regarding potential vendor lock-in, increased operational complexity, and cost management. Architects adopting this philosophy must have a clear understanding of the trade-offs and a robust strategy for mitigating these potential issues.

House Based Manufacturing Micro Clustering

                                 image generated by meta ai House-based manufacturing micro-clustering in China refers to the hyper-local, v...