Abhishek Choudhary

🚀 𝐋𝐋𝐌𝐬 𝐀𝐫𝐞 𝐭𝐡𝐞 𝐍𝐞𝐰 𝐂𝐨𝐦𝐩𝐢𝐥𝐞𝐫𝐬 — 𝐁𝐮𝐭 𝐖𝐢𝐭𝐡 𝐚 𝐓𝐰𝐢𝐬𝐭 Software development is shifting again. Just as compilers once lifted us from assembly to high-level languages, Large Language Models are lifting us from code to natural language intent. But unlike traditional compilers, LLMs are 𝐧𝐨𝐧-𝐝𝐞𝐭𝐞𝐫𝐦𝐢𝐧𝐢𝐬𝐭𝐢𝐜. The same prompt may yield different answers—even with settings locked down. That unpredictability makes some dismiss their viability for production systems. I see it differently. History shows we’ve built reliable systems on top of inherently unpredictable components before—think concurrency, network, timing of events. The key isn’t eliminating variability; it’s 𝐞𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 𝐚𝐫𝐨𝐮𝐧𝐝 𝐢𝐭. This demands a new mindset: 👉 From 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐧𝐞𝐬𝐬-𝐛𝐲-𝐜𝐨𝐧𝐬𝐭𝐫𝐮𝐜𝐭𝐢𝐨𝐧 (perfect code → guaranteed result) 👉 To 𝐜𝐨𝐫𝐫𝐞𝐜𝐭𝐧𝐞𝐬𝐬-𝐛𝐲-𝐯𝐚𝐥𝐢𝐝𝐚𝐭𝐢𝐨𝐧 (rigorous evaluation → dependable systems) The organizations that win won’t just run bigger LLMs. They’ll build the 𝐞𝐯𝐚𝐥𝐮𝐚𝐭𝐢𝐨𝐧 𝐢𝐧𝐟𝐫𝐚𝐬𝐭𝐫𝐮𝐜𝐭𝐮𝐫𝐞 to harness them reliably—transforming probabilistic outputs into real-world impact. 💡 How are you approaching validation and reliability as AI reshapes your engineering stack? #AI #Leadership #Engineering #GenerativeAI #TechStrategy

87

11 Kommentare

🚗 LLMs vs Agents vs Agentic AI — Explained with LEGOs 🧱 Imagine you’re handed a pile of LEGO blocks and asked to build a car. Here’s how it plays out in the world of AI: 🔹 LLM (Large Language Model) The LLM is like a brilliant kid who has read every LEGO manual ever written. You ask, “How do I build a car?” and it gives you detailed instructions — maybe even alternatives based on what kind of car you want. But… it won’t actually build it for you. 🔹 Agent Now imagine giving those instructions to a helper (the agent) who can follow them. You tell the agent, “Here’s what the LLM said — now go assemble it.” The agent reads the blueprint, connects the pieces, and maybe even checks back if it’s unsure. It acts based on the LLM’s intelligence. 🔹 Agentic AI Agentic AI takes it one step further. You just say, “I need a car that can move fast and carry 2 passengers.” It breaks the problem down, figures out what kind of car to build, asks the LLM when needed, collects the right LEGO blocks, builds iteratively, tests it, improves it, and handles unexpected bumps along the way. In short, it thinks, plans, and acts — all autonomously. ⸻ 🤖 LLM = Knowledge 🧑‍🔧 Agent = Action 🧠 Agentic AI = Goal-driven Autonomy We’re entering a new era where AI doesn’t just answer — it accomplishes. #AgenticAI #LLMs #AIAgents #GenerativeAI #LLM #AIExplained #TechMetaphors #ArtificialIntelligence

56

3 Kommentare

