DEV Community: Dr Haina

An LLM is not an AI product

Dr Haina — Mon, 05 Oct 2026 13:45:17 +0000

Calling an LLM API and wrapping a UI around it gives you a demo. Shipping it to real users takes a full stack:

LLM: the intelligence layer
Data extraction: Firecrawl, Crawl4AI, Docling, LlamaParse
Embeddings: text into vectors
Vector database: Pinecone, Qdrant, Weaviate, Milvus, PostgreSQL
RAG and orchestration: retrieve, build context, send to the LLM
Application: agents, copilots, search, workflows
Evaluation: Ragas, TruLens, Giskard
Production: auth, observability, rate limits, caching, monitoring, versioning, cost control

The real flow is not User → LLM → Answer.

It is Data → Extraction → Embeddings → Retrieval → Context → LLM → Application → Evaluation → Production.

LLM = Intelligence.
Full Stack = Product.

What does your production AI stack look like? Which layer gave you the most trouble?

ai #llm #rag #softwareengineering #webdev

LLMs vs AI Agents Explained: A Practical Guide by Dr. Haina Fatima (XINI8 Engine)

Dr Haina — Sat, 03 Oct 2026 08:26:10 +0000

Hi, I'm Dr. Haina Fatima. I started my career as a physician and radiologist, and today I lead development and product at XINI8 Engine, an AI-native software engineering platform within the XINI8 ecosystem. Coming from outside traditional software, the terms "LLM" and "AI agent" confused me for a long time, because people use them as if they mean the same thing. They do not. Here is the mental model that finally made it click for me.

What an LLM actually is

A large language model (LLM) is a system trained on huge amounts of text to predict the next token in a sequence. From that one skill come the abilities we see: answering questions, summarizing, translating, writing code, and drafting documents.

On its own, an LLM is stateless and passive:

It only knows what was in its training data plus whatever you put in the prompt.
It cannot look anything up, click anything, or run anything.
Each call is independent unless you send the history again.

Think of it as a very well read colleague who answers from memory, with no phone, no computer, and no notebook.

What an agent adds

An AI agent is an LLM placed inside a loop, with a goal and a set of tools. Instead of answering once, it can decide what to do next, act, look at the result, and continue until the goal is met.

The building blocks are:

A goal given by the user or the system.
Tools the model can call, such as search, a database query, a calculator, or an API.
Memory, meaning the conversation so far, notes, or retrieved documents.
A loop that feeds tool results back to the model until it decides it is done.

If the LLM is the brain, the agent is the brain plus hands plus a to-do list.

A minimal agent loop

This is simplified pseudocode in Python, not tied to any specific provider:

def run_agent(goal, tools, max_steps=8):
    messages = [{"role": "user", "content": goal}]

    for step in range(max_steps):
        reply = call_llm(messages, tools=list(tools.keys()))

        # The model either asks for a tool or gives a final answer
        if reply.tool_call is None:
            return reply.text

        name = reply.tool_call.name
        args = reply.tool_call.arguments

        result = tools[name](**args)

        messages.append({"role": "assistant", "tool_call": reply.tool_call})
        messages.append({"role": "tool", "name": name, "content": str(result)})

    return "Stopped: step limit reached."

Notice what matters here. The intelligence comes from the model, but the safety comes from your code: the step limit, the fixed list of tools, and the fact that you decide what each tool is allowed to do.

When to use which

Situation	Better fit
Summarize, rewrite, classify, or extract from text you already have	Plain LLM call
A fixed sequence of steps you can write down in advance	A normal workflow with LLM calls inside
Open-ended tasks where the next step depends on what was found	Agent
High-stakes decisions	Agent or LLM with human review

A lesson I learned the hard way is that many problems do not need an agent. If you can draw the steps as a straight line, a simple pipeline is cheaper, faster, and easier to debug. Reach for an agent only when the path genuinely cannot be known ahead of time.

A healthcare example

Take medical billing, which I know well from my work in revenue cycle management. A claim gets denied, and someone has to work out why and what to do next.

A plain LLM can read the denial text and explain it in plain language.
A workflow can extract the denial code, look up the rule, and draft an appeal letter in fixed steps.
An agent can investigate: pull the claim, check the payer policy, compare it with the documentation, decide that a code correction is needed, and prepare the resubmission.

