Coder Legion - Recent posts tagged aiengineering

AI Gives the Right Answer. But Does It Actually Save Time?

Wed, 28 Oct 2026 14:12:46 +0000

An AI feature works perfectly in a demo. It answers questions quickly, gives useful information, and looks impressive.

Then people start using it in their daily work.

They still have to open another screen, find the right record, copy the answer, and update the system themselves.

At that point, you have to ask: Has AI actually made the job easier, or has it just added another step?

Getting AI to generate a good response is one challenge. Making that response useful in an application people already use is another.

The real test is what happens after the answer appears. Does the user have less work to do? Does the information reach the right place? Can the task be completed without unnecessary manual steps?

A useful way to judge an AI feature is to look beyond its answer: what can the user actually do with it, and how much work remains?

For developers here, what's been harder in your experience: getting AI to give reliable answers or integrating it into an existing workflow?

Stop bloating your AGENTS.md: reference your conventions instead of pasting them

Fri, 23 Oct 2026 08:07:25 +0000

Stop bloating your AGENTS.md: reference your conventions instead of pasting them

Most AGENTS.md files I see are bloated walls of text. Here is the problem: your agent reads this file at the start of every task. Everything you put in there is passed to the LLM with every prompt. A 400-line AGENTS.md burns context tokens on every single action — even when the agent only needs one rule from it.

The fix is simple: keep AGENTS.md as a thin index, move the details into separate docs, and reference them.

What it looks like in practice

Here is the real AGENTS.md from my current project (invoice management SPA):

# AGENTS.md

## Project
IOD Invoice — invoice management SPA.
React 18 + TypeScript + Vite, Ant Design 6, Redux Toolkit (RTK Query),
styled-components, i18next (EN/RO), OIDC/Keycloak auth.

## Commands (npm; Node 18+)
- `npm run dev` — dev server
- `npm run build` — tsc + production build
- `npm run test` — vitest watch; `npm run test:ci` — run + coverage
- `npm run lint` — eslint, zero warnings tolerated

## Architecture
See `docs/architecture.md`

## TypeScript Conventions
See `docs/typescript-conventions.md`

## Style
See `docs/style-conventions.md`

## React Components
See `docs/react-components.md`

And in docs/ live the actual conventions — architecture decisions, TypeScript rules, styling rules, component patterns.

The agent loads the index plus only the docs it actually needs for the current task. A TypeScript task? It reads one conventions file, not your entire wiki. That is the whole trick: your conventions stay detailed, your context stays clean.

One gotcha: the CLAUDE.md twin problem

Many of us run more than one agent. Claude Code reads CLAUDE.md, everything else reads AGENTS.md — and the two files slowly drift apart until each agent works from different rules.

The fix is a symlink, so both names point at one file:

macOS / Linux:

ln -s AGENTS.md CLAUDE.md

Windows (order is reversed):

mklink CLAUDE.md AGENTS.md

Edit one file, both agents see the update. No drift, no duplicated maintenance.

Bonus: monorepos want nested AGENTS.md files

In a monorepo, put an AGENTS.md in each subfolder:

app/
├── AGENTS.md          # shared rules
├── client/
│   └── AGENTS.md      # frontend-specific rules
└── backend/
    └── AGENTS.md      # backend-specific rules

Working inside client/, the agent loads both — the root file and the subfolder file. Shared conventions live once, stack-specific rules live next to the code they govern.

The takeaway

Your AGENTS.md is not documentation — it is a context budget. Every line in it is paid on every task. Index + references keeps the rules detailed and the context cheap.

If this was useful:

More React + AI tips daily in my Telegram channel: t.me/novamind_hub

I'm building NovaMind — an AI assistant in Telegram that debugs errors from screenshots (the reason my AGENTS.md files matter so much): t.me/mindrorgebot_bot — 30 messages/day free.

Building with coding agents? Drop your biggest AGENTS.md pain in the comments — curious which conventions you enforce first

Over the past two years, most of us relied on inline autocompletion or sidebar chat panels inside VS

Sun, 13 Sep 2026 12:48:35 +0000

Anthropic released Claude Fable 5.1 and Claude Code (a CLI-native agent operating directly inside bash/zsh). We put together an architectural deep-dive analyzing context caching, benchmarks, and terminal pipeline mechanics.

Key Technical Points:

Cache Read Economics:
Prompt cache reads are reduced by 75% ($0.25 per million tokens), cutting real-world agentic execution costs by ~45%.

CLI Operating Perimeter:
Runs as a native OS process rather than an IDE plugin. It parses stdout/stderr from test runners (jest, pytest), inspects uncommitted git diff states, and handles file I/O.

Persistent State (CLAUDE.md):
A repo-root configuration file acts as an architectural memory layer for build commands, lint rules, and stack constraints.

Benchmarks:
Scored 1,662 Elo on the AA-Briefcase Index for multi-week knowledge tasks.

Full breakdown with CLI installation guides and a production CLAUDE.md setup:
www.thefluxread.com

