Forem: Hooman

🧠 Context Engineering: The Skill That Actually Makes AI Work

Hooman — Fri, 24 Apr 2026 15:59:00 +0000

Every time you send a message to ChatGPT, Claude, or any LLM, it forgets you exist. No memory of your last conversation. No context from before. Nothing. The only way it “knows” who you are is if you re-introduce yourself. Every. Single. Time. That is not a bug. That is the problem context engineering solves.

Most people blame the model when AI gives garbage outputs. Wrong diagnosis. The model is not the problem. The context is. Everything an LLM needs to answer your question must be sent WITH your question. Understanding this one thing will change how you work with AI.

Context has 4 building blocks. Think of each as a dial you can tune.

1/ Memory

Your conversation history and preferences. The catch? LLMs have limits. Long conversations get summarized, and that is when “drift” happens. You start repeating yourself. The AI forgets your rules. That is not the model getting dumber. That is imperfect memory management.

2/ Files

Documents, screenshots, PDFs fed directly into the context. Hot tip: drop a screenshot into ChatGPT and ask it to build a prompt from it. Works shockingly well.

3/ RAG (Retrieval Augmented Generation)

Before your question hits the LLM, smart systems quietly search a knowledge base and stuff relevant results into the context alongside it. That is why internal AI chatbots can answer questions about your specific products. Not magic. Retrieval.

4/ Tools

The LLM does not execute tools. It tells your system WHAT to run. Your system runs it, stuffs the result back into the context, and THEN the model answers. Tool calling is the AI directing traffic, not doing the work.

Most people treat prompts like a black box. Throw stuff in, hope for the best.

But when you see memory, files, tools, and prompt structure as separate levers, you stop guessing and start engineering.

The 6 prompt components that actually matter:

✓ Role: “You are an expert in...”

✓ Personality: tone and style

✓ Request: the actual task

✓ Format: be explicit (bullets, JSON, table)

✓ Examples: two good, two bad works wonders

✓ Constraints: “never do X”

Most people only use the Request and skip the other five.

Here is the bigger picture.

Context engineering is not just for developers building agentic systems. It is a thinking skill.

When you learn to structure information so a machine can reason over it accurately, you get better at structuring information for humans too. Clearer writing. Clearer thinking. Clearer communication.

Context is not a setting you configure once. Context is everything you send.

Get that right and the model almost does not matter.

Are you still treating AI like a magic black box, or are you already thinking about context?

Drop a comment. I am curious where people are at with this.

Originally posted on my Substack

Google Just Upgraded Its AI Research Agent, and It's a Big Deal

Hooman — Fri, 24 Apr 2026 15:42:17 +0000

Google DeepMind announced two significant evolutions of its autonomous research agent: Deep Research and Deep Research Max. Both are built on Gemini 3.1 Pro, and together they represent a meaningful shift in what AI-assisted research can actually do at a professional level.

If you’ve been following the AI space, you’ll know that “research agents” have been a hot topic. But most of them still feel like glorified summarizers. Google is making a credible case that it’s moving past that.

From Summarizer to Research Engine

When Google first released the Gemini Deep Research agent to developers back in December 2025 via the Interactions API, it was already impressive. But the team describes the new version as a transformation from “a sophisticated summarization engine into a foundation for enterprise workflows.” That’s not just marketing language. The new agents are designed to support real-world use cases in finance, life sciences, and market research, producing fully cited, professional-grade analyses from a single API call. The key upgrade? The ability to blend the open web with proprietary data streams, which changes the game significantly for enterprise users.

Two Agents, Two Use Cases

Google is now offering two distinct configurations. Deep Research is the speed-optimized option, built for interactive user surfaces where low latency matters. Think of it as the version you’d embed directly into a product that a user is actively engaging with. Deep Research Max is the heavy-duty option, using extended test-time compute to iteratively reason, search, and refine its output. Google specifically positions it for asynchronous, background workflows, like a nightly cron job that generates exhaustive due diligence reports for an analyst team by morning.

MCP Support, Native Charts, and Multimodal Inputs

Three new capabilities stand out. First, Model Context Protocol (MCP) support is arguably the most significant addition. Deep Research can now connect to custom data sources and specialized professional data providers (think financial data, market intelligence platforms) securely via MCP. This turns it from a web searcher into an autonomous agent capable of navigating any specialized data repository you point it at. Google is already collaborating with FactSet, S&P Global, and PitchBook on their MCP server designs.

Second, native charts and infographics are new for the Gemini API. The agent now generates high-quality charts and infographics inline with HTML, dynamically visualizing complex data sets within the report itself. That’s a meaningful step toward presentation-ready outputs.

Third, multimodal research grounding means you can feed the agent a mix of PDFs, CSVs, images, audio, and video as input context. Combined with Google Search, URL context, code execution, and file search running simultaneously, the tool is starting to look like a genuine research analyst rather than a chatbot with a search button.

Collaborative Planning and Real-Time Streaming

Two other additions are worth noting for developers and product builders. Collaborative planning lets you review and refine the agent’s research plan before it begins execution, giving you granular control over scope. This is critical in regulated industries where you need to know exactly what the agent is and isn’t looking at. Real-time streaming, meanwhile, lets you track the agent’s intermediate reasoning steps live, with thought summaries and outputs arriving as they’re generated, which is a much better experience than waiting for a finished report to land.

