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

How to Extract Profile Data Correctly from Linkedin

 

                                                                         meta ai

Almost all companies today rely on LinkedIn to extract candidate profiles during hiring or onboarding. However, despite widespread use, even large enterprises frequently fail to extract complete and accurate profile data. The result is broken or partial imports, dozens of mismatches and formatting errors, and missing sections like certifications, experience, or education. This often forces candidates to manually re-enter or correct the information—costing them time, creating frustration, and negatively impacting their experience.

To read LinkedIn profile details (including licenses and certifications) after authorization, follow this short and structured approach:


✅ Prerequisites

  • LinkedIn Developer Account

  • A registered LinkedIn app

  • OAuth 2.0 access token with r_liteprofile, r_emailaddress, and r_fullprofile (requires special permission)


🔐 OAuth Authorization (Basic Steps)

  1. Redirect user to LinkedIn Auth URL:

https://www.linkedin.com/oauth/v2/authorization?response_type=code
&client_id=YOUR_CLIENT_ID
&redirect_uri=YOUR_REDIRECT_URI
&scope=r_liteprofile%20r_emailaddress%20r_fullprofile
  1. Exchange code for access token:

POST https://www.linkedin.com/oauth/v2/accessToken
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&
code=AUTHORIZATION_CODE&
redirect_uri=YOUR_REDIRECT_URI&
client_id=YOUR_CLIENT_ID&
client_secret=YOUR_CLIENT_SECRET

📥 API Call to Fetch Profile Data

⚠️ The Licenses & Certifications section is part of Member Profile API (v2), which requires LinkedIn Partner Program access.

Endpoint to fetch certifications (partner-only):

GET https://api.linkedin.com/v2/licenses
Authorization: Bearer ACCESS_TOKEN

Or using the profile projections endpoint (partner access):

GET https://api.linkedin.com/v2/me?projection=(id,firstName,lastName,licensesAndCertifications)
Authorization: Bearer ACCESS_TOKEN            

📌 Note

  • Regular apps do not have access to r_fullprofile or licensesAndCertifications.

  • To access them, apply to LinkedIn Partner Program.


Here’s a complete Streamlit-based LinkedIn OAuth and profile fetch demo, including guidance on Partner access and alternatives.


📁 Folder Structure

linkedin_profile_app/
├── app.py
├── .env
└── requirements.txt

📄 .env

CLIENT_ID=your_linkedin_client_id
CLIENT_SECRET=your_linkedin_client_secret
REDIRECT_URI=http://localhost:8501

📄 requirements.txt

streamlit
requests
python-dotenv

📄 app.py

import streamlit as st
import requests
import os
from urllib.parse import urlencode
from dotenv import load_dotenv

load_dotenv()

CLIENT_ID = os.getenv("CLIENT_ID")
CLIENT_SECRET = os.getenv("CLIENT_SECRET")
REDIRECT_URI = os.getenv("REDIRECT_URI")

AUTH_URL = "https://www.linkedin.com/oauth/v2/authorization"
TOKEN_URL = "https://www.linkedin.com/oauth/v2/accessToken"
PROFILE_URL = "https://api.linkedin.com/v2/me"

SCOPES = "r_liteprofile r_emailaddress"

def get_auth_url():
    params = {
        "response_type": "code",
        "client_id": CLIENT_ID,
        "redirect_uri": REDIRECT_URI,
        "scope": SCOPES
    }
    return f"{AUTH_URL}?{urlencode(params)}"

def get_token(auth_code):
    data = {
        "grant_type": "authorization_code",
        "code": auth_code,
        "redirect_uri": REDIRECT_URI,
        "client_id": CLIENT_ID,
        "client_secret": CLIENT_SECRET
    }
    response = requests.post(TOKEN_URL, data=data, headers={"Content-Type": "application/x-www-form-urlencoded"})
    return response.json().get("access_token")

def fetch_profile(access_token):
    headers = {"Authorization": f"Bearer {access_token}"}
    response = requests.get(PROFILE_URL, headers=headers)
    return response.json()