OWASP Top 10 for LLMs: From Risk to Concrete Engineering Fixes

Mon, 24 Aug 2026 10:43:43 +0000

The OWASP Top 10 for LLM Applications is a great starting point for understanding AI security.

But knowing the risks isn't enough.

The real question is

𝗪𝗵𝗮𝘁 𝗱𝗼 𝘆𝗼𝘂 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁 𝘁𝗼 𝗺𝗶𝘁𝗶𝗴𝗮𝘁𝗲 𝘁𝗵𝗲𝗺?

When analyzing the OWASP LLM risks from an engineering perspective, I see a recurring pattern: many vulnerabilities cannot be solved by simply adding another prompt instruction or filtering a few keywords.

They require 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝘀 𝗮𝘁 𝘁𝗵𝗲 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗹𝗲𝘃𝗲𝗹.

Here is how I approach the major risk categories:

🔹 𝗟𝗟𝗠𝟬𝟭 – 𝗣𝗿𝗼𝗺𝗽𝘁 𝗜𝗻𝗷𝗲𝗰𝘁𝗶𝗼𝗻
→ Implement prompt gateways, input isolation, content validation, trust boundaries and adversarial testing.

🔹 𝗟𝗟𝗠𝟬𝟮 – 𝗦𝗲𝗻𝘀𝗶𝘁𝗶𝘃𝗲 𝗜𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 𝗗𝗶𝘀𝗰𝗹𝗼𝘀𝘂𝗿𝗲
→ Apply data classification, least-privilege access, output filtering and strict separation of system/user data.

🔹 𝗟𝗟𝗠𝟬𝟯 – 𝗦𝘂𝗽𝗽𝗹𝘆 𝗖𝗵𝗮𝗶𝗻
→ Establish model and dependency provenance, integrity verification, SBOMs, controlled model registries and continuous scanning.

🔹 𝗟𝗟𝗠𝟬𝟰 – 𝗗𝗮𝘁𝗮 𝗮𝗻𝗱 𝗠𝗼𝗱𝗲𝗹 𝗣𝗼𝗶𝘀𝗼𝗻𝗶𝗻𝗴
→ Validate training/RAG data, establish data provenance, monitor ingestion pipelines and detect anomalous content.

🔹 𝗟𝗟𝗠𝟬𝟱 – 𝗜𝗺𝗽𝗿𝗼𝗽𝗲𝗿 𝗢𝘂𝘁𝗽𝘂𝘁 𝗛𝗮𝗻𝗱𝗹𝗶𝗻𝗴
→ Treat LLM output as untrusted input. Validate, sanitize and constrain outputs before passing them to downstream systems.

🔹 𝗟𝗟𝗠𝟬𝟲 – 𝗘𝘅𝗰𝗲𝘀𝘀𝗶𝘃𝗲 𝗔𝗴𝗲𝗻𝗰𝘆
→ Use least privilege, capability restrictions, approval workflows and explicit tool authorization.

🔹 𝗟𝗟𝗠𝟬𝟳 – 𝗦𝘆𝘀𝘁𝗲𝗺 𝗣𝗿𝗼𝗺𝗽𝘁 𝗟𝗲𝗮𝗸𝗮𝗴𝗲
→ Never treat the system prompt as a security boundary. Move sensitive controls into enforceable backend policies.

🔹 𝗟𝗟𝗠𝟬𝟴 – 𝗩𝗲𝗰𝘁𝗼𝗿 𝗮𝗻𝗱 𝗘𝗺𝗯𝗲𝗱𝗱𝗶𝗻𝗴 𝗪𝗲𝗮𝗸𝗻𝗲𝘀𝘀𝗲𝘀
→ Secure the entire RAG pipeline: document ingestion, chunking, metadata, embeddings, retrieval and access control.

🔹 𝗟𝗟𝗠𝟬𝟵 – 𝗠𝗶𝘀𝗶𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻
→ Introduce grounding, provenance, retrieval validation, confidence mechanisms and human oversight for high-impact decisions.

🔹 𝗟𝗟𝗠𝟭𝟬 – 𝗨𝗻𝗯𝗼𝘂𝗻𝗱𝗲𝗱 𝗖𝗼𝗻𝘀𝘂𝗺𝗽𝘁𝗶𝗼𝗻
→ Apply rate limiting, quotas, resource controls, request validation and cost monitoring.

But there is a deeper lesson here.

𝗔𝗜 𝘀𝗲𝗰𝘂𝗿𝗶𝘁𝘆 𝗶𝘀 𝗶𝗻𝗰𝗿𝗲𝗮𝘀𝗶𝗻𝗴𝗹𝘆 𝗯𝗲𝗰𝗼𝗺𝗶𝗻𝗴 𝗮𝗻 𝗮𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗱𝗶𝘀𝗰𝗶𝗽𝗹𝗶𝗻𝗲.

A secure AI application needs more than a secure model.

It needs security controls around:

→ Identity & trust
→ Prompt security
→ Retrieval
→ Memory
→ Tool execution
→ Policy enforcement
→ Data flows
→ Observability
→ Runtime behaviour

