# Mehedi Hasan Shifat > I build AI products that hold up in production. Product Engineer · AI Products & Systems · Dhaka, Bangladesh · Open to collaborations. Goes by Shifat. Product engineer with AI depth. I build AI products end to end, from multi-agent systems at Nordivo to Pagewala, my live AI sales agent, and make the systems under them fast. ## Now - **Building:** AI-native products, developer tools, and practical software for everyday problems - **At work:** Software Engineer III at Nordivo — building a multi-agent SEO Intelligence Engine - **Exploring:** Multi-agent orchestration, RAG, workflow automation, and cloud-native AI - **Practicing:** Reading, thinking, and writing consistently - **Goal:** Building profitable, independent products ## By the numbers - **1M+** images/day on one server, down from a 10-server cluster - **100M+** requests/day through the gateway every one of 100+ services routes through - **9.4K+** installs of Claude Code Dashboard across VS Code Marketplace and Open VSX - **33K+** downloads and 370+ GitHub stars on Ubuntu Launcher ## How I build ### 1. Fundamentals before rewrites An image service rendered HTML in headless Chrome and needed 10 servers to keep up. No rewrite: I split the work across browser tabs behind a bounded promise pool, so Node's thread pool could finally use every core. **Result:** 400 → 100 min per 100K images · 10 servers → 1 · 16 → 6 GB RAM ### 2. Question the requirement A zip step pinned an 8-core machine at 95% CPU. Before tuning anything, I asked the team downstream. They unzipped everything on arrival, so file size never mattered. Switching LZMA2 for Deflate traded size nobody needed for CPU we did. **Result:** ~80% less CPU · 2× concurrent jobs ### 3. Reliability is the product In Pagewala the model talks, but the server decides. Prices come from the database, stock moves in a transaction, and three layers stop duplicate orders. An AI that sells has to be boring where money is involved. **Result:** Live, built solo [Read more](https://www.heyshifat.com/projects/pagewala) ## Stack Java, Spring Boot, Spring Cloud, Node.js, Express.js, Next.js, React, TypeScript, JavaScript, Python, FastAPI, Flutter, MongoDB, PostgreSQL, Docker, CI/CD, AWS, Google Cloud Platform, DigitalOcean, LangChain, LangGraph, Celery, Redis, OpenAI API, RAG, N8N, System Design, Microservices ## Contact - **Email:** mhshifat757@gmail.com (best for work; replies within 24 hours) - **LinkedIn:** https://linkedin.com/in/mhshifat - **GitHub:** https://github.com/jspw - **X:** https://x.com/mhshifat757 - **Resume (PDF):** https://www.heyshifat.com/mehedi_hasan_shifat_resume.pdf --- # Projects Everything Shifat has built, grouped by kind. Projects with a case study link to the full write-up. ## AI Products Agents and copilots that do real work. ### Pagewala *AI Products* An AI sales agent for Facebook Page sellers in Bangladesh that handles customer conversations, product questions, and order capture through Messenger. **Stack:** Next.js, TypeScript, AI Agents, Meta Graph API **Links:** [Live site](https://www.pagewala.com/) · [Case study](https://www.heyshifat.com/projects/pagewala) ### Briefly AI *AI Products* An AI briefing workspace that turns scattered updates from connected work tools into concise, actionable daily briefings. **Stack:** Next.js, TypeScript, AI, Workflow Automation **Links:** [Live site](https://briefly-ai.heyshifat.com/) ### DynaMate — AI Internal Copilot *AI Products* AI-powered enterprise copilot automating leave management, meeting scheduling, and policy queries. Scalable multi-agent architecture built in 24 hours. **Outcome:** First Runners-Up, DSI internal AI Hackathon **Stack:** Python, LangChain, FastAPI, Next.js, LLM ### Spyre — AI Job Search Platform *AI Products* Career platform with CV parsing, AI-driven ATS keyword scoring, job-role matching, and real-time chat. Improves job seekers' application success rates. **Stack:** Next.js, React, Node.js, Socket.io, OpenAI API ## Products Everyday tools for money, plans, and reading. ### Arthonitee *Products* A Bangladesh-first financial calculator and learning platform for making clearer decisions about income tax, loans, DPS, FDR, savings, and everyday money. **Stack:** Next.js, TypeScript, Financial Calculators, Bangla **Links:** [Live site](https://www.arthonitee.com/) ### HishabNai *Products* A personal finance product built to make everyday money tracking and shared expenses simpler, clearer, and less stressful. **Stack:** Next.js, TypeScript, PostgreSQL, Personal Finance **Links:** [Live site](https://www.hishabnai.com/) ### Resume Studio *Products* A resume builder with a live A4 preview, tailored variants for each application, swappable templates, and one-click PDF export. **Stack:** Next.js, PDF Export, Live Preview **Links:** [Live site](https://products.resume-studio.heyshifat.com/) ### Planwise *Products* A personal planning studio for structuring, visualizing, and tracking meaningful plans, so you can see the whole plan at a glance. **Stack:** Next.js, Planning, Visualization **Links:** [Live site](https://products.planwise.heyshifat.com/) ### Read Me *Products* A quiet place to read markdown. Open a file, fetch a link, or paste text; it stays on your device and opens with or without a connection. **Stack:** Vite, Markdown, Offline-first **Links:** [Live site](https://tools.readme.heyshifat.com/) ## Developer Tools Things I built to make my own workflow better. ### Exciton *Developer Tools* A CLI that runs Claude Code with an agentic framework like superpowers dialled to the level the task deserves, for one session, without touching your global setup. **Stack:** TypeScript, Node.js, Claude Code, CLI **Links:** [npm](https://www.npmjs.com/package/exciton) · [Source](https://github.com/jspw/exciton) ### Claude Code Dashboard *Developer Tools* VS Code extension that reads local Claude Code session data and displays real-time usage analytics — tokens, costs, sessions, and project-level insights. Built for engineers running Claude Code day-to-day. **Outcome:** 1.6K+ VS Code installs · 7.8K+ Open VSX downloads **Stack:** Claude Code, TypeScript, VS Code, React, Node **Links:** [Live site](https://claude-code-dashboard-jspw.vercel.app) · [Source](https://github.com/jspw/Claude-Code-Dashboard) ### VibeGard Web *Developer Tools* Privacy-first web platform that protects sensitive data before it reaches AI tools. Automatically detects and masks secrets, credentials, and private information in real time, enabling safe usage of LLMs without exposing critical data. **Stack:** Next.js, TypeScript, Regex **Links:** [Live site](https://vibegard.vercel.app) ### VibeGard Extension *Developer Tools* Browser extension that automatically masks sensitive input before it is sent to AI tools like ChatGPT or Claude. Intercepts prompts in real time, ensuring secrets and private data are protected without disrupting workflow. **Stack:** TypeScript, Chrome Extension API, Content Scripts, DOM Interception **Links:** [Live site](https://chromewebstore.google.com/detail/vibegard/lbpbkloocbiacpabkkeiddeabfaiahec?utm_source=item-share-cb) ## Apps & Extensions Native macOS, Android, and browser utilities. ### Chrome Shelf *Apps & Extensions* A privacy-first Chrome extension for saving tabs and tab groups into an organized, searchable shelf. Close tabs without losing the context you need later. **Stack:** TypeScript, React, Chrome Extension API, Chrome Storage **Links:** [Live site](https://chromewebstore.google.com/detail/chrome-shelf/cijpjgclabfbdbpieahfamgjacmnohdg) ### Ubuntu Launcher *Apps & Extensions* Lightweight Ubuntu-GNOME-inspired Android launcher with customizable UI, shortcuts, and app management. **Outcome:** 370+ GitHub stars · 65 forks · 33K+ downloads **Stack:** Flutter, Dart, Android, Java, Open Source **Links:** [Source](https://github.com/jspw/Ubuntu-Launcher) ### ScrollSense *Apps & Extensions* A native macOS utility that keeps trackpad scrolling natural and mouse-wheel scrolling traditional, automatically, with per-device preferences. **Stack:** Swift, macOS, CGEventTap, Swift Package Manager **Links:** [Source](https://github.com/jspw/ScrollSense) ### Hush *Apps & Extensions* A native macOS menu-bar utility that quietly quits regular apps after their last window closes, keeping Cmd+Tab clean without touching background-only apps. **Stack:** Swift, macOS, Accessibility API **Links:** [Source](https://github.com/jspw/Hush) ### MyBebsha — E-commerce Mobile App *Apps & Extensions* Flutter e-commerce app built from scratch to help sellers in Dhaka digitize their shops. Full release lifecycle on Google Play Console. **Outcome:** 1,000+ sellers onboarded **Stack:** Flutter, Dart, REST APIs --- # Pagewala: an AI sales agent for Facebook Page sellers Case study by Mehedi Hasan Shifat · 2026-10-09 **Role:** Solo founder & engineer: product, design, and full-stack build > How I built an AI agent that answers customer questions and captures orders through Messenger for small sellers in Bangladesh, without letting it invent a single price. ## The problem Small businesses across Bangladesh sell almost entirely through Facebook Pages. Every sale starts as a Messenger conversation: "price?", "available?", "delivery kobe hobe?", often with a product photo or a link to a post. Sellers answer the same questions hundreds of times a day, take orders by hand in chat, and lose sales whenever they're slow, offline, or overwhelmed. Off-the-shelf chatbots don't fit. They answer questions but don't sell, they don't understand Banglish, and they don't know the seller's actual catalog. ## What Pagewala does Pagewala connects to a seller's Facebook Page and acts as an always-on salesperson in Messenger: - **Answers product questions** in Bangla, English, or Banglish, matching whatever the customer writes. - **Understands photos and post links.** A customer can send a screenshot or paste a post URL and get the right product back. - **Actually sells.** It nudges browsers toward a decision, suggests one complementary item, and handles "too expensive" without just repeating the price. - **Captures orders** by collecting name, phone, address, and payment method one question at a time, then confirming a full recap before anything is recorded. - **Turns comments into conversations.** When someone comments "price?" under a post, Pagewala replies privately in Messenger with that post's product already in context. - **Hands off to a human** when it isn't sure, when the customer is upset, or when a seller-defined trigger word appears, and then stays silent until the seller turns it back on. Sellers get a dashboard with live conversations, orders (with export), analytics, and per-page agent settings. The catalog can be entered by hand, synced from Facebook posts, or imported from a CSV or Excel file. ## How it works Built with **Next.js 16**, **Postgres on Neon** through **Drizzle**, and **Gemini 2.0 Flash**, called over plain HTTP behind a small provider interface (Ollama is a drop-in alternative). 1. **Webhook in, 200 out.** Facebook's webhook is verified with an HMAC-SHA256 signature and answered immediately. The agent runs in the background with Next's `after()`, and every message is de-duplicated by its Facebook message ID, because Facebook retries for up to 24 hours. 2. **An input pipeline decides what the customer sent:** button tap, post link, photo, voice, or text. A post link is matched exactly against synced posts first, then by the post's text through the Graph API. 3. **Retrieval without a vector database.** Seller catalogs are small (20 to 200 products), so the whole catalog is loaded and keyword-matched in memory. The products being discussed are remembered on the conversation, so a follow-up like "XL size ache?" still knows which shirt it means. 4. **One model call per message.** Photos are passed inline with up to 100 candidate products rather than through a separate vision call, which halves the cost per image. 5. **Two tools, nothing else:** `place_order` and `escalate`. The dashboard updates live using Postgres `LISTEN/NOTIFY` streamed over server-sent events, so there's no Redis or Pusher to run. ## The hard parts **Never trusting the model with money.** The model is told to use only listed products, but the server doesn't rely on that. `place_order` ignores any price the model sends and looks up each item from the database. It validates quantities and decrements stock atomically inside a transaction, so if any item runs out mid-order, the whole order rolls back. **Stopping the double order.** Customers end with "ok, thanks!", and the model would sometimes place the same order again. Three layers fix it: - the prompt receives an `[ORDER STATUS]` block describing the order already placed; - earlier turns in the history are annotated with whether `place_order` actually succeeded; - the server rejects any identical set of items in the same conversation within 15 minutes. **Selling, not just answering.** A `[SALES BEHAVIOR]` section in the prompt makes the agent act like an experienced Bangladeshi seller: invite a decision after a few questions, suggest at most one extra item, and mention low stock only when it's true. **Spending AI calls only where they matter.** Comments are high volume, so buying intent is detected with a Bangla, Banglish, and English keyword list, with no model call. Trigger words escalate before the model is called. The first AI call happens only when a customer actually replies in Messenger. **Facebook's 24-hour rule.** A page can only reply within 24 hours of the customer's last message. A cron job marks expired conversations in the dashboard, and any new message from the customer reopens them automatically. ## Where it stands Pagewala is live at [pagewala.com](https://www.pagewala.com/). A seller can sign up for free, connect a Facebook Page, add a catalog, and have the agent answering Messenger in under 10 minutes, with no credit card. I built it solo, from the first commit in April 2026 to a working product with a seller dashboard, order management, analytics, comment automation, and a platform admin panel by August. ## What I learned Building it was the easy part. Getting an agent to hold a good sales conversation in Bangla and Banglish came together faster than I expected. In a demo, a model that gets things right almost every time looks finished. Production is different. Once real customers, real sellers, and real money are involved, "almost every time" isn't good enough. The rare miss is an order at the wrong price, the same order placed twice, or the last item sold to two people. Each of those lands on a small business that has to pack, ship, refund, or apologize for it. That's why most of the work in this case study isn't about the conversation at all. It's the server-side price lookup, the atomic stock update, and the duplicate-order guard. Building is easy. Production hits harder, especially when it touches money, so I now design for the failure cases from the first line. ## What's next WhatsApp alerts for new orders and escalations are designed but not wired up yet; today sellers see them in the dashboard. Background work will also move from `after()` to a durable queue, so a slow model call can never be lost. --- # Experience ## Software Engineer III (Full Stack, AI), Nordivo 2026 – Present · Helsinki, Finland - Designing and developing an SEO Intelligence Engine using FastAPI, LangGraph, LangChain, Celery, Redis, and PostgreSQL. - Building autonomous multi-agent orchestration for SEO analysis, competitor research, keyword discovery, and AI-powered content generation. - Developing coordinator and specialist agents with human-in-the-loop approvals, workflow automation, and outcome tracking. - Architecting and deploying scalable, cost-conscious AI services on Google Cloud using Cloud Run, Cloud SQL, Secret Manager, IAM, and Cloud Scheduler. - Implementing Bitbucket Pipelines for automated containerized deployments to Google Cloud. **Stack:** Python, FastAPI, LangGraph, LangChain, Celery, Redis, PostgreSQL, Google Cloud, Docker, Bitbucket Pipelines ## Software Engineer (L3), Dynamic Solution Innovators Ltd. Jul 2023 – Apr 2026 - Led a team of 5 to ship a large-scale B2B product for US banks & credit unions — campaign management, direct mail design, offer management, landing pages, surveys, analytics, with Email & SMS targeting. - Redesigned a message queue-based Express.js + Spring Boot service: cut image generation time by 75%, RAM by 62.5%, CPU by 66.67% — processing 1M+ images/day on a single server. - Engineered an OAuth-based API Gateway (Spring Cloud Gateway) fronting all 100+ microservices and 100M+ requests/day using Virtual Threads. - Built an Audience Upload pipeline with Spring Batch to process 1M+ records efficiently. - Automated deployment of 10+ microservices via Docker and GitLab CI/CD pipelines. **Stack:** Java, Spring Boot, Spring Cloud, Node.js, React, MongoDB, PostgreSQL, Docker, AWS, Xero API, OpenAI ## Full Stack Developer & AI Consultant, Upwork (Freelance) Sep 2023 – Present · Top Rated · 100% Job Success · $6K+ earned · 9 jobs · 5.0 avg rating - Delivered 9 client projects across backend, frontend, and full-stack — earning 100% Job Success and Top Rated status. - Built long-term relationships with repeat clients, with 5 projects for a single UK-based client totaling $4,800+. - Also run a Development & IT Consultation service — 7 sessions, all 5-star rated — covering architecture reviews, tech stack selection, system design, and project feasibility. **Stack:** Node.js, Express.js, NestJS, React, Spring Boot, PostgreSQL, REST APIs ### Client projects #### Backend Cleanup & Long-term Development UK-based SaaS Client (repeat) · Mar 2024 – Mar 2025 · $3,880 earned · 5/5 Year-long engagement including backend architecture cleanup, feature development, and ongoing maintenance across multiple services. **Stack:** Node.js, Express.js, NestJS, REST APIs > Great work, attention to detail, would highly recommend. #### Full-Stack API Integration International Client · Mar 2025 – Present · $800 earned · 5/5 Currently building full-stack features with multiple third-party API integrations. **Stack:** Full Stack, API Integration #### Spring Boot + React + PostgreSQL Website International Client · May 2024 – May 2025 · $400 earned · 5/5 End-to-end development and deployment of a full-stack web application. **Stack:** Spring Boot, React, PostgreSQL #### HIPAA-Compliant React Application Healthcare Client · Feb 2024 – May 2024 · $1000+ earned · 5/5 Senior React + Spring Boot development for a HIPAA-compliant healthcare platform — 21 hours of hourly work. **Stack:** React, Spring Boot, Java, HIPAA #### Node.js RESTful API Development UK-based Client (repeat) · Dec 2023 – Mar 2024 · $500+ earned · 5/5 Designed and built high-performance RESTful APIs with Node.js and Express.js for integration with a Next.js frontend. Two separate contracts. **Stack:** Node.js, Express.js, REST APIs, Next.js > Great work provided, I would highly recommend Mehedi. #### NestJS Backend Service UK-based Client (repeat) · Jan 2024 · $450+ earned · 5/5 Rapid delivery of a NestJS backend service for an existing product. **Stack:** NestJS, Node.js, TypeScript > Great work as usual. #### REST API & React Integration Japan-based Client · Sep 2023 – Nov 2023 · $550 earned · 5/5 Built REST APIs with Node.js, Express, and Mongoose for a Next.js admin panel with 6 resource types. Deployed on Render.com. Separate contract for React frontend API integration. **Stack:** Node.js, Express.js, Mongoose, React, Next.js > Very well done, definitely will hire again. Fast response as well as good understanding of development in general. ## Software Engineer L1, Dynamic Solution Innovators Ltd. Sep 2021 – Jun 2023 - Built scalable RESTful APIs with Spring Boot and Express.js; optimized MongoDB and PostgreSQL queries, reducing data fetch time by 30%. - Built a custom React.js drag-and-drop editor using Context API, Redux, and TanStack Query for the B2B banking product. - Developed a Python-based CV/resume parser with 80% prediction accuracy for an ATS system. - Dockerized multiple services and automated deployments via Ansible & Jenkins CI/CD pipelines. - Integrated report generation (PDF, XLSX) with Java iText — reduced HR workload by 20–30%. **Stack:** Spring Boot, Express.js, React.js, Python, MongoDB, PostgreSQL, Docker, Jenkins ## Software Engineer (Part-time), Logiqbits (Startup) Jun 2020 – Sep 2021 - Built the MyBebsha mobile (Android) application from scratch using Flutter for mybebsha platform, onboarding 1000+ sellers. It is a seller e-com application to digitalise their shop. - Implemented design from Figma, work on push notifications with Firebase and used Bloc as well as Cubits for state management while following bloc pattern architecture. - Responsible for managing app testing and release in Google Play Console. - Built RESTful APIs with Express.js — JWT auth, role-based access, and file uploads for a headless CMS. - Implemented a module-based permission system for granular access control in a SaaS blog platform. **Stack:** Flutter, Dart, Express.js, Node.js, JWT, MongoDB --- # Services Open to collaborations. To start a conversation, email mhshifat757@gmail.com. ## AI-Native Product Development Design and build AI-powered products from the ground up — combining LLMs, agent workflows, and modern architectures to create intelligent, production-ready systems. - LLM integration (OpenAI, Claude, Gemini, local models) - AI agent systems (tool use, multi-step workflows, orchestration) - RAG pipelines, vector embeddings, and knowledge retrieval - Vibe coding with AI-assisted development (Loveable, Builder.io, Bolt, Claude Code, Codex) - Automation with n8n and AI-driven workflows **Ideal for:** Startups and teams building AI-first products or adding intelligent capabilities like copilots, assistants, or automated decision systems. ## Technical Strategy & AI Consultation Practical, execution-focused guidance on architecture, AI adoption, and product feasibility — based on real-world experience building scalable systems and AI integrations. - AI adoption strategy (where and how to use LLMs effectively) - System architecture & design reviews - Tech stack selection for AI + product scalability - Performance, cost, and feasibility analysis - Rapid validation of product ideas and MVP scope **Ideal for:** Founders, CTOs, and teams navigating AI adoption or making high-impact technical decisions. ## Full-Stack Product Engineering End-to-end product development — from idea to production. I build fast, scalable, and maintainable applications with AI deeply integrated into the development workflow. - Next.js / React frontend with TypeScript - Node.js / Spring Boot backend systems - AI-integrated features (generation, summarization, automation) - Database design (PostgreSQL, MongoDB) - Cloud deployment, CI/CD, and production readiness **Ideal for:** Teams and founders who need to ship MVPs quickly or build production-grade products with modern stacks. ## Backend Systems & Scalable APIs Design and build high-performance backend systems that scale — from microservices to data pipelines, with a strong focus on reliability and efficiency. - Microservices architecture (Spring Boot, NestJS) - API design & gateway systems (high-throughput, low-latency) - Batch processing & data pipelines (large-scale datasets) - System optimization and performance tuning - Integration with AI services and external APIs **Ideal for:** Products handling scale, complex workflows, or requiring robust backend systems to support growth. --- # Never Let the Model Touch the Price By Mehedi Hasan Shifat · 2026-10-09 · AI, Agents, LLMs, Product Engineering > Lessons from building an AI sales agent that takes real orders: the model can suggest, but the server decides, especially when money and stock are involved. When I started building [Pagewala](https://www.pagewala.com/), an AI sales agent that answers customers and takes orders in Facebook Messenger, the hard part wasn't getting the model to sound like a good salesperson. The hard part was making sure it could never cost a seller money. A chatbot that gets a fact wrong is embarrassing. An agent that records an order at the wrong price, or sells stock that doesn't exist, is a real loss for a small business. So the whole design comes down to one rule: **The model proposes. The server decides.** ## The Model Gets Exactly Two Tools Pagewala's agent can do two things besides talk: `place_order` and `escalate`. That's the whole surface. Fewer tools means fewer ways to go wrong. The model doesn't look up prices, update stock, or touch the database. It fills in a structured order: product IDs, quantities, name, phone, address, and payment method. Then it hands that over. The prompt tells it to only use listed products, never invent a price, and recap the full order before placing it. Those instructions help. But they're instructions, and instructions are not guarantees. ## Price Comes From the Database, Never the Model The `place_order` schema still has a `unit_price` field, because models tend to echo the price back anyway. The server ignores it completely. For every item, the price is looked up by `product_id`. If someone talks the model into "the price is ৳10 now", it doesn't matter. The number the model writes never reaches the order. The same goes for everything else the server can check: - Quantity must be a positive integer. - Name, phone, and address must be present, or the order is rejected and the agent asks again. - Every query is scoped to the seller's page, so one shop can never touch another's products. ## Stock Is Decremented Atomically Two customers can try to buy the last item at the same moment. So the stock check and the decrement are one conditional update inside a transaction (simplified): ```ts await tx .update(products) .set({ stockQuantity: sql`${products.stockQuantity} - ${quantity}` }) .where( and( eq(products.id, productId), eq(products.pageId, page.id), sql`${products.stockQuantity} >= ${quantity}` ) ); ``` If any item in the order can't be fulfilled, the whole transaction rolls back and the customer is told it just sold out. There's no partial order and no negative stock. ## The "Ok, Thanks!" Problem This one surprised me. A customer confirms an order. The agent places it. The customer replies "ok thanks!" and the model sometimes calls `place_order` again with the exact same items. It makes sense from the model's point of view. The conversation still ends with a confirmed order and a happy customer. So I fixed it in three layers: 1. **Tell the model what already happened.** When an order exists in the conversation, the prompt gets an `[ORDER STATUS]` block: what was ordered, the total, and when. It's told to just say thanks. 2. **Show it the outcome of its own tool calls.** Earlier turns in the history are annotated with whether `place_order` actually succeeded, failed, or was skipped. Without that, the model only sees that it called the tool, not what happened. 3. **Refuse duplicates on the server anyway.** An identical set of items in the same conversation within 15 minutes is treated as the same order. The check runs before any stock changes, so a repeated call can't double-decrement stock or double-notify the seller. The first two make the model behave. The third makes it not matter when it doesn't. ## Spend AI Calls Only Where They Pay Off Guardrails aren't only about correctness. They're also about cost. - A seller can define trigger words. If one appears, the conversation goes straight to a human without calling the model at all. - Comments under posts are high volume, so buying intent ("price?", "dam koto?") is detected with a keyword list, not the model. The first AI call happens only when the customer actually replies in Messenger. - A photo is sent along with the one main model call, instead of making a separate vision call first. ## The Pattern None of this is specific to sales. Any agent that touches something real (money, inventory, bookings, permissions) needs the same split: - Let the model handle language: understanding, persuading, collecting details. - Let the server handle facts: prices, stock, identity, and whether something already happened. - Assume the model will occasionally do the wrong thing, and make sure the wrong thing is harmless. ## If You're Building Your First Agent That Takes Actions Start from the question "what's the worst thing this tool call could do?", not "how do I make the model call it correctly?" The "ok, thanks!" double order taught me that. My prompt was clear. The model understood it most of the time. And "most of the time" is not good enough when every mistake is a real order a seller has to pack, ship, or cancel by hand. So for every tool, I now ask three things before writing a single line of prompt: 1. **What does the server re-check?** Anything that can be looked up should be looked up, not taken from the model. 2. **What happens if it's called twice?** Make repeats harmless, because they will happen. 3. **How does the model find out what happened?** If it can't see the result of its last action, it will guess, and its guess is usually "do it again." Prompting makes an agent behave well. Server-side checks keep it safe when it doesn't, and only the second kind of work lets you put it in front of real customers. --- # Why I Built Exciton By Mehedi Hasan Shifat · 2026-10-09 · AI, Claude Code, Developer Tools, Agents > Agentic frameworks for Claude Code install once and govern every session. A three-line bug fix shouldn't get the same ceremony as a new subsystem, so I built a per-session dial. Agentic frameworks like [superpowers](https://github.com/obra/superpowers) make Claude Code dramatically better at big work. They push it to brainstorm first, write a plan, get approval, and work in small, reviewed steps. For a new subsystem, that's exactly what I want. For a three-line bug fix I've already diagnosed, it's a lot of ceremony. It kept happening on the smallest tasks. I'd already read the stack trace, found the line, and knew the fix. All I wanted was the diff. Instead, the session opened with a brainstorm, asked clarifying questions about a change I'd already decided, and proposed writing a plan for my approval. None of that was the framework misbehaving. It was doing exactly what it was built to do, on every task, because it had no way to know which tasks deserved it. After enough small fixes that took longer with the framework than without it, I stopped blaming the framework and started building the missing dial. ## The Problem: Frameworks Are All or Nothing These frameworks install once, globally, and then govern **every** session. Claude Code plugins are enabled by default when installed, and there's no supported way to say "this session, keep the skills around but don't force the process." Someone asked for exactly that in superpowers' [issue #645](https://github.com/obra/superpowers/issues/645): a mode that skips the automatic injection but keeps the skills callable. It was closed without being implemented. So the choice was: live with the ceremony everywhere, or uninstall the framework and lose it for the work where it shines. ## The Idea: A Per-Session Dial [Exciton](https://www.npmjs.com/package/exciton) runs Claude Code with a framework set to the level the task deserves, for one session, without changing anything else: ```sh npm i -g exciton exciton superpowers --no-hooks # skills stay callable, nothing auto-fires exciton superpowers # the full framework, exactly as published ``` Quit it, run plain `claude`, and everything behaves exactly as before. The name comes from physics. An exciton is a bound electron–hole pair. It exists only while the system is excited, and when it recombines, the material is exactly as it was. That's the whole design goal: a configuration that lives for one session and leaves no trace. ## How It Works Without Touching Your Setup Exciton uses two documented Claude Code features and nothing else: - `--settings '{"enabledPlugins":{"":false}}'` turns a plugin off for one session. - `--plugin-dir ` adds a plugin for one session from a directory you control. For `--no-hooks`, Exciton stages a copy of the framework with its `hooks/` directory left out. Hooks are discovered by convention, so removing the folder leaves nothing dangling. The skills are still there; nothing pushes them into the conversation. The most important rule: **nothing under `~/.claude` is ever written.** Exciton reads your Claude Code configuration and only writes inside `~/.exciton/`. It never runs `claude plugin install`, because installing a plugin enables it globally, which is the exact problem it exists to avoid. ## Decisions I Made on Purpose **One framework at a time.** Frameworks like superpowers, BMAD, and Spec Kit all define *how a session is run*, so two of them would fight over the same job. Naming two is refused. Ordinary plugins (language servers, MCP integrations, design helpers) just add capabilities, so Exciton never touches them. **No version picker.** A framework is either the copy Claude Code already has, or Exciton's own copy of the newest release, refreshed with `exciton update`. Choosing between releases is a question almost nobody needs answered, and supporting it would have meant a `@version` syntax that collides with Claude Code's own `name@marketplace` plugin IDs. **Explain before acting.** The first run walks you through what Exciton is and lets you add the frameworks you want. It doesn't assume you already agree with it. **Proof, not promises.** An integration test suite checks real Claude Code behavior against its own debug output, including that no Claude state file is modified. ## When I Reach for It My rule is simple: the amount of process should match the amount of uncertainty. **Plain `claude`** for mechanical work: a dependency bump, a config change, a rename, or a question about the codebase. No framework at all. **`exciton superpowers --no-hooks`** for work I've already figured out: a bug I've diagnosed, a small feature with an obvious shape, or a refactor I can describe in one sentence. The skills are still on the shelf, so if the task turns out bigger than I thought, I can ask for brainstorming or a plan by name. But nothing forces a design review on a three-line fix. **`exciton superpowers`** when the uncertainty is real: a new subsystem, an unfamiliar codebase, or anything where getting the design wrong is expensive. That's where brainstorm, plan, approve, and small reviewed steps earn their cost. The `xc` alias keeps all of this short, e.g. `xc superpowers --no-hooks`. The biggest change isn't speed. It's that I stopped fighting the framework. Before, every session meant either sitting through the full process or uninstalling the framework and losing it for the work it's great at. Now that decision takes one flag at the start of the session, and it never follows me into the next one. ## Try It ```sh npm i -g exciton exciton ``` It needs Node 22.18 or newer, Claude Code on your `PATH`, and macOS or Linux. The source and the full mechanism write-up are on [GitHub](https://github.com/jspw/exciton). --- # How to Use Claude Code or Codex for Real Coding Work By Mehedi Hasan Shifat · 2026-03-25 · AI, Claude Code, Codex, Developer Workflow > A practical Claude Code and Codex workflow for software engineers: discuss the idea first, lock the implementation plan, break work into epics, ship task by task, and write strong unit tests. If you want to use Claude Code or Codex for real coding work, the biggest mistake is asking the agent to build before the architecture is clear. Most bad experiences with AI coding agents come from using them too early and too vaguely. People open Claude Code or Codex, paste a rough idea, and say "build this." Sometimes it works. More often it produces code that looks convincing but has weak architecture, sloppy edge-case handling, and very uneven tests. The workflow that works for me is slower at the beginning and much faster by the middle. I do not start with implementation. I start with thinking. > **The short version:** Use Claude Code or Codex like a fast implementation partner, not a slot machine. Discuss the idea first, lock the architecture, break the work into small tasks, review every diff, and take testing seriously. ## Do Not Start in Execution Mode If the tool has a plan mode, I usually leave it off at the beginning. Early-stage work should stay conversational. I want the model to help pressure-test the idea before it starts touching files. This is where the strongest model and higher reasoning settings help the most. If the task is ambiguous, architectural, or risky, I will often use the best model available with high or max reasoning. The goal at this stage is not code. The goal is clarity. Here is the kind of prompt that works well: ```markdown I want to build a subscription analytics dashboard for B2B SaaS teams. Do not write code yet. Ask me the most important product and architecture questions first. Then propose a detailed implementation plan that covers: - data model - API boundaries - auth and permissions - UI structure - likely failure points Give me tradeoffs between two approaches and recommend one. ``` This usually surfaces the real issues early: - Do I need multi-tenant isolation? - Is this server-rendered or highly interactive? - Where does caching belong? - Which part is actually risky? If you skip this stage, the agent starts making assumptions for you. **When I switch to the best model and high or max reasoning** I do that when the task is architectural, ambiguous, or expensive to get wrong. Greenfield projects, auth boundaries, data modeling, caching strategy, and tricky refactors are good examples. I usually do not spend the strongest model on simple CRUD work or repetitive implementation. That is where a cheaper, faster execution loop is usually enough. ## Lock the Plan Before You Write Code Once the back-and-forth conversation has stabilized, I ask the agent to write down the plan and the reasoning behind it. This matters more than most people think. You want a durable record of: - What you are building - How you plan to build it - Why you chose this approach over alternatives - Where the risks are - How it should be tested I usually ask for something like this: ```markdown Write the final implementation plan as a working spec. For each major decision, include: - chosen approach - rejected alternative - why we rejected it - files or modules likely to change - testing strategy Keep it concise but detailed enough that we can execute from it. ``` That document becomes the operating manual for the rest of the work. It also stops the project from drifting every time the conversation gets long. ## Plan the Sprint in Epics, Not Random Tasks After the implementation plan is fixed, I ask the agent to turn it into a sprint plan. This is another place where people lose control. They ask the agent to build everything at once. That usually creates giant diffs, mixed concerns, and poor reviewability. A better approach is to break the work into deliverable epics with clear tasks. For example: 1. Foundation and schema setup 2. Auth and role boundaries 3. Analytics queries and API routes 4. Dashboard UI 5. Testing, hardening, and cleanup Then each epic gets smaller tasks that can be implemented safely in one pass. The prompt can be simple: ```markdown Turn the implementation plan into a sprint plan. Break it into deliverable epics. For each epic, include: - goal - task list - dependencies - acceptance criteria - key risks Keep tasks small enough that one agent run can complete them cleanly. ``` This does two useful things: - It gives you a clean execution order - It gives the agent smaller, safer units of work > **Why epics matter:** The point of epics is not project management theater. It is to keep the AI agent from mixing schema work, UI work, auth work, and tests into one giant diff that is painful to review. ## Execute One Task at a Time Once the sprint exists, I stop discussing the whole project and start operating task by task. This is where Claude Code and Codex become much more useful. They are very good when the scope is specific and the definition of done is clear. A good execution prompt looks like this: ```markdown Take Epic 2, Task 1: add role-based access middleware. Constraints: - follow the existing auth pattern - do not add dependencies - keep the middleware isolated from page components - add or update tests for the new behavior When done, give me: - files changed - what was implemented - what was tested - any open questions ``` That is dramatically better than saying "add RBAC." The more specific the task package is, the less time you spend correcting avoidable mistakes. **What I expect back after each task** - A short summary of what changed - The exact files touched - What tests were added or updated - Any compromises, assumptions, or open questions ## Review Every Task Like a Real PR This part is non-negotiable. Do not treat AI-generated code as either magical or disposable. Review it the same way you would review code from a smart but fast-moving teammate. The questions I care about are: - Does the architecture still make sense? - Did the agent solve the right problem or just the easiest version? - Is the code over-engineered? - Did it silently change behavior outside the task boundary? - Are the names, abstractions, and file placements coherent? AI agents are often directionally correct but locally messy. Review is where the quality comes back. ## Unit Testing Is Where You Save Yourself This is the part I would emphasize the most. AI agents can write plausible code very quickly. They can also write plausible bugs very quickly. Unit tests are one of the few reliable defenses against that. The mistake is letting the agent improvise the test strategy after the implementation is already written. I prefer to be very deliberate here. > **The main risk:** AI-written code often looks more correct than it actually is. The danger is not obviously broken code. The danger is subtle behavior that passes casual review and fails later in production. Before or during implementation, I ask for the test plan explicitly: ```markdown Before finalizing the code, list the unit test matrix for this task. Cover: - happy path - boundary conditions - invalid input - permission failures - regression cases Call out any behavior that should be integration-tested instead of unit-tested. ``` That one step catches a lot of weak testing. **What I check in AI-written unit tests before approving them** - Whether the tests challenge behavior instead of mirroring implementation details - Whether permission failures and invalid input are covered - Whether mocks are lightweight enough that the test still proves something real - Whether edge cases are named clearly enough to document intent - Whether a few cases should really be integration tests instead ## What Good AI-Written Tests Look Like Bad AI-written tests usually have one of these problems: - They only test the happy path - They assert implementation details instead of behavior - They mock so much that the test proves nothing - They miss authorization and failure cases - They duplicate the code's assumptions instead of challenging them Good tests do the opposite. Imagine the agent is implementing a function that archives a project. A useful test suite would not stop at "project archives successfully." It would also check: - a user cannot archive another workspace's project - archiving an already archived project is handled correctly - audit logs are written - invalid project IDs fail cleanly A simple example: ```typescript it("rejects cross-workspace archive attempts", async () => { await expect( archiveProject({ actorWorkspaceId: "workspace-a", projectWorkspaceId: "workspace-b", projectId: "proj_123", }) ).rejects.toThrow("Forbidden"); }); ``` That kind of test is valuable because it checks a real failure mode, not just a happy-path output. ## The Workflow in Practice If I simplify the whole process, it looks like this: 1. Keep the early conversation open and exploratory. 2. Use stronger models and higher reasoning for architecture and ambiguous decisions. 3. Lock the implementation plan and record the rationale. 4. Turn the plan into sprint epics and concrete tasks. 5. Ask the agent to implement one task at a time. 6. Review every task carefully. 7. Be extremely attentive to unit tests and edge cases. That is the difference between using AI as autocomplete and using it as an engineering partner. > **A simple rule:** Never let the agent earn the right to implement by writing lots of code. Let it earn the right by showing a sound plan, clear tradeoffs, and a test strategy you trust. ## Where People Usually Go Wrong Most failures come from one of these habits: - Starting implementation before the idea is clear - Asking for huge end-to-end builds in one shot - Not writing down decisions and tradeoffs - Skipping review because the output "looks right" - Treating tests as optional or low priority If you fix those five things, your success rate with Claude Code or Codex goes up immediately. ## Final Thought The best way to use Claude Code or Codex is not to hand over the keyboard and hope for the best. Use them for what they are exceptionally good at: executing clearly defined work, moving fast through mechanical implementation, and helping you maintain momentum. But keep ownership of the hard parts: the architecture, the planning, the sequencing, the review, and especially the tests. That is where good software still gets made. --- # Context Engineering Beats Clever Prompts By Mehedi Hasan Shifat · 2026-03-24 · AI, LLMs, Prompt Engineering, Developer Tools > In the current AI era, model quality depends less on clever wording and more on the context you assemble around the task. For the first year of the AI boom, everyone obsessed over prompt wording. Add "act as a senior engineer." Add "think step by step." Add five more adjectives. Sometimes it helped. Usually it didn't. The real lever turned out to be context. If the model has the right constraints, examples, current state, and source material, average prompts perform surprisingly well. If that context is missing, no amount of prompt polishing will save the output. ## The Prompt Is Only the Tip Most bad AI output is not caused by a weak sentence at the top of the prompt. It is caused by the model not having the information needed to do the job well. That missing information usually falls into one of these buckets: - What the task actually is - What "good" looks like in this product or company - What data, files, or APIs are relevant right now - What constraints must not be violated When people say "the model is inconsistent," they often mean "the model is guessing across missing context." ## What Context Engineering Actually Means Context engineering is the practice of packaging the task so the model can reason with the right materials instead of improvising from general training data. A strong context stack usually contains: - Stable instructions: conventions, non-negotiable rules, output format - Working context: the specific files, records, or documents needed for this task - Examples: one or two good outputs that define the bar - Tool access: retrieval, search, codebase access, or structured data lookups - State: what already happened in the current session and what changed recently That is the difference between a toy demo and a reliable workflow. ## A Better Way to Package Work Instead of writing a giant paragraph, I now build small context bundles. ```markdown Task: Write release notes for version 2.4.0 Constraints: - Keep it under 200 words - Lead with breaking changes - Match the tone of previous release notes Reference: - Last three release note entries - Product style guide Working data: - Merged PR titles and labels - Version number - List of breaking schema changes ``` This is not prompt magic. It is task packaging. The output gets better because the model no longer has to infer what matters. ## Retrieval Beats Copy-Paste A common mistake is shoving everything into the prompt window and hoping for the best. More context is not automatically better. Bad context is expensive noise. The better approach is selective retrieval: - Pull the relevant docs, not the whole wiki - Pass the touched files, not the whole repository - Include recent conversation state, not the entire chat transcript - Use examples that match the task closely The model needs a clean working set, not a data landfill. ## Failure Modes to Watch Context engineering sounds obvious until you see how often teams get it wrong. ### 1. Stale context Your prompt says one thing. The docs say another. The codebase says a third thing. The model is not confused because it is weak. It is confused because you fed it contradictions. ### 2. Missing state Agentic workflows break when the model cannot see what already changed. If it does not know which files were edited or what the current plan is, it will redo work or drift. ### 3. Overloaded context When you include too much low-signal material, the important details become harder to use. This is the AI version of bad information architecture. ### 4. No examples of taste Style guides help, but examples are better. If you want a specific voice, structure, or code pattern, show one. ## How This Changes Product Teams In the current AI era, the highest leverage people are not the ones with the fanciest prompts. They are the ones who know how to structure knowledge. That means: - Designers need clearer pattern libraries - Engineers need better project docs and cleaner boundaries - Product teams need shared definitions of "done" - Everyone benefits from examples, checklists, and source-of-truth docs AI exposes messy context faster than humans do. If your internal knowledge is fragmented, model output will mirror that fragmentation. ## A Practical Checklist Before blaming the model, check these first: - Did I give it the exact task and desired output shape? - Did I include the relevant files, docs, or records? - Did I define constraints clearly? - Did I show at least one example of a good answer? - Did I remove stale or conflicting instructions? - Did I keep the working set narrow enough to stay focused? Most quality gains come from fixing those six things, not from rewriting the first sentence ten times. ## The Bigger Shift Prompt engineering was always a transitional phrase. The durable skill is context design. That applies whether you are building coding agents, AI support tools, internal copilots, or customer-facing assistants. The model is only one layer. The real product is the system around it: the retrieval, the constraints, the memory, the examples, and the review loop. The teams that understand that are going to build AI products that feel reliable. Everyone else will keep arguing about wording while the model keeps guessing. --- # Shipping Software in the Agent Era By Mehedi Hasan Shifat · 2026-03-24 · AI, Agents, Software Engineering, Productivity > AI agents did not remove engineering work. They shifted the bottleneck from typing code to defining scope, guardrails, and review loops. The old bottleneck in software was implementation throughput. You had more ideas than engineering hours, so every feature had to fight for attention. That bottleneck is moving. In the agent era, writing code is cheaper than it used to be. The expensive part is now upstream and downstream of implementation: framing the task well, reviewing the change, verifying the result, and deciding whether the feature should exist at all. That changes how good teams operate. ## The Bottleneck Moved A lot of discussions about AI in software still fixate on code generation quality. That matters, but it misses the point. The bigger shift is this: once an agent can touch multiple files, read project context, and execute a task end to end, the scarce skill is no longer typing speed. It is operational clarity. Can your team define work precisely? Can you isolate risky changes? Can you verify behavior quickly? Can you keep architectural quality while moving faster? Those questions decide whether agents create leverage or chaos. ## What Good Agent Work Looks Like The highest-value prompts are not clever. They look like clean task briefs. ```markdown Goal: Add bulk archive to the admin users table Constraints: - Keep the page server-rendered - Reuse the existing confirmation dialog - Do not add dependencies Files to inspect: - src/app/admin/users/page.tsx - src/components/admin/UsersTable.tsx - src/components/ui/ConfirmDialog.tsx Done when: - Multiple rows can be selected - Archive requires confirmation - Success and failure states are visible to the admin - A regression test covers the new flow ``` That structure does three things: - It narrows the search space - It communicates quality expectations - It makes the review easier because "done" is explicit ## The New Engineering Loop My default loop now looks like this: 1. Package the task with constraints, file references, and definition of done. 2. Let the agent implement the first pass. 3. Review the diff like a human teammate's work. 4. Run tests, verify behavior, and trim anything unnecessary. Notice what disappeared: long stretches of mechanical implementation. Notice what became more important: task design and judgment. ## What Humans Still Own This is the part people either overstate or understate. Agents are great at local execution. Humans still need to own the cross-cutting decisions: - Architecture: where the change belongs and what abstractions are justified - Product judgment: whether the feature solves the right problem - Risk boundaries: what must be reviewed manually and what can be automated - Quality standards: what "done" means in this codebase If you hand all of that over, velocity goes up for a week and codebase entropy goes up for a year. ## Where Teams Waste the Gain Most teams do not lose time because the model is slow. They lose time because the workflow around it is sloppy. Common traps: - Vague asks like "improve this" or "clean this up" - No constraints on dependencies, architecture, or scope - No test or verification path - Huge prompts with weak signal - Accepting AI output wholesale instead of editing aggressively Agent workflows reward sharp boundaries. If the ask is fuzzy, the implementation will be fuzzy too. ## Metrics That Actually Matter If you want to know whether your team is adapting well to the current AI era, stop measuring vibes and start measuring workflow health. The useful signals are: - Cycle time from idea to verified change - Review time per task - Defect rate after AI-assisted changes - Scope completed per week, not just number of commits - Time spent on boilerplate versus decisions The goal is not "more AI." The goal is more shipped value per unit of engineering attention. ## Small Teams Benefit the Most This shift disproportionately helps small product teams. Why? Because small teams are usually constrained by implementation bandwidth, not by a lack of ideas. When agents compress the cost of routine engineering work, small teams can afford to take on broader features, cleaner refactors, and better polish. But there is a catch: the team has to stay disciplined. Without conventions, review standards, and clean task packaging, agents just help you create a mess faster. ## The New Advantage For a long time, engineering advantage came from hiring more builders or finding unusually productive ones. Now there is another lever: teams that can convert messy product intent into precise, agent-ready work packages will outship teams that still operate through vague tickets and slow handoffs. That is the real story of software in the agent era. The implementation got cheaper. Clarity became the premium skill. --- # Why AI Products Need an Evaluation Layer By Mehedi Hasan Shifat · 2026-03-23 · AI, Evals, Product Engineering, LLMs > If your product depends on model output, you need more than anecdotes and vibes. You need evals that tell you when quality is improving or regressing. AI products fail in a very specific way: they look good in demos and unstable in production. That happens because humans are bad at evaluating probabilistic systems by memory. We remember the impressive outputs, forgive the misses, and tell ourselves the product is "getting smarter" even when quality is drifting sideways. If model output affects user trust, your team needs an evaluation layer. Not eventually. Early. ## Why Manual QA Breaks Down Traditional software testing assumes deterministic behavior. Given the same input, the same code should produce the same result. LLM systems are different: - Output quality is partly subjective - Small prompt changes can cause broad behavior shifts - Retrieval changes can improve one case and break another - Model upgrades can alter tone, latency, and failure modes at once You cannot reliably manage that with ad hoc spot checks in staging. ## What an Evaluation Layer Actually Is An evaluation layer is a repeatable way to answer one question: Did this change make the product better, worse, or just different? At minimum, that means: - A representative dataset of real or realistic tasks - Clear success criteria for each task - A repeatable way to run the system against that dataset - A score or review process that can be compared over time Without that, every prompt change is basically a guess. ## Start Smaller Than You Think Teams hear "evals" and imagine a big platform project. That is unnecessary at the beginning. A small evaluation setup can be enough: ```json { "input": "Summarize this support conversation for the CRM", "checks": [ "mentions refund amount", "captures customer sentiment", "does not invent company policy" ] } ``` Collect 30 to 50 examples like that and you already have something useful. You can run prompt changes against them and inspect the deltas instead of relying on intuition. ## Three Kinds of Evals That Matter ### 1. Deterministic checks Use these when there is a hard rule: - JSON parses correctly - Required fields are present - PII is redacted - Citations are included - Tool calls match the schema These are cheap, reliable, and should be your first layer. ### 2. Model-graded or rubric-based checks Use a rubric when quality is partly semantic: - Did the summary capture the key issue? - Did the answer stay grounded in the provided context? - Did the tone match the product requirement? This layer is less precise than deterministic checks, but it catches real product regressions that syntax tests miss. ### 3. Human calibration You still need periodic human review, especially for nuanced tasks. The goal is not to remove people from evaluation. The goal is to focus their attention where it matters most. Human review is best used to: - Calibrate rubrics - Audit edge cases - Catch subtle trust failures - Re-label examples as the product evolves ## Metrics Beyond "Accuracy" "Accuracy" is often too vague to be useful in AI systems. The better question is: what kind of failure actually hurts the user? That usually leads to more practical metrics: - Hallucination rate - Groundedness to retrieved context - Task completion rate - Refusal rate when the model should answer - Latency at acceptable quality - Cost per successful task A cheaper model that fails more often can be more expensive at the product level. A faster answer that users do not trust is not really faster. ## The Evaluation Layer Is Product Infrastructure This is the mindset shift I think most teams still miss. Evals are not a research luxury. They are production infrastructure for any product that puts model output in front of users. You would not ship payments without monitoring. You would not ship authentication without logs. You should not ship AI features without a way to measure behavior change. ## A Good First Week Plan If you are shipping an AI feature right now, do this first: 1. Pick one high-value workflow, not the entire product. 2. Collect 30 real examples or realistic simulations. 3. Define three obvious failure modes. 4. Add deterministic checks where possible. 5. Review outputs before and after every prompt, retrieval, or model change. That is enough to stop flying blind. ## The Teams That Win In the current AI era, product quality will increasingly depend on how well teams manage model behavior over time, not just how quickly they can connect to an API. The winners will not be the teams with the flashiest demos. They will be the teams with tight feedback loops, representative eval sets, and the discipline to measure regressions before users do. That is what makes AI features feel dependable instead of lucky. --- # Claude Code Changed How I Build Software By Mehedi Hasan Shifat · 2026-03-20 · AI, Claude Code, Productivity, Developer Tools > I stopped using AI as autocomplete and started using it as an implementation partner. Here's how Claude Code reshaped my entire development workflow. Six months ago I was using Copilot like everyone else — tab-completing boilerplate, occasionally impressed, mostly indifferent. Then I started using Claude Code as my primary implementation partner and everything shifted. This isn't a product review. It's a workflow breakdown from someone who ships production code with AI every single day. ## The Mental Model Shift Most developers treat AI coding tools as fancy autocomplete. You write a function signature, it fills in the body. That's useful but small. The shift: **think in tasks, not lines of code.** Instead of writing code and asking AI to finish it, I describe what I want at a higher level and let Claude handle the implementation. My job becomes architecture, review, and direction. ```markdown # What I used to do: 1. Write function skeleton 2. Let Copilot fill it in 3. Fix the parts it got wrong # What I do now: 1. Describe the feature or fix 2. Claude Code implements it across multiple files 3. I review, adjust direction, iterate ``` The difference isn't speed — it's **scope**. I can tackle tasks that would've taken hours of boilerplate in minutes. ## My Daily Workflow Here's what a typical session looks like: ### 1. Start with context I keep a `CLAUDE.md` at the project root with architecture decisions, conventions, and constraints. Claude reads it automatically. This is the single highest-leverage thing you can do — it turns generic AI assistance into project-aware collaboration. ```markdown # CLAUDE.md example - Use server components by default, "use client" only for interactivity - All data lives in content/data/*.json with thin TS wrappers - Glass-card design system with violet/blue/cyan gradient accents - Never add dependencies without asking ``` ### 2. Work in conversation I don't ask Claude to write isolated functions. I describe what I'm building and let the conversation evolve: > "Add a collapsible toggle for the client projects section. Keep ExperienceItem as a server component — extract just the collapsible part as a client component." Claude creates the component, updates the imports, handles the state management. One prompt, multiple coordinated file changes. ### 3. Review like a senior engineer This is where most people go wrong — they accept or reject wholesale. Instead, I review AI output the same way I'd review a junior engineer's PR: - Does the approach make sense architecturally? - Are there edge cases it missed? - Does the code match the project's conventions? - Is it over-engineered? The last point is important. AI tends to add error handling, type guards, and abstractions you didn't ask for. I trim aggressively. ## Patterns That Work ### Parallel exploration When I'm unsure about an approach, I'll ask Claude to explore multiple options: > "Show me three ways to handle dark mode persistence. Pros and cons of each." This replaces 30 minutes of Stack Overflow and blog posts with a focused comparison tailored to my exact stack. ### Data migration Moving hardcoded TypeScript arrays to JSON data files? Tedious, error-prone work that AI handles perfectly: > "Migrate all static data from src/data/*.ts to content/data/*.json. Keep thin TS wrapper files for type-casting. Update all imports." Seven files changed, zero bugs. This is the kind of task where AI earns its keep — mechanical transformations across many files with consistent patterns. ### CSS debugging Describing visual bugs in text is surprisingly effective: > "In dark mode, the glass cards appear whitish instead of the dark translucent look. The content is hard to read against the background." Claude identified that `:not(.dark)` CSS selectors were matching intermediate DOM elements, not just ``. A subtle specificity bug I might have spent an hour on. ## What AI Is Bad At Let's be honest about the failure modes: **Taste.** AI doesn't know when something looks off. It can implement any design you describe, but it won't tell you that your color palette feels muddy or that a section needs more whitespace. You still need design sensibility. **System boundaries.** When the bug is at the intersection of multiple systems — say, a CSS specificity issue caused by how a React framework applies class names at build time — AI can struggle to connect the dots without explicit guidance. **Knowing when to stop.** Ask Claude to "improve" something and it'll keep going. Add error handling, add types, add tests, add documentation. You have to be specific about scope and firm about "that's enough." ## The Productivity Math I tracked my output over three months. Rough numbers: - **Features shipped per week:** ~40% more than pre-AI baseline - **Time per feature:** down, but not dramatically — maybe 25% - **Scope per feature:** this is the real win — I'm building more ambitious things because the implementation cost dropped The time savings alone don't justify the workflow change. The scope expansion does. Projects I would've simplified or deferred are now shipping. ## Getting Started If you want to try this workflow: 1. **Set up `CLAUDE.md`** in your project root. Spend 20 minutes documenting your conventions, stack decisions, and constraints. This pays for itself immediately. 2. **Start with refactoring tasks.** Migration, restructuring, moving files — low risk, high volume, perfect for building trust in the workflow. 3. **Graduate to feature work.** Once you're comfortable reviewing AI output, start describing features at a higher level and letting Claude handle implementation. 4. **Keep your architectural brain engaged.** The moment you stop thinking critically about the code being written, quality drops. AI is your implementation partner, not your replacement. ## The Bigger Picture We're at an inflection point. The developers who figure out how to work *with* AI — directing it, reviewing its output, maintaining architectural ownership — are going to ship at a fundamentally different pace than those who don't. It's not about AI writing your code. It's about you becoming the architect of a system where AI handles the implementation. The skills that matter shift from "can you write this function" to "can you design this system, evaluate tradeoffs, and maintain quality at higher velocity." That shift is already happening. The question is whether you're adapting your workflow to match. --- # TypeScript Patterns I Actually Use By Mehedi Hasan Shifat · 2025-11-15 · TypeScript, JavaScript > Not the advanced wizardry — just the practical patterns that show up in real codebases and make the type system work for you. There's a gap between "TypeScript exists" and "TypeScript is making my codebase meaningfully safer." These are the patterns that close that gap in day-to-day work. ## Discriminated Unions for State Instead of a mess of optional fields, model mutually exclusive states explicitly: ```typescript type RequestState = | { status: "idle" } | { status: "loading" } | { status: "success"; data: T } | { status: "error"; error: string }; ``` Now exhaustive `switch` statements work and TypeScript narrows `data` and `error` to the right variants automatically. ## `satisfies` for Config Objects `satisfies` validates against a type without widening — you keep the literal types: ```typescript const routes = { home: "/", blog: "/blog", contact: "/contact", } satisfies Record; // routes.home is typed as "/" not string ``` This is great for config objects where you want both validation and autocompletion on the literal values. ## `Awaited>` When you need the resolved return type of an async function without duplicating a type definition: ```typescript async function getUser(id: string) { return db.user.findUnique({ where: { id } }); } type User = Awaited>; ``` ## Branded Types for IDs Plain `string` types for IDs are too permissive. Brand them to prevent mixing up `UserId` and `PostId`: ```typescript type UserId = string & { readonly _brand: "UserId" }; type PostId = string & { readonly _brand: "PostId" }; function createUserId(id: string): UserId { return id as UserId; } ``` Now passing a `PostId` where a `UserId` is expected is a type error. ## `infer` for Extracting Types Useful when you need to pull a type out of a generic: ```typescript type UnpackPromise = T extends Promise ? U : T; type UnpackArray = T extends Array ? U : T; ``` ## Closing Thoughts The goal isn't type gymnastics — it's catching real bugs. Discriminated unions and branded types give you the most safety per line of type code. Use the rest when the problem actually calls for it. --- # Uses ## Daily drivers - **[Claude Code](https://www.anthropic.com/claude-code):** My main coding agent. Discuss the idea, lock the plan, then ship it task by task. - **[Codex](https://openai.com/codex):** The other agent I run, with the same plan-first workflow. - **[VS Code](https://github.com/jspw/VS-Code-Config):** Where I review every diff. My config has 150+ stars on GitHub. - **[Superpowers](https://github.com/obra/superpowers):** Brainstorm, plan, then small reviewed steps. I dial it per session with Exciton. ## AI tooling - **[Exciton](https://github.com/jspw/exciton):** Runs Claude Code with a framework like Superpowers at the level the task deserves (built by Shifat) - **[Claude Code Dashboard](https://github.com/jspw/Claude-Code-Dashboard):** Tokens, costs, and sessions for every Claude Code project, inside VS Code (built by Shifat) - **[Ollama](https://ollama.com):** Local models for experiments - **[OpenAI API](https://platform.openai.com):** Production AI features - **[n8n](https://n8n.io):** Workflow automation ## Stack - **[Python + FastAPI](https://fastapi.tiangolo.com):** Backend services at Nordivo - **[LangGraph + LangChain](https://www.langchain.com/langgraph):** Multi-agent orchestration and RAG - **[Celery + Redis](https://docs.celeryq.dev):** Background jobs and queues - **[Next.js + TypeScript](https://nextjs.org):** My products, including this site - **[Node.js / Express.js](https://nodejs.org):** APIs, scripts, lightweight services - **[Flutter](https://flutter.dev):** Mobile apps when needed - **[Java + Spring Boot](https://spring.io/projects/spring-boot):** Years of it at DSI ## Infrastructure - **[Google Cloud](https://cloud.google.com):** Cloud Run, Secret Manager, and Cloud Scheduler at work - **[PostgreSQL (Cloud SQL)](https://cloud.google.com/sql):** The default database, at work and in my products - **[Bitbucket + PR agents](https://bitbucket.org):** Pipelines deploy to Google Cloud, and AI agents review pull requests - **[Docker](https://www.docker.com):** Every project gets containerized - **[Vercel](https://vercel.com):** Hosting for my products ## Editor & Terminal - **[iTerm2 + Zsh](https://iterm2.com):** Oh My Zsh with a minimal prompt - **[IntelliJ IDEA](https://www.jetbrains.com/idea):** Java / Spring Boot projects ## macOS - **[Hush](https://github.com/jspw/Hush):** Quits apps after their last window closes, so Cmd+Tab stays clean (built by Shifat) - **[ScrollSense](https://github.com/jspw/ScrollSense):** Natural scrolling on the trackpad, traditional on the mouse, automatically (built by Shifat) ## Browser extensions - **[Chrome Shelf](https://chromewebstore.google.com/detail/chrome-shelf/cijpjgclabfbdbpieahfamgjacmnohdg):** Saves tabs and tab groups into a searchable shelf (built by Shifat) --- # Contact Open to collaborations. - **Email:** mhshifat757@gmail.com (best for work; replies within 24 hours) - **LinkedIn:** https://linkedin.com/in/mhshifat - **GitHub:** https://github.com/jspw - **X:** https://x.com/mhshifat757 - **Resume (PDF):** https://www.heyshifat.com/mehedi_hasan_shifat_resume.pdf