Showing posts with label software. Show all posts
Showing posts with label software. 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.

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.

Sunday

How to Start an Income as an iPhone APP Developer

                                                                meta ai

Many students and beginner developer followers asked me about keeping the iPhone app available for users to download on their iPhones. Just to clarify, iPhone apps are hosted and distributed through the App Store, not iTunes (iTunes is mainly for music, movies, etc.).1

Regarding fees to keep your app on the App Store:

  • There is no separate fee per download or per month/year simply to keep your app listed once it's published, in addition to the commission Apple takes on paid apps or in-app purchases.
  • However, you absolutely must have an active Apple Developer Program membership to have your app available for download on the App Store.

The Apple Developer Program has an annual fee of $99 USD (the price might vary slightly by region in local currency).2

This annual membership is what allows you to:

  1. Distribute your apps on the App Store.
  2. Submit updates to your app.
  3. Access the latest beta software, tools (like Xcode), and resources needed for development.3
  4. Use services like TestFlight for beta testing, App Store Connect for managing your app, and various Apple frameworks and capabilities.

If your Apple Developer Program membership expires and you do not renew it, your app will eventually be removed from the App Store, and users will no longer be able to download it.4 You also won't be able to submit any updates.

So, while there isn't a fee specifically to keep a listing active separate from developer costs, the annual $99 Developer Program fee is mandatory to maintain your app's presence and availability on the App Store.

Income as a developer

Okay, now let's break down your earnings as a developer for your iPhone app priced at $5 per download on the Apple App Store.

Apple charges a commission fee on app sales and in-app purchases.1 There are two main commission rates that could apply to you, depending on your total annual earnings from the App Store:

  1. Standard Commission Rate: 30%
  2. Reduced Commission Rate (App Store Small Business Program): 15%2

The reduced 15% rate applies if your total proceeds (your earnings after Apple's commission) across all your apps in the previous calendar year were less than $1 million USD.3 If your proceeds were $1 million USD or more, the standard 30% rate applies. For new developers, the 15% rate generally applies until their proceeds exceed $1 million in a calendar year.

Here's how your earnings and Apple's commission would be calculated for 1000 downloads, based on these two scenarios:

Scenario 1: Standard 30% Commission Rate

  • App Price per download: $5
  • Apple's Commission per download: 30% of $5 = $1.50
  • Your earning per download: $5 - $1.50 = $3.50
  • Total Revenue from 1000 downloads: 1000 * $5 = $5000
  • Total Commission paid to Apple for 1000 downloads: 1000 * $1.50 = $1500
  • Your total earnings for 1000 downloads: 1000 * $3.50 = $3500

Scenario 2: Reduced 15% Commission Rate (App Store Small Business Program)

  • App Price per download: $5
  • Apple's Commission per download: 15% of $5 = $0.75
  • Your earning per download: $5 - $0.75 = $4.25
  • Total Revenue from 1000 downloads: 1000 * $5 = $5000
  • Total Commission paid to Apple for 1000 downloads: 1000 * $0.75 = $750
  • Your total earnings for 1000 downloads: 1000 * $4.25 = $4250

In summary:

For 1000 downloads of your $5 app:

  • If the standard 30% commission applies, you would earn $3500, and you would pay $1500 in commission to Apple.
  • If the reduced 15% commission applies, you would earn $4250, and you would pay $750 in commission to Apple.

Keep in mind that there might also be taxes (like VAT or sales tax) depending on the user's location, which are typically handled by Apple and deducted before the commission is calculated. The amounts above represent your earnings before any income tax you might owe.

How to become an iPhone app Developer

Okay, embarking on the journey to become an iPhone app developer using Swift is exciting! Here’s a detailed guide on how you can get started, covering what you need to learn, the necessary setup, resources, and the role of simulators.

1. The Very First Step: Get the Right Hardware

  • You need a Mac: This is non-negotiable for native iOS development with Swift and Xcode. Xcode, the essential software for building iOS apps, only runs on macOS.
    • Minimum Recommended Specs: While older Macs can technically run Xcode, a modern Mac (preferably with Apple Silicon like the M1, M2, M3, or M4 chip) will provide a much smoother development experience, faster build times, and better longevity. Aim for at least 8GB of RAM (16GB is highly recommended) and at least 256GB of SSD storage (512GB or more is better, as Xcode and simulators can take up significant space).
    • Why a Mac? Apple controls the entire ecosystem. Their tools (Xcode) are exclusively for their operating system (macOS) to build apps for their devices (iPhone, iPad, etc.).

2. Your Essential Software: Xcode

  • What it is: Xcode is Apple's Integrated Development Environment (IDE). It's a free application available on the Mac App Store.
  • What it includes: Xcode is your all-in-one tool. It includes:
    • Code Editor: Where you'll write your Swift code.
    • Compilers: To turn your Swift code into an app your iPhone can run.
    • Interface Builder/Canvas: Tools to design your app's user interface visually (Storyboards for UIKit, Canvas for SwiftUI).
    • Simulator: Allows you to run and test your app on virtual iPhones and iPads on your Mac.
    • Debugger: Helps you find and fix errors in your code.
    • Documentation Browser: Access to Apple's extensive documentation.
    • App Store Connect Integration: Tools for managing and submitting your app to the App Store (requires a paid developer account later).

3. What You Need to Learn

This is the core part of becoming a developer. It's a journey, so focus on learning step-by-step.

  • a) Swift Programming Language:

    • Fundamentals: Start with the basics: variables, constants, data types (Strings, Integers, Booleans, Arrays, Dictionaries), control flow (if/else, loops), functions, optionals (a key Swift concept).
    • Object-Oriented Programming (OOP) / Protocol-Oriented Programming (POP): Understand classes, structs, enums, protocols, inheritance, and how to organize your code. Swift heavily utilizes POP.
    • Intermediate Concepts: Error handling, closures, extensions, generics, concurrency (how to perform tasks without freezing your app).
  • b) UI Framework (Choose one to start, but be aware of the other):

    • SwiftUI: (Recommended for beginners starting now) Apple's newer, declarative framework. You describe what your UI should look like, and the system figures out how to render it. It's designed to be easier to learn and faster to build interfaces, and it works across all Apple platforms.
    • UIKit: The older, imperative framework. You tell the system how to build the UI step-by-step. It's mature, powerful, and still widely used in existing apps. Learning UIKit provides a deep understanding of how iOS interfaces work.
    • Start with SwiftUI if you're brand new, as it represents the future of Apple development and is often considered more intuitive for modern UI patterns.
  • c) Core iOS Development Concepts:

    • App Life Cycle: How an app launches, runs in the background, becomes active, and terminates.
    • View Hierarchy: How UI elements are organized on the screen.
    • Handling User Input: Responding to taps, swipes, gestures, and text input.
    • Navigation: How users move between different screens in your app (e.g., using NavigationView in SwiftUI or UINavigationController in UIKit).
    • Data Persistence: How to save data on the device (e.g., UserDefaults for small amounts, Core Data or Realm for structured data, saving to files).
    • Networking: How to connect your app to the internet to fetch or send data (e.g., using URLSession).
  • d) Design Principles (Optional but helpful):

    • Familiarize yourself with Apple's Human Interface Guidelines (HIG). This document outlines best practices for designing intuitive and consistent iOS apps.