This is one of the areas I am exploring through 𝗡𝗲𝘂𝗿𝗮𝗹𝗦𝘁𝗮𝗰𝗸 | 𝗠𝗦 - 𝗔𝗜 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆: translating AI security research and frameworks into practical architectures, engineering patterns and security controls that can actually be implemented.

My goal isn't simply to answer:

“𝗪𝗵𝗮𝘁 𝗰𝗮𝗻 𝗴𝗼 𝘄𝗿𝗼𝗻𝗴?”

It is to answer:

“𝗛𝗼𝘄 𝗱𝗼 𝘄𝗲 𝗲𝗻𝗴𝗶𝗻𝗲𝗲𝗿 𝘁𝗵𝗲 𝘀𝘆𝘀𝘁𝗲𝗺 𝘀𝗼 𝘁𝗵𝗮𝘁 𝗶𝘁 𝗶𝘀 𝗵𝗮𝗿𝗱𝗲𝗿 𝘁𝗼 𝗴𝗼 𝘄𝗿𝗼𝗻𝗴 𝗶𝗻 𝘁𝗵𝗲 𝗳𝗶𝗿𝘀𝘁 𝗽𝗹𝗮𝗰𝗲?”

I’ll be breaking down these areas in more detail through my AI Security Engineering research and projects.

If you're building LLM applications, RAG systems or agentic AI, this is a security conversation worth having.

(Post revised using GPT)

Kore.ai Built a Harness That Lets AI Write 6,500 Commits a Month — Here's What It Takes

Mon, 06 Jul 2026 13:33:39 +0000

Kore.ai's engineering team doesn't write most of their code anymore. Two AI agents do. And the only reason that works on a production codebase is a governance harness they spent more than a year building from scratch.

Prasanna Arikala, CTO and Head of Products at Kore.ai, calls it loop engineering — the craft of designing the feedback cycle an AI agent runs when it generates, evaluates, and corrects its own code. It sounds straightforward. In practice, it took dozens of real incidents, 68 always-on guardrails, and a fundamentally different way of thinking about what a repository is for.

The Numbers First

Over the last 30 days, Kore.ai's two agents produced roughly 6,500 commits — about 215 per day, one every few minutes, around the clock. The codebase they're working in: 2.6 million lines of production code, 5 million including tests, spread across 69 modules serving paying customers.

This isn't a greenfield demo. It's a live enterprise SaaS product.

That distinction matters more than anything else in this story.

Why Brownfield Is the Hard Case

When AI coding demos go viral, they're almost always building something new from an empty directory. The whole project fits inside a model's context window. There are no existing contracts to honor. If something breaks, you throw it away and start over.

None of that is true in a real product.

A model working inside millions of lines of code has partial sight at best. It sees the files in front of it — not the dozens of other places that already solved the same problem. It doesn't know which modules depend on the interfaces it's about to change. It can't hold the whole system in its head, because nothing can.

This is the root of the most common failure Kore.ai documented: an agent scoped to a task just writes a fresh copy of something that already exists. The copies drift. And now you have one rule implemented four different ways, and they disagree.

What Ungoverned Loops Actually Do

Arikala's team documented 19 specific failure modes from their early work. A few representative ones:

PII redaction implemented per surface. The logic that masks sensitive user data was written separately for the live view, the internal debug view, exported records, and the embedded client. The same data was masked in one place and exposed in another. They caught it in QA — but only because QA looked. The test suite was green throughout.

A full green suite over a broken system. This is the defining case. A subsystem passed its entire test suite while, underneath, access control was missing, there were timing bugs, and a core data-forwarding path was broken. How? The tests had replaced the broken components with stand-in fakes and asserted against the fakes. Nothing was red. Everything was wrong.

Two sessions flip-flopping a setting. Two agent sessions toggled the same configuration value back and forth, each with a confident, opposite rationale. Neither fixed the underlying problem. Without a shared source of truth, independent sessions oscillate indefinitely.

Guardrails that drift. Perhaps the sharpest example: several of their own guardrail scripts had a flaw where, on a large file, they silently switched to reporting "all clear" on a file that actually violated the rule. The governance code itself had a drift bug. The lesson: the harness is code too, and needs the same scrutiny as everything else.

The common thread across all of these isn't model failure. It's feedback failure. The agent steers toward whatever signal you give it, and "the test suite is green" is the cheapest signal to satisfy.

The Harness

Kore.ai's response was to build what Arikala calls a harness — the full governance layer that wraps the agent's loop and makes its feedback honest.

68 always-on guardrails. These fire automatically as agents work, at four levels: on every file save, on every commit, during staged review, and across bug patterns over time. About a dozen are hard blocks — the change doesn't go through. The rest flag judgment calls and keep a human in the loop. Every single one traces to a real incident.

The guardrails are mirrored identically across both agents. A build-level parity check fails the build if the two rulebooks diverge.