In real healthcare settings, the agent should prepare and recommend, while a trained person approves anything that affects a patient or a payment. Never put patient identifiers into a tool or service you have not checked for compliance with the rules that apply to you.

Common ways agents fail

Hallucinated actions. The model calls a tool that does not exist or invents arguments. Validate every call.
Endless loops. Always set a step limit and a cost limit.
Prompt injection. Text from a web page or document can contain instructions that try to hijack the agent. Treat all retrieved content as untrusted data, never as commands.
Over-permissioned tools. Give each tool the minimum access it needs. Read-only by default.
No evaluation. If you cannot measure whether the agent got better, you are guessing. Build a small test set early.
Compounding errors. A small mistake in step two can poison steps three to ten. Add checkpoints.

What this means for AI-native engineering

At XINI8 Engine, we think about software engineering as something AI can increasingly help with, but only when the right structure surrounds it: clear goals, limited tools, logging, and human review where it counts. The same principles in this article apply whether you are building a billing assistant or an engineering platform.

Practical tips if you are starting out

Begin with a single LLM call and get that working.
Add one tool, then test it thoroughly.
Log every step, including prompts, tool calls, and results.
Keep a human in the loop for anything irreversible.
Write down what "done" looks like so the agent, and you, know when to stop.

Closing thoughts

LLMs gave us a general purpose language engine. Agents are what happens when we give that engine a goal, tools, and the ability to try again. The most useful skill for builders right now is not wiring up the fanciest agent, but knowing when a simple prompt is enough, when a workflow is better, and when an agent really earns its complexity.

I am still learning, and I would love to hear from you. What is the first task you gave an agent, and what went wrong? Share it in the comments.

About the author

Dr. Haina Fatima is a physician (MBBS), radiologist (MS Radiology), and certified medical coder who moved into health IT and technology. She leads development and product at XINI8 Engine, an AI-native software engineering platform within the XINI8 ecosystem, is Co-Founder of Voltra Studio (Web3 and blockchain infrastructure), and is RCM Director and Partner at Doctor Billing Experts.

lets connect dev people

Dr Haina — Mon, 14 Sep 2026 09:19:28 +0000

Building QINIX: The Technology Infrastructure Behind a More Responsible iGaming Future

Dr Haina — Mon, 14 Sep 2026 09:18:50 +0000

The next generation of iGaming will not be defined only by games and user interfaces. It will also depend on the infrastructure operating behind them.

**
** is being developed with that idea at its core: building technology for digital gaming that considers security, player verification, compliance, fraud prevention, responsible gaming and operational transparency as fundamental parts of the system.

More Than a Gaming Platform

Modern iGaming environments require significantly more than a frontend and a payment system. Operators need mechanisms for KYC, AML, player verification, transaction monitoring, fraud detection, responsible gambling and risk management.

QINIX is focused on bringing these capabilities into a technology-driven infrastructure designed to support scalable digital gaming experiences.

The objective is not simply to add compliance after a platform has been built. The goal is to consider security, verification and responsible gaming throughout the architecture.

The Team Behind QINIX

QINIX is being developed by a multidisciplinary team with experience spanning technology, product development, media, business strategy, digital infrastructure and compliance.

The team includes Yordy Diaz, Virginia Schmidt, Ashir Ansari, Saif ur Rehman, Tom Paca and Dr. Haina Fatima.

Yordy Diaz is the founder of QINIX and also a co-founder of the broader XINI8 ecosystem. He is also the founder of Flinix and OneFlex, bringing years of experience across technology, entertainment and digital product development.

Yordy describes the philosophy behind the team simply:

“Innovation begins when we stop asking what exists and start asking what could exist.”

That philosophy is reflected in how QINIX approaches product development: not treating existing gaming infrastructure as the limit, but asking what a more intelligent, secure and responsible architecture could look like.

Technology, Compliance and Player Protection

For developers and operators, compliance is increasingly becoming a technology problem as much as a regulatory one.

Identity verification needs reliable data flows. AML systems need transaction intelligence. Fraud prevention requires behavioral signals and risk analysis. Responsible gaming requires mechanisms capable of identifying patterns and responding appropriately.

These systems need to work together.

QINIX is exploring this intersection between iGaming technology, compliance infrastructure, cybersecurity, player protection and intelligent digital systems.