def main():
    st.title("🔗 LinkedIn Profile Fetch")

    query_params = st.experimental_get_query_params()
    auth_code = query_params.get("code", [None])[0]

    if auth_code:
        access_token = get_token(auth_code)
        if access_token:
            profile = fetch_profile(access_token)
            st.success("Profile fetched successfully!")
            st.json(profile)
        else:
            st.error("Failed to get access token.")
    else:
        auth_url = get_auth_url()
        st.markdown(f"[🔐 Authorize with LinkedIn]({auth_url})")

if __name__ == "__main__":
    main()

🚫 Certifications & Licenses Access (Important Note)

LinkedIn does not allow access to licensesAndCertifications through the public API. You must:


✅ Workaround Options

  1. LinkedIn Data Export (Manual User Upload)
    Ask user to export their LinkedIn data:
    https://www.linkedin.com/psettings/member-data → Select JSON → Upload and parse the Licenses & certifications.json.

  2. Unofficial Puppeteer/Selenium-based scraper
    Not recommended – violates TOS and risks ban.


Here's a LinkedIn Data Export JSON parser built with Flask that reads the exported ZIP, extracts the Licenses & Certifications, and displays them:


✅ Folder Structure

linkedin_parser_app/
├── app.py
├── templates/
│   └── index.html
├── uploads/
└── requirements.txt

📄 requirements.txt

Flask
python-dotenv

📄 templates/index.html

<!DOCTYPE html>
<html>
<head>
    <title>LinkedIn Data Parser</title>
</head>
<body>
    <h2>Upload LinkedIn Export ZIP</h2>
    <form action="/" method="post" enctype="multipart/form-data">
        <input type="file" name="zipfile" required>
        <button type="submit">Upload & Parse</button>
    </form>

    {% if certifications %}
        <h3>Licenses & Certifications</h3>
        <ul>
        {% for cert in certifications %}
            <li><strong>{{ cert['name'] }}</strong> - {{ cert['authority'] }} ({{ cert['start_date'] }}{% if cert['end_date'] %} to {{ cert['end_date'] }}{% endif %})</li>
        {% endfor %}
        </ul>
    {% endif %}
</body>
</html>

📄 app.py

from flask import Flask, request, render_template
import os, zipfile, json, tempfile

app = Flask(__name__)
UPLOAD_FOLDER = 'uploads'
os.makedirs(UPLOAD_FOLDER, exist_ok=True)

def extract_certifications_from_json(json_data):
    certs = []
    for item in json_data:
        certs.append({
            "name": item.get("name"),
            "authority": item.get("authority", {}).get("name", ""),
            "start_date": item.get("starts_on", {}).get("year", ""),
            "end_date": item.get("ends_on", {}).get("year", "")
        })
    return certs

@app.route("/", methods=["GET", "POST"])
def index():
    certifications = []
    if request.method == "POST":
        zip_file = request.files["zipfile"]
        if zip_file and zip_file.filename.endswith(".zip"):
            with tempfile.TemporaryDirectory() as tmpdirname:
                zip_path = os.path.join(tmpdirname, zip_file.filename)
                zip_file.save(zip_path)
                with zipfile.ZipFile(zip_path, 'r') as zip_ref:
                    zip_ref.extractall(tmpdirname)
                
                cert_path = os.path.join(tmpdirname, 'Licenses & certifications.json')
                if os.path.exists(cert_path):
                    with open(cert_path, 'r', encoding='utf-8') as f:
                        data = json.load(f)
                        certifications = extract_certifications_from_json(data)
    return render_template("index.html", certifications=certifications)

if __name__ == "__main__":
    app.run(debug=True)

✅ Usage

  1. Ask users to download their LinkedIn data export (JSON).

  2. Upload the ZIP via this app.

  3. It parses and displays Licenses & Certifications directly.


Here is the REST API version with FastAPI to parse LinkedIn Data Export ZIP and return Licenses & Certifications in JSON format:


✅ Folder Structure