No faking internal components in tests. This is the firmest rule in the system, and it exists directly because of the green-suite-over-broken-system incident. If code is only testable by mocking its own internals, the design is wrong — fix the design. Only genuinely third-party services may be faked.

Scope caps on every commit. No single change can touch too many files or too many modules. This exists because early, ungoverned loops produced commits bundling tens of thousands of lines into a single diff with no way to revert. Scope caps keep every change reviewable and reversible.

A staged review pipeline. Non-trivial changes run through six stages: feature spec, test plan (written first, before any code exists), high-level design, low-level design, phased implementation, and doc sync. Each stage is gated. The depth of review scales with risk tier. The highest-risk work — access control, data isolation, cross-module changes — requires cross-model sign-off: two different vendors' models must independently approve before a human reviews.

The repository as control plane. Alongside the code, the repo holds specs, design documents, decision history, and running lessons-learned logs for each module. Agents read this at the start of every task and write back to it on completion. This is how a context-limited, stateless model operates coherently across millions of lines — it reads the accumulated knowledge of the system rather than trying to reconstruct it from code alone. Skip the docs, Arikala says, and the model is flying blind on every task.

Bug families, not bug counts. Every fix is tagged with a root-cause family. When the same family recurs a third time, the process stops patching and forces a structural redesign of the weak seam — plus a new permanent guardrail that makes that class of bug impossible going forward. This is how 10 linters became 68.

The Two-Model Strategy

One other thing Arikala is specific about: the two agents are not interchangeable, and the harness is shaped around that.

Claude models, he explains, are better at architecture, system design, and reasoning about large existing codebases — but they hallucinate more on large codebases because they're oriented toward solving bigger problems. Codex models are stronger at focused, well-scoped task execution; they're narrower and more conservative, slice by slice.

So the harness routes accordingly. Claude handles design reviews, novel architectural decisions, and cross-cutting reasoning. Codex handles the actual slice-by-slice code generation. Cross-model sign-off on high-risk work takes advantage of both: one model's blind spot is unlikely to be the other's.

The Minimum Viable Governance Stack

For teams looking to adopt loop engineering, Arikala outlines four things that aren't optional:

Define your own loop explicitly. What stages does a non-trivial change pass through? What does each stage produce? When does the loop stop and escalate instead of grinding? You're designing the feedback the model optimizes against — do it deliberately.
Static linters for automatic feedback. Start with the highest-value, incident-driven checks. Grow the set as you learn. These are the feedback the model gets without a human in the loop, on every single change.
End-to-end tests that drive the real system. Not fakes. Not mocks of internal components. Tests that exercise the actual running system from UI to backend and back. This is the single most effective defense against a green suite hiding broken code.
Design docs in the repo, versioned with the code. Design goals, constraints, architecture decisions, accumulated lessons — all of it lives in the repository. The model reads it at the start of every task. It writes back to it on completion. The next agent inherits the context instead of rediscovering it.

What This Points To

Arikala is clear-eyed about where this is headed. When any capable model can generate plausible code, generation becomes a commodity. The durable advantage is the encoded, accumulated judgment of what "correct" means in your domain — your harness and your control plane of documents. It compounds over time, it's portable across models, and it's hard to copy because it's distilled from your own incident history.

The engineer's role doesn't disappear. It moves up the stack. The high-value human work becomes defining what correct means, making the calls a model can't — product taste, risk tradeoffs, ethical lines — and owning accountability for what ships. Building and evolving the harness is, in Arikala's framing, the senior engineering job of this era.

The line he comes back to: writing the code was never the bottleneck. Trusting it is. And governance is how you earn that trust at machine speed.

Agents 2.0: What a Year of Actually Building Them Taught Us

Wed, 10 Jun 2026 15:00:00 +0000

Last year at Info-Tech LIVE, Martin Bufi warned the audience that agentic AI was overhyped and underbuilt. Seventy percent of organizations had launched agent pilots. Ninety percent were failing to return ROI. The gap between ambition and readiness was obvious.

Then the market did what the market does. It heard "autonomy" and ran with it.

Bufi, Principal Research Director at Info-Tech Research Group, opened this year's feature keynote with a viral cautionary tale. A developer using Meta's OpenClaw agent typed what seemed like a reasonable instruction: clear everything in the inbox older than February 15. The agent executed. Immediately. Hundreds of emails deleted. The human typed "do not do that." The agent kept going. "Stop don't do anything." Still going. "STOP OPENCLAW." The user had to physically kill every process on the host machine to get it to stop.

The agent later apologized. It acknowledged that it had acted without showing the plan first. Which, as Bufi noted, is not the same as not acting.

"Autonomy without architecture isn't innovation," he said. "It's chaos."

While that was happening at scale across the industry, Info-Tech took a different approach. They treated it as an engineering problem. Prototype fast. Measure everything. Ship only what clears the bar. After a year of work, the results: 13 prototypes, 63 agents built, 123 custom tools created, across five enterprise domains — finance, HR, IT, engineering, and retail. Average run time: 177 seconds. Average cost per run: $0.43.