The broader objective is to create infrastructure that can evolve with the requirements of modern digital gaming rather than relying on disconnected tools and processes.

Building With a Long-Term Perspective

QINIX is part of the XINI8 ecosystem, where technology, media, gaming and digital infrastructure are being developed across interconnected products.

The team believes the future of iGaming will require stronger infrastructure beneath the user experience. Games may be what players see, but verification, security, compliance, risk management and responsible gaming are what help create a sustainable platform.

QINIX is being built around that principle.

The work is still developing, but the direction is clear: bu*ild the infrastructure first, make responsibility part of the architecture, and create technology capable of supporting the next generation of digital gaming.*

AI is not the end of the technology cycle.

Dr Haina — Fri, 11 Sep 2026 16:03:44 +0000

It may be the beginning of the next one.

The internet connected people to information.

Cloud computing connected people to scalable computing.

AI is making intelligence increasingly accessible.

So what happens when intelligence becomes abundant?

I believe the next major shift will be from AI that answers questions to systems that can independently operate, coordinate, transact and act in the real world.

That opens the door to a much bigger technology stack:

Autonomous agent networks
Machine-to-machine economies
Robotics and physical AI
Synthetic biology + AI
Autonomous scientific research
Energy intelligence
Digital identity and trust infrastructure
Intelligence marketplaces
Spatial computing
Brain-computer interfaces

The important part is that these technologies won't develop independently.

They will converge.

AI agents will use marketplaces.
Agents will transact with other agents.
Machines will interact with digital infrastructure.
Robots will bring intelligence into the physical world.
AI will accelerate scientific discovery.
Synthetic biology will make parts of biology programmable.
New identity and trust systems will become necessary when billions of autonomous actors enter the network.

This could lead to something much bigger than today's AI ecosystem:

The Autonomous Internet.

An internet connecting not only people and information, but:

People → AI → Agents → Machines → Organizations → Physical Systems

And that changes the question.

The opportunity may not be to build another AI model.

It may be to build the infrastructure that allows millions of intelligent systems to work
together safely and efficiently.

Models provide intelligence.

The next layer will provide context, memory, orchestration, verification, identity, permissions, marketplaces and real-world execution.

That is the layer I believe is worth watching.

AI may be the technology of this decade.

But the systems built around autonomous intelligence could define the next one.

What do you think comes after AI?

𝗧𝗵𝗲 𝟯𝟬 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗔𝗜 𝗧𝗲𝗿𝗺𝘀 𝗠𝘆 𝗧𝗲𝗮𝗺 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗨𝘀𝗲𝘀

Dr Haina — Tue, 08 Sep 2026 05:48:48 +0000

My team kept asking the same question in different words: what's the difference between an agent loop and an agentic workflow. So I put together the list I wish someone had handed me a year ago. Plain English, no fluff.

𝗖𝗼𝗿𝗲 𝗠𝗲𝗰𝗵𝗮𝗻𝗶𝗰𝘀
𝟭. 𝗔𝗜 𝗔𝗴𝗲𝗻𝘁: given a goal, plans, acts, checks results, keeps going.
𝟮. 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗪𝗼𝗿𝗸𝗳𝗹𝗼𝘄: pre-designed multi-step process using AI.
𝟯. 𝗔𝗴𝗲𝗻𝘁 𝗟𝗼𝗼𝗽: decide, act, observe, repeat until done.
𝟰. 𝗧𝗼𝗼𝗹 𝗖𝗮𝗹𝗹𝗶𝗻𝗴: model calls a function, works off the real result.
𝟱. 𝗔𝗴𝗲𝗻𝘁 𝗛𝗮𝗿𝗻𝗲𝘀𝘀: the code managing tools, state, and permissions.
𝟲. 𝗣𝗿𝗼𝗺𝗽𝘁 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴: crafting instructions to get reliable behavior.
𝟳. 𝗖𝗵𝗮𝗶𝗻 𝗼𝗳 𝗧𝗵𝗼𝘂𝗴𝗵𝘁: model reasons step by step before answering.
𝟴. 𝗥𝗲𝗔𝗰𝘁 𝗣𝗮𝘁𝘁𝗲𝗿𝗻: alternating reasoning and action in one loop.