linkedin_fastapi_parser/
├── main.py
├── utils.py
├── requirements.txt
└── uploads/

📄 requirements.txt

fastapi
uvicorn
python-multipart

📄 utils.py

import zipfile, tempfile, json, os

def extract_certifications_from_zip(zip_file) -> list:
    with tempfile.TemporaryDirectory() as tmpdir:
        zip_path = os.path.join(tmpdir, "upload.zip")
        with open(zip_path, "wb") as f:
            f.write(zip_file.read())

        with zipfile.ZipFile(zip_path, "r") as zip_ref:
            zip_ref.extractall(tmpdir)

        cert_path = os.path.join(tmpdir, "Licenses & certifications.json")
        if not os.path.exists(cert_path):
            return []

        with open(cert_path, "r", encoding="utf-8") as f:
            data = json.load(f)

        return [
            {
                "name": c.get("name"),
                "authority": c.get("authority", {}).get("name", ""),
                "start_date": c.get("starts_on", {}).get("year", ""),
                "end_date": c.get("ends_on", {}).get("year", "")
            }
            for c in data
        ]

📄 main.py

from fastapi import FastAPI, UploadFile, File, HTTPException
from utils import extract_certifications_from_zip

app = FastAPI()

@app.post("/upload")
async def upload_linkedin_zip(file: UploadFile = File(...)):
    if not file.filename.endswith(".zip"):
        raise HTTPException(status_code=400, detail="Only ZIP files are allowed.")
    
    certifications = extract_certifications_from_zip(await file.read())
    if not certifications:
        raise HTTPException(status_code=404, detail="No certifications found in the ZIP.")
    
    return {"certifications": certifications}

✅ Run the Server

uvicorn main:app --reload

Test at:
http://localhost:8000/docs → Use /upload with a LinkedIn ZIP file.




Monday

LLMs Brought a New Kind of Software Engineering

LLMs Are a New Kind of Software

We are going to present a comparative view of Traditional Software vs LLMs (Large Language Models) to highlight how LLMs represent a fundamental shift in the software paradigm.


Comparison Table

Traditional Software LLMs (Large Language Models)
Deterministic Non-deterministic
Fast Slow
Cheap Expensive
Rigid Flexible
If → then Reasoning

Detailed Explanation

1. Deterministic vs Non-deterministic

  • Traditional Software follows a fixed, rule-based approach. Given the same input, it always produces the same output.

  • LLMs are probabilistic. Their outputs can vary for the same input because they are based on learned patterns from data rather than hard-coded rules.

2. Fast vs Slow

  • Traditional programs execute instructions quickly because they’re optimized and compiled to run directly on machines.

  • LLMs involve complex computations (e.g., matrix multiplications in neural networks), often requiring GPUs or TPUs, which can make them slower, especially for larger prompts or models.

3. Cheap vs Expensive

  • Once built, traditional software is inexpensive to run at scale.

  • LLMs are resource-intensive and require significant compute power, making them expensive to run, especially at high volume or with low latency requirements.

4. Rigid vs Flexible

  • Traditional software is inflexible: it needs explicit updates for new logic or edge cases.

  • LLMs are adaptable and can respond to a broad range of tasks (e.g., translation, coding, summarization) without being explicitly programmed for each.

5. If → Then vs Reasoning

  • Traditional software logic is hard-coded using conditional statements.

  • LLMs can “reason” based on their training — they generalize from massive data and can infer context or patterns to provide intelligent outputs, mimicking reasoning.


Conclusion

This comparison emphasizes the paradigm shift from rule-based programming to data-driven intelligence. LLMs open new possibilities where software can handle fuzzy, open-ended, and unstructured tasks—something traditional software struggles with—making them revolutionary in fields like AI assistance, content generation, and natural language interaction.

Here's a practical example demonstrating both Traditional Software (Deterministic) and LLM-based (Non-Deterministic) approaches for solving a simple task: Intent Classification from user input.


🧠 Use Case: Detecting User Intent (e.g., Greeting, Order, Complaint)


1. Traditional Software Approach (Deterministic)

