A technical blog on web development, infrastructure, and AI coding tools. Posts cover setup steps plus failure cases, decision criteria, and limits found in production.
It’s Friday afternoon, and a Pull Request (PR) with 50 file changes just landed. It includes a large-scale refactoring essential for a new feature, resulting in extensive modifications. Colleagues leave comments like ‘I’ll look at it Monday,’ and soon, next week’s deployment schedule starts slipping indefinitely. Reviewers feel overwhelmed, unsure where to start, while the PR author wastes time resolving conflicts caused by delayed reviews.
The root cause of this situation is a lack of context. Reviewers must expend significant cognitive resources to grasp the entire context of the changed code. Tracing all function call relationships and evaluating potential side effects is tedious and challenging. Consequently, reviews often focus only on superficial code style, or a hasty ‘LGTM’ might be given without properly examining the core logic.
In this post, I’ll compare how AI-powered code editor Cursor can solve this problem, using a Before/After format. I’ll cover specific methods that leverage AI’s ability to understand and summarize the entire codebase, reducing reviewer burden and enabling more in-depth reviews.
A colleague joined a new project and was tasked with refactoring a legacy module. To understand a file with thousands of lines, they copied the entire code into a high-performance model like Claude 3 Opus and started asking questions. The results were quite satisfactory, but another team member doing a similar task used a different model or a different questioning approach and received completely different answers.
Everyone was surprised by the monthly bill. We found that certain tasks incurred costs tens of times higher than expected. The root cause was indiscriminately feeding long contexts. While individual productivity might have temporarily increased, for the team as a whole, it led to unpredictable costs and a lack of consistency in output.
In this post, I’ll cover some rules and default settings that a technical lead or senior developer should establish when introducing Anthropic models to a team. This can help manage costs predictably and maintain a consistent quality of output from team members.
I first introduced Antigravity CLI during a legacy service migration. The first few days went smoothly, but as the number of files grew, the CLI started modifying files it had “already fixed.” Upon inspection, I found that context was resetting between sessions, causing the CLI to proceed with subsequent tasks completely unaware of previous decisions. This led to the same function signature being changed twice, breaking tests written in between both times.
This post explores how Antigravity CLI handles context, where loss occurs, and patterns to maintain intent across sessions. If you’re experiencing symptoms like “the CLI randomly changes code,” the cause is likely not a tool bug.
After reading this post, you’ll understand why context breaks when crossing session boundaries in Antigravity CLI and what file structures and calling patterns to use to prevent it.
Recently, our team’s monthly commercial LLM API costs started exceeding estimates. Concerns about data security also led us to explore running models locally as an alternative. Conveniently, I had a development machine with an M2 Max chip, and LM Studio’s ability to run high-performance models like Llama 3 with just a few clicks, without complex setup, was very appealing.
Initial experiences were successful. I could freely generate code and ask questions without worrying about API key management or token costs. It provided immediate help for simple script writing and boilerplate code generation. However, after about a week of deep practical application, I realized an unexpected ‘cost’ was emerging beyond hardware specs or model performance. It wasn’t a visible monetary expense, but it was clearly consuming my time and mental energy.
In this post, I’ll cover three easily overlooked costs (exploration, consistency, and context) that lie beyond hardware specifications when operating local models using LM Studio, along with specific examples.
Mid-sprint, a team member pushed Copilot-generated code directly to a PR. The reviewer took twice as long as usual to verify the logic. The review ultimately began with the question, “Did you write this code yourself, or did Copilot?” The team had adopted Copilot three weeks prior but lacked any guidelines.
This situation isn’t an issue with the tool itself. Copilot is designed as a personal productivity tool, but team usage introduces review standards, context sharing, and license management. Starting with “just try it” without preparation often leads to friction before productivity gains.
This post covers the decisions leaders should make before adopting Copilot, broken down by team size (1 → 3 → 10 people), and the reasons behind them. I’ll focus on team agreement points rather than installation methods.