𝗜𝗻𝗽𝘂𝘁𝘀
𝟵. 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴: deciding what the model sees at each step.
𝟭𝟬. 𝗠𝗲𝗺𝗼𝗿𝘆: persisting info across sessions.
𝟭𝟭. 𝗠𝗖𝗣: standard way to connect agents to tools and data.
𝟭𝟮. 𝗚𝗿𝗼𝘂𝗻𝗱𝗶𝗻𝗴: tying output to verified facts.
𝟭𝟯. 𝗛𝗮𝗹𝗹𝘂𝗰𝗶𝗻𝗮𝘁𝗶𝗼𝗻: confidently generating false information.
𝟭𝟰. 𝗘𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴𝘀: numerical representations of meaning.

𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀
𝟭𝟱. 𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴: breaking a goal into ordered subtasks.
𝟭𝟲. 𝗥𝗲𝗮𝘀𝗼𝗻𝗶𝗻𝗴: weighing tradeoffs to pick the next move.
𝟭𝟳. 𝗦𝗲𝗹𝗳 𝗥𝗲𝗳𝗹𝗲𝗰𝘁𝗶𝗼𝗻: agent reviews its own output before finalizing.

𝗦𝗰𝗮𝗹𝗶𝗻𝗴
𝟭𝟴. 𝗠𝘂𝗹𝘁𝗶 𝗔𝗴𝗲𝗻𝘁 𝗦𝘆𝘀𝘁𝗲𝗺: specialized agents dividing the work.
𝟭𝟵. 𝗢𝗿𝗰𝗵𝗲𝘀𝘁𝗿𝗮𝘁𝗶𝗼𝗻: coordinating which agent does what, when.
𝟮𝟬. 𝗛𝗮𝗻𝗱𝗼𝗳𝗳: passing a task to a more specialized agent.
𝟮𝟭. 𝗦𝘂𝗯 𝗔𝗴𝗲𝗻𝘁: smaller agent spun up for one specific piece.
𝟮𝟮. 𝗔𝟮𝗔: protocol letting agents from different systems talk.

𝗦𝗮𝗳𝗲𝘁𝘆
𝟮𝟯. 𝗚𝘂𝗮𝗿𝗱𝗿𝗮𝗶𝗹𝘀: hard limits on agent actions.
𝟮𝟰. 𝗛𝗜𝗧𝗟: a person approves irreversible actions.
𝟮𝟱. 𝗦𝗮𝗻𝗱𝗯𝗼𝘅𝗶𝗻𝗴: isolating actions from production systems.
𝟮𝟲. 𝗣𝗿𝗼𝗺𝗽𝘁 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻: malicious input hijacking instructions.
𝟮𝟳. 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆: logging what an agent actually did.
𝟮𝟴. 𝗘𝘃𝗮𝗹𝘀: testing if the right steps were taken, not just the output.

𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗮𝗹
𝟮𝟵. 𝗖𝗼𝗺𝗽𝘂𝘁𝗲𝗿 𝗨𝘀𝗲: agent operates a UI directly, no API needed.
𝟯𝟬. 𝗔𝗴𝗲𝗻𝘁 𝗪𝗮𝘀𝗵𝗶𝗻𝗴: calling something an agent when it's just a chatbot.

Save this if your team's asking the same questions.

What term took your team the longest to actually agree on?

AgenticAI #AI #MCP #EngineeringLeadership

From Generative AI to Systemic AI

XINIENGINE: A Software Factory Built for Developers, Not Around Them

Dr Haina — Sun, 16 Aug 2026 11:01:17 +0000

There is a version of automation that tries to replace developers. This is not that.

XINIENGINE was built on a simpler premise: most of a developer's time is not spent making decisions. It is spent on repetition. Scaffolding the same boilerplate. Writing tests for logic that already works. Wiring up the same integrations project after project. Waiting on deployment pipelines. None of that requires judgment. All of it requires time.

XINIENGINE removes the repetitive layer and leaves the parts that actually need a developer.

The System

XINIENGINE is an AI software factory. It is not a single model generating code from a prompt. It is a coordinated system of over 150 specialized agents, each built for a specific function inside the development lifecycle.

Here is how a build moves through the system.

Input
A developer or team defines the goal, the requirements, and any constraints through the Control Panel. This can be as scoped as an API endpoint or as broad as an application.