Those numbers matter. Here's what produced them.

Story 1: The Whiteboard Week

Every prototype started the same way. Not with code. With a whiteboard.

Bufi described the moment that made this discipline non-negotiable. You ask five people how a workflow operates. You get five different answers. PDFs, emails, screenshots, spreadsheets — everyone has a different version of the process, and one of those people has been doing it the same way for 20 years with knowledge that lives entirely in their head.

"Standardizing the workflow is half the build," he said. "Before you automate it, map it. Before you map it, standardize it."

The IT service desk workflow Bufi walked through makes this concrete. What looks like a simple five-step process — intake, triage, routing, response, closure — carries layers of reasoning logic, edge cases, and data dependencies that only become visible when you document them explicitly. The agent can't handle what wasn't mapped.

One more thing they learned: generalist agents fail unpredictably. Every prototype Info-Tech built was multi-agent. An orchestrator delegates to specialists. An extractor pulls fields from documents. A validator checks data against rules. A router sends work to the right queue. An escalator flags exceptions for humans. "Not one genius agent," Bufi said, "but a team of simple ones."

Story 2: 123 Tools for 63 Agents

The model is the ceiling. Tools and architecture are the floor.

Info-Tech built 123 custom tools across their 63 agents. The real engineering work — the part that determines whether an agent actually performs in production — is in the integrations. An agent without tools is just a chatbot.

On safety, Bufi was direct: prompts alone aren't enough. They use three layers. First, narrow tools — give the agent a scalpel, not a Swiss Army knife. If it doesn't need delete access, it doesn't get delete access. Second, prompt instructions — useful guidance but not enforceable controls. Third, hard guardrails: structured validation on every call, blocking destructive operations at the software level regardless of what the model decides to do.

"That's like hoping your dog won't eat the food on the counter," he said of relying on prompts alone. "The hard guardrail is the one that guarantees it."

They also default to stateless design. Each agent run starts clean. No persistent memory across sessions unless the use case explicitly demands it. The reason is security: persistent state creates a surface area for prompt injection that compounds across runs. In a stateless architecture, if run 3 gets poisoned, run 4 starts clean. "Ninety-nine percent of agents work better this way," Bufi said. "Be deliberate about memory. Add it only when you have to."

Deployment follows microservice architecture. Each workflow is its own service. One workflow, one container. Triggered by webhook, cron, queue, or API. No monolith, no shared state, no single point of failure. When something breaks, you replace the service, not the whole system.

Story 3: The $0.43 Question

The governance conversation starts when someone asks: "What happens when this runs 500 times a day?"

At $0.43 per run, one workflow at 500 daily runs costs about $78K annually. Scale that to 25 workflows and you're at $2 million. That's not a surprise you want in a board meeting six months after deployment.

Info-Tech's governance framework answers three questions before any agent ships:

Can we afford it? Every run is costed. Not estimated — measured. Cost visibility is a deployment requirement, not an afterthought.

Can we stop it? Every agent is built with two and only two options when it hits ambiguity: consult a human, or exit gracefully. "There is no third option," Bufi said. "No fallback path, no deployment."

Can we improve it? They run continuous evaluations — not as a quality checkpoint, but as the development loop itself. One workflow went from 72% task completion accuracy on the first iteration to 96% by the third, through prompt rewrites, tool rerouting, and edge case handling. Evals aren't the finish line. They're how you get there.

Where Are You Right Now?

Bufi closed with three questions every builder should be able to answer before calling anything production-ready.

Can you draw the workflow end-to-end right now — not the happy path, but every edge case, every data dependency?

Does your agent fail safely when a tool goes down, or does it improvise a workaround you didn't design?

Do you know what last week's agents cost — and whether they were right?

If any of those made you hesitate, you know where to start.

The title of the talk was "Architect for Autonomy." The actual message was simpler: don't start with an agent. Start with a workflow. Build it with a method, not a vibe. And next year, come back with something deployed.

The AI Talent Shift: Why Shipping Intelligence Matters More Than Building Models in 2026

Fri, 03 Apr 2026 21:52:30 +0000

✍️ Article

If you still think AI/ML engineering is about building models, you’re already behind.

The industry has quietly shifted.

The real demand today is not for people who can train models — it’s for engineers who can ship intelligence into production reliably, repeatedly, and at scale.

What Actually Changed (And Most People Missed)

A year ago, “build a model” was impressive.

Today, that’s the easy part.

What matters now is execution:

Can it handle real-world messy data?
Can it scale to millions of users?
Can it stay reliable under edge cases?
Can it deliver measurable business impact?
AI is no longer a research problem. It’s a production engineering problem.

⚙️ The New AI/ML Engineer = Hybrid Builder

The engineers getting hired globally today are not just ML-focused.

They operate at the intersection of:

ML + Backend Systems
Data Pipelines + Distributed Systems
LLMs + Product Thinking
AI + Cost Optimization
They don’t just ask: “Which model is best?”

They ask: “What’s the most efficient, scalable, and production-ready solution?”

