LLM Coding Workflow Best Practices

I've been using AI coding tools for a while now & it feels like every 3 months the paradigm shifts. Anyone remember putting "You are an elite software engineer..." at the beginning of your prompts or manually providing context? The latest paradigm is Agent Driven Development & here are some tips that have helped me get good at taming LLMs to generate high quality code. 1. Clear & focused prompting ❌ "Add some animations to make the UI super sleek" ✅ "Add smooth fade-in & fade out animations to the modal dialog using the motion library" Regardless of what you ask, the LLM will try to be helpful. The less it has to infer, the better your result will be. 2. Keep it simple stupid ❌ Add a new page to manage user settings, also replace the footer menu from the bottom of the page to the sidebar, right now endless scrolling is making it unreachable & also ensure the mobile view works, right now there is weird overlap ✅ Add a new page to manage user settings, ensure only editable settings can be changed. Trying to have the LLM do too many things at once is a recipe for bad code generation. One-shotting multiple tasks has a higher chance of introducing bad code. 3. Don't argue ❌ No, that's not what I wanted, I need it to use the std library, not this random package, this is the 4th time you've failed me! ✅ Instead of using package xyz, can you recreate the functionality using the standard library When the LLM fails to provide high quality code, the problem is most likely the prompt. If the initial prompt is not good, follow on prompts will just make a bigger mess. I will usually allow one follow up to try to get back on track & if it's still off base, I will undo all the changes & start over. It may seem counterintuitive, but it will save you a ton of time overall. 4. Embrace agentic coding AI coding assistants have a ton of access to different tools, can do a ton of reasoning on their own, & don't require nearly as much hand holding. You may feel like a babysitter instead of a programmer. Your role as a dev becomes much more fun when you can focus on the bigger picture and let the AI take the reigns writing the code. 5. Verify With this new ADD paradigm, a single prompt may result in many files being edited. Verify that the code generated is what you actually want. Many AI tools will now auto run tests to ensure that the code they generated is good. 6. Send options, thx I had a boss that would always ask for multiple options & often email saying "send options, thx". With agentic coding, it's easy to ask for multiple implementations of the same feature. Whether it's UI or data models asking for a 2nd or 10th opinion can spark new ideas on how to tackle the task at hand & a opportunity to learn. 7. Have fun I love coding, been doing it since I was 10. I've done OOP & functional programming, SQL & NoSQL, PHP, Go, Rust & I've never had more fun or been more creative than coding with AI. Coding is evolving, have fun & let's ship some crazy stuff!

AI coding LLMs and tools are improving rapidly. There is a massive amount of value and velocity teams can unlock by using them correctly. One reminder I recently shared internally at Productboard that’s worth repeating more broadly👇 It’s critical to start with a strong product specification. Spend the first 1–2 hours iterating on the spec definition to ensure all requirements are clear and there are no surprises mid-implementation. A few practical tips on how to do that: 🔹 Paste (or even better, pull via MCP) the specs you got from your PM into a Markdown file 🔹 Ask Claude: “Ask me any questions needed to make sure you deeply understand the feature we will be building.” You might get 40–60 questions back - ideally use something like WhisperFlow so you don’t spend the next two hours just answering them 🔹 Ask Claude: “Propose three very different approaches to building this feature and explain their pros and cons in terms of complexity, maintainability, and user value.” Then iterate toward the approach that makes the most sense 🔹 Ask Claude: “Research the codebase, put together an implementation plan for this feature, and come back with additional product questions that need to be answered before implementation.” Context engineering is just as critical. A few tips there: 🔹 Use a “Research → Plan → Implement” staged flow, fully wiping the context window between each stage instead of relying on automatic compaction 🔹 Spend significant time reading, reviewing, and adjusting the outputs of each stage 🔹 Use research sub-agents heavily - you may need to explicitly prompt for this depending on the tool and LLM you’re using When it comes to implementation quality: 🔹 Make sure you truly understand every line of code you push into a PR 🔹 Having the agent walk you through the changes and explain non-obvious parts (especially around libraries or frameworks) is often a great idea Tooling matters more than ever: 🔹 Make sure you deeply understand the features and tricks of the coding tools you use - not easy when tools like Claude Code and Cursor ship updates almost daily 🔹 Invest in AI tooling configuration in your repos 🔹 Invest in better linters - the best teams are often doubling the number of linter rules compared to pre-AI days, giving agents fast and precise feedback 🔹 Constantly update your AGENTS.md / Claude.md files as you notice behaviors that should be adjusted - top teams update these almost daily And finally: 🔹 Share your tips and tricks with colleagues How are you and your teams approaching AI-assisted coding today? What practices have made the biggest difference for you so far?

