Need to play with next version @angular v14. Some of good addition added to latest release 🥳.

Current PDF viewers weren't designed for the AI era. We have to reimagine them. Open a two-page invoice and every viewer feels identical. Then try reading 300 pages while cross-referencing twenty sources, following a citation from page 12 to page 340 and back again — and the whole thing starts to grind. The viewer isn't broken. It was built for a world where you read one document at a time. That world is gone. AI made our thinking faster. The reader never caught up. Page count is where it shows. Ten pages, everything's smooth. Three hundred and it crawls. A thousand-page report or a dense scan, and the experience collapses — so you build little rituals around it. Close the tabs. Wait for it to settle. Scroll slowly. Don't jump to page 240. That's not a user problem. It's a design problem. So I stopped asking how to make a viewer render faster, and started asking whether we've been looking at documents the wrong way entirely. I think we have. It's the question I keep coming back to. But I'd rather learn from real habits than guesses. So: what do you use to read PDFs? Not the one you'd recommend in a meeting — the one you genuinely open every day. And what's the one thing it does that quietly annoys you, especially with big files? I read every reply. #PDF #BuildInPublic #UX #Performance #ProductDesign

I've spent years building UI, and the hardest part was never the code. I came up in frontend — websites, apps, more screens than I can count. Then five-plus years working with LLMs and turning ideas into things that actually ship. The lesson that stuck has nothing to do with models or frameworks. People don't remember your stack. They remember how it felt to use what you built — capable, or stuck. So when I build now, I spend my time on that. The feeling of it, not just the function. That's the bar I'm holding my own work to. If you're early in your journey or deep in a build right now: keep going. The empathy is the part that takes time, and it's the part that makes the work matter. What's the last product that made you feel genuinely capable? #BuildInPublic #AI #UX

🌟 Turning Challenges into Opportunities 🌟 When we’re thrown into a difficult situation, it’s easy to feel stuck. But those moments often hide new paths and push us past our usual limits. I’ve decided to take on a fresh challenge—not just to prove I can handle it, but to show what I’m truly capable of. A wise man once said, “Showcase your strengths so your weaknesses go unnoticed.”  Let my strengths lead, let the experience shape me, and let the results speak for themselves. 🚀 Exciting news: I’m ready to showcase what I’ve built. Stay tuned—I’ll be unveiling a new project/initiative soon! #GrowthMindset #Leadership #ContinuousImprovement #Innovation #SelfDevelopment #NewBeginnings

It's time to become "The boss". Change is coming.

The most sustainable way to build is to be honest about the struggle. No hype, just the process.

Shipped an LLM feature. Invoice arrived. Still couldn't tell you which customer spent what. This is the common case in 2026, not the exception. Most teams I talk to don't have a clean answer. The fix isn't a dashboard. It's six fields tagged at the call site: user_id, customer_id, feature, deployment, prompt_version, agent_run_id. Provider logs strip context. Post-hoc parsing breaks. Three failure modes from real incidents: → Runaway agent loops — retry-on-malformed-output billing tokens until a guard fires → Retry storms — SDK retries on transient 503s that the app never sees but the bill catches → Context bloat — a longer system prompt moves cost-per-request before total spend looks wrong Pricing is the second problem and it's worse than people think: • Reasoning tokens → 30–40% undercount if you only count visible output • 128K context crossing → silently 2x's per-token price, no signal in the response • Same model, different prices per host (Kimi K2.5: $0.5/$2.8 Together, $0.6/$3 Fireworks) Tooling is catching up. Cloudflare AI Gateway shipped dollar-budget limits in June 2026, scoped per model/provider/attribute. Portkey open-sourced their 3,500-model pricing DB. Langfuse v4 exposes cost_details per observation, queryable by tag. FinOps Foundation 2025: AI spend management jumped from 31% to 63% of practitioners YoY — the largest one-year swing in the report. Tag at request time. Enforce at the gateway. Then you can answer the question. How is your team attributing token spend today?

