01 · Agents & tool use
Systems that act, not just answer
Orchestration, the Model Context Protocol, permission policies, and the failure modes that only appear once an agent can change something.
MCP · orchestration · permissions
Rahman MD · Software & AI systems
Making AI useful is an engineering problem.
Notes on agents, retrieval, evaluation, and the unglamorous work of putting language models into production.
Make it useful. Make it understandable.
I'm Rahman — a software engineer who builds software end to end with generative AI: from spec to tested, deployed, monitored production systems, with coding agents doing the typing and me owning the decisions. I write about what actually holds up when a model meets real data, real users, and real consequences.
Open to AI engineering roles — applied LLM systems, agents, and end-to-end AI-built software
Latest note
Oct 2026 · 9 min
How I build software end to end with generative AI
Agents write most of the code. I own the spec, the tests, the deploy, and the post-mortem. The loop and the guardrails.
Read the noteWhat I write about
Four threads, one question: does it work in production?
Demos are easy. The interesting problems start when a model has to act on real data, inside real constraints, for people who did not write the prompt.
02 · Retrieval & context
What goes in the window
Retrieval as a ranking problem, compaction, citations as a contract, and why a million-token context is a capability rather than a strategy.
RAG · context engineering · grounding
03 · Evaluation
Measuring before and after shipping
Golden sets, trace review, regression gates on every prompt or model change, and the handful of metrics that predict whether users will trust the thing.
evals · trace review · regression
04 · The industry
What the labs shipped, and what it changes
A monthly reading of model releases, platform changes, and agent products — written for the people who have to build on top of them.
monthly · releases · platform notes
How I build
End to end with generative AI — from idea to production.
I build and run real systems with AI coding agents: an algorithmic trading platform with market-data services, broker integrations, a serverless bot on AWS, and operator dashboards — plus this site and an Entra ID access-control lab. The agent types; I decide, verify, and ship.
01 · Research & specify
Plan before code
The agent first explains why the current behaviour exists and proposes a prioritised plan. I write the task with the outcome, the limits, and how we will know it worked.
specs · repo instructions · context
02 · Build
Agents in isolation
Work happens in a separate git worktree, never in the checkout live processes run from. Front end, APIs, data model, and cloud resources in one pass.
Claude Code · MCP · Node.js · AWS
03 · Verify
Evidence, not enthusiasm
Tests for the code, and replays against real historical data for anything with consequences. Most ideas stop here — that is the system working.
tests · replays · evals
04 · Ship & operate
A human gate, then ownership
I review the diff, push, and restart. Then dashboards, first-run checks, and written post-mortems that turn each incident into a rule.
CI/CD · monitoring · post-mortems
Latest writing
Notes from building with language models.
October 2026 in AI, week one: small models, cheaper caches, agents with an email address
Claude Haiku 5.5 with a 1M-token context, Sonnet 5.5 cache reads at half price, Mistral Large 4 in preview, Google's Gemini agent with its own workplace identity, and Anthropic narrowing what agents may fetch. What changed in the first nine days of October, and what I would do before month end.
Read the updateIn this note
- Small models got serious
- Agents got identities and audit trails
- Platforms are hardening the defaults
- A four-item checklist for October
September 2026 in AI: the month agents got their own computers
Opus 5.5 and Sonnet 5.5, GPT‑6 Astra, OpenAI's always-on Dots, and Anthropic's disclosure that Claude leads a quarter of its own R&D.
IndustryAgents
The evaluation gap: why agent demos don't survive production
A working demo tells you the happy path exists. An eval tells you how often you find it. How to build the golden set, grade traces, and gate every change.
EvaluationAgents
Human-in-the-loop is a design decision, not a disclaimer
Three review patterns, a two-axis rule for choosing between them, and how to make the human step cheap enough that people actually do it.
AgentsDesign
Context engineering: a bigger window is not a strategy
What belongs in the context, what stays out, how to measure retrieval on your own questions, and what to preserve when you compact a long conversation.
RetrievalContext
How I think about AI
A good prompt is table stakes. The system around it is the product.
Six rules I keep coming back to, whether the project is a document assistant, a tool-using agent, or a pipeline nobody will ever see.
-
Start from the decision, not the model
Name the decision the output will drive and who makes it. The model, the prompt, and the retrieval all follow from that.
-
Ground every claim in something retrievable
If the answer can't point at a source the user can open, it is a guess. Design so the guess is visible.
-
Measure before you ship, then keep measuring
An eval set of fifty real cases beats a hundred opinions. Run it on every prompt, tool, and model change.
-
Keep humans where the consequences are
Approval gates belong where actions are hard to reverse. Everywhere else, make review cheap and sample it.
-
Prefer the smallest model that passes the eval
Capability is bought per token. Spend it where the eval says it matters, and route the rest somewhere cheaper.
-
Write it down so the next person understands it
Prompts, tool schemas, and permission policies are code. Version them, review them, and explain the why.
About
Curious by nature. Focused on useful work.
I'm a software engineer with a background in web applications, API integrations, and automation. Over the past few years that work has shifted toward AI systems: language models, retrieval, tool-using agents, and the evaluation and review processes that make them trustworthy enough to rely on.
I write here to think clearly and to share what I learn while building. The posts are opinionated but grounded — when I describe an industry change I link the source, and when I describe a practice it is one I have actually used or tested.
These days I build most software end to end with AI coding agents — my own algorithmic trading platform, its data services and dashboards, and this site among them. The agent writes most of the code; I own the specification, the review, the tests against real data, the deploy, and the post-mortem when something breaks. Here is how that works.
If you're hiring for a role where AI has to work, not just demo, I'd like to hear from you. I'm happy to walk through any of the ideas on this site in more depth, and I share my resume on request.
Get in touch
Hiring, collaborating, or comparing notes?
Email is the fastest way to reach me. I reply to every message about AI engineering roles, projects, and the writing here.
rahman2k8@gmail.com · I share my resume by email rather than as a public download — the request link opens a pre-filled message.