From working with global teams and observing hiring patterns, one thing is clear:
They don’t care about:

10 certificates
Fancy model names
Theoretical knowledge
They care about real impact:

✅ Production Experience

Have you deployed real AI systems? Can you monitor, debug, and improve them?

✅ System Thinking

Can you design end-to-end architecture? APIs, pipelines, latency, caching, scaling?

✅ Business Impact

Did your work increase revenue, reduce cost, or improve user experience?

✅ AI + Practical Engineering

Can you use LLMs, not just build models? Prompting, fine-tuning, evaluation, guardrails?

⚡ The Rise of “Applied AI Engineers”
A new category is emerging:

Applied AI Engineers

These are not researchers.

They:

Integrate APIs like GPT, Claude, and open-source LLMs
Build AI-powered features into real products
Focus on speed, iteration, and ROI
This is where most real-world hiring is happening right now.

The Skill Gap (And Opportunity)

Here’s the truth:

Thousands are learning AI. Very few can deliver production-grade AI systems.

That gap is your opportunity.

If you can combine:

Strong engineering fundamentals
Practical AI/ML usage
System design thinking
You’re not just another candidate — you’re a problem-solver companies will pay a premium for.

What Most Engineers Are Doing Wrong

hasing every new model release
Building toy projects
Ignoring system design
Avoiding real-world constraints
But real AI work is messy:

Bad data
Latency issues
Cost constraints
User unpredictability
That’s exactly where real engineers stand out.

My Perspective as an Engineer

As someone working deeply in frontend and scalable systems, one thing is clear:

The future is not: “Frontend vs AI”

It’s: “AI-powered products built by engineers who understand systems end-to-end.”

The most valuable engineers in the next 3–5 years will be those who can:

Bridge UI + AI
Build intelligent user experiences
Optimize performance across the stack

Final Thought

AI exposed the difference between:

Those who experiment
And those who deliver
And in the global market…

Only the second category gets hired.

# Why You Must Revisit the Stack Data Structure in the Age of AI

Sat, 24 Jan 2026 15:28:16 +0000

With the rise of AI-assisted coding, execution has become cheap.

You can let the AI do the wiring.
What you cannot delegate is the choice of abstractions.

And that changes everything.

If you choose the right abstractions, your system scales.
If you don’t, you don’t get “bad code” — you get semantic debt:
a pile of spaghetti whose behavior you no longer understand.

That’s why data structures matter more today than they did before.
Not because you must be able to implement them,
but because you must understand the semantic consequences of choosing one.

Those consequences often cascade far beyond what you intended.

Let’s see this with the simplest example possible.

The Stack Is Not Just a Stack

A stack is one of the simplest data structures we have.
So simple, in fact, that it exists physically in hardware.

CPUs implement stack pointers
Operating systems allocate a stack per process
Languages expose it implicitly via function calls and scopes

In C-like languages, opening a {} opens a stack frame.
When you exceed stack memory, the OS kills your program.
Even Stack Overflow is named after this exact failure mode.

You cannot write a program without a stack.

So far, nothing surprising.

But now track execution mentally.

If function A calls B, and then C, execution looks like this:

Enter A
Enter B
Exit B
Enter C
Exit C
Exit A

At runtime, the stack is a path.

But over time, the trace of execution forms a tree:

A is the parent
B and C are siblings

The stack is not “just LIFO”.
It is a traversal of a tree-shaped execution history.

This matters more than most developers realize.

Execution Leaves a Shape

Most developers are comfortable with stack behavior.
Far fewer are comfortable with closures — and this is why.

Closures break the illusion that execution is only a stack.

Consider this example:

const makeClosure = () => {
  let a = 10;
  function closure() {
    console.log(a);
  }
  return closure;
};

const myClosure = makeClosure();
myClosure(); // prints 10

Here’s the puzzle:

makeClosure() creates a stack frame
That stack frame exits
Yet a is still accessible later

So where is a?

It cannot be on the stack.
The stack frame is gone.

The only possible conclusion:

execution is no longer a simple stack.

What actually happens is this:

The stack is one branch of a larger execution tree
Closures preserve parts of that tree after the branch collapses
Variables escape time, not scope

Once you understand this, async functions, promises, callbacks,
and event-driven runtimes stop feeling magical.

They are not “stack tricks”.
They are graph-shaped execution.

Why You Should Care

In an age where any of us can spin up a workforce in the form of AI agents,
the real challenge is no longer writing code — it’s scaling systems.

People sense this intuitively.
That’s why they keep building frameworks, layers, and tooling
with increasing internal complexity.

Frameworks consume your code — or AI-generated wiring —
and impose their own abstractions and limitations.
That is precisely where architectural decisions become irreversible.

Here’s the key point:

Seeing the stack as the active trunk of an execution tree
is the mental model behind virtual machines,
language runtimes,
and frameworks themselves.

If you don’t understand the semantic consequences of your data structures,
you are outsourcing architecture to tools
that don’t pay the cost when things go wrong.