def classify_intent(text):
    text = text.lower()
    if "hello" in text or "hi" in text:
        return "Greeting"
    elif "order" in text or "buy" in text:
        return "Order"
    elif "not working" in text or "problem" in text:
        return "Complaint"
    else:
        return "Unknown"

# Test
print(classify_intent("Hi there"))               # Greeting
print(classify_intent("I want to buy a laptop"))  # Order
print(classify_intent("My device is not working"))# Complaint

🔹 Deterministic: Same input = same output
🔹 Rigid: Needs explicit if-else for every condition
🔹 Fast and Cheap


2. LLM-based Approach (Non-Deterministic)

import openai

openai.api_key = "your-api-key"

def classify_intent_with_llm(text):
    prompt = f"What is the user's intent in the following message?\nMessage: \"{text}\"\nIntent:"
    
    response = openai.Completion.create(
        engine="gpt-3.5-turbo-instruct",  # Or any available model
        prompt=prompt,
        max_tokens=10,
        temperature=0.3
    )
    
    return response.choices[0].text.strip()

# Test
print(classify_intent_with_llm("Hi there"))                # Greeting
print(classify_intent_with_llm("I want to buy a laptop"))   # Order
print(classify_intent_with_llm("My device is not working")) # Complaint

🔹 Non-Deterministic: May vary slightly each time
🔹 Flexible: Can handle unseen or ambiguous phrasing
🔹 Expensive & Slower



You're absolutely right — the future is not about LLMs replacing traditional software, but about merging both into a new paradigm, often referred to as:


🌐 Agentic Software Systems / Cognitive Architectures

🔁 The Future Is Hybrid

Traditional Software 🤝 LLMs / Agentic Models
Deterministic logic + Reasoning & Flexibility
APIs, Databases + Language, Code, Tools
Speed, Control + Adaptivity, Learning

🧠 Key Concepts Emerging:

  1. Agentic and Multi Agent Workflows
    LLMs act as agents that reason, plan, and call APIs/tools (e.g., ReAct, AutoGPT, LangGraph, ADK, CrewAI).

  2. Tool-Using LLMs
    LLMs delegate precise computation to traditional tools (e.g., calculators, DBs, API calls).

  3. Event-driven Agents
    Instead of “if → then”, agents can “observe → think → act”.

  4. Prompt Engineering + Function Calling
    Structured prompts + calling specific functions bring control and predictability to LLMs.

  5. LangChain, LangGraph, ADK, Semantic Kernel, Autogen, CrewAI
    Frameworks are emerging to orchestrate LLMs + code + tools into reliable systems.


📌 Future Software Engineering Stack (Agentic)

[ UI / App ]
     ↓
[ Event → LLM Agent ]
     ↓
[ Plans → Tools / APIs ]
     ↓
[ Executes → Validates → Stores ]

🧭 Think of It As:

  • Traditional code = Muscle

  • LLMs/Agents = Brain

  • Together = Intelligent System


✅ Summary

FeatureTraditional SoftwareLLM-based Software
Rule-based
Learns from data
Same output always❌ (depends on temperature, context)
Handles fuzzy input

The future of software is agentic, hybrid, modular, and tool-aware. Developers will write code plus design workflows for reasoning agents that combine the best of both worlds.

Wednesday

Some Handy Git Use Cases

Let's dive deeper into Git commands, especially those that are more advanced and relate to your workflow.

Understanding Your Workflow

Your provided commands outline a common workflow:

  1. Feature Branch Development: You're working on a feature branch (SMGF2201-7370).
  2. Staying Updated: You're fetching and integrating changes from the team's development branch (develop_mlops_deployment).
  3. Reviewing Changes: You're using git log -p, gitk, and git show to examine differences and commit details.
  4. Tagging: You're using git tag to mark specific commits.

Advanced Git Commands and Concepts

Here's a breakdown of related and advanced commands, organized for clarity:

