Muhammad Awais

Muhammad AwaisSep 9, 2026

I gave an AI coding agent a real production task. Not a toy project. Not a LeetCode problem. A real codebase with existing architecture, APIs, database logic, dependencies, and a few problems nobody had documented. I gave it the requirement. Then I watched. It explored the repository. Found the relevant files. Traced the API flow. Changed multiple parts of the code. Ran tests. Fixed its own errors. And eventually opened a working implementation. A few years ago, this would have taken an engineer hours. Now it can happen in minutes. But there was one thing the agent couldn't decide for itself: What was the right solution? It could navigate the code. It could generate code. It could debug. It could iterate. But engineering decisions still needed context. That's what makes AI agents different from simple coding assistants. We're moving from: “AI helps me write code.” to: “AI can actually operate inside my codebase.” And I think the next generation of engineers won't compete with AI agents by typing code faster. They'll compete by knowing what to ask, what to verify, and what not to let the agent change. The keyboard is becoming less important. Engineering judgment is becoming more important.

Muhammad AwaisSep 24, 2026

Most AI applications don't need an LLM to make every decision. That's what made Jev interesting to me. Instead of generating a paragraph and then asking your application to figure out what the model actually meant, Jev is designed to make structured decisions. For example: → Which workflow should run? → Should this request be escalated? → How urgent is it? → Does this belong to category A, B, or C? → How confident is the model about that decision? The output is a structured result with probabilities, rather than another block of generated text. This opens up an interesting architecture for AI applications: LLM → understands the request Jev → makes a decision Code → executes the workflow Jev → evaluates the next decision Human → handles uncertain cases You don't necessarily need one large model doing everything. You can combine different models based on what each part of your system actually needs. For developers building AI agents and automation, I think this is an important direction to watch. The future of AI might not just be bigger LLMs. It could be better combinations of different types of models. Jev is still very new, so I'm interested to see how it performs in real production workloads beyond the early benchmarks.

Muhammad AwaisSep 21, 2026

One thing I got wrong about RAG for a long time: I thought improving the model would solve most of the problems. Then I started looking more closely at the retrieval side. You can have a good LLM, good embeddings, and a properly configured vector database, and the application can still return a bad answer. The reason is pretty simple. The model doesn't know what was in your database. It only knows what you actually put into its context. If the document was chunked badly, the useful information might be split across different chunks. If the embedding doesn't represent the query well, the search can return something that looks similar but isn't actually useful. And sometimes the problem isn't the vector search at all. It's the metadata, filters, query rewriting, or the lack of reranking after the initial search. This made me look at RAG differently. A vector database is not just somewhere to store embeddings. It's part of the path between the user's question and the model's answer. I've been experimenting with things like chunking strategies, metadata filtering, hybrid retrieval and reranking, and the difference can be surprisingly large. The interesting part of AI engineering isn't always getting a better model. Sometimes it's making sure the model gets better context in the first place. That's probably going to become a much bigger part of building reliable AI applications. #AI #GenerativeAI #RAG #VectorDatabase #VectorDB #MachineLearning #LLM #AIEngineering #ArtificialIntelligence #SoftwareEngineering #Developer