The hard part is no longer code generation. AI coding agents are moving into PRs, review gates, tests, security constraints, and measurement. That’s the right direction. GitHub routes Copilot agent work through PR review. SWE-bench keeps pushing toward more realistic evaluation. OWASP now treats things like prompt injection, supply-chain exposure, and excessive agency as real risk areas for LLM systems. That tells me the important question has changed. Not: “can the agent write code?” But: “can the team safely absorb the code it writes?” The useful work is in the control loop: permissions, evals, review requirements, logs, rollback paths, and honest measurement of whether the system actually got better. Agents will improve. But better output does not remove the need for better engineering boundaries.

Agents need guardrails, not mythology. AI coding agents are starting to look less like “autonomous engineers” and more like constrained contributors: useful on scoped issues, tests, docs, bug fixes, and cleanup. That’s not a downgrade. That’s how software works. The current signal is pretty consistent: developers are using AI tools, but still spend real time checking, debugging, and reviewing the output. DORA’s 2025 report put it well: AI amplifies the system you already have. It doesn’t fix the system for you. So the practical question is not “can the agent build the feature?” It’s: did we give it a small enough task, enough context, automated tests, CI, code review, and a clear boundary where a human still owns judgment? The boring workflow is the product feature.

AI observability needs shared language. Once an AI request goes through a gateway, router, retry, fallback, tool call, and model provider, “check the logs” stops being a debugging strategy. You need to see the production path as one logical operation. That’s why OpenTelemetry’s GenAI semantic conventions are interesting. They define spans, metrics, and events for AI clients, model calls, agents, tools, token usage, latency, and more. The important bit: this is not just tracing an HTTP request. The GenAI span is meant to represent the logical AI operation, including automatic retries when they happen. The spec is still marked Development, so version carefully. But the direction is right. AI runtime behavior is getting more dynamic. The telemetry should get more standard, not more bespoke.

Agents need permissions, not vibes. The moment an AI agent can call tools, read data, or change systems, it becomes a runtime actor — not just a prompt wrapped around a model. That means the security questions change. Who is the agent acting for? Which tool is it allowed to call? What scope does it have? Was this action authorized now? Can we audit the decision path later? This is where least-privilege tool access starts to matter. OWASP guidance points to scoped tools, allowlists, and auditability. NIST is actively looking at identity and authorization for AI agents. MCP authorization is moving toward OAuth-style patterns. Different efforts, same direction: agents need identity, policy, and logs near the execution boundary. A gateway/proxy layer is a practical place to enforce that before tool calls happen — instead of burying policy inside every agent implementation.

Agents need brakes before they need speed. The useful shift in production AI agents is from “how smart is the model?” to “what is this system allowed to do?” That’s where the real risk shows up: tool calls, external systems, permissions, irreversible actions. You can see the pattern across the stack now. OWASP has agentic AI threat guidance. AWS Bedrock Agents, OpenAI Agents SDK, and LangChain all support human approval before sensitive tool calls. MCP authorization is pushing toward scoped access. Tracing is becoming a runtime primitive, not a nice-to-have. That points to a simple rule: if an agent can act, policy needs to sit before execution. Allowed tools. Scoped permissions. Audit trails. Approval gates. Kill switch. Boring controls first. Demos second.

I just reserved my Cloudflare Wallet tag: althaf.cloudflare.pay. Reserve yours now at cloudflare.pay

Agents make API governance more granular. It is no longer enough to ask: “Can this app call this endpoint?” Now the runtime needs to know which agent is acting, who delegated authority, which tool was invoked, what resource the token is valid for, and whether the whole path can be audited later. That is why MCP, OAuth, workload identity, and API gateways are converging. MCP authorization is moving toward familiar OAuth patterns: resource servers, resource metadata, audience binding, and explicit confused-deputy guidance. The interesting shift: gateways do not go away. They move up from route control to tool-invocation control. Agent-native infra still needs policy, identity, quotas, and traces. It just needs them at the level where agents actually act.