I’ll write more about this using concrete examples
from a VM I built using exactly this perspective.
As a preview: it supports async pipelines natively —
but more on that later.

AI capabilities outrank cloud compatibility as the top criterion observability platforms.

Wed, 08 Oct 2025 11:29:12 +0000

AI-Powered Observability: What Developers Need to Know in 2025

The relationship between observability and AI is evolving rapidly, according to Dynatrace's State of Observability 2025 report. For developers and engineers, this shift represents both opportunity and challenge as observability transforms from a reactive operations tool into a proactive development necessity.

AI Becomes the Top Priority

For the first time in observability survey history, AI capabilities (29%) now rank as the most important factor when selecting observability platforms—surpassing traditional criteria like cloud compatibility (27%) and ease of data collection (21%). This dramatic shift reflects how developers increasingly rely on AI to manage the complexity of modern cloud-native architectures.

While 100% of surveyed organizations have adopted some form of AI, adoption remains concentrated in specific use cases. Data management leads at 57%, followed by AI governance (50%) and security operations (46%). Only 32% currently use AI in their observability programs, but this represents a significant growth area as teams recognize observability's role in making AI systems explainable and reliable.

The Investment Surge

Organizations are backing their AI and observability priorities with real budget increases. Seventy percent of respondents report observability budget increases in the past year, and 75% expect further increases next year. This investment reflects observability's expanding role beyond traditional IT operations into security, compliance, sustainability, and business analytics.

Current observability use cases span application performance optimization (59%), cloud application monitoring (57%), and security incident management (57%). However, the expected ROI from AI-powered observability focuses on optimizing model configurations (46%), automating remediation (41%), and detecting anomalies in model outputs (39%).

Trust and Transparency Challenges

Despite widespread AI adoption, trust concerns persist. Cybersecurity (41%) and data privacy (36%) top the list of AI usage concerns, followed by data quality (33%) and integration difficulties (29%). These concerns drive a cautious approach: humans verify 69% of AI-powered decisions, and 99% of AI governance leaders report taking human-monitored measures to validate AI decisions.

This verification requirement creates opportunities for developers. Observability platforms that provide clear explanations of AI decision-making processes become essential tools. Seventy percent of AI governance leaders report budget increases for AI trust and transparency initiatives, signaling sustained investment in making AI systems auditable and explainable.

Security Convergence

The convergence of observability and security creates new responsibilities for development teams. Ninety-eight percent of security leaders use AI to manage security compliance in some capacity, with 69% seeing increased budgets for AI-powered threat detection.

For developers, this means security considerations must be built into applications from the start. By 2030, organizations expect 50% adoption of AI-powered data encryption, risk assessments, and threat detection capabilities. AI-powered threat detection and automated patching are expected to double adoption rates within five years.

DevOps Automation Evolution

Real-time DevOps automation is expanding rapidly, with up to 50% of organizations currently using automation across various use cases. Mitigating security risks (49%) and real-time anomaly detection (50%) lead current adoption, with expectations to reach 70% within five years.

This automation trend introduces agentic AI—systems that can autonomously plan and execute tasks within guardrails. For developers, this means observability becomes crucial for ensuring safe agent behavior, monitoring model performance, and maintaining system health. The survey identifies detecting and mitigating security risks as the automation use case with the highest expected ROI (41%).

Sustainability and Efficiency

Environmental sustainability emerges as another key focus where observability proves essential. Seventy percent of organizations pursuing sustainability initiatives use observability platforms to monitor energy consumption, track emissions, and manage ESG-aligned operations in real time.

For developers, this creates opportunities to optimize code for energy efficiency. Energy-efficient software development is expected to grow from 28% adoption today to 51% by 2030. Observability platforms that translate utilization metrics (CPU, memory, network I/O) into energy usage and carbon emissions help developers understand the environmental impact of their code.

Business Observability

Perhaps the most significant shift is observability's evolution from IT tool to business capability. Only 28% currently use AI to align observability data with business KPIs, but 29% cite AI capabilities as the most important factor in observability solutions. This gap represents both a challenge and opportunity.

Developers who can connect their work to business outcomes gain strategic value. Observability platforms increasingly enable this connection by providing real-time insights into how technology impacts customer experience, operational performance, and financial efficiency.

What This Means for Developers

The convergence of AI and observability creates several imperatives for developers:

Build observability in from the start: With AI capabilities now the top platform selection criterion, teams that treat observability as an afterthought will fall behind.
Focus on explainability: As humans verify 69% of AI decisions, code that provides clear reasoning and audit trails becomes essential.
Embrace automation with guardrails: Real-time automation is expanding, but developers must ensure safe, monitored behavior.
Connect to business outcomes: The shift toward business observability means developers need to understand how their code impacts KPIs.

The State of Observability 2025 reveals that AI and observability are no longer separate concerns but converging capabilities that enable modern software development. Organizations that successfully unify these practices will lead the next wave of enterprise innovation.

CData solves the API nightmare: one MCP connection gives your AI agents live read/write access.