I work at Airbnb where I write 99% of my code with LLMs. One thing you need to understand is they only write shit code if you let them. When you're building high quality production software, writing code is always the 𝗹𝗮𝘀𝘁 𝘀𝘁𝗲𝗽. Your first step is to understand the problem that needs to be solved. Then ideate solutions, consider alternatives, explore tradeoffs and refine your exploration into a concrete plan. Even as you implement the plan task by task you should not be coding a stream of conscious. That leads to bad code design. You should be considering the architecture of the code, abstractions and coming up with a clean way to write it. Only after all this upfront design and planning work do you then start manually typing code with your fingers. That last step is not necessary to do manually anymore. Whenever I think of coding, I immediately reach for an LLM because I use it like a power tool. A carpenter does not leave their power drill on the table when they need to screw in a bolt. Why would you not use an LLM to execute on your plan? You are in the driver's seat, providing direct technical guidance at every step. 𝗬𝗼𝘂𝗿 𝗲𝘅𝗽𝗲𝗿𝗶𝗲𝗻𝗰𝗲 𝗮𝗻𝗱 𝘀𝗸𝗶𝗹𝗹 𝗹𝗲𝘃𝗲𝗹 𝗱𝗶𝗿𝗲𝗰𝘁𝗹𝘆 𝗶𝗺𝗽𝗮𝗰𝘁 𝗵𝗼𝘄 𝗴𝗼𝗼𝗱 𝘁𝗵𝗲 𝘀𝗼𝗹𝘂𝘁𝗶𝗼𝗻 𝗶𝘀. No, this is not slower than doing it without LLMs. You should also use LLMs as power tools for research, planning and architecture. This will get you even higher quality software than without them. It allows you to go far beyond due diligence and truly explore, analyze and refine your design fully before any single line of code is written. I use the following workflow to naturally research, design and plan the feature I want to build in the form of a conversation which then gets converted to a formal Spec that the LLM can implement task by task:  1. Explain the problem to the LLM.  2. Give it your ideas for the initial solution  3. Tell it explicitly: “Propose an approach first. Show alternatives to my solution, highlight tradeoffs. Do not write code until I approve.”  4. Review the proposal, poke holes in it, iterate  5. Tell it to write the plan to disk as a spec so you can hand off to another session later  6. Lastly, let it generate code. This is an excerpt from my article “Writing High Quality Production Code With LLMs Is A Solved Problem” full article here on LinkedIn —> https://lnkd.in/d3v-i9iK

How to actually code with LLMs in 2026. Not the hype. What's working for engineers who ship: 1️⃣ 𝗦𝗽𝗲𝗰 𝗯𝗲𝗳𝗼𝗿𝗲 𝗰𝗼𝗱𝗲 Don't throw wishes at the LLM. → Describe the idea → Let the AI ask questions until requirements are clear → Compile into spec.md → Generate step-by-step plan → Then code It's "waterfall in 15 minutes." 2️⃣ 𝗦𝗺𝗮𝗹𝗹 𝗰𝗵𝘂𝗻𝗸𝘀 Ask for too much = jumbled mess. "Like 10 devs worked on it without talking." One function. One bug. One feature. Then next. 3️⃣ 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗽𝗮𝗰𝗸𝗶𝗻𝗴 LLMs are only as good as what you show them. → Relevant code → API docs → Known pitfalls → Preferred approaches Don't make the AI guess. 4️⃣ 𝗠𝗼𝗱𝗲𝗹 𝗺𝘂𝘀𝗶𝗰𝗮𝗹 𝗰𝗵𝗮𝗶𝗿𝘀 Each model has blind spots. Stuck? Copy the same prompt to another model. Sometimes a second opinion is all you need. 5️⃣ 𝗛𝘂𝗺𝗮𝗻 𝗶𝗻 𝘁𝗵𝗲 𝗹𝗼𝗼𝗽 AI writes with complete conviction. Including bugs. Including nonsense. Treat every snippet like junior dev code. Read it. Run it. Test it. 6️⃣ 𝗖𝗼𝗺𝗺𝗶𝘁 𝗹𝗶𝗸𝗲 𝘀𝗮𝘃𝗲 𝗽𝗼𝗶𝗻𝘁𝘀 AI generates fast. Veers off course fast. Commit after each small task. Your safety net when AI goes sideways. 7️⃣ 𝗥𝘂𝗹𝗲𝘀 𝗳𝗶𝗹𝗲𝘀 Use CLAUDE.md, GEMINI.md, or .cursorrules. → Your coding standards → Your patterns → Your constraints Train it once. Enforce everywhere. The mental model: LLMs are over-confident junior devs. You're the senior engineer. They're the force multiplier. 💾 Save this before your next AI coding session.