The AI gateway is becoming the LLM SRE layer. A lot of AI architecture talk still starts with the model: provider, context window, benchmark, price. But production pain usually shows up one layer earlier. Quota walls. Provider errors. Runaway token spend. Prompt abuse. Requests that need to be blocked before they hit a model. Debugging whether latency, cost, policy, or provider health caused the issue. That’s why AI gateways are converging around routing, caching, retries, fallback, rate limits, observability, and policy enforcement. This is not just API management with a new label. LLM traffic has its own failure modes: token-based cost, context limits, content-policy errors, multi-provider routing, and workload-specific tradeoffs across cost, latency, quota, capability, and policy. The model creates the experience. The gateway increasingly decides whether it survives production.

Agents need identities, not just API keys. Once an AI agent can read data, call tools, and change state, it is no longer “just a prompt.” It is a production actor. That changes the security model. NIST is looking directly at agent identity, authorization, auditing, and ways to constrain + monitor agent access. OWASP’s agentic guidance emphasizes least-privilege tools and step-up auth for high-impact actions. The big cloud platforms are converging on the same idea: treat agents as first-class principals, give them scoped permissions, avoid shared static keys, and make every tool action attributable. More autonomy without identity is just a bigger blast radius.

LLM cost control belongs in the request path. AI spend gets weird because cost is not tied cleanly to “one request.” A user action can fan out into long prompts, tool calls, retries, memory/context, cached inputs, and variable output length. The invoice tells you what happened too late. A better control point is runtime: - tag every call by user, feature, team, model, prompt version, token type, cache status - cap output where possible - route routine work to cheaper models - reserve expensive models for tasks that need them - alert on anomalies before the bill lands This is why an AI gateway should be more than a proxy. It can be the place where routing, observability, caching policy, and budget enforcement converge.

Benchmarks are not production coverage. Offline evals matter. But once an agent can use tools, retrieve data, call APIs, hand off work, or take actions, a benchmark score is only the starting line. The weird failures usually happen in the runtime path: wrong tool, bad arguments, failed retrieval, unsafe action, looping, silent quality drift. That’s why serious agent systems need traces, online evals, tool-call monitoring, alerts, human review samples, and regression checks. The ecosystem is already moving there: OpenAI Agents SDK traces tool calls and guardrails; LangSmith and Phoenix support production tracing + online evals; OpenTelemetry is adding GenAI/MCP conventions. Offline evals tell you whether known cases still pass. Runtime observability tells you what the agent actually did.

Agent memory is production data. “Memory” sounds like personalization. In an agent system, it is more than that: chats, preferences, files, tool outputs, inferred facts, prior decisions, and sometimes the context that drove an action. That is a persistent data system attached to a reasoning loop. The controls are boring for a reason: consent, visibility, deletion/export, retention limits, least-privilege access, and audit trails for memory changes and tool actions. This lines up with where AI governance is already going: EU AI Act logging/oversight, NIST AI RMF lifecycle risk management, ISO/IEC 42001 management systems, and OWASP’s focus on prompt injection, sensitive disclosure, insecure plugins, and excessive agency. If an agent can remember and act, memory is not UX sugar. It is governed infrastructure.

Prompt injection gets worse with tools. Against a chatbot, prompt injection is mostly a content-safety problem. Against an agent that can read data, call APIs, approve actions, or trigger workflows, it becomes an infrastructure problem. OWASP’s 2025 LLM Top 10 still ranks prompt injection as the #1 LLM app risk. It also calls out indirect prompt injection from websites, files, docs, and external content — and notes that impact scales with the agency granted to the model. So the control point can’t just be “write a better system prompt.” You need policy in the runtime path: screen prompts and tool responses, constrain tools by identity, log decisions, require approvals, and block requests outside policy. That’s the security case for AI gateways. The model can reason. The gateway decides what the system is allowed to do.