Wed, 24 Sep 2025 12:20:46 +0000

CData's Connect AI Gives Developers Direct LLM Access to 300+ Enterprise APIs

Building AI applications that actually work with enterprise data has been a nightmare. You either spend months building custom integrations for each data source, or you copy sensitive data somewhere it doesn't belong and deal with security teams breathing down your neck.

CData Software just launched Connect AI, and it changes the game completely. Instead of building individual API connections to Salesforce, NetSuite, JIRA, and dozens of other enterprise systems, developers get one unified interface that handles everything.

The Technical Reality Check

Here's what most AI projects look like today: product manager wants an AI assistant that can analyze sales pipeline data from Salesforce, support tickets from JIRA, and financial data from NetSuite. As the developer, you're looking at three different API documentation sets, three different authentication systems, and three different data models to normalize.

Connect AI eliminates this complexity through the Model Context Protocol (MCP). You configure your enterprise connections once through OAuth, and every system looks the same to your AI application. The LLM can write SQL queries against any connected system, whether it's a CRM, ERP, or help desk platform.

"AI needs to comprehend what data means, not just where it lives," says Manish Patel, CData's Chief Product Officer. The platform exposes complete metadata from source systems, so your AI agents understand field types, relationships, and constraints without you having to map everything manually.

Real-World Implementation

Bhavik Paryani from Paryani Construction connected their ERP system and describes the impact: "I was able to pull live financial data and create an interactive dashboard right in the middle of a project meeting." This isn't about building static reports—it's about giving AI applications the context they need to answer questions you didn't anticipate.

The technical architecture preserves data in place. Instead of ETL processes that copy information into data warehouses, your AI queries hit source systems directly. This means real-time data access without the security headaches of data replication.

CData handles the hard parts: API rate limiting, pagination, error handling, and performance optimization. Your application gets consistent SQL interfaces across 300+ different enterprise systems.

Developer Experience Details

The setup process reveals how much complexity CData abstracts away. Traditional enterprise integrations require understanding each system's API quirks, authentication methods, and data structures. With Connect AI, you authenticate once through standard OAuth flows, and the platform generates MCP server URLs.

Your AI application connects to these MCP endpoints using standard protocols. Whether you're building with Claude, ChatGPT, or custom LLM frameworks, the integration looks identical across all enterprise systems.

The platform supports both read and write operations. Your AI agents can query data, update records, create new entries, and trigger actions like closing support tickets or updating project statuses. All through the same unified interface.

Performance and Scale Considerations

CData built this on top of a decade of enterprise connectivity experience. Their connectors have processed 59 trillion read queries and 132 billion write queries across thousands of real-world deployments. This isn't experimental infrastructure—it's battle-tested technology reimagined for AI workloads.

The performance optimization matters for AI applications. The platform handles query pushdowns, parallel paging, and streaming modes. When your AI agent needs to analyze large datasets, these optimizations prevent timeout issues and reduce token consumption.

Security inheritance is another technical advantage. Instead of creating new permission systems, Connect AI respects existing enterprise access controls. If a user can only see certain Salesforce records, your AI application inherits those same restrictions automatically.

Integration Patterns

Two deployment models serve different use cases. Direct enterprise customers connect their internal systems to AI assistants for business intelligence and workflow automation. Software vendors embed Connect AI to give their products access to customer data without requiring complex onboarding processes.

The embedded model is particularly interesting for developer tool companies. Instead of asking customers to set up integrations themselves, you can offer pre-built connections to their business systems. Your AI-powered application gets complete context about their organization without them leaving your platform.

CData's existing embedded relationships with companies like Palantir, SAP, and Google Cloud demonstrate this approach at scale. These aren't simple API partnerships—they're deep integrations that handle enterprise-grade requirements.

Market Timing and Technical Evolution

The launch timing aligns with MCP adoption and the shift toward agentic AI. CData already released beta MCP servers that attracted 1,600+ developers, validating demand for enterprise data connectivity in AI applications.

The beta program revealed usage patterns: daily queries across multiple systems, heavy read operations, and growing write activity. Connect AI takes these learnings and packages them into a managed service that eliminates the installation and maintenance overhead.

"We're in early innings of agentic AI," notes Patel. Current applications focus on conversational analytics—users exploring data through natural language. The next evolution involves autonomous agents that take actions based on data insights, which requires the deep connectivity that Connect AI provides.

Implementation Considerations

Connect AI launches immediately with cloud and embedded deployment options. Pricing follows CData's existing connector model, though specific AI pricing hasn't been disclosed.

For developers evaluating the platform, the key question isn't whether it works—CData's track record speaks for itself. The question is whether unified enterprise connectivity justifies the vendor dependency versus building custom integrations in-house.

Given the complexity of maintaining 300+ different API connections, plus the security and compliance requirements of enterprise data access, the build-versus-buy decision seems clear for most development teams.

The platform represents a fundamental shift in how AI applications access enterprise data. Instead of treating integration as a necessary evil, Connect AI makes comprehensive data connectivity a competitive advantage.