K-Spot Development Story: What I Learned Through AI-Collaborative Development
Over the past few months, I’ve been heavily using LLMs like GPT, Claude, and Copilot for my personal project, K-Spot. K-Spot is currently available on the Apple App Store, and the Android version is in closed beta. While developing this app, I accumulated a lot of know-how in collaborating with AI and realized that while “LLMs are tools,” “how to use them properly” is a whole different problem. I want to share the AI utilization know-how I’ve gained through many trials and errors.
1. It All Comes Down to ‘Context’
The secret to getting good code from an LLM isn’t in the question but in the situation. Instead of just saying, “Do this,” you need to first explain the “why, how, and in what environment” the task should be done. It’s like telling a chef what ingredients you have, what tools you can use, and what flavor you’re looking for. LLMs don’t know your project’s specific structure or rules, so without specific context, they’ll often rely on guesswork and create code that goes in the wrong direction.
For example, I use a collection called businessSubmissions, but if I ask for code without any explanation, the LLM often tries to query data based on a collection named business. To solve problems like this, you have to get the LLM to properly understand your working environment. Here’s a specific method I’ve used to do just that.
2. Extending Context with MCP
I’ve found great help using two protocols called ‘Sequential Think MCP’ and ‘Memory Bank MCP.’ These protocols give the LLM a framework for systematic thinking and long-term memory, which allows it to overcome the limitations of simple prompting.
Sequential Think MCP is a method that guides the LLM to think in steps when solving a complex problem. Instead of a simple request like “Fix this bug,” it forces a systematic thought process: “Analyze the cause of the bug,” “formulate a hypothesis for the solution,” and then “write code to verify that hypothesis.” This makes the LLM go through a logical process, just like a person would, which significantly increases accuracy.
Memory Bank MCP is a way of organizing a project’s key decisions, API specs, and DB structure into Markdown files that the LLM can reference at any time. This eliminates the need to explain the same context repeatedly. I made sure to record any changes in the Claude.md file and also had it consistently update the README.md and other relevant project files. Even though my Claude.md file always tells it to reference this file to understand the database structure, it still makes silly mistakes sometimes. This makes me realize that the world of LLMs and prompting is truly a mystery.
💡 Tip: Always describe your database structure, API specs, and state management methods thoroughly before you ask a question. It’s okay if the prompt is long; that’s the key to accuracy.
3. Get the ‘First Step’ Right, Instead of Iterating on Revisions
Thinking, “I’ll just get it to fix the code if it’s wrong,” might work at first. But if you try to revise a single file multiple times, the LLM’s understanding of the code’s context will get tangled, and you’ll end up wasting even more time.
💡 Tip: For file-level refactoring, it’s often more efficient to clearly define the design direction from the beginning. Instead of saying, “Fix this based on the old code,” it’s often better to say, “I want to change this structure, so please rewrite the whole thing.”
4. LLMs Excel at ‘Brainstorming’ More Than ‘Completing’ a Task
When you’re stuck, just asking an LLM, “How should I approach this?” can show you a path forward.
💡 Example: “I have business data stored in Firestore, and I need to display it as markers on a Mapbox map using React Native. The challenge is that there are too many markers, so I need to implement a clustering algorithm. Additionally, I want to add an animation when a user taps a marker to expand its detail card. What would be a good architectural approach to handle the marker state, clustering logic, and animation performance without causing lag?”
5. Using LLMs for Collaboration Is a Different Problem
When you’re working alone, you can quickly fix a mistake the LLM makes. But in a team project, the LLM’s “guesswork coding” can quickly become technical debt. This problem gets even more complex if team members use different LLM/coding tools (e.g., Copilot, GPT, Claude). Different tools have different training data and generation styles, which can lead to inconsistent code. Plus, the cost ($$$) of using these tools can’t be ignored.
💡 If you’re using LLMs on a team: You need to create a template to clearly share the database structure and API specifications. You also need to create prompt guidelines so that everyone consistently provides that information to the LLM.
6. Ditch the Illusion That ‘My Own Usage Is Enough’
To truly use LLMs well, you have to change your entire communication style with them. It’s like learning a new programming language.
Beyond just “knowing how to ask good questions,” it’s crucial to deeply understand the LLM’s limitations and how it works. LLMs can sometimes have hallucinations and state incorrect information as fact. The ability to filter out and verify these errors is ultimately up to a person.
How to break down a prompt
What information to specify
What results to expect
Learning all of this and understanding that the final responsibility for the work you produce lies with you, not the LLM, is the essence of LLM utilization.
Conclusion
Many people think of Copilot or Claude as a “magic tool that codes for you,” but they’re really more like a very smart, but sometimes erratic, collaborator. However, when developers point out a bug caused by a new AI-generated code and say, “This is why AI-collaborative development doesn’t work; we need human developers,” they’re missing the point. Bugs can happen no matter who writes the code, and the important thing is that code from an AI needs the same thorough review and testing as code written by a person.
Developing an MVP in just a few days with AI-collaborative development is a truly amazing technological leap. But if you get complacent with that speed and become lax with quality control, the consequences will come back to haunt your service operations. As is always the case, don’t forget that the LiveOps nightmare of a late-night outage begins the moment code goes into production.
It’s like in the movie <Iron Man 2>, when Tony Stark invents a new element for his arc reactor with the help of his AI, JARVIS. JARVIS. handled the vast knowledge and data analysis, but it was ultimately Tony Stark who grasped the core of the problem and creatively came up with the solution. So, Tony Stark is the one who proposed the solution and took responsibility for the results, while J.A.R.V.I.S. was just a tool — though a much better (and more expensive) tool than today’s LLMs.
Disclosure: This article was first drafted by ChatGPT 4o based on a series of Q&A sessions related to the K-Spot project, then refined by Gemini 2.5 Flash. It was to improve the sometimes-awkward Korean phrasing of ChatGPT, but probably not much for English.
Also K-Spot is available on Apple AppStore! : https://apps.apple.com/us/app/k-spot/id6747911904