1. Branching and Merging (Beyond Basic Pulls)

  • git rebase:
    • Purpose: Integrates changes from one branch into another by reapplying commits on top of the target branch. This creates a cleaner, linear history.
    • Usage:
      Bash
      git checkout SMGF2201-7370
      git rebase origin/develop_mlops_deployment
      
    • Explanation: This rewrites your feature branch's history as if you had branched off the latest develop_mlops_deployment.
    • Caution: Rebase rewrites history, so avoid rebasing branches that have already been pushed and shared with others.
  • git merge --squash:
    • Purpose: Combines all changes from a feature branch into a single commit on the target branch.
    • Usage:
      Bash
      git checkout develop_mlops_deployment
      git merge --squash SMGF2201-7370
      git commit -m "Merged feature branch SMGF2201-7370"
      
    • Explanation: This is useful for creating a clean history when merging feature branches, especially when those branches contain many small commits.
  • git cherry-pick:
    • Purpose: Applies specific commits from one branch to another.
    • Usage:
      Bash
      git checkout target_branch
      git cherry-pick <commit_hash>
      
    • Explanation: This is useful for selectively incorporating changes from other branches.
  • git branch -D <branch_name>:
    • Purpose: Force deletes a branch.
    • Explanation: Use this when a normal git branch -d fails because the branch hasn't been fully merged.

2. Inspecting Changes (Advanced)

  • git diff:
    • Purpose: Shows differences between commits, branches, or files.
    • Usage:
      • git diff: Shows changes since the last commit.
      • git diff <commit1> <commit2>: Shows changes between two commits.
      • git diff <branch1> <branch2>: Shows changes between two branches.
      • git diff --staged: Shows changes that are staged for commit.
      • git diff --name-status <commit1> <commit2>: shows only the file names that changed, and the type of change (A=added, M=modified, D=deleted).
  • git bisect:
    • Purpose: Helps find the commit that introduced a bug by performing a binary search through the commit history.
    • Usage:
      Bash
      git bisect start
      git bisect bad <bad_commit>
      git bisect good <good_commit>
      
    • Explanation: Git will automatically check out commits, and you'll mark them as "good" or "bad" until the problematic commit is identified.
  • git blame:
    • Purpose: Shows who last modified each line of a file and when.
    • Usage:
      Bash
      git blame <file_name>
      
    • Explanation: This is useful for understanding the history of specific lines of code.

3. Rewriting History (Use with Caution)

  • git commit --amend:
    • Purpose: Modifies the last commit.
    • Usage:
      Bash
      git commit --amend
      
    • Explanation: This allows you to change the commit message or add/remove files from the last commit.
  • git rebase -i (Interactive Rebase):
    • Purpose: Allows you to edit, reorder, squash, or drop commits during a rebase.
    • Usage:
      Bash
      git rebase -i <commit_hash>
      
    • Explanation: This is a powerful tool for cleaning up your commit history.
  • git reset:
    • Purpose: Resets the current branch to a specific commit.
    • Usage:
      • git reset --soft <commit_hash>: Keeps changes staged.
      • git reset --mixed <commit_hash>: Keeps changes unstaged.
      • git reset --hard <commit_hash>: Discards all changes.
    • Caution: git reset --hard can result in data loss, so use it carefully.
  • git reflog:
    • Purpose: Shows a log of all changes to the HEAD pointer, including branch switches, resets, and commits.
    • Explanation: This is a safety net that allows you to recover from mistakes.

4. Stashing

  • git stash:
    • Purpose: Temporarily saves changes that are not ready to be committed.
    • Usage:
      • git stash: Saves changes.
      • git stash list: Lists stashed changes.
      • git stash apply: Applies the last stashed changes.
      • git stash pop: Applies and removes the last stashed changes.
      • git stash drop <stash_id>: Removes a specific stash entry.

Example scenarios:

  • You need to work on a hotfix while in the middle of your feature branch:
    1. git stash
    2. git checkout main
    3. Create hotfix branch, make changes, commit, and merge.
    4. git checkout SMGF2201-7370
    5. git stash pop

