blog main page

Most of the time, LLM-assisted refactors do not fail because the model cannot code, but because we do not transfer intent clearly enough for the changes to be safe. In this post, I share a practical way to close that gap: treat the LLM like a requirements debugger and iteratively turn fuzzy “support bulk edit” style statements into explicit, testable rules. I use a familiar product scenario, bulk editing calendar events, to show why multi-select turns “obvious” behavior into ambiguity traps, and which lightweight artifacts (glossary, decision log, scenario matrix, stop criterion) make the work manageable. Part 1 focuses on the problem and the refinement process; Part 2 will walk through the workflow with concrete examples you can reuse.

This post explains how I use the 22 UI prompts from the previous article as part of a practical, day-to-day development workflow. Rather than treating UI polish as a separate phase or a design exercise, I integrate these prompts directly into feature work, code reviews, and pre-merge checks. The goal of this article is to show when each prompt is useful, why it belongs at that point in the process, and how they collectively help keep UI quality high without slowing down delivery. Concrete before-and-after examples, the exact prompts, and detailed change explanations are available in the linked GitHub repository, while this post focuses on decision-making and timing.

This article is a practical walkthrough of how I use large language models as a UI and UX accelerator in real production work. I am primarily a back-end developer, but UI is still part of what I ship, and quality matters. Instead of guessing at visual decisions or over-investing time in polish, I rely on a small, repeatable set of prompts that help me audit, refine, and stabilize interfaces quickly. In this post, I break down 22 concrete UI use cases, explain when and why each prompt is useful, and show how they fit into a real development workflow. For every case, you can explore full before-and-after runnable examples, the exact prompt used, and a clear summary of what changed in the linked GitHub repository.

System design interviews often focus on architecture, scalability, and performance, especially for senior engineering roles. But there is one critical dimension that is frequently overlooked: cost. In this post, I share why adding cloud cost estimation to your system design answers can significantly elevate your interview performance. Using a practical Azure-based example, I walk through how cost awareness demonstrates real-world engineering maturity, business alignment, and pragmatic decision-making that interviewers genuinely value.