Orchestration
An Orchestrator Agent breaks the goal into a task plan and routes work to the relevant specialized agents. This is closer to how a technical lead breaks down a ticket than how a chatbot answers a prompt.

Parallel Execution
Specialized agents work simultaneously, not sequentially. While one agent handles backend logic, another is writing tests, another is reviewing for security issues, another is handling deployment configuration. Work that would normally happen in stages happens in parallel.

Integration Layer
Agents operate through real infrastructure: APIs, MCP, LSP, databases, cloud services, and browser automation. This is what allows output to be functional software, not a code sample that still needs to be wired together.

Output
The result is tested, integrated, and deployable. Not a draft. Not a scaffold. A working system.

Why This Matters for Developers Specifically

Most AI coding tools operate at the level of a single function or a single file. They are useful, but they still require a developer to manage the surrounding architecture, keep track of state across the project, and manually verify that generated code fits the system it is being dropped into.

XINIENGINE operates at the level of the project. The Orchestrator Agent maintains context across the entire task. Specialized agents are not generating isolated snippets, they are contributing to a coordinated build with shared context and dependencies tracked across the system.

This is the difference between autocomplete and a team.

Control Stays With the Developer

None of this is autonomous in the sense of unsupervised. Every layer is visible and controllable.

Start or pause any agent at any point. Assign priority to what matters first. Track live progress through a real-time scheduler and activity feed, not a black box. Review and approve before anything ships to production. Modify and iterate without starting over.

This matters because developer trust is earned through visibility, not promised through automation. XINIENGINE is built to be audited at every step, not just accepted at the end.

What Gets Built

Web and mobile applications. Backend services and APIs. Automation pipelines. SaaS platforms. Internal tools. Integrations across existing systems.

The scope is set by the developer, not the platform.

The Point

XINIENGINE is not trying to make developers unnecessary. It is trying to make the unnecessary parts of development disappear, so that the time developers do spend is spent on architecture, logic, and the decisions that actually require a human in the loop.

Early access is opening soon for developers who want to build with the system directly.

Must read

Dr Haina — Sun, 16 Aug 2026 10:58:54 +0000

Separating AI provenance from detection myths

Sylwia Laskowska

Aug 11

The End of Undetectable AI Text? Claude’s New Watermark Explained

#news #ai #llm

160

108

6 min read

21 Days In: A Doctor's First Steps Into Tech

Dr Haina — Wed, 05 Aug 2026 20:09:42 +0000

I never thought I would say this, but few weeks ago I opened my laptop and started learning how apps are actually built. Not as a doctor. As a complete beginner. No coding background, no computer science degree, just curiosity and a lot of patience.

It has been humbling. It has also been one of the most exciting things I have done in a long time.

The first thing that struck me was how much invisible work sits behind every app we tap on without thinking. Every button, every login screen, every "loading" spinner is hiding a whole world underneath. That world has a name: the backend. And the way the backend talks to the app in front of you is called an API. Once I understood that, I could not stop noticing it everywhere. Every app I open now, I catch myself wondering what is happening behind the screen.

A few days into this, I started exploring GitHub, watching how developers actually share and build projects together, piece by piece, version by version. It felt like walking into a hospital and finally understanding what happens in the operating room instead of just seeing the patient before and after.

But the moment that really stopped me was Playwright.

I was building a small app for practice, and I used Playwright to test it. I expected a tool. What I got felt closer to watching something think. It opened the browser on its own, found buttons, clicked them, waited exactly as long as it needed to, and reacted the moment something on the page changed. As a doctor, that kind of pattern recognition and precise, patient observation is something I understand deeply. Seeing a machine do it for a website felt strangely familiar, and completely astonishing at the same time.

That is the part nobody tells you when you start learning tech later in life. You are not just learning to code. You are learning to see. Every app becomes a small mystery you now have a few tools to solve.

Ten days in, I do not know much yet. But I know enough to be hooked. If you have ever looked at an app and wondered how it actually works underneath, that curiosity is the only qualification you need to start.

If a doctor with zero coding background can sit down and build something in ten days, so can you.

xini8 #drhainafatima #xiniengine

At XINI8, we're building XINIENGINE

Dr Haina — Tue, 04 Aug 2026 09:12:21 +0000

At XINI8, we're building XINIENGINE as an open AI development platform that gives developers, startups, and enterprises the infrastructure to build intelligent applications without starting from scratch.