Important Considerations

  • Collaboration: When working in a team, communicate before rewriting shared history.
  • Understanding History: Learn how to interpret Git logs and visualize commit graphs.
  • Practice: The best way to learn Git is to use it regularly.

Some More Commands Revisited with Advanced Context

  1. git switch SMGF2201-7370
    • Explanation: You're switching to your feature branch.
    • Advanced:
      • git switch -c new_branch: Creates and switches to a new branch in one command.
      • git switch -: switch back to the last branch.
  2. git fetch origin develop_mlops_deployment
    • Explanation: You're fetching the latest changes from the remote develop_mlops_deployment branch.
    • Advanced:
      • git fetch origin: Fetches all branches from the remote.
      • git fetch --prune origin: removes remote-tracking references to remote branches that no longer exist on the remote. This is very useful for cleaning up local clutter.
  3. git log -p HEAD..FETCH_HEAD or gitk HEAD..FETCH_HEAD
    • Explanation: You're inspecting the changes between your local HEAD and the fetched FETCH_HEAD.
    • Advanced:
      • git log --graph --oneline --decorate: Provides a concise graphical representation of the commit history.
      • git log --author="Your Name": Filters logs by author.
      • git log --since="YYYY-MM-DD" --until="YYYY-MM-DD": Filters logs by date range.
      • git log --grep="search term": filters commits by commit message content.
      • git log -S"string": Find commits that change addition or removal of particular strings.
  4. git pull origin develop_mlops_deployment
    • Explanation: You're pulling (fetching and merging) the remote changes into your feature branch.
    • Advanced:
      • git pull --rebase origin develop_mlops_deployment: Pulls and rebases instead of merging, creating a cleaner history.
      • If merge conflicts arise, use git status to locate the files, manually resolve the conflicts, git add the resolved files, and then git commit.
  5. gitk HEAD...FETCH_HEAD
    • Explanation: You're viewing the symmetric difference between your HEAD and FETCH_HEAD.
    • Advanced: This is very good for seeing what changes are unique to each branch.
  6. git show c82a22c39cbc32576f64f5c6b3f24b99ea8149c7, git show HEAD^, git show HEAD^^, git show HEAD~4
    • Explanation: You're viewing the details of specific commits.
    • Advanced:
      • git show --stat: Shows the statistics of the changes in a commit.
      • git show --name-only: Shows only the names of the files changed in a commit.
  7. git tag v3 1b2e1d63ff
    • Explanation: You're creating a tag named v3 for the commit 1b2e1d63ff.
    • Advanced:
      • git tag -a v3 -m "Release v3": Creates an annotated tag with a message. Annotated tags are recommended.
      • git tag -d v3: Deletes the tag v3.
      • git push origin v3: Pushes the tag to the remote repository.
      • git tag -l "v*": Lists all tags matching the pattern "v*".
  8. git log v3..v2, git log v2.., git log --since="2 weeks ago", git log v2.. Makefile
    • Explanation: You're filtering the commit log based on tags, dates, and file paths.
    • Advanced: Combine these filters for complex queries. For example, git log --author="Your Name" --since="1 week ago" Makefile.

Workflow Enhancements

  • Pre-commit Hooks:
    • Create scripts that run automatically before each commit to enforce code style, run tests, or prevent committing certain files.
    • This can be done by placing executable scripts inside the .git/hooks/ directory.
  • Git Aliases:
    • Create shortcuts for frequently used Git commands.
    • Example: git config --global alias.co checkout allows you to use git co instead of git checkout.
  • Using a GUI Client:
    • Tools like GitKraken, SourceTree, or GitHub Desktop can provide a visual interface for Git, making complex operations easier.
  • Commit Message Conventions:
    • Establish clear and consistent commit message conventions within your team.
    • This makes it easier to understand the history and track changes.
  • Code Reviews:
    • Use pull requests or merge requests to facilitate code reviews before merging changes into the main branch.
    • This helps to catch bugs and improve code quality.

By mastering these commands, you'll be able to manage your Git repositories more effectively and collaborate more efficiently.

House Based Manufacturing Micro Clustering

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