Md Sawjal Sikder’s Post

Built a full AI Agent system on Django. Tool System, Agent Loop, Multi-Agent, Streaming, and RAG — single project, unified architecture. 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗮𝗹 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀: → Agent Loop: A while loop that checks whether the LLM returned a function call or a text response. If function call — execute the tool, append the result to context, send it back to the LLM. Repeat until it returns text. → Tool System: Strategy Pattern on top of a BaseTool abstract class. Each tool implements name, description, parameters, and execute(). ToolRegistry handles central registration — adding a new tool = 1 class + 1 line of register. → Multi-Agent: Inter-agent communication layer. Researcher agent gathers data, Validator agent verifies, Reporter agent formats the output. Each agent runs independently with its own system prompt and tool set. → Streaming: Token-level real-time delivery via SSE (Server-Sent Events). StreamingHttpResponse on the Django side, EventSource on the frontend. → RAG Pipeline: Chunk documents, convert to embeddings, index in a vector DB. On user query, run similarity search to pull the most relevant chunks and inject them as context to the LLM. → Memory: Persistent conversation history via Conversation & Message models. The agent carries prior context into the LLM's context window. Stack: Django + DRF / Gemini API Function Calling / SQLite + Vector DB #AIAgents #Django #Python #LLM #RAG #Gemini #MultiAgent

🚀 Streaming HTTP Response — Powering Real-Time Web Experiences Today I explored an interesting backend concept: Streaming HTTP Response In a typical HTTP request, the server prepares the entire response and sends it all at once. But with streaming, the server starts sending data in chunks as soon as it becomes available. 👉 This means: Users don’t have to wait for the full response — content starts appearing instantly. 💡 Real-world examples: 🎥 Video streaming platforms (YouTube, Netflix) 💬 Live chat applications 🤖 AI tools (real-time response generation) 📊 Live dashboards & logs ⚙️ Tech Insight: Streaming responses often use chunked transfer encoding: Transfer-Encoding: chunked And in Python/Django, this can be implemented using generators (yield). 🧑💻 Example (Django): from django.http import StreamingHttpResponse def stream_view(request): def generate(): for i in range(5): yield f"Chunk {i}\n" return StreamingHttpResponse(generate(), content_type="text/plain") 🔥 Why it matters: Faster perceived performance Improved user experience Memory efficient Ideal for real-time systems 📌 Currently exploring: Django + Celery + Redis + Streaming responses to build scalable real-time applications. #WebDevelopment #Django #Backend #Python #LearningInPublic #TechExploration

"Claude and the New Developer: How AI Is Reshaping Coding Skills in 2026" TypeScript overtook Python as the most used language on GitHub. 80% of new developers use AI in their first week. The role of software engineer is shifting from writing code to orchestrating agents. #AI #Claude #DeveloperSkills #TypeScript #GitHub 👉 Read full article: https://lnkd.in/dF8vJVzZ

This is the right direction—ownership over dependency. Running models locally gives you control over cost, privacy, and customization. But it’s not “free”—you’re trading API bills for hardware limits, maintenance, and optimization work. Scaling, latency, and model updates will test your setup the moment real production load hits. The real advantage is not just saving money—it’s building capability. When you control the stack, you control performance, data flow, and innovation speed. If you can handle: GPU constraints and optimization Model fine-tuning and updates Infrastructure stability Then this path gives you leverage most people don’t have. Curious to see how you handle scaling and performance under load.

I saw a podcast clip today where this guy was bragging about rewriting a Django endpoint in Rust. He said it was 20x faster and then proceeded to roast Django as slow and “legacy.” It was a great clip 😂. Super compelling. You should’ve seen the smug look on his face! But man… it’s also a classic architectural trap. Here’s the unsexy truth if you’re building real products in 2026: 1. Most of the time, it barely moves the needle. Sure, a simple “Hello World” JSON endpoint flies in Rust. But this 20x only shows up in CPU-bound work. Most apps are I/O-bound, the real latency comes from the database or third-party APIs (Stripe, OpenAI, etc). You can shave 2ms off the Python layer and your user still waits 102ms. The big wins are rarely where people think. 2. Speed is cheap. Understanding is expensive. AI can rewrite your whole backend in Rust for “free.” Cool. But now you have a codebase your team might not deeply understand at 3 AM when something breaks. You’ve traded Django’s mature security and patterns for something that feels magical… until it doesn’t. 3. The smart move is using both. The best teams I see right now follow the Glue + Engine approach (this is literally how modern AI companies work): • Keep Django for 90% of the app (auth, admin, ORM, security, rapid iteration). • Pull out the real bottlenecks (heavy calculations, image processing, complex logic) and rewrite just those parts in Rust using PyO3. Rust wins here because its compiler catches a ton of mistakes that even AI still makes. You get near-C performance with way better safety. Bottom line: Optimize for developer velocity most of the time. Only optimize for raw execution speed when it actually matters. Don’t let a sexy benchmark convince you to throw away years of proven tooling. Build systems your team can actually own and maintain. What do you think? Have you seen big Rust rewrites deliver the promised gains, or mostly pain? #Django #Rust #Python #SoftwareEngineering #Backend #WebDev