Few Lessons from Deploying and Using LLMs in Production Deploying LLMs can feel like hiring a hyperactive genius intern—they dazzle users while potentially draining your API budget. Here are some insights I’ve gathered: 1. “Cheap” is a Lie You Tell Yourself: Cloud costs per call may seem low, but the overall expense of an LLM-based system can skyrocket. Fixes: - Cache repetitive queries: Users ask the same thing at least 100x/day - Gatekeep: Use cheap classifiers (BERT) to filter “easy” requests. Let LLMs handle only the complex 10% and your current systems handle the remaining 90%. - Quantize your models: Shrink LLMs to run on cheaper hardware without massive accuracy drops - Asynchronously build your caches — Pre-generate common responses before they’re requested or gracefully fail the first time a query comes and cache for the next time. 2. Guard Against Model Hallucinations: Sometimes, models express answers with such confidence that distinguishing fact from fiction becomes challenging, even for human reviewers. Fixes: - Use RAG - Just a fancy way of saying to provide your model the knowledge it requires in the prompt itself by querying some database based on semantic matches with the query. - Guardrails: Validate outputs using regex or cross-encoders to establish a clear decision boundary between the query and the LLM’s response. 3. The best LLM is often a discriminative model: You don’t always need a full LLM. Consider knowledge distillation: use a large LLM to label your data and then train a smaller, discriminative model that performs similarly at a much lower cost. 4. It's not about the model, it is about the data on which it is trained: A smaller LLM might struggle with specialized domain data—that’s normal. Fine-tune your model on your specific data set by starting with parameter-efficient methods (like LoRA or Adapters) and using synthetic data generation to bootstrap training. 5. Prompts are the new Features: Prompts are the new features in your system. Version them, run A/B tests, and continuously refine using online experiments. Consider bandit algorithms to automatically promote the best-performing variants. What do you think? Have I missed anything? I’d love to hear your “I survived LLM prod” stories in the comments!

If you’re building anything with LLMs, your system architecture matters more than your prompts. Most people stop at “call the model, get the output.” But LLM-native systems need workflows, blueprints that define how multiple LLM calls interact, how routing, evaluation, memory, tools, or chaining come into play. Here’s a breakdown of 6 core LLM workflows I see in production: 🧠 LLM Augmentation Classic RAG + tools setup. The model augments its own capabilities using: → Retrieval (e.g., from vector DBs) → Tool use (e.g., calculators, APIs) → Memory (short-term or long-term context) 🔗 Prompt Chaining Workflow Sequential reasoning across steps. Each output is validated (pass/fail) → passed to the next model. Great for multi-stage tasks like reasoning, summarizing, translating, and evaluating. 🛣 LLM Routing Workflow Input routed to different models (or prompts) based on the type of task. Example: classification → Q&A → summarization all handled by different call paths. 📊 LLM Parallelization Workflow (Aggregator) Run multiple models/tasks in parallel → aggregate the outputs. Useful for ensembling or sourcing multiple perspectives. 🎼 LLM Parallelization Workflow (Synthesizer) A more orchestrated version with a control layer. Think: multi-agent systems with a conductor + synthesizer to harmonize responses. 🧪 Evaluator–Optimizer Workflow The most underrated architecture. One LLM generates. Another evaluates (pass/fail + feedback). This loop continues until quality thresholds are met. If you’re an AI engineer, don’t just build for single-shot inference. Design workflows that scale, self-correct, and adapt. 📌 Save this visual for your next project architecture review. 〰️〰️〰️ Follow me (Aishwarya Srinivasan) for more AI insight and subscribe to my Substack to find more in-depth blogs and weekly updates in AI: https://lnkd.in/dpBNr6Jg

I replaced 307 lines of agent code with just 4 lines. Graph-based thinking changed everything for my LLM agents. Curious how a 100-line framework can transform your AI workflows? Read on. I've spent years building my own agent framework and teaching graph theory, but discovering PocketFlow made me rethink my approach to LLM-powered programs. Its graph-based abstraction was a game-changer for clarity and modularity. My old AgentBot implementation had a 307-line __call__ method. With PocketFlow, I rebuilt it in about 100 lines, with the core agent graph constructed in just 4 lines. PocketFlow structures LLM programs as graphs, not loops. Each Node is a unit of execution, and Flows connect them, making the logic explicit and visualizable. This shift made my code more maintainable and easier to reason about. In this blogp ost, I share concrete examples: topic extraction, agentic date retrieval, and shell command execution—all orchestrated as graphs. The new approach let me visualize agent architectures and made adding new tools trivial. The biggest lesson? Thinking in graphs, not loops, transforms how you build LLM applications. It brings clarity, modularity, and makes your execution flow explicit. If you're curious about building smarter, more maintainable LLM agents, check out my deep dive and let me know your thoughts! How are you structuring your LLM-powered workflows—loops, graphs, or something else? What challenges have you faced? #ai #llm #agentframeworks #graphtheory #machinelearning