dbt Labs announcement of #dbt (con)Fusion has a lot of things that we as a data community need to discuss. dbt Fusion is a complete rewrite of dbt Core in Rust. Unlike dbt Core, which is completely free and open source under Apache 2.0, dbt Fusion is not open source as it is under the more restrictive Elastic 2.0 license. Although Fusion is free to use, it restricts its usage in a hosted or managed offering to 3rd parties. You may think this is fine, but there are far-reaching implications. Open source is amazing because it incentivizes individuals and companies to invest in it without risk. A company can go all in on open source because no matter what the direction of the core maintainers is, it can be forked and used for whatever reason you want. A non-permissive license like Elastic will disincentivize companies from investing. Don't get me wrong, there's nothing ethically wrong about dbt Labs' decision. It may even be in their best financial interest to do so. However, I want to analyze what led to this situation and what it might mean for the future of dbt Core. What I believe this means is that dbt's strategy is to put dbt Core in "maintenance mode" to focus on Fusion and their other proprietary offerings. The wording of the announcement was very carefully selected to be vague. In particular, when referring to dbt Core support, it was only highlighted that bug fixes, security patches, and compatibility would be ongoing. According to their dbt Core roadmap, they've separated out the dbt language from the runtime. There's a specific callout that Fusion and Core will inevitably diverge because Fusion has additional capabilities that cannot be added to Core. To me, it makes sense that this is the chance for dbt Labs to invest in more restrictive and profitable software while slowly deprecating what not only made them great but is also their biggest challenge to financial growth. Ultimately, resources are finite, and companies must prioritize what makes sense for the business. Given dbt Core's foundational importance to modern data infrastructure, Analytics Engineers deserve a free, open, and continually evolving transformation platform. Otherwise, your career will be dangerously dependent on the decisions of a single company. To safeguard the continuing innovation and development of the transformation space, it may be time to start a discussion about an open standard for defining data transformations.

795

49 Kommentare

𝟯 𝗺𝗶𝘀𝘁𝗮𝗸𝗲𝘀 𝘁𝗵𝗮𝘁 𝗺𝗼𝘀𝘁 𝗮𝗿𝗲 𝗱𝗼𝗶𝗻𝗴 𝗶𝗻 𝘁𝗵𝗲𝗶𝗿 𝗳𝗶𝗿𝘀𝘁 𝗟𝗟𝗠 𝗽𝗿𝗼𝗷𝗲𝗰𝘁𝘀 👇 I am no exception :) 𝟭. 𝗡𝗼𝘁 𝗸𝗻𝗼𝘄𝗶𝗻𝗴 𝗞𝗣𝗜𝘀 𝘁𝗼 𝗼𝗽𝘁𝗶𝗺𝗶𝘇𝗲 𝗳𝗼𝗿 𝗯𝗲𝗳𝗼𝗿𝗲 𝘁𝗵𝗲 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻: especially if you are working on automation using LLMs. After a few months of development you are very likely to run into the scenario where your work is not moving the metrics fast enough. ❗️ Negative effect - lost trust from stakeholders. Likely to result in the project getting cut. ✅ Fix - align with stakeholders on the KPIs early. Dig deeper to understand what inputs will drive the required output. 𝟮. 𝗡𝗼𝘁 𝗶𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗶𝗻𝗴 𝗢𝗯𝘀𝗲𝗿𝘃𝗮𝗯𝗶𝗹𝗶𝘁𝘆 𝗲𝗮𝗿𝗹𝘆 𝗶𝗻 𝘁𝗵𝗲 𝗽𝗿𝗼𝗷𝗲𝗰𝘁. ❗️ Negative effect - running blind, it will be impossible to know which part of the application is causing bad performance, what is slowing down the application, how much separate parts of the system are costing you. ✅ Fix - set up Observability tooling (LangSmith, LangFuse etc.) early, instrument your code. 𝟯. 𝗡𝗼𝘁 𝗵𝗮𝘃𝗶𝗻𝗴 𝗲𝘃𝗮𝗹𝘂𝗮𝘁𝗶𝗼𝗻/𝘁𝗲𝘀𝘁 𝗱𝗮𝘁𝗮𝘀𝗲𝘁𝘀 𝗿𝗲𝗮𝗱𝘆 𝘄𝗵𝗲𝗻 𝗶𝘁𝗲𝗿𝗮𝘁𝗶𝗻𝗴 𝗼𝗻 𝘁𝗵𝗲 𝗮𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻: LLM based systems might become complex, changes in any part of the pipeline might derail the system and negatively impact cases that used to work. ❗️ Negative effect - Previously working case will inevitably stop working. You will spend days trying to figure out what caused this. ✅ Fix - construct your evaluation/test datasets early and include these in tests executed via your CI/CD pipelines. ℹ️ You will be able to reuse some of the data in these datasets in few shot examples so it’s not a waste of time! Are you guilty for not having the above? What other mistakes would you add? #LLM #MachineLearning #AI