4. Learning Resources

There are tons of resources available, both free and paid.

  • Official Apple Resources (Highly Recommended - Free):

    • Apple Developer Website (developer.apple.com): This is your primary source for documentation, tutorials, sample code, and videos from Apple's annual WWDC conferences.
    • "The Swift Programming Language" Book: Available for free on Apple Books and the web, this is the definitive guide to Swift.
    • SwiftUI Tutorials: Apple provides excellent hands-on tutorials on building apps with SwiftUI.
    • "Develop in Swift" Tutorials: Apple offers structured learning paths, often used in educational settings.
  • Popular Third-Party Resources (Many offer free content, some are paid):

    • Hacking with Swift (hackingwithswift.com): Offers a huge amount of free text and video tutorials, including the popular "100 Days of SwiftUI" challenge.
    • Ray Wenderlich (now Kodeco) (kodeco.com): Provides high-quality tutorials (text and video) on a wide range of iOS development topics. Has both free and subscription content.
    • Udemy, Coursera, edX: Offer structured video courses, often covering fundamentals to advanced topics. Look for highly-rated courses on Swift, SwiftUI, or iOS Development.
    • YouTube: Many developers create free video tutorials on specific topics or project builds (e.g., CodeWithChris).
    • Books: Many introductory and in-depth books on Swift and iOS development are available.
    • Online Communities: Stack Overflow and the iOS programming subreddits (like r/iOSProgramming, r/SwiftUI) are great for getting help and seeing common issues.

5. Using Simulators

  • Can you use them? Absolutely! Simulators are an integral part of iOS development.

  • What they do: They allow you to run and test your app on various simulated iPhone and iPad devices directly on your Mac. You can test different screen sizes, orientations (portrait/landscape), and iOS versions.

  • Pros: Fast to launch, convenient for testing UI layout on multiple devices without needing physical hardware.

  • Cons:

    • Performance: App performance in the simulator may not perfectly reflect real-world performance on a physical device.
    • Hardware Features: Many hardware features are not available or fully simulated (e.g., camera, gyroscope/accelerometer, Bluetooth, push notifications in their entirety, battery life impact).
    • Real-World Interaction: Testing touch sensitivity, scrolling feel, and how the app handles interruptions (like phone calls) requires a physical device.
  • Do you need a physical device? While you can learn a lot using only the simulator, you will eventually need a physical iPhone or iPad for:

    • Testing features that don't work in the simulator.
    • Assessing real-world performance and user experience.
    • Deploying your app for beta testing (TestFlight) or to the App Store (requires provisioning the app on a physical device through your developer account). You can test on your own physical devices with a free Apple ID during development, but distribution requires the paid program.

6. Starting Your Journey and Other Details

  1. Get Your Mac and Install Xcode: This is the absolute technical starting point.
  2. Start with Swift Fundamentals: Use a resource like Apple's Swift book or a beginner course. Focus on understanding the core language concepts.
  3. Move to UI Development: Choose SwiftUI or UIKit and start building simple screens and user interactions.
  4. Build Small Projects: Create basic apps (like a to-do list, a simple calculator, a weather display app fetching data) to apply what you learn and build confidence.
  5. Don't Aim for Perfection Initially: Focus on learning and completing small features. Your first apps won't be App Store ready, and that's perfectly fine.
  6. Persistence is Key: Learning to develop apps takes time and effort. You will encounter errors and challenges. Learn how to debug and search for solutions (Stack Overflow is your friend!).
  7. The Apple Developer Program ($99/year) is NOT required for learning and testing on your own devices. You only need it when you are ready to distribute your app to others via the App Store or TestFlight.

Starting out can feel overwhelming, but by breaking it down into smaller, manageable steps and focusing on understanding the core concepts and tools, you can definitely become an iPhone app developer. Good luck!

House Based Manufacturing Micro Clustering

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