The Enterprise Bet

What’s clear from this announcement is that Google is making a serious enterprise play. The focus on finance and life sciences, the partnerships with FactSet, S&P Global, and PitchBook, and the emphasis on factuality and source diversity all point to a product team working in regulated, high-stakes environments. Google also notes that Deep Research already powers research capabilities inside the Gemini App, NotebookLM, Google Search, and Google Finance, which is a meaningful signal about the maturity of the underlying infrastructure.

Deep Research and Deep Research Max are available today in public preview via paid tiers in the Gemini API, with Google Cloud availability for startups and enterprises coming soon. If you’re building research-heavy products or workflows, this is worth a close look.

Originally posted on my Substack

How I learn in the age of Ai coding

Hooman — Fri, 24 Apr 2026 15:39:23 +0000

There is a strange thing that happens when AI starts writing your code for you. You might assume learning slows down. That you become passive. That you are just a prompt monkey, copy-pasting outputs and shipping features without really understanding what is going on under the hood.

That has not been my experience at all. At least not anymore.

If anything, I am learning differently now, and in some ways more richly than before. The topics I am picking up are not always the ones I expected to care about. But they are sticking, and they are making me a better builder. Let me explain what I mean.

The AI Codes, But I Still Have to Understand the Problem

When I work with an AI coding assistant, the code gets written fast. But bugs still surface. Edge cases still bite. And when something breaks, I still have to diagnose it. That diagnosis process is where a lot of my learning now lives.

A recent example: I was building a text-to-speech (TTS) feature. The AI scaffolded the whole thing quickly. But then things started going wrong in ways I did not immediately understand. Fixing those issues sent me down some genuinely interesting rabbit holes.

Learning About TTS Input Length Limits and Chunking

The first thing I ran into was that TTS APIs have input length limitations. Most of them cap how much text you can send in a single request. When I fed a long block of content into the API, it either failed silently or threw an error I did not immediately recognize.

The AI could generate a chunking solution for me, and it did. But to actually steer it toward the right solution, I had to understand the problem first. What counts as a “chunk”? Do you split on character count, word count, or sentence boundaries? What happens if you split mid-sentence? Does the audio sound jarring at the seam?

I learned that splitting on sentence boundaries produces much cleaner audio output. I learned about the tradeoffs between chunk size and API latency. I learned how to think about reassembling audio segments in the right order. None of this was in the original feature spec. All of it came from debugging a problem the AI helped create and then helped solve.

Learning About Markdown and Special Characters in TTS

The second rabbit hole was even more interesting. When you pipe markdown content directly into a TTS engine, it reads everything. And I mean everything. The asterisks. The pound signs. The underscores. The hyphens used as bullet points.

Suddenly your clean article gets narrated as “asterisk asterisk important asterisk asterisk” and the whole thing sounds broken. This is not a bug exactly. It is just a mismatch between how markdown is structured for visual rendering versus how raw text is processed by a speech engine.

To fix it, I had to learn about stripping markdown before passing text to TTS. There are libraries that help with this, and the AI pointed me toward them. But understanding why the problem existed, and what categories of characters cause issues, meant I could write better prompts the next time. I could tell the model exactly what I needed: strip headers, remove emphasis markers, preserve sentence structure, handle code blocks gracefully.

That kind of specific instruction only comes from having gone through the problem once.

Learning About Porosity

This one came from a completely different project but the same pattern. I was working on something that involved understanding how materials or data structures “breathe,” for lack of a better word. How things pass through layers. The concept of porosity came up, and because the AI was doing the implementation, I had the mental space to actually sit with the concept rather than rushing to write code.

I looked it up. I read about it. I let myself get curious about it in a way that I might not have if I had been heads-down in syntax.

That is a real benefit of AI-assisted development that does not get talked about enough. When the mechanical parts of coding are handled, you get cognitive headroom to actually learn the domain you are building in.

How This Changes the Way I Work Next Time

Here is the part that matters most to me. Every one of these learning moments, TTS chunking, markdown stripping, porosity, they do not just inform the current project. They change how I approach the next project.

When I hit a TTS feature again, I will prompt the AI differently from the start. I will say: handle input length limits with sentence-aware chunking, strip markdown before synthesis, and return audio segments in order. That is a much better starting prompt than “build me a TTS feature.” The AI can only be as precise as the person steering it.

This is the core of how I think about learning in this era. The AI handles execution. My job is to build a richer and richer mental model of the problem space so that I can direct the execution better each time. The learning loop is still very much alive. It just runs through different channels now.

The Takeaway

AI coding has not made learning irrelevant. It has shifted what you need to learn and when. You spend less time memorizing syntax and more time understanding systems, constraints, and domain concepts. You learn through debugging, through curiosity, and through the iterative process of steering a model toward better outputs.

Every weird edge case is a lesson. Every broken feature is a map of something you did not know yet. And the next time you sit down to build something similar, you bring all of that with you.

That feels like learning to me.

Originally posted on my Substack