81

13 Kommentare

Not all large language models are created equal. The architecture behind an LLM determines how fast it runs, how well it scales, and where it shines. Here are 6 architectures every AI builder should know: ➤ 1. Encoder-Only → Focus: Deep understanding, embeddings → Trained on: Masked tokens → Ideal for: Search, classification Examples: BERT, RoBERTa ➤ 2. Decoder-Only → Focus: Next-token prediction → Trained on: Left-to-right context → Ideal for: Chat, code, agents Examples: GPT-4, Claude, LLaMA ➤ 3. Encoder-Decoder (Seq2Seq) → Focus: Input → Output mapping → Trained on: Paired data → Ideal for: Translation, summarization Examples: T5, BART ➤ 4. Mixture of Experts (MoE) → Focus: Sparse routing for scale → Trained on: Expert selection → Ideal for: High performance, lower cost Examples: GLaM, DeepSeek-V2 ➤ 5. State Space Models (SSMs) → Focus: Long context, fast compute → Trained on: State transitions → Ideal for: Large documents, low latency Example: Mamba ➤ 6. Hybrid Models → Focus: Best of all worlds → Trained on: Mixed paradigms → Ideal for: Balanced performance Examples: Jamba, Grok 🌟 Follow the AIKaDoctor (Free AI & Data Science Resources)  channel on WhatsApp: https://lnkd.in/dCTCEKKc 📌Follow Habib Shaikh For more such content.

220

24 Kommentare

AI is just search. Love this new post by 🤖 Jacky Liang on why: - Semantic search fails where precision matters - Vector databases are doomed - Claude Code’s grep-powered search destroys Cursor’s vectors - Hybrid search (combining lexical, full-text, and semantic) is the future My favorite line: "Similarity ≠ relevance. Vector search can’t find getUserById." If you’re building an AI app, whether it’s a code assistant, chatbot, or product search, this piece is a must-read. And this is just the beginning. We’re kicking off a series showing how to: - Build multi-search systems using Postgres - Combine surgical precision of lexical search with fuzzy power of full-text - Add vector search for semantic understanding (when it actually helps) Read Jacky's post here: https://lnkd.in/g5wrUDbp

69

5 Kommentare

“Throw out the clever code.” This was Bjarne Stroustrup’s advice to a room full of engineers responsible for building the fastest trading systems on Wall Street. I invited the creator of C++, and one of the most influential programmers in computing history, to do a talk on performance optimization at the New York STAC Summit. Here was his advice to them. 1. Measure everything that matters. Your intuition about what’s inefficient is often unreliable. Don’t guess; get data to know where effort is truly needed. 2. Distributed fat is costly. Small, widespread inefficiencies can accumulate into significant costs across any system or organization. 3. Don’t over-optimize prematurely. The temptation to perfect every detail early on often leads to complex, hard-to-maintain systems. 4. Throw out the clever code. If you can’t understand what’s going on, neither can the optimizer. Link to full talk: https://lnkd.in/e8_x5-DC #STAC #LowLatency #Engineering #Performance #C++ #WallStreet

1.035

50 Kommentare

🏇 𝗥𝗲𝗱𝘂𝗻𝗱𝗮𝗻𝗰𝘆 𝗜: 𝗟𝗼𝘀𝘁 𝗶𝗻𝗳𝗼𝗿𝗺𝗮𝘁𝗶𝗼𝗻 In German there is a phrase, "the left hand not knowing what the right hand does". Most software has deliberately been designed in a similar fashion. You are calling a function with a known effect but what happens inside is opaque to you. 😓 As a result, (temporary) data / information gathered on one side of the function call tree is not available on the other side. If your string class does not readily contain the length of the string, it's almost a certainty that different parts of the system will call strlen() or something similar over and over again. 💡 There are a few of things you can do to address that situation; all of them can fix "Big-O" algorithmic problems. From easy to hard: ✅ useful naming conventions Use getXYZ() only for O(1), quick access functions. If you need to traverse data, use xyz() for findXYZ() instead. The caller can then make sure to call the function e.g. once instead of N times. ✅ result caching, memoization If inputs/parameters for consecutive calls are related, e.g. in case of path traversal, you may store the latest input (path) and the respective output (graph location) inside your function. Next time the function gets called, check if you can simply continue the traversal from the prior end point. ✅ rich data structures The OOP version of memoization. Alongside the "core" object data, store any frequently requested derived data. E.g. strings should store their length information in some form. ✅ data flow object model, dynamic programming Eliminate the need for temporary data by representing the processing state inside the data /object model itself. Local processing functions are replaced by state transformations. Good examples for this are graph algorithms but you can extend the idea to larger systems. ❓ What are your strategies for dealing with redundant processing? Anything you would like to add? #FiveHorsemen #Redundancy #algorithms #performance