Our vision is simple: instead of piecing together dozens of AI services, developers should have access to a unified platform where they can build, connect, automate, and scale AI-powered products.

One of the core components of XINIENGINE is RAGCODED.

What is RAGCODED?

RAGCODED is XINIENGINE's Retrieval-Augmented Generation (RAG) module. It enables AI applications to retrieve information from trusted sources before generating a response.

Rather than relying only on an AI model's training data, RAGCODED connects to documents, databases, APIs, websites, cloud storage, and enterprise knowledge bases. This allows AI agents to provide more accurate, relevant, and up-to-date answers.

Why It Matters

Every business has information that an AI model doesn't know:

Internal documentation
Product manuals
Customer records
Research papers
Knowledge bases
Standard operating procedures
API documentation
Company policies

RAGCODED allows developers to securely connect these data sources so AI can reason using real business knowledge.

Part of a Much Bigger Platform

RAGCODED is only one building block of XINIENGINE.

The platform is being designed with a growing ecosystem of AI infrastructure, including:

AI agent framework
Workflow automation
Model Context Protocol (MCP) integration
Long-term memory
Tool calling
API orchestration
Knowledge retrieval
Prompt management
Multi-agent collaboration
AI pipelines
Vector search
Authentication and security
Analytics and monitoring
SDKs and developer APIs

Each module is designed to work independently or together, giving developers the flexibility to build anything from a simple AI assistant to enterprise-scale autonomous systems.

Building the Future, Module by Module

XINIENGINE isn't a single application. It's a growing ecosystem of AI infrastructure where each component solves a specific problem.

RAGCODED is the knowledge engine.

Other modules will focus on automation, orchestration, memory, communications, developer tools, media processing, and intelligent workflows.

Together, they form the foundation for building the next generation of AI-powered software.

This is just the beginning. As XINIENGINE evolves, we'll continue introducing new modules that make advanced AI development more accessible, more scalable, and more practical for developers around the world.

Python had its worst year on the popularity index. JavaScript too

Dr Haina — Sun, 02 Aug 2026 05:56:32 +0000

Same month, both hit record contributor counts on GitHub.**

Not a contradiction. The ranking is just measuring the wrong thing now.

TIOBE tracks Google searches for a language name. That signal died with ChatGPT — Stack Overflow's question volume is down ~78% since launch. We didn't stop asking questions, we stopped asking them in public. The crawler just can't see a chat window.

So forget the index. Look at what's actually shipping:

Python is winning the model layer, and it's not close.

Transformers pulled 43.4M installs in a week vs 1.8M for the JS build. 23:1.
OpenAI's Python client: 97.7M weekly. The npm version: 31.8M.
vLLM, SGLang — Python on the outside, CUDA underneath. It's the control plane for every expensive GPU in the building.

TypeScript is winning the product layer, and the reason should sound familiar to anyone pairing with an assistant daily.

It passed Python for #1 in GitHub contributor count last year.
Growing 67% YoY vs Python's 49% and plain JS's 25%.
The compiler catches the model's wrong guesses (bad signature, wrong field name) before runtime. Untyped code finds out in prod, at 3am, from a log.

Then TS shipped a Go-rewritten compiler in v7 this July — type-checking VS Code's own codebase went from 125s to 10.6s. The tax for type safety just got cut 10x in the exact year assistants started depending on it.

Even the labs' own tooling shows the split: Claude Code is TypeScript. Codex CLI moved from TypeScript to Rust for speed. Nobody's reaching for Python to build the interface.

The "versus" framing is dead. These two stopped competing for the same job around 2023.

Python owns training, fine-tuning, serving, research.
TypeScript owns the agent loop, the tool calls, the thing the user's thumb touches.

Curious where the room lands on this — if you're picking up a language this year, are you picking it for the model or for the product? Genuinely think that's the only question that matters now.

Python #TypeScript #AI #devcommunity #buildinpublic

The Road to AGI: Why Intelligence Architecture Matters More Than Model Size

Dr Haina — Wed, 29 Jul 2026 05:31:55 +0000

The AI conversation usually starts with the wrong question: "How intelligent is the model?" A more useful question is: "Which layers of intelligence does the system actually possess?"