Just finished reading an amazing book: AI Engineering by Chip Huyen. Here’s the quickest (and most agile) way to build LLM products: 1. Define your product goals Pick a small, very clear problem to solve (unless you're building a general chatbot). Identify use case and business objectives. Clarify user needs and domain requirements. 2. Select the foundation model Don’t waste time training your own at the start. Evaluate models for domain relevance, task capability, cost, and privacy. Decide on open source vs. proprietary options. 3. Gather and filter data Collect high-quality, relevant data. Remove bias, toxic content, and irrelevant domains. 4. Evaluate baseline model performance Use key metrics: cross-entropy, perplexity, accuracy, semantic similarity. Set up evaluation benchmarks and rubrics. 5. Adapt the model for your task Start with prompt engineering (quick, cost-effective, doesn’t change model weights): craft detailed instructions, provide examples, and specify output formats. Use RAG if your application needs strong grounding and frequently updated factual data: integrate external data sources for richer context. Prompt-tuning isn’t a bad idea either. Still getting hallucinations? Try “abstention”—having the model say “I don’t know” instead of guessing. 6. Fine-tune (only if you have a strong case for it) Train on domain/task-specific data for better performance. Use model distillation for cost-efficient deployment. 7. Implement safety and robustness Protect against prompt injection, jailbreaks, and extraction attacks. Add safety guardrails and monitor for security risks. 8. Build memory and context systems Design short-term and long-term memory (context windows, external databases). Enable continuity across user sessions. 9. Monitor and maintain Continuously track model performance, drift, evaluation metrics, business impact, token usage, etc. Update the model, prompts, and data based on user feedback and changing requirements. Observability is key! 10. Test, Test, Test! Use LLM judges, human-in-the-loop strategies; iterate in small cycles. A/B test in small iterations: see what breaks, patch, and move on. A simple GUI or CLI wrapper is just fine for your MVP. Keep scope under control—LLM products can be tempting to expand, but restraint is crucial! Fastest way: Build an LLM optimized for a single use case first. Once that works, adding new use cases becomes much easier. https://lnkd.in/ghuHNP7t Summary video here -> https://lnkd.in/g6fPsqUR Chip Huyen, #AiEngineering #LLM #GenAI #Oreilly #ContinuousLEarning #ProductManagersinAI

𝐂𝐈/𝐂𝐃 𝐁𝐞𝐬𝐭 𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞𝐬 𝐟𝐨𝐫 𝐋𝐋𝐌 𝐀𝐩𝐩𝐥𝐢𝐜𝐚𝐭𝐢𝐨𝐧𝐬: 𝐒𝐢𝐱 𝐄𝐬𝐬𝐞𝐧𝐭𝐢𝐚𝐥 𝐏𝐚𝐭𝐭𝐞𝐫𝐧𝐬 LLM applications are not just models.   They are evolving software systems with data pipelines, prompts, APIs, and user-facing workflows. Treat them like production systems. 𝐇𝐞𝐫𝐞 𝐚𝐫𝐞 𝐬𝐢𝐱 𝐩𝐚𝐭𝐭𝐞𝐫𝐧𝐬 𝐭𝐡𝐚𝐭 𝐦𝐚𝐭𝐭𝐞𝐫: 1. Continuous Integration   • Trigger CI on every code push.   • Spin up clean environments.   • Install dependencies, run automated tests, and package model artifacts. 2. Version Control   • Track changes across code, data, prompts, and models.   • Branch for experiments.   • Keep main stable. 3. Continuous Deployment   • Ship updates with minimal downtime.   • Use load balancers and versioned deployments.   • Support safe rollouts. 4. Automated Testing   • Go beyond unit tests.   • Include integration, performance, and evaluation testing.   • Monitor outputs and trigger rollback when needed. 5. Monitoring & Rollback   • Track latency, token usage, hallucination rates, drift, and failures.   • Build automated rollback triggers. 6. Optimized Training & Fine-Tuning   • Automate experiments.   • Structure ingestion pipelines (chunking, preprocessing).   • Track hyperparameters and evaluation metrics. Why this matters: LLM failures don’t usually happen at inference alone.   They happen because: • Prompts change without versioning   • Fine-tunes are deployed without evaluation   • Monitoring is reactive   • Rollbacks are manual  LLM systems require disciplined CI/CD. If you’re building AI in production, your pipeline must handle: Code + Data + Models + Prompts + Infrastructure. Are you shipping prompts or engineering systems? ♻️ Repost this to help your network get started ➕ Follow Jaswindder for more #DevOps #AIOps