Some days I write Python for hours… and nothing “visible” changes. No new screen. No shiny feature. Just endpoints, logs, and small decisions that no one sees. Then I switch to React. And suddenly everything is visible. A button moves. A page feels faster. It looks like progress. But here is what I have realised. The real work usually happens in the invisible part. Designing an API that will not break later. Fixing a slow query that no one complained about yet. Handling edge cases before they become real problems. Lately, I have been spending time with AI systems as well. Not building demos, but trying to make them actually useful. And that has been humbling. Because it is not about the model. It is about how you connect everything around it. Different tools. Different layers. Same goal every day: 👉 Build something that quietly works well. What part of your work feels invisible… but matters the most? #SoftwareEngineering #FullStack #Python #ReactJS #NextJS #FastAPI #Django #AWS #AI #GenAI #BuildInPublic #TechCareers #Developers

🚀✨ 𝐄𝐱𝐜𝐢𝐭𝐞𝐝 𝐭𝐨 𝐒𝐡𝐚𝐫𝐞 𝐌𝐲 𝐋𝐚𝐭𝐞𝐬𝐭 𝐏𝐫𝐨𝐣𝐞𝐜𝐭! 𝐈’𝐯𝐞 𝐛𝐮𝐢𝐥𝐭 𝐚 𝐁𝐚𝐢𝐫𝐚𝐧 𝐒𝐨𝐧𝐠 𝐓𝐫𝐞𝐧𝐝𝐢𝐧𝐠 𝐑𝐞𝐞𝐥 𝐆𝐞𝐧𝐞𝐫𝐚𝐭𝐨𝐫 𝐏𝐥𝐚𝐭𝐟𝐨𝐫𝐦 🎬 Now you can simply upload a 6-second video clip, and the system automatically transforms it into a cinematic, Bairan-style edited reel 🎥⚡ ⚙️ How it works: Upload your clip ➝ Processed by system ➝ Instantly generated stylish reel 💫 🛠 Tech Stack: 🐍 Python (Backend video processing) ⚛️ React (Frontend UI) 🔥 Flask + Media automation pipeline 💡 Key Highlights: ✨ Fully automated reel generation ⚡ Fast & seamless processing 🎬 No manual editing needed 🚀 End-to-end full-stack integration 📚 What I learned: 💻 Video processing using Python 🌐 Full-stack development (React + Flask) 🤖 Building automation-based creative tools 🔗 GitHub Links: Backend: https://lnkd.in/ddDyUUYC Frontend: https://lnkd.in/d_m7EZcp 🙏 Open for feedback, suggestions, and improvements! #Python #ReactJS #Flask #FullStackDevelopment #VideoProcessing #Automation #AI #WebDevelopment #ProjectShowcase #CodingLife 🚀🔥

🚀 From JavaScript to Python in 5 Minutes? Here’s What Happened… Today I worked on a personal project where I tried shifting my codebase from JavaScript to Python — and honestly, I was surprised by how smooth the process was. With the help of GitHub Copilot, I gave access to my existing codebase, and within minutes… boom 💥 Most of the JS code was converted into Python! It felt almost magical, but it also got me thinking 👇 ✅ Upside: If you already have a good understanding of programming concepts, tools like this can be a complete game changer. They can save hours of manual work and help you experiment faster. ⚠️ Downside: Giving full access to your codebase — especially in production — can be risky. There are concerns around security, data exposure, and unintended changes. 👉 Lesson learned: Use AI tools smartly. They’re powerful assistants, not replacements for careful decision-making. Would I use it again? Yes. Would I use it directly on production code? Definitely not. Curious to know — have you tried using AI tools like this in your workflow? 🤔 #AI #GitHubCopilot #Python #JavaScript #LearningInPublic #Tech

Behind every line of JavaScript code, there’s an invisible engine managing memory, scope, and function calls — that engine is the Execution Context. Understanding this concept changed the way I debug code, write cleaner functions, and truly grasp how JavaScript works under the hood. 🚀 If you want to master hoisting, closures, scope chain, call stack, and this keyword, start here. Strong fundamentals always outperform shortcuts. 💡 #JavaScript #ExecutionContext #WebDevelopment #FrontendDeveloper #Programming #Coding #SoftwareEngineer #DeveloperLife #TechLearning #LearnToCode #100DaysOfCode #JavaScriptDeveloper #CodingJourney #SoftwareDevelopment #Debugging #AI #ArtificialIntelligence #GenerativeAI #OpenAI #TechTrends #FutureOfWork #Innovation

My #backendDevelopment #bugFixes I have been assigned for my team's #ReactJS / #Python food-related app are taking longer than expected, again. (also #Flask, #JWT, #SQLAlchemy are used) The level of understanding of code required requires time and human effort. That is why my team and I are prepared to take on new projects in this era of automation, because, unlike our counterparts who are entering this field by copy-pasting without first understanding, we understand (though far from expert-level), or are constantly and actively growing in our understanding, of the basics of what's going on under the hood and what to look for when editing code (unlike "black boxes" where you don't know and can't control what's under the hood). We are now deciding that the MVP will be a working model but more changes will have to be made after that before it is production-ready. That's okay, because it's better to ensure a secure and stable application in order to test it with real users. Right now the database is only being tested locally. But this app's concept is genuinely novel and something that would benefit at least one company out there, maybe more, even beyond the food industry -- and no, it is not an application that claims to run on "AI" -- it is funny how that fact actually makes us stand out. I am eager to share more specifics about it and my team members' GitHub links if and when it clears the development phase. Lessons learned: build one layer at a time, and don't rush a professional project if it will result in a bad or unreliable product. #HammondSoftware