Human intelligence isn't a single capability — it's a stack of interconnected cognitive functions. Mapping that stack onto artificial intelligence gives us a much clearer framework for understanding where we are on the path to AGI (artificial general intelligence), and what agentic AI actually changes.

The Cognitive Stack

Human intelligence breaks down into distinct, interdependent functions:

Perception — seeing, hearing, sensing, and recognizing patterns
Memory — working, short-term, long-term, episodic, and semantic memory
Learning — adapting from experience, feedback, and new information
Reasoning — inference, comparison, deduction, induction, problem solving
Planning — breaking objectives into actions and deciding what happens next
Creativity — generating new ideas, concepts, and solutions
Intuition — recognizing patterns before conscious reasoning
Strategy — modeling possible futures and consequences
Metacognition — evaluating one's own thinking, uncertainty, and mistakes
Self / identity — continuity, preferences, experiences, persistent objectives
Consciousness — subjective experience and awareness

Across all of these sits one more layer: goals, motivation, and values.

This is a useful lens for evaluating modern AI. Today's large language models are already remarkably capable at perception, language, pattern recognition, knowledge synthesis, reasoning, coding, and generation. But most of that capability lives inside a single interaction — a prompt in, a response out. What's largely been missing is everything downstream of the answer: acting on it, verifying it, adapting to what happens next.

That's the gap agentic AI is built to close.

Agentic AI Changes the Architecture, Not Just the Output

Instead of simply generating an answer, an AI agent can understand a goal, build context, retrieve information, use tools, plan a sequence of actions, execute them, observe results, evaluate outcomes, correct its approach, and continue until the objective is achieved.

That's a fundamentally different paradigm from prompt-response AI. It's also where the more interesting engineering work is happening — not in making models larger, but in building intelligence systems around models.

In this framing, the model becomes the reasoning engine. Everything else is engineered around it:

Context engineering — situational awareness
Retrieval-augmented generation (RAG) — external knowledge and retrieval
Memory systems — persistent long-term memory
Tool use — interaction with the digital world
Agent loops — perception, action, feedback, correction
Planning systems — decomposition and execution
Graph engineering — relationships, entities, and world models
Reflection — evaluation and metacognition
Multi-agent systems — specialized, collaborative intelligence
Goal systems — objectives and decision criteria
Persistent agents — continuity and identity

The distinction that falls out of this: AI answers. Agentic AI acts. Increasingly sophisticated agentic systems can learn from their own actions, maintain context across time, coordinate with other agents, use external tools, and pursue objectives over extended periods rather than a single exchange.

Where AGI Actually Fits

Rather than defining artificial general intelligence purely by benchmark scores, it's more useful to think about AGI as the convergence of multiple intelligence layers operating together: general learning, reasoning, memory, planning, adaptation, world models, creativity, metacognition, autonomous action, and goal-directed behavior.

Under that definition, AGI isn't necessarily one breakthrough model. It's more likely to emerge from the integration of many cognitive capabilities into a persistent, adaptive system — which is exactly why intelligence architecture, not just model scale, is the thing worth watching.

Artificial superintelligence (ASI) represents a further threshold: intelligence substantially exceeding human capability across most important cognitive domains.

One distinction is worth being precise about: AGI does not equal consciousness, and neither does ASI. A system could become extraordinarily capable — outperforming humans across nearly every cognitive task — without having any subjective experience at all. Capability and consciousness are separate questions, and conflating them muddies both.

A Better Question Than "How Do We Make AI Smarter?"

A more productive framing is: what actually constitutes intelligence, which components does AI already possess, which remain weak, and how do we engineer the missing pieces?

That produces a practical framework for evaluating any AI system:

Human capability → cognitive function → AI equivalent → current capability → limitation → engineering mechanism → AGI requirement

Run any current model or agent through that chain, and the gaps become obvious — not as vague limitations, but as specific missing components: persistent memory, reliable multi-step planning, genuine metacognitive self-correction, coherent identity over time.

The Progression

The trajectory isn't "better chatbots" or "larger models." It's increasingly sophisticated intelligence architectures capable of perceiving, remembering, reasoning, planning, acting, evaluating, and adapting — built as systems, not single models.

That points to a progression: AI → agentic AI → AGI → ASI.

The real engineering question isn't how to generate more intelligent output. It's how to build systems that don't just generate intelligence, but operationalize it.