31

6 Kommentare

The Context Engineering Framework is quickly becoming one of the most important tools for anyone building reliable LLM systems. Getting the model to respond is the easy part. The real challenge is: → What should the model know right now? → Where should that info come from? → How should it be structured, stored, retrieved, or compressed? That’s exactly what this framework solves. 🧠 𝗪𝗵𝗮𝘁 𝗶𝘀 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 Context engineering = designing dynamic systems that deliver the right info, in the right structure, at the right time, so models can reason, retrieve, and respond effectively. This matters most in agents, copilots, retrieval-augmented pipelines, and anything with memory or tools. ⚙️ 𝗜𝗻𝘀𝗶𝗱𝗲 𝘁𝗵𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿𝗶𝗻𝗴 𝗙𝗿𝗮𝗺𝗲𝘄𝗼𝗿𝗸 Here’s the 3-layer system I use when designing end-to-end LLM workflows 👇 1️⃣ Context Retrieval & Generation → Prompt Engineering & Context Generation → External Knowledge Retrieval → Dynamic Context Assembly 2️⃣ Context Processing → Long Sequence Processing → Self-Refinement & Adaptation → Structured + Relational Information Integration 3️⃣ Context Management → Fundamental Constraints (tokens, latency, structure) → Memory Hierarchies & Storage Architectures → Context Compression & Trimming 🧱 All of this feeds into the Context Engine, which handles: → User Prompts → Retrieved Info → Available Tools → Long-Term Memory This is what gives your system continuity, task awareness, and reasoning depth across steps. ⚙️ Tools I would recommend: → LangGraph for orchestration + memory → Fireworks AI for fast, open-weight inference → LlamaIndex for modular retrieval → Redis & Vector DBs for scoped memory recall → Claude/Mistral for summarization and compression If your system is hallucinating, drifting, or missing the mark, it’s likely a context failure, not a prompt failure. 📌 Save this framework. 📩 Share it with your team before your next agent or RAG deployment. 〰️〰️〰️ Follow me (Aishwarya Srinivasan) for real-world GenAI system breakdowns, and subscribe to my Substack for deep dives and weekly insights: https://lnkd.in/dpBNr6Jg

321

59 Kommentare

Everyone’s talking about LLMs… but fewer people are asking: Where does all that knowledge actually live? The truth is, every great AI application has a “memory layer” behind it — and that’s where vector databases come in. They’re the quiet infrastructure powering similarity search, recommendations, and retrieval-augmented generation (RAG). Without them, most of the magic we see in GenAI wouldn’t scale. Here’s a quick breakdown of the open-source landscape 👇 🔹 Purpose-Built Vector Databases Milvus → the market leader, handles billions of vectors, cloud-native, supports IVF, HNSW, DiskANN. Weaviate → versatile hybrid search + built-in AI modules. Qdrant (Rust-based) → strong performance + JSON payload filtering. ChromaDB → developer-friendly, deeply integrated with LangChain & LlamaIndex. Deep Lake → optimized for multimodal data (text, audio, video). Vespa / Vald → trusted for high-scale, cloud-native search. 🔹 Database Extensions Adding Vector Support Postgres + pgvector → if you live in SQL-land, this is the bridge. Elasticsearch / OpenSearch → blend classical keyword search with vectors. Cassandra 5.0 → distributed-first, now with vector queries. Redis / Neo4j → flexible overlays: graph + cache + vectors. 🔹 Libraries & Frameworks Faiss (Meta) → the workhorse for vector similarity search. ScaNN (Google) → speed + accuracy using partitioning & quantization. Annoy (Spotify) → an early classic, now succeeded by Voyager. Lucene / Solr → battle-tested search engines with added vector power. Picking a vector store isn’t just about speed — it’s about fit. Need huge scale? Milvus, Weaviate, Qdrant. Already love Postgres? Use pgvector. Building custom? Start with Faiss or ScaNN. In short: the best database is the one that meets your needs, not the other way around. If you were building a production LLM app today, would you go “all in” with a purpose-built vector DB — or extend the database you already know (Postgres, Elastic, etc.)? Why?

44

13 Kommentare

🚀 Exciting News for Developers! Introducing Gemini CLI – the Open‑Source AI Agent from Google 🚀 Today, we unveiled Gemini CLI, bringing Gemini 2.5 Pro right into your terminal — and it’s fully open source under Apache 2.0. Here’s what makes it a game‑changer: 🔧 Terminal-native AI • Interact using natural language to write/debug code, automate workflows, perform deep research, generate content, and manage tasks — all from within your shell . • Supports image/video generation via Veo and Imagen . 🎯 Powerful under the hood • Powered by Gemini 2.5 Pro with a massive 1 million‑token context window — ideal for large codebases or complex prompts . • Includes Model Context Protocol (MCP), Google Search integration, and seamless VS Code Code‑Assist sync . ✅ Generous, free preview access • Get up to 60 model requests per minute and 1,000 per day with a free Gemini Code Assist license . • Works on Windows, macOS, and Linux without cost . 🛠️ Open‑source & extensible • Source code is available on GitHub — invite contributions, inspect security, and customize it to your needs . • Leverages shared backend with Gemini Code Assist in VS Code — enjoy agentic coding both in‑IDE and in terminal . Why this matters Gemini CLI transforms your terminal into a powerful AI partner — ideal for developers who crave efficiency, improvise workflows, or just love doing everything from the shell. With generous free usage and open‑source flexibility, it's poised to become an essential tool for innovators and teams alike. #GeminiCLI #GenerativeAI #OpenSource #DeveloperTools #Productivity #GoogleAI 🔗 Come join the conversation: https://lnkd.in/gGNBjsgF • Explore the GitHub repo to get started. • Check out insights from Thomas Kurian, CEO of Google Cloud, and community responses on LinkedIn .

39

Programming is not just about pounding out code—anybody can pound out code, including LLMs—but intentional coding is what separates the top 1% of exceptional programmers from the rest. An excerpt from a high-performance parallel computing book I'm reading, speccing out some programming styles you can consider to squeeze more performance gains from your parallel programs as well as make it less confusing for the compiler for optimal execution. #artificialintelligence #deeplearning #machinelearning #llm #innovation #technology #startups #ai #cloudengineering #cloudcomputing

22

3 Kommentare

After some survey, I would love to publish why junior or mid-level roles are not readily available in Rust, and why they may not be for a while unless we actively work towards it. This is based on A one on one interview of: 10 start-ups using Rust in production. 10 start-ups not using Rust but interested in trying it. 5 months of personal research. what will you expect the article cover or looking to see?

25

7 Kommentare

OpenAI released open-weight models last week. They run locally. They’re cheap. But they don’t outperform Qwen, GLM, or even Deepseek. So why did this release matter so much? And what does it change if you’re building with LLMs? #ai #openai

22

2 Kommentare

Context: I am being asked about it a lot by smart people. 📊 Why I chose C++23 over Rust for my DB25 SQL parser Just shared my technical reasoning with the Rust community - not to start a language war, but to discuss real-world trade-offs in high-performance systems. The context: DB25 achieves 20M+ tokens/sec with 4.5x SIMD speedup Key factors that tipped the scales: SIMD optimization maturity (SSE4.2/AVX2/AVX-512) Zero-copy arena allocation control Direct integration with existing SQL ecosystem Decades of C++ compiler vectorization What I admire about Rust: Memory safety by default Fearless concurrency Cargo package management Strong community focus on safety The best tool depends on your constraints. For DB25's extreme performance needs, C++23 was right. For my next project emphasizing safety over raw speed? Rust is absolutely on the table. Both languages solve real problems. Having multiple excellent systems languages makes us all better developers. What's your experience with language choice for performance-critical projects? #SystemsProgramming #CPlusPlus #RustLang #Performance #SQL #TechDecisions 📄 Full technical discussion: attached 🔗 Projects: https://lnkd.in/gqemydKY

64

1 Kommentar