Forem: CodeLink

How Figma Make is Closing the 'Idea-to-Proof' Gap

CodeLink — Fri, 21 Nov 2025 08:50:25 +0000

Every product team knows the tension between speed and clarity. Moving from a concept on a slide to something people can actually test is often slow, expensive, and fragmented. That gap between what we imagine and what we can demonstrate is where many good ideas stall.

Figma Make enters this space with a bold promise: to compress the distance between idea and proof, giving teams the power to build realistic, functional prototypes directly from their designs.

The Core Problem: Ideas Are Hard to Show

As a product designer, I live in the idea-to-pitch loop with a constant question: How do I make my teammates or clients see what I see?

Mockup help. Words help. But they’re not enough. Whether it be pitching to investors, scoping with clients, or aligning internal teams, ideas are always easy to talk about, but hard to show.

We're stuck in a gap between the concept and the tangible, interactive experience needed to get real feedback. The problem is that turning a raw idea into a functional prototype is slow, expensive, and often out of reach. Too often, we pitch promises, not proof.

For non-designers, this gap is even wider. Turning an idea into something tangible often means wrestling with complex tools, waiting on design or engineering support, or worse, going into critical meetings with nothing but words.

This is the exact gap Figma Make aims to fill. It’s a new set of capabilities designed to turn ideas into clickable, functional prototypes faster than ever.

The Solution: What Figma Make Offers

Figma Make introduces a new approach to prototyping, allowing teams to build dynamic, data-driven web applications and prototypes directly from their designs.

Here’s what I think makes it different:

Prompt-to-App: Using AI (currently Claude 3.7 Sonnet), I was surprised by how quickly I could turn a static layout into something clickable simply by providing a Figma design and a natural-language prompt.
Point-and-Prompt: Being able to select a component on the canvas and adjust its behavior with a short instruction made iteration much faster. It felt closer to having a conversation with the tool rather than switching between menus or searching for the right setting.
Reasoning & Error Detection: This is my personal favorite. It can explain its logic, manage versioning, and even offer automatic error detection and code quality improvements with the "Fix for me" feature.
Integrated Backend Support: Figma Make allows prototypes to: a) connect to real APIs, databases, and custom backend logic; b) build dynamic experiences like form submissions, authentication, or AI-driven interactions; c) integrate directly with tools like Xano, Supabase, Airtable, or other custom endpoints. I don’t need a technical background to set any of this up, yet I can still test real product flows.

Essentially, it moves prototyping from just "linking screens" to "building mini-apps."

Putting It to the Test: A Hackathon Case Study

I recently had the chance to explore Figma Make’s full potential during CodeLink’s 2025 Hackathon.

Our team decided to build an AI Tutor App that would generate a complete learning course, including lectures, practice questions, and a final project, all from a single uploaded lecture. Users could customize the project's theme and difficulty based on their learning objectives.

As the team's designer, I was responsible for building the end-to-end working prototype so we could rapidly test our ideas.

My technical background is quite limited, but the open dialogue and natural language interface of Figma Make immediately lowered the barrier. Because it’s built right within Figma, it provides a convenient and safe "sandbox" environment. I could try new ideas without any risk, thanks to the built-in versioning and revert options.

We started with a static design and a simple prompt:

Use the reference design to build an AI Tutor App that generates learning courses based on uploaded lectures. Generate Selection Questions for practices, and create a course project with a custom topic, based on user learning objectives

In a remarkably short time, we had a functional prototype that the team could actually use and test, not just click through.

To test out the resulting prototype, read our full article here.

Make the Most of Figma Make

These practices make the AI more accurate, reduce rework, and keep your prototype manageable as it grows in complexity.

Define Specific Requirements: Be explicit about what the design needs to achieve. Specify where it fits in the product and any constraints. Clear inputs lead to more accurate outputs. For example, “This screen is part of onboarding, must include email + OTP fields, and follow mobile layout rules.”
Prepare a Clean Design File: Before prompting, organize your Figma file. Remove unused layers, group related components, and standardize naming (e.g., Button/Primary, Form/Input). A tidy structure helps Figma Make understand hierarchy and reduces errors.
Break Down Complex Tasks: For multi-step flows or advanced logic, start small. Instead of prompting “build the full checkout flow,” begin with “create the cart summary section,” then layer in payment, validation, and API steps gradually. This keeps the build predictable and easier to refine.

Final Takeaways

My single biggest discovery is just how much value Figma Make adds before the official design phase even has to start. We’re not just building faster, but also learning faster:

Designers can test usability and interaction logic earlier.
Product owners can demonstrate scope and feasibility with live prototypes.
Clients and stakeholders can interact with a concept rather than interpret slides.

Teams can quickly get a general feeling for an idea, uncover real user pain points, and test complete flows in a realistic, data-driven environment. This creates a tighter feedback loop of Idea → Interaction → Insight and turns discussions into evidence-based iteration.

For product owners, designers, founders, or anyone stuck in the loop of talking about their ideas, Figma Make might finally be the tool that lets the idea truly show itself.

Multi-agent Systems Explained: The Next Step in AI Evolution

CodeLink — Wed, 22 Oct 2025 09:01:00 +0000

Artificial Intelligence (AI) is evolving beyond single, monolithic models. Today’s most capable systems are made up of multiple AI agents. This new paradigm of multi-agent systems (MAS) represents the next step in AI evolution, where collaboration and coordination between agents matter as much as individual intelligence.

In this article, we’ll break down what multi-agent systems are, how they work through real-world analogies, and explore the different architectures that make them scalable and effective in practice.

LLM Agents

With the rapid development of Large Language Models (LLMs), many systems are now built around an LLM core (ChatGPT, Claude, LLaMA, etc.) and extended with prompts, functions, or pipelines to perform specific tasks. These systems are known as LLM Agents.

There are several types of LLM Agents, depending on how they are implemented:

Tool-calling agents: These agents use the LLM to interact with external functions or tools, like searching a database or accessing an API.
Graph agents: Instead of tackling a prompt all at once, this agent breaks a complex task into smaller steps. Each step might call a specific prompt or function, with the output of one step feeding into the next. In this method, agents are built as a directed graph or state machine, each node representing reasoning or tool-calling steps. Popular frameworks to develop this type of agent are LangGraph, CrewAI, LLamaIndex, …
Planning Agents: These agents create a plan of action before executing steps. They break complex goals into smaller tasks by using prompting methods. A simple setup might include two stages: First is planning, where the agent analyzes the request and outlines step-by-step actions. Second is execution, the agent executes the plan, combining the original request with the generated steps to deliver the final output. Modern frameworks such as AutoGPT, BabyAGI, and CAMEL have expanded and refined this approach.
Reasoning Agents: Currently, one of the most widely adopted approaches, inspired by the 2023 paper “ReAct: Synergizing Reasoning and Acting in Language Models.” These agents simulate human-like logical reasoning. Upon receiving a request, the agent thinks, decides, and reasons through what it needs to do, then executes an action, observes the result, and updates its state. This loop of think → act → observe → update continues until the goal is reached or a stopping condition is met. Unlike Planning Agents, who create a fixed plan and execute it in one go, Reasoning Agents work in a continuous feedback loop.

Multi-Agent Systems

A multi-agent system is exactly what it sounds like: a system that combines multiple, individual agents, allowing them to work together to handle tasks far more complex than any single agent could manage alone. These agents can collaborate in different ways, depending on how the system is designed.

Let’s check out the three most common multi-agent architectures to see how each one shapes coordination, scalability, and performance.

1. Network

Imagine you're starting a company with three friends: a Back-end developer, a Front-end developer, and an admin. Everyone knows each other well and collaborates closely.

In the early days of the company, your main goal is to find as many customers as possible, so external connections and relationships become crucial.

When a customer reaches out to any member of your team to request a product or service, that person will notify the others and check whether they are capable of handling the request. If they can, they complete the task and deliver the result to the customer. If not, or if they can only handle part of it, they will reach out to the rest of the team to find someone who can continue or complete the process.

Simple Scenario: A customer who knows your Back-end developer asks for a simple Application Programming Interface (API) for their business. The Back-end developer can handle this alone, complete the work, and deliver the final product directly to the customer.

Complex Scenario: The same customer returns, but this time they want a full application - a User Interface (UI), more APIs, and a server to deploy everything on. The Back-end developer can't do this alone. He breaks the project down and asks each team member to contribute their part. Once all the pieces are finished, he assembles the final product and delivers it to the customer.

This is the core concept of a Network Multi-Agent Architecture. Each agent in the system handles a specific task, and they are all interconnected. Every agent is aware of the others and their unique capabilities. You set one agent as the entry point; when a request comes in, this agent analyzes whether it can handle it alone or if it needs to pass the task (or parts of it) to other agents in the network.

Technical Example: You have three agents - a Search Agent (to pull data from a database), a Calculate Agent (for numerical tasks), and a Chart Agent (to create visualizations).

When you ask the system to "calculate the company's revenue last year," the request will be handled as below:

This architecture is great for small systems with fewer than ten agents; you can connect them directly and don't have to think about their relationship or hierarchy. However, it has two main disadvantages:

Scalability: As your system grows, adding a new agent becomes a headache. You have to establish a connection from the new agent to all existing agents and then update all existing agents to recognize the new one.
Cost: To work effectively, each agent needs context about all the other agents in its prompt. As the system gets more complex, these prompts grow larger, consuming more tokens for every request. This can quickly become expensive and even hit API limits, causing complex requests to fail.

2. Supervisor

Your company is growing. With more customers and tasks pouring in daily, you want your teammates to focus on working in their specific domain instead of finding more clients for your business. You’ve also hired some specialists from different domains to expand the company’s tech stack. The structure of your company becomes a little different.

Everybody is now under your management, and you’ll act as the central supervisor. When a client comes with a request, they meet with you. You analyze their requirements, delegate the work to the right person, and manage the process. Once the task is complete, the team member reports back to you for final verification before you deliver the result to the client.

Simple Scenario: A client comes to your company to request a custom AI for analytical tasks. You assign this directly to your AI Engineer. Once the engineer has built and tested the AI, they deliver it to you, and you present the final product to the client.

Complex Scenario: A client wants a full-featured application with an integrated AI, a User Interface, a Back-end, and CI/CD (Continuous Integration/Continuous Deployment) pipelines. Now, you must act as a project manager. You break the request into smaller tasks and create a workflow:

Step 1: You assign the research and creation of the analytical AI to the AI Engineer.

Step 2: Once the AI model is ready, you pass it to your Back-end engineer to integrate it into a robust server-side application.

Step 3: When the back-end is complete, you ask your Front-end engineer to build a user interface that communicates with it.

Step 4: Finally, you bring everything to your DevOps engineer to create the CI/CD pipelines and deploy the application on a server.

Step 5: You wrap up the finished project and deliver it to the client.

In this model, a central coordinator agent (you) connects to all other agents in a 1-to-1 relationship. This coordinator's job is to analyze requests, break them down, and delegate tasks to the appropriate specialist agent.

Technical Example: You still have the Search Agent, Calculate Agent, and Chart Agent. Instead of connecting them together, you create a coordinator to maintain a 1:1 connection between this coordinator and the others.

Let's revisit the request to "calculate the company's revenue last month." With a supervisor agent managing the process, the workflow is far more structured:

Unlike the network model, the specialist agents don't need to know about each other; they only communicate with the coordinator. This allows them to focus purely on their tasks.

However, this architecture introduces a new bottleneck: the coordinator. As you add more agents to the system, the coordinator's prompt grows larger with information about each new agent it manages. Eventually, it too can become unwieldy and hit token limits. That’s the reason why we have another architecture to handle this, and it’s called hierarchical.

3. Hierarchical

To learn more about this architecture, read the full blog article here.

Agent as a Tool

In modern development, the concept of “agents as tools” often overlaps with hierarchical or supervisor systems.

Instead of coding separate functions for each tool, you can treat an agent as a domain-specific tool that handles a group of related tasks. Then, you can treat that entire multi-agent system as a single, powerful "tool" that a higher-level agent can call upon. This is a highly effective way to encapsulate complex capabilities and build incredibly sophisticated systems.

Conclusion

A multi-agent system provides a structured way to manage multiple LLM agents within a single ecosystem:

Network architecture works best for small systems with fewer agents.
Supervisor architecture suits medium-sized systems.
Hierarchical architecture is ideal for large-scale setups.

Each approach has trade-offs in scalability, complexity, and efficiency. Based on your needs, you can choose the most suitable architecture and framework.

To get started, it’s worth exploring LangGraph and LlamaIndex as they are among the most popular frameworks for developing LLM and multi-agent systems. LangGraph also provides tutorials for building multi-agent setups.

If you’re wondering how to connect agents built with different frameworks or languages, explore Agent-to-Agent communication and MCP (Model Context Protocol). Combining those concepts with the architectures above will help you design an adaptive, scalable multi-agent system.

The Human Truths of Database Migration

CodeLink — Thu, 04 Sep 2025 14:58:49 +0000

The Human Side of Tech Decisions

We like to think that in the world of technology, logic and data are the lighthouse. The best algorithm or the fastest system always wins. But if you look closely, you’ll find that our most critical tech decisions are surprisingly human.

Consider this Asian philosophy:

At first glance, it sounds like a business adage, yet it sheds a surprising light on the complex, human-driven journey of data migration.

Data migration is a deep, multi-layered shift that affects systems, workflows, budgets, and most importantly, people. And once a company does commit to migrating, the challenges that follow go far beyond just moving data.

This article breaks down the truths and trials of this journey, moving beyond the marketing hype to what really matters.

How We Really Pick a Database

Let’s unpack the quote above further and see how choosing a database can be in real life.

Pedigree First

It's human nature to trust what's popular, so a database’s reputation, its "pedigree," can carry a lot of weight. This creates a powerful "halo effect": we assume that because a technology is widely used, it must be the best for every situation.

Take MongoDB, for example. Its huge market share and massive community make it feel like the default "safe" choice. A less-known database might be a better technical match for certain use cases, but they rarely get the same attention.

When pedigree takes the lead, teams might default to the familiar without diving into whether it’s actually the best tool for the job. That can lead to suboptimal choices, higher long-term costs, and missed opportunities to build something better.

Relationships Second

Beyond brand names, we stick with what and who we know, a.k.a our “relationships.” This could be a strong relationship with a vendor, a helpful online community, or simply your development team's comfort level with a certain technology.

A team might stick with a familiar tool simply because it's easier than learning something new. The feeling of safety that comes from established relationships often wins out, even if an unfamiliar alternative could deliver better results.

Money Takes Third Place

Of course, “money” always has a seat at the table. The total cost of ownership (licensing fees, operational overhead, training, etc.) is a huge driver in any tech decision. It can push teams toward more affordable or already-supported solutions.

The problem is when cost starts driving the decision instead of informing it. Choosing the cheapest path can mean settling for a weaker fit, which might cost more down the line in performance issues or scaling challenges.

Only Then Does Intellect Matter

And here we are, at the bottom of the list: the pure technical capabilities. This is the database's true "intellect": performance benchmarks, indexing capabilities, query language power and flexibility, architecture fit, so on and so forth.

Ideally, this is where the decision should start and end. But by the time teams reach this stage, it’s often already skewed by reputation, relationships, or cost. The technical merit becomes a box to tick, not the core of the choice.

More Alike Than You Think: MongoDB vs RethinkDB

The tech world loves a good rivalry, and it's easy to get caught up in marketing that highlights what makes each tool unique: the killer feature, the standout use case, the unique philosophy, etc. But if you look past the hype, you'll find that competing technologies often share the same DNA.

This is what we mean by seeking a “truth in tech”: cutting through branding to focus on the core engineering principles. And sometimes, that truth reveals unexpected common ground.

Take MongoDB and RethinkDB. Unlike MongoDB, which requires developers to poll for changes, RethinkDB has a fundamentally different architecture that allows developers to continuously push updated query results in real time. However, let’s look at their biggest commonalities in our full article here.

This kind of foundational overlap is easy to miss if you’re only comparing surface-level features or chasing a single “killer” use case. At the end of the day, the choice between databases should be based on a deeper analysis of your needs, not just a single feature.

3 Core Challenges of Database Migration

Database migration may sound straightforward. Just move data from point A to point B, right? In reality, it’s a minefield of risks and complexities that, if not managed carefully, can cause major headaches.

Based on what we’ve seen, below are some real-world migration risks:

Technical Hurdles

Let’s start with the obvious: the technical side is tough. You’re dealing with high stakes and high complexity, and there’s not much room for error.

Data Integrity and Consistency: The absolute number one rule is that all data remains accurate, complete, and consistent throughout the transfer process. Any loss, corruption, or inconsistency can have a serious impact on everything from financial records to customer trust.
Schema Incompatibility: Data from the old database rarely fits perfectly into the new one. Especially when moving between different types of databases (like from a relational database to a NoSQL document store, or even between different NoSQL schemas). This requires careful mapping to ensure structural compatibility and optimal performance in the new environment.
Migration Downtime Risk: The goal is always a migration that your users barely notice. In practice, that’s hard. Even a short disruption can cause financial losses, erode user satisfaction, and damage an organization's reputation.
Integration with Existing Systems: Your new database needs to play nicely with all your existing apps, services, and reporting tools within the broader technological ecosystem. This often requires updates to connectors, APIs, and data pipelines, followed by rigorous testing a.k.a our next point.
Rigorous Testing: It’s a non-negotiable, as this stage is where hidden issues usually emerge. You’ll have to validate the data, benchmark performance in the new environment, test app behavior, and run disaster recovery procedures.
Data Volume and Velocity: If you're moving massive datasets, especially for systems with high transaction rates or real-time data streams, things get even more complicated. This requires robust infrastructure, optimized migration strategies, and careful management of network bandwidth and processing power.

These technical problems aren't isolated; they're interconnected. A small oversight in one area, like a flawed schema or a poor data check, can easily snowball into major problems like integration failures, slow performance, or an inconsistent database.

Taking shortcuts creates "invisible technical debt," or hidden problems that don't show up right away but will appear months later as mysterious bugs, performance bottlenecks, and maintenance nightmares. That’s why migrations demand a quality-over-speed mindset.

Resource Realities

Beyond the technical challenges, a database migration puts a major strain on your resources.

Unexpected Costs: Few migrations stay under budget. Database migrations frequently exceed initial estimates. Unforeseen problems, the need for special tools, or hiring outside experts can quickly blow up expenses.
Tooling Limitations and Custom Scripting: Off-the-shelf migration tools rarely do it all. Many teams find they need custom scripts to handle specific data transformations, complex integration points, or unique features of the source or target database. That development work takes time and pulls engineers off other priorities.
Infrastructure Demands: The target environment might require better hardware, cloud services, or architecture changes, adding to the total cost. This is to meet the performance and scalability requirements for the migrated data and the applications that will interact with it.

And these aren’t just line items; they come with an “opportunity cost.” When your best engineers are tied up on migration, they’re not shipping new features or pursuing growth initiatives. That can slow momentum and delay progress elsewhere in the business.

The People Factor

Finally, and most importantly, every migration is also a change management challenge. A technology shift is only successful if the people involved embrace it.

Skill Gaps: Teams may lack the necessary expertise with the new database, creating a significant bottleneck. This means you'll have to invest heavily in training or hire new talent, both of which take time and money.
Resistance to Change: People get comfortable with their tools and workflows. Introducing a new system, even if it’s better, often meets friction. In worst case scenario, frustration and resistance. Success requires empathy, strong communication, and early involvement from stakeholders.
Misalignment: A lack of clear communication or buy-in from all stakeholders (development, operations, and business stakeholders) can kill a project. Consistent, honest communication builds trust and keeps everyone aligned.
Expectations and Human Error: Set realistic expectations without sugarcoating the complexity. And protect against avoidable mistakes with clear procedures, validation steps, and fallback plans.

This people layer in database migration, if neglected, can build up what we call “cultural debt.” This goes beyond project delays; it leads to low morale, a loss of trust in leadership, and a team that’s resistant to future changes. A bad migration experience can haunt your company's culture and agility for years.

A successful migration creates a stable, scalable foundation without burning out your team, breaking your systems, or losing momentum. And that takes more than technical skills. Focus on your people with clear communication and training, and you’ll see resistance turned into support and a tough migration became a powerful opportunity for your team to grow.

What Migration Really Teaches Us

Database migrations are never just about tech. This is a “truth in tech” from the very beginning, when database selection is shaped as much by pedigree, relationships, and money as they are by intellect. It’s just as true when the migration begins, where the real hurdles aren’t just code and servers, but the interconnected challenges of budgets, resources, and people.

Ignoring this human reality is how we accumulate hidden costs: the technical debt from rushed solutions, the opportunity cost from a distracted team, and the deep cultural debt that comes from a poorly managed change.

What matters most isn’t just the system you move to, but how honestly you assess what’s driving the move, and how well you bring your people along. Done right, migration isn’t just a technical shift. It’s a chance to rethink how your organization builds, decides, and grows.

All in all, we want to say thank you, RethinkDB, for its invaluable contribution to our system. It’s a genuinely well-designed technology, loved by our team and many others, even when in reality, not everything goes as we wish.

Lovable vs Builder.io vs Figma Make: What’s the Vibe Code Tool for You?

CodeLink — Thu, 21 Aug 2025 13:22:07 +0000

What Kind of Vibe Are You Coding?

There’s a new term making the rounds that perfectly captures the shift in modern software development: vibe coding. Coined by OpenAI co-founder Andrej Karpathy, it describes an AI-assisted workflow where developers use natural language prompts to generate and refine code. Instead of writing every line manually, you guide an AI, turning high-level goals and plain English descriptions into functional applications.

In the center of the trend, AI-powered low-code platforms are making big promises. They offer an incredible speed boost, moving ideas from prototype to production faster than ever. But the real test comes post-MVP.

In this article, we’ll compare three mature platforms (Builder.io, Lovable, and Figma Make) from a technical perspective, moving past the marketing hype to see how they handle code quality, backend integration, GitHub workflows, and whether they can produce production-ready code that stands up to the demands of scaling.

The goal is simple: help you decide which tool fits your vibe coding workflow today and won’t slow you down tomorrow.

Two Categories of Vibe Coding Tools

Vibe coding tools generally fall into two groups:

For technical users: AI-assisted coding tools like Copilot, Cursor, Windsurf, Bolt.new, v0.dev, and Replit, built to speed up development while offering full integration with traditional software development life cycle.
For non-technical users: Low-code platforms like Lovable, Builder.io, and Figma Make, designed to turn prompts, images, or designs into functional UIs without needing programming know-how.

The second category is where the most interesting questions about bridging vibe code and custom development arise. It’s these visual builders we’ll be focusing on.

Choosing Between Lovable, Builder.io, and Figma Make

Each offers a unique philosophy on how to get from prototype to production, but they all promise to give developers superpowers:

Lovable is an AI-native tool that turns prompts or screenshots into clean, production-ready UIs. Its focus on built-in backend support makes it a strong choice for rapidly building functional applications.

Builder.io is pitched as the visual development platform for teams who want it all. This app provides a developer-friendly no-code workflow for building and optimizing digital experiences with full control, whether visually or in code.

Figma Make is built for the design-first workflow to eliminate the gap between design and development. It empowers teams to turn meticulously crafted Figma frames into live, interactive apps without leaving the design ecosystem.

The table below breaks down their core capabilities, user experience, and technical considerations side by side.

Feature / Factor	Lovable	Builder.io	Figma Make
Prompt-to-Code	✅	✅	✅
Image-to-Code	✅ Direct screenshot	✅ Figma/Screenshot	✅ Figma-native
Deployment	✅ Built-in deploy	✅ Netlify, Vercel integrations	✅ Via Make Cloud
Backend & DB Integration	✅ Supabase native	🟡 Plugin-based	✅ via Supabase, Xano, etc.
Source Code Control	✅ GitHub integration	✅ GitHub integration	✅ GitHub export
Claude Code	✅	✅	✅
Built-in UI Editor	❌ VS Code-style interface	✅ Drag-and-drop (can be cluttered)	✅ Intuitive and Figma-native
Interface / UX	✅ Minimal and focused	🟡 Rich but dense	✅ Familiar Figma interface
Pricing (at time of test)	Freemium + subscriptions starting from $25	Freemium + subscriptions starting from $24	Freemium + paid templates/add-ons

So, Which One Makes Sense for You?

The right choice depends on your role, goals, and technical comfort level. Use this table to see which platform best fits your context.

Persona	Common Needs	Technical Level	Likely Fit
Non-tech founder	Build MVP, test an idea fast	Low	Lovable or Figma Make
Product designer	Build responsive UI mockups or marketing pages	Low	Figma Make or Builder.io
Technical founder	Rapid UI scaffolding with clean code	Medium	Lovable (with audit)
Internal tools team	Build admin panels, dashboards	Medium - High	All of them
Enterprise design+dev	Collaborate on branded landing pages	Low - Medium	Builder.io or Figma Make
Figma-centric team	Extend Figma workflows into production-ready UI	Low - Medium	Figma Make

Under the Hood: How Each Tool Treats Code

The long-term value of any AI UI builder comes down to the quality and usability of its output. Want a realistic look at what to expect? Read our full blog here.

Best Practices for Vibe-Code Platforms

Getting the most out of tools like Lovable, Builder.io, and Figma Make goes beyond typing a prompt; it’s about how you guide and refine the process.

Provide As Much Context As Possible

Vague prompts yield vague results.

Don't just ask for "a login page." Specify the user type, the design intent, and the core functionality. The more context you provide, the less work you'll have to do later.

Attach Visual or Structural References

Show, don’t tell. That’s the most effective way to communicate your vision.

Whenever possible, use the image-to-code features by providing a screenshot or a wireframe. If you're coming from a design background, linking directly to a Figma frame gives the AI a powerful, unambiguous blueprint to work from, dramatically improving the quality of the first draft.

Plan for Iterative Prompting

Don't expect a perfect, finished product on the first try. If it’s unrealistic to get that from human teammates, it’s just as unrealistic from an AI model.

So, trust the process and keep the conversation going. Your first prompt gets you a baseline. From there, you refine it with follow-up commands.

Plan for Handoffs and Refactors

If you're working in a team, establish a clear process for how AI-generated code is audited and integrated. Schedule time for a developer to review the code, refactor it to match your project's conventions, and connect the necessary backend logic.

The clean handoff to engineering teams requires a mutual understanding that the output is a starting point. Which leads us to the next point.

Think Beyond the Demo

The primary value of these platforms is in generating high-quality scaffolding. They eliminate the tedious work of building the initial UI structure, but they don't deliver a finished, production-hardened application.

Always treat the output as a significant head start, not the finish line. That’s the key to creating maintainable AI-generated code and successfully scaling beyond the MVP.

What Happens Post-MVP

You've used an AI UI builder to launch your MVP in record time. It looks great, and the initial feedback is positive. Now what?

Common Pitfalls

The initial velocity can mask common pitfalls that emerge as you scale:

Spaghetti code: Relying on endless prompt tweaks without a structured plan can create a tangled web of AI-generated styles and logic that becomes nearly impossible to refactor or maintain.
Vendor lock-in: Your application can become so dependent on a platform's proprietary components and build processes that you can't easily move it. And it’s not ideal to be reliant on a single provider for hosting, updates, and scaling.
Unscalable infrastructure: The convenience of a platform's built-in backend can hit a ceiling just as your user base starts to grow, forcing complex and costly migrations when you can least afford them.
Performance and security: These platforms’ generated code is front-end heavy and not optimized for high-traffic performance or safe data handling. If left unchecked, this can easily introduce security risks, slow load times, and bottlenecks later on.

All of these create a classic recipe for technical debt. Every quick prompt tweak you make to fix a problem, instead of stepping back for structured planning, is a small deposit into that debt.

Recommendations

Avoid these traps and ensure your project has a future with our best practices:

Conduct early code audits: Before adding more complexity, have a developer audit the codebase to catch any issues while they’re still small. Understand its structure, identify potential hardening or refactoring opportunities, and establish clear coding conventions.
Balance speed with maintainability: What’s fast now isn’t always fast later. The initial speed of AI generation is an asset, but it should be immediately channeled into a workflow that prioritizes clean architecture and maintainable AI-generated code.
Emphasize human oversight: Ultimately, an AI can accelerate the process, but it’s not the captain. A developer must own the architecture, validate the output, and make the critical decisions needed to build a robust, scalable, and secure application.

The era of vibe coding is here, but building a production-grade application still requires more than just a clever prompt. The real magic is picking tools you can grow with, not just ones that wow in a demo. And that’s exactly how we do things at CodeLink.

How We Turned Our Notion Playbook into a Slack Assistant with a Low-Code RAG Stack

CodeLink — Thu, 14 Aug 2025 14:00:00 +0000

Let us set the scene. It’s mid-morning, your coffee’s gone cold, and someone on the team pings in Slack asking:

“Hey, how many remote weeks can I get each year?”

You vaguely remember the answer hiding somewhere deep in the company playbook. A few Notion pages and bookmarks later, you’re still searching.

Understanding the struggle, we at CodeLink decided to build an internal assistant that could instantly answer company policy questions right in Slack, using a combination of Notion, a low-code orchestration tool (n8n), vector search, and a large language model.

No guessing page names. No digging through tabs. Just answers.

The Real Pain That Sparked It

At CodeLink, we document a LOT of useful things: company values, benefits, workflows, policies, you name it. But the more we document, the harder it gets to find stuff.

Faced with the current number of 260+ pages, team members often:

Slam CTRL+K in Notion trying random keywords
Ask in Slack and hope someone knows
Guess document titles like it’s a game of corporate Wordle

And when you finally do find the answer? It’s buried three sections deep in a page you didn’t expect.

The Idea of Letting Slack Just... Answer

We asked ourselves: “What if you could just type a Slack command like ‘What’s our remote meeting policy?’ and get an instant, accurate answer?”

That kicked off a simple but powerful internal initiative: using a lightweight Retrieval-Augmented Generation (RAG) workflow to connect Slack with our company knowledge, orchestrated entirely through n8n.

High-Level Workflow

Extract: Fetch Notion playbook content, including nested pages.
Chunk: Split content into manageable text blocks.
Store: Save these blocks in a vector database to enable semantic search.
Retrieve: When a Slack command is sent, convert the query into a vector and find the most relevant content.
Generate: Feed the results to an LLM to summarize the most relevant answers.
Respond: Send a human-friendly answer back to Slack with source references.

A high-level workflow to turn company policies to a Q&A Slackbot

Why We Chose Low-Code for Orchestration

Rather than building a full backend service to handle Slack events, query pipelines, and logic routing, we leveraged n8n to manage much of the integration and data flow logic.

Why That Worked Well for Us

We could design and iterate workflows quickly without scaffolding a backend.
Built-in integrations (Slack, Webhook, HTTP, conditional logic) saved a lot of time.
It remains visual and accessible to both devs and technical stakeholders.
Custom code is still possible using function nodes when needed.

This allowed our team to focus on the core value: getting information into people’s hands, fast.

Lightweight Slack-to-answer pipeline powered by n8n, from user command to response delivery

For example, instead of scaffolding a backend code logic just to call an embedding service, we simply configure an HTTP node in n8n. The model is specified, authentication is already handled via a predefined credential type of n8n, and the user’s input can be dragged directly into the request body. No boilerplate, no server code, just clean input/output that’s easy to visualize and test right inside the workflow.

An HTTP node configured to call the embedding API with dynamic input and built-in credentials, no backend code needed

Real Examples: The Bot in Action

Here are some real examples of how the assistant is being used inside Slack:

Example 1: Daily standup optionality

Example 2: Online meeting etiquette

What n8n Workflows Are (and Aren’t)

While n8n gives us incredible speed and flexibility, it’s not a catch-all solution.

Where it shines:

Automating internal workflows
Building quick prototypes or MVPs
Bridging systems using APIs or webhooks

Where it falls short:

High-scale, latency-sensitive production systems
Scenarios needing deep observability or reliability
Complex business logic with edge cases

💡 Pro tip: n8n is a jetpack for your workflow. But jetpacks aren’t built for long-haul flights. Use with context. Low-code tools are best seen as accelerators. They don’t replace solid engineering; they amplify it.

Why Not Just Use Notion Enterprise?

We get this question a lot, and it’s valid. Notion’s Enterprise Search is a robust and centralized solution for finding information across a large workspace.

But for our team, context is everything.

This assistant is scoped specifically to our internal playbook and lives directly inside Slack, the place where our team collaborates most. That means faster answers, less context-switching, and more relevance to how we actually work day to day.

All in all, this small project isn’t meant to compete with or replace what Notion is building. Instead, it complements it. A lightweight solution focused on one high-impact use case: surfacing key internal answers fast.

Final Thoughts

This project wasn’t just about answering questions in Slack. It was about making company knowledge accessible, contextual, and usable, exactly when and where people need it. By combining the right tools, Notion for content, a vector database for search, an LLM for natural answers, and n8n for orchestration, we created a simple but powerful assistant that actually gets used.

So the next time someone asks, “What’s our policy on…”

You can just smile and say: “Ask Slack.”

And that’s the real win.

A Guide to REST API Design Best Practices

CodeLink — Thu, 07 Aug 2025 04:07:16 +0000

In today’s digital ecosystems, Application Programming Interfaces (APIs) are the backbone of modern software development. They enable different applications to communicate and exchange data seamlessly.

Among the various API architectural styles, Representational State Transfer (REST) stands out for its simplicity, scalability, and statelessness. However, designing REST APIs isn’t just about getting data from points A to B. It’s about creating APIs that are not only functional but also easy to use, maintain, and evolve.

This guide will walk you through key REST API design best practices to help you build scalable, reliable, and developer-friendly APIs that reflect the standards we uphold at CodeLink.

1. Embrace Meaningful and Consistent Naming Conventions

Clear and consistent naming is the first step towards a well-designed API.

Use nouns to represent resources: Resources are the core concept in REST. Think of Uniform Resource Identifiers (URIs) as references to objects, not actions (e.g., /users not /getUserList, /orders not /getOrderList).
Pluralize resource names: Most API endpoints work with collections of data, so it’s clearer to use plural forms. For example, use GET /users to retrieve a list of users, and GET /users/{id} to get details for one specific user.
Set conventions and stick with them: Whether you choose singular or plural (though plural is recommended), stick with it across your entire API. Consistency reduces confusion and makes the API more predictable.
Use hyphens (-) for multi-word resources: When a resource name contains multiple words, use hyphens (-) to separate them for better readability in URIs. Avoid using underscores (_) or camelCase in URIs (e.g., /product-categories, not /productCategories or /product_categories).
Keep URIs lowercase: Ensure URIs are in lowercase to maintain consistency and avoid potential issues with case sensitivity.

2. Leverage HTTP Methods Correctly

HTTP methods (also knon as verbs) define the actions to be performed on resources. In RESTful APIs, using these methods with semantic precision ensures predictable behavior and clear communication.

GET: Retrieve a representation of a resource. GET requests should be safe (not alter server state) and idempotent (multiple identical requests have the same effect as a single one).
POST: Create a new resource. It's also used for actions that don't fit neatly into other methods (e.g., /users/{id}/send-verification-email). POST requests are not idempotent.
PUT: Update an existing resource entirely. If the resource doesn't exist, PUT can create it. PUT requests are idempotent.
PATCH: Partially update an existing resource. PATCH is ideal when you only need to modify a few fields of a resource. PATCH requests are not necessarily idempotent.
DELETE: Remove a resource. DELETE requests are idempotent.

Grasping the concepts of idempotency and safety for these methods is crucial to prevent unexpected behaviors.

3. Utilize HTTP Status Codes Effectively

HTTP status codes give clients clear feedback about what happened and why regarding their requests. Use standard HTTP status codes appropriately.

🟢 2xx (Success):

200 OK: Standard response for successful HTTP requests.
201 Created: The request has been fulfilled, and a new resource is created. Include a Location header pointing to the new resource.
204 No Content: The server successfully processed the request, but there is no content to return (often used for DELETE requests).

3xx (Redirection):

301 Moved Permanently: This and all future requests should be directed to the given URI.
304 Not Modified: Used for caching purposes.

🟡 4xx (Client Errors):

400 Bad Request: The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax).
401 Unauthorized: Authentication is required and has failed or has not yet been provided.
403 Forbidden: The server understood the request, but is refusing to authorize it.
404 Not Found: The requested resource could not be found.
405 Method Not Allowed: The method specified in the request is not allowed for the resource.
429 Too Many Requests: The user has sent too many requests in a given amount of time.

🔴 5xx (Server Errors):

500 Internal Server Error: A generic error message, given when an unexpected condition was encountered.
503 Service Unavailable: The server is currently unavailable (e.g., overloaded or down for maintenance).

Provide clear and informative error messages in the response body, ideally in JSON format, to help developers troubleshoot and debug faster.

4. Prepare for Versioning

APIs are not static. As your product evolves, your API will too, whether through adding new features, improving performance, or fixing design flaws. Versioning your API allows you to release updates without breaking existing client integrations.

URI Versioning (e.g., /api/v1/users): This method is the most commonly used. It's clear and easy to route requests to the correct version. CodeLink prefers this approach for its clarity and simplicity.
Header Versioning (e.g., Accept: application/vnd.myapi.v1+json): This method makes URIs cleaner, but it may confuse developers who are used to more explicit URI versioning schemes. This approach is better suited for internal or closely coupled APIs.
Query Parameter Versioning (e.g., /users?version=1): While it can be beneficial in some instances, it might clutter URIs and sometimes be more complicated to manage.

Whatever strategy you choose, apply it consistently and document it clearly. A well-defined versioning approach ensures long-term API maintainability.

5. Support Filtering, Sorting, and Pagination

When your API returns collections of data, giving clients control over what and how they receive enhances both performance and usability. By providing mechanisms to filter, sort, and paginate, clients can retrieve exactly the data they need, reduce server load, and improve response times.

Filtering

Allow clients to filter results based on specific criteria (e.g., G_ET /products? category=electronics&status=available_).

Sorting

Enable clients to define the order in which results are returned (e.g., GET /users?sort=-createdAt for descending order by creation date).

Pagination

For large datasets, return results in chunks (pages) rather than all at once. Standard methods include:

Limit/Offset: (retrieve 20 products starting from the 41st).
Cursor-based: Uses a pointer to the last item in the previous set, often more performant for huge datasets (e.g., GET /products?page-size=20&cursor=abcdef).

Implementing these features thoughtfully will enhances the client experience.

6. Design for Statelessness

Each client request to the server must contain all necessary information to understand and process it. The server should not store any client context between requests. This approach, called statelessness, improves scalability, reliability, and visibility. Authentication tokens are typically sent with each request to maintain session identity without server-side session storage.

7. Secure Your API

Security is a must. Shield your API from unauthorized access and malicious threats.

Use HTTPS (TLS/SSL): Always encrypt communication between clients and your API to protect data in transit.
Implement Robust Authentication: Use standard authentication mechanisms like OAuth 2.0 or OpenID Connect. Avoid rolling your own authentication.
Enforce Authorization: Ensure that authenticated users only have access to the resources and operations they are permitted to use.
Input Validation: Validate all incoming data to prevent common vulnerabilities, such as SQL injection or Cross-Site Scripting (XSS).
Rate Limiting: Protect your API from abuse and ensure fair usage by implementing rate limits.

Prioritizing security from the start helps prevent breaches, protects user data, and builds long-term trust with your API users.

8. Provide Clear and Comprehensive Documentation

Your API is only as good as its documentation. Well-documented APIs help developers understand and integrate easily.

Use a Standard Format: Tools like OpenAPI (formerly Swagger) help you define and document your API in a machine-readable and human-readable format.
Include: Authentication instructions. Detailed descriptions of each endpoint, including URI, HTTP method, request parameters, and example requests/responses. Explanation of error codes and messages. Information on rate limiting and versioning.
Keep it Up-to-Date: Documentation should be updated alongside your API to reflect changes accurately.

Clear, consistent, and up-to-date documentation reduces support overhead and accelerates adoption.

Partnering with CodeLink for API Excellence

Designing high-quality REST APIs is an art that blends technical expertise with a focus on the developer experience. By following these best practices, you can create APIs that are not only powerful and scalable but also a pleasure for developers to work with.

At CodeLink, we are dedicated to helping businesses design, develop, and deploy APIs that drive innovation, streamline processes, and unlock new revenue streams.

If you're looking for a partner to help design or optimize your API strategy, we’re here to help. Let’s connect!

The Cost of Choosing the Wrong Tech Stack – A Lesson from a Tech Lead

CodeLink — Thu, 31 Jul 2025 10:58:04 +0000

TL;DR

The Perfect Architecture Trap: A fintech startup chose a complex tech stack for perceived performance benefits but crashed from 40 to 20 story points velocity because the architecture was overly complex for their actual needs and team capabilities.
Root Causes: Choosing unfamiliar technologies without team expertise while implementing microservices architecture created operational chaos that solved tomorrow's scalability problems while creating today's velocity problems.
The Fix: Refactored to a simpler architecture aligned with team strengths, resulting in 60% velocity improvement, simplified operations, and restored team morale within 6 weeks.
Key Lesson: Team expertise trumps technology hype - validate with proof-of-concepts first, match complexity to organizational maturity, and optimize real bottlenecks (not theoretical ones) while being transparent with stakeholders about technical decisions' business impact.

The "Perfect" Architecture

In early 2021, I worked at a fintech startup where we faced an exciting challenge: building a fintech application from scratch. We designed what seemed like the ideal system – microservices with domain-driven design, powered by Go. Our reasoning seemed sound:

Performance First: Fintech demanded speed for handling thousands of requests so we chose Go for its fast runtime.
Microservices for Scale: Each service had its own database to eliminate bottlenecks
Domain-Driven Design: Complex business rules needed clean abstractions and extensive testing

Here's what we should have done first: built a two-week proof of concept with a single critical user journey. Instead, we launched into full development with confidence. Two months later, we were drowning.

When Reality Hits

Our sprint velocity crashed from 40 story points to barely 20. Features that should have taken 6-9 story points were consistently taking 12-15 points. What went wrong?

The Go Language Trap

The biggest red flag I missed: we had JavaScript veterans but no Go experts, yet we chose Go anyway. This should have been a hard stop.

Go in 2021 was deceptively simple – too simple for complex domain logic. Without generics (which didn't arrive until Go 1.18), we found ourselves writing repetitive boilerplate code. The multiple layers of DTOs – from controller to application service to domain model and back became a nightmare of manual mapping. Every small change rippled through endless conversion functions.

Any experienced Go developer would have warned us about the boilerplate hell for complex domain models. We were learning a new language while trying to implement complex patterns – a recipe for disaster.

Microservices Without Operational Maturity

Our 10 microservices seemed elegant in theory, but created operational chaos:

10 Databases, 10 Migration Scripts: that consumed enormous developer time.
Transaction Nightmares: How do you maintain data consistency across 10 different databases? We built custom middleware to track transaction states and handle rollbacks – a massive engineering effort that added months to every feature.
Communication Complexity: Services needed both synchronous (gRPC) and asynchronous (message queues) communication, requiring extensive boilerplate and making testing incredibly difficult.

We were solving tomorrow's scalability problems while creating today's velocity problems. The classic rule is "start with a modular monolith, extract services when you have real pain points." We did the opposite.

Not to mention that "thousands of requests" for a pre-investment fintech startup was pure over-engineering. We were building for Netflix scale when we needed to focus on getting our first 100 users.

The Hidden Costs of Wrong Decisions

Every architectural decision multiplied our complexity:

Testing a single transaction across multiple services became an integration nightmare
Debugging issues required tracing through multiple service logs
Simple changes required coordinating deployments across multiple services

But the technical pain wasn’t the worst of it. The people cost was higher:

Onboarding new developers took weeks just to grasp how services interacted
Knowledge became siloed, code reviews slowed down, and team morale dropped
Senior developers were spending days on tasks that should have taken hours.
One team member told me bluntly: "I feel like I'm fighting the language instead of solving problems."

Asking Better Questions (And Having Hard Conversations)

When sprint velocity halves, that should trigger immediate investigation – not months of struggle. I should have called a technical spike after the first month.

We stepped back and asked fundamental questions that we should have started with:

The hardest conversation was admitting to stakeholders that our "modern, scalable" architecture was actually slowing us down. I had to explain that we needed to invest a full month in refactoring to hit our roadmap targets. I framed it as risk mitigation: continue struggling and miss our investor milestones, or invest now to ensure consistent delivery for the next six months.

The real lesson: I should have handled the sunk cost fallacy head-on. The architecture was fundamentally wrong, and trying to "fix" it would have been throwing good money after bad.

The Solution of Strategic Simplification

We made the hard decision to refactor to a Node.js monolith using NestJS but this time, we built incrementally:

Team Expertise Alignment

Leveraging our JavaScript experience eliminated the learning curve, letting us focus on business logic instead of language quirks. This wasn't just about technical efficiency. it was about team morale and confidence.

Modular Monolith Architecture

Single Database: Transactions became simple again.
Clear Domain Boundaries: We kept domain separation for potential future microservices migration, but without the operational overhead.
Reduced DTOs: JavaScript's native JSON handling eliminated layers of conversion code.
Simplified Testing: Unit and integration tests became straightforward.

Performance Strategy

Instead of distributed complexity, we focused on proven database optimization:

Intelligent caching strategies
Proper indexing
Connection pooling
Query optimization

We could always add sharding later if needed, then we'd solve actual performance problems, not theoretical ones.

Incremental Validation

This time, we built and deployed core features every week, just enough to test assumptions and get feedback quickly. This allowed us to validate each architectural decision with real usage data instead of theoretical discussions.

Small, tangible wins replaced uncertainty, helping us make smarter choices with less risk and more clarity.

The Positive Results

The change was transformative. Six weeks after the refactor:

60% Velocity Improvement: Features that once took 12-15 story points were now consistently delivered in 6-8 points.
Simplified Testing: Integration tests that were once nearly impossible became a routine part of our workflow.
Developer Happiness: The mood shifted entirely. The team was energized and excited to be building products again, not fighting tools.
Stakeholder Confidence: We delivered our next investor milestone two weeks ahead of schedule.

Key Lessons for Tech Stack Selection

This experience taught me invaluable lessons that I now apply to every project at CodeLink.

1. Validate Before You Build

Never design an entire architecture in meetings. Build a two-week proof of concept (PoC) that focuses on a single, critical user journey. Every system sounds elegant in a slide deck. The only real test is whether it works under real conditions.

Rule of thumb: If your proposed stack makes easy things hard, it will make hard things impossible.

2. Team Expertise Trumps Technology Hype

Your team's existing skills matter more than the latest trends. A "worse" technology that your team has mastered will outperform a "better" technology they struggle with.

We chose Go without any Go expertise, and paid for it with slow progress and burned-out developers. As a technical leader, your job is to set your team up for success, not to implement the most impressive architecture.

3. Match Complexity to Organizational Maturity

Microservices solve real problems at scale and with mature teams. Startups need velocity, not distributed systems complexity. Build for your current reality, not your imagined future.
Start with a modular monolith. Extract services when you have real pain points, not theoretical ones. Complexity is a tax, don’t pay it early.

4. Identify Your Real Bottlenecks

We assumed our bottleneck was application performance when it was actually database queries and developer productivity. Optimize the constraints that matter.

When velocity drops significantly, stop and investigate immediately. Don't let teams struggle for months. Treat it as the emergency it is.

5. Consider Total Cost of Ownership

Every tech choice comes with a hidden price tag – some visible, some not. When evaluating technologies, go beyond performance and features:

Learning curve and hiring difficulty
Maintenance burden and update frequency
Testing and debugging complexity
Long-term scalability (both technical and organizational)
Team morale and productivity impact

6. Translate Technical to Business Terms For Stakeholders

When technical choices go wrong, your response matters more than the original mistake.

Stakeholders may not understand technical debt, but they understand risk, delays, and missed milestones. Be transparent about problems, frame technical debt in business impact terms, and provide clear success metrics for solutions.

Handle the sunk cost fallacy head-on. Sometimes the best decision is admitting the fault in the architecture and starting over.

MCP Under the Hood

CodeLink — Tue, 29 Jul 2025 14:35:26 +0000

If you have been following AI development, you have probably heard about Model Context Protocol, or MCP for short. It is a simple protocol that empowers LLMs and extends their capabilities.

This article uses a simple real-time query example to show how MCP works under the hood.

Real-time query example

We implement a weather MCP server that allows users to query real-time weather conditions from any location using the Claude Desktop App.

LLMs are incapable of querying real-time data, so if you ask it “Current weather in NYC?”, without MCP (and web search turned off), it’ll return something like this:

And with MCP, it can now answer the query by leveraging tools:

How does it work?

From a high level, there are several components:

It's important to note that in this example, the MCP Client and MCP Server both exist locally on the user's desktop. The Desktop Claude App is the MCP Client host, meaning that the MCP Client exists inside the app.

The MCP Server provides two tools to return real-time information:

get_alerts: Get weather alerts for a US state. It requires an argument,state - a two-letter US state code (e.g., CA, NY)
get_forecast: Get weather forecast for a location. It requires 2 arguments, latitude - latitude of the location, and longitude - longitude of the location.

For each tool, the MCP makes a call to its respective Weather API endpoint, which are just normal HTTP endpoints at https://api.weather.gov.

Under the hood, several steps are going on:

The Claude Desktop gets a list of available tools, in this case, get_alerts and get_forecast
Claude Desktop sends the user query to Claude LLM
Claude LLM analyzes the available tools and decides which ones to use
The Claude Desktop executes the chosen tools through the MCP server
Weather API returns the real-time information
The results are sent back to Claude LLM
Claude LLM formulates a natural language response and Claude Desktop displays the final answer

A deeper view

To understand how all these components coordinate, we'll use a request diagram. Please note that it has already been simplified to omit some protocol details.

Step 1: The MCP Client gets a list of available tools from MCP Server

The MCP Client establishes a connection to the Server and retrieves available tools. These tools are stored in the session and are structured as follows:

[
    {
        'name': 'get_alerts',
        'description': 'Get weather alerts for a US state.', 
        'input_schema': {
            'properties': {
                'state': {'title': 'State', 'type': 'string'}
            }, 
            'required': ['state'], 
            'title': 'get_alertsArguments', 'type': 'object'}
    },
    {
        'name': 'get_forecast', 
        'description': 'Get weather forecast for a location',
        'input_schema': {
            'properties': {
                'latitude': {'title': 'Latitude', 'type': 'number'},
                'longitude': {'title': 'Longitude', 'type': 'number'}
            }, 
            'required': ['latitude', 'longitude'],
            'title': 'get_forecastArguments', 'type': 'object'
        }
    }
]

All information, such as tool name, description, and arguments, is defined on the server side. The MCP Server Python code looks like this:

@mcp.tool()
async def get_alerts(state: str) -> str:
    """Get weather alerts for a US state.
    Args:
            state: Two-letter US state code (e.g. CA, NY)
    """
    # Implementation...

@mcp.tool()
async def get_forecast(latitude: float, longitude: float) -> str:
    """Get weather forecast for a location.
    Args:
        latitude: Latitude of the location
        longitude: Longitude of the location
    """
    # Implementation...

Step 2: Claude Desktop sends your question to Claude LLM

Tool calling is actually supported by Claude LLM and isn't a new feature introduced by MCP. According to the official Claude LLM documentation:

If you include tools in your API request, the model may return tool_use content blocks that represent the model's use of those tools. You can then run those tools using the tool input generated by the model and then optionally return results back to the model using tool_result content blocks.

The exact tool structure above will be added to the query to Claude LLM. Example code in Python:

self.anthropic.messages.create(
        model="claude-3-5-sonnet-20241022",
    max_tokens=1000,
    messages=[{'role': 'user', 'content': 'Current weather in NYC?'}],
    tools=... # tools defined as above
)

Step 3: Claude LLM analyzes the available tools and decides which ones to use

With the provided tools, the LLM determines which one is appropriate for the user's query. In this example, it recognizes that for the query "Current weather in NYC?" it needs to call get_forecast

Since this tool requires two parameters: latitude and longitude, the LLM understands that it needs to provide the coordinates for NYC, which it already knows from its training data.

The LLM will respond with something like this:

TextBlock(citations=None, text="Let me get the weather forecast for New York City. I'll use approximate coordinates for Manhattan.", type='text')

ToolUseBlock(id='toolu_***', input={'latitude': 40.7128, 'longitude': -74.006}, name='get_forecast', type='tool_use')], model='claude-3-5-sonnet-20241022', role='assistant', stop_reason='tool_use', stop_sequence=None, type='message', usage=Usage(...))

Step 4: The Claude Desktop executes the chosen tools through the MCP server

The Claude Desktop app will then utilize the protocol to query the weather API. The request will go through the Claude Desktop App, MCP Client, and MCP Server due to the protocol design.

Step 5: Weather API returns the real-time information

The response from Weather API will be returned in reverse order, first to MCP Server, then MCP Client and finally to Claude Desktop App. The payload looks similar to this:

This Afternoon:
Temperature: 72°F
Wind: 9 mph S
Forecast: A chance of rain showers. Partly sunny. High near 72, with temperatures falling to around 68 in the afternoon. South wind around 9 mph. Chance of precipitation is 30%.

---

Tonight:
Temperature: 62°F
Wind: 6 to 9 mph SE
Forecast: A chance of rain showers before 11pm, then showers and thunderstorms. Cloudy. Low around 62, with temperatures rising to around 64 overnight. Southeast wind 6 to 9 mph. Chance of precipitation is 100%. New rainfall amounts between 1 and 2 inches possible.

...

Step 6: The results are sent back to Claude LLM

Claude Desktop App will send the original query "Current weather in NYC?" along with the weather forecast payload from Step 5 to Claude LLM.

Step 7: Claude LLM formulates a natural language response, and Claude Desktop displays the final answer

Claude LLM formulates a natural language response, and Claude Desktop displays the final answer. Based on the forecast data provided, the LLM creates a friendly response, which is then displayed on the Desktop App:

Here's the current weather for NYC:
This Afternoon: 72°F with partly sunny skies and a 30% chance of rain showers. South winds around 9 mph.
Tonight: Expect significant weather changes with showers and thunderstorms developing (100% chance), temperatures around 62°F, and 1-2 inches of rainfall possible.

And that's the whole flow of this simple example! As you can see, it is a mechanism that standardizes and simplifies how the LLM works with external tools or resources.

Why is MCP needed?

MCP is so simple that you almost don't need one to orchestrate tool calling. However, it helps standardize resources, and the community has quickly developed many useful MCP servers. There are literally hundreds of them ready for use, such as GitHub, Jira, Slack, Cloudflare, Blender, etc., and the list keeps growing. You can simply add these to your Claude Desktop App or any host (like an IDE or chat client) to extend its capabilities!

Besides the tools or functions used in this simple example, MCP also supports other capabilities:

Resources: File-like data that can be read by clients (like API responses or file contents)
Tools: Functions that can be called by the LLM (with user approval)
Prompts: Pre-written templates that help users accomplish specific tasks

Final thoughts

The MCP ecosystem is quite new, but there's definitely a lot of excitement surrounding it. It will mature further as developers rush to build innovative applications with it.

While MCP significantly enhances AI capabilities, it also brings a new wave of security threats, which we have already addressed in another article.

How to Decide if Your Product Needs AI (or If You’re Just Chasing Trends)

CodeLink — Thu, 24 Jul 2025 14:00:00 +0000

In the current technology landscape, "AI-powered" is often treated as a definitive badge of innovation. Investors are drawn to it. Customers expect it. And businesses everywhere are scrambling to ride the hype.

However, the strategic application of AI is a matter of precision, not trends. Adding AI "just because" can drain budget, burn out teams, and dilute everyone’s focus on the real goals. The critical question is not if you can use AI, but why you should.

Below is a step-by-step guide that’s designed to help you decide with clarity.

Step 1: Performing a "Yes" or "No" Test for AI

AI excels in tasks that require cognitive-level processing. To determine if it’s the right fit, diagnose your own situation with a foundational question: Is there an intellectual process I’m trying to automate?

If your answer is no, and the task can be solved with basic logic or standard control flows, an AI model is unnecessary. Simple rule-based systems are faster, cheaper, and more reliable in those cases. For example, a system that sorts support tickets based on keywords is a clear-cut task for a simple rules engine.

But if your answer is yes, go deeper: Can the process be clearly defined with a fixed set of rules?

If you can manually write down all the rules—even if the list is long—doing so will give you more stable and consistent results than an AI model. If not, and the process involves nuance, uncertainty, or too many edge cases to list, that’s when AI makes sense.

Step 2: Spot the Signs of a Trend-Driven AI Strategy

Before moving forward, it's critical to gut-check your motives. Purposeful application is what separates a powerful AI feature from "AI theater." Here are the common signs that your team is chasing trends rather than value:

AI for marketing, not function: Are you adding the label just for the sound of it? While it might attract initial clicks, products risk damaging trust when users find there’s no real substance behind the claim.
The human replacement myth: AI is a powerful assistant, not a replacement for experts. Your team’s domain knowledge is what keeps an AI model relevant and sharp. Without human feedback, its quality will inevitably degrade.
Vague goals: An appeal to "improve our product with AI" is not a strategy. If you can't clearly state the problem you're solving and how to measure success, AI won't magically find the answer for you.
Lack of technical understanding: Effective AI solutions demand strong engineering and mathematical expertise. Without this, expect models that are probably inefficient, brittle, or incapable of scaling.
Insufficient or low-quality data: An AI model is a direct reflection of its training data. Without large, relevant, and well-labeled datasets, the model cannot learn or generate meaningful outcomes.
Ignoring data privacy and security: Handling user data is a huge responsibility. A plan for data privacy and security isn't an afterthought; it must be a core part of your AI development from day one.

Being able to spot these signs is the key to separating a valuable feature from a costly distraction.

Step 3: A 5-Step AI Evaluation Framework

Once you've confirmed you have a valid use case and are proceeding for the right reasons, this deliberate framework helps ensure your potential AI feature is strategically sound before you invest deeply. Ready to evaluate a potential AI feature?

Introduce AI expertise to your team: Before starting a journey into new territory, you bring an expert guide. Do the same here. Work with experienced AI strategists who can help define the path clearly and understand what's actually feasible.
Find the "aha!" moment: Where could AI create a genuine "aha!" moment for your users? Pinpoint specific opportunities where it could deliver measurable value, whether through smart automation, deep personalization, or better security.
Frame the problem clearly: Every successful project starts with a clear mission. For AI, that means defining: Input - What data will the system receive?; Output - What result should it generate?; Success - What does “good performance” look like?
Gather data and domain knowledge: Collect the right data, then pair it with human wisdom. Your domain experts are the ones who understand the user needs and tricky edge cases that will make an AI solution truly effective.
Develop and iterate together: Great AI isn't a one-time setup. It needs to be tested, refined, and improved with a constant feedback loop between your engineers, product owners, and experts. It must be woven into your product, not just bolted onto the side like a forgotten plugin.

Final Thoughts: AI is a Tool, Not a Goal

Ultimately, AI is not the goal. It’s a powerful tool for solving the right kinds of problems. True advancement comes from asking the right questions, framing the problem with clarity, and making strategic investments in expertise and data.

The bottom line will always be this: AI should serve your product, not distract from it.

💡 Need Help Deciding If Your Product Needs AI?

At CodeLink, our product and AI experts help teams distinguish between real value and industry hype. We partner with startups and enterprises to identify and build smart, practical applications of AI that drive meaningful results. Let's talk.

From LLM to AI Agent: What’s the Real Journey Behind AI System Development?

CodeLink — Tue, 22 Apr 2025 08:08:35 +0000

AI agents are a hot topic, but not every AI system needs to be one.

While agents promise autonomy and decision-making power, simpler & more cost-saving solutions better serve many real-world use cases. The key lies in choosing the right architecture for the problem at hand.

In this post, we'll explore recent developments in Large Language Models (LLMs) and discuss key concepts of AI systems.

We've worked with LLMs across projects of varying complexity, from zero-shot prompting to chain-of-thought reasoning, from RAG-based architectures to sophisticated workflows and autonomous agents.

This is an emerging field with evolving terminology. The boundaries between different concepts are still being defined, and classifications remain fluid. As the field progresses, new frameworks and practices emerge to build more reliable AI systems.

To demonstrate these different systems, we'll walk through a familiar use case – a resume-screening application – to reveal the unexpected leaps in capability (and complexity) at each level.

Pure LLM

A pure LLM is essentially a lossy compression of the internet, a snapshot of knowledge from its training data. It excels at tasks involving this stored knowledge: summarizing novels, writing essays about global warming, explaining special relativity to a 5-year-old, or composing haikus.

However, without additional capabilities, an LLM cannot provide real-time information like the current temperature in NYC. This distinguishes pure LLMs from chat applications like ChatGPT, which enhance their core LLM with real-time search and additional tools.

That said, not all enhancements require external context. There are several prompting techniques, including in-context learning and few-shot learning that help LLMs tackle specific problems without the need of context retrieval.

Example:

To check if a resume is a good fit for a job description, an LLM with one-shot prompting and in-context learning can be utilized to classify it as Passed or Failed.

RAG (Retrieval Augmented Generation)

Retrieval methods enhance LLMs by providing relevant context, making them more current, precise, and practical. You can grant LLMs access to internal data for processing and manipulation. This context allows the LLM to extract information, create summaries, and generate responses. RAG can also incorporate real-time information through the latest data retrieval.

Example:

The resume screening application can be improved by retrieving internal company data, such as engineering playbooks, policies, and past resumes, to enrich the context and make better classification decisions.
Retrieval typically employs tools like vectorization, vector databases, and semantic search.

Tool Use & AI Workflow

LLMs can automate business processes by following well-defined paths. They're most effective for consistent, well-structured tasks.

Tool use enables workflow automation. By connecting to APIs, whether for calculators, calendars, email services, or search engines, LLMs can leverage reliable external utilities instead of relying on their internal, non-deterministic capabilities.

Example:

An AI workflow can connect to the hiring portal to fetch resumes and job descriptions → Evaluate qualifications based on experience, education, and skills → Send appropriate email responses (rejection or interview invitation).
For this resume scanning workflow, the LLM requires access to the database, email API, and calendar API. It follows predefined steps to automate the process programmatically.

AI Agent

AI Agents are systems that reason and make decisions independently. They break down tasks into steps, use external tools as needed, evaluate results, and determine the following actions: whether to store results, request human input, or proceed to the next step.

This represents another layer of abstraction above tool use & AI workflow, automating both planning and decision-making.

While AI workflows require explicit user triggers (like button clicks) and follow programmatically defined paths, AI Agents can initiate workflows independently and determine their sequence and combination dynamically.

Example:

An AI Agent can manage the entire recruitment process, including parsing CVs, coordinating availability via chat or email, scheduling interviews, and handling schedule changes.
This comprehensive task requires the LLM to access databases, email and calendar APIs, plus chat and notification systems.

Key takeaway

1. Not every system requires an AI agent

Start with simple, composable patterns and add complexity as needed. For some systems, retrieval alone suffices. In our resume screening example, a straightforward workflow works well when the criteria and actions are clear. Consider an Agent approach only when greater autonomy is needed to reduce human intervention.

2. Focus on reliability over capability

The non-deterministic nature of LLMs makes building dependable systems challenging. While creating proofs of concept is quick, scaling to production often reveals complications. Begin with a sandbox environment, implement consistent testing methods, and establish guardrails for reliability.

From AI Hype to Real Value: Four Pillars of Successful Generative AI Deployment

CodeLink — Tue, 18 Feb 2025 18:46:36 +0000

When we discuss “AI” here, we’re specifically focusing on Generative AI Deployment within enterprise environments. Generative AI (GenAI)—a form of artificial intelligence based on neural networks and a subset of machine learning—goes beyond traditional models. While conventional machine-learning models often excel at classification or regression tasks, generative AI models create new content—text, images, code—based on learned patterns. This ability to “generate” new data brings unique opportunities and risks, making Generative AI Deployment a critical strategy for modern businesses.

In this article, we explore practical steps and four key pillars for Generative AI Deployment using the corporation’s own data to drive real value. By integrating a robust data strategy, skilled talent, clear application plans, and proactive risk management, you can transition from AI hype to tangible business success.

Approaches to Leveraging Generative AI in Corporate Environments

Broadly, there are two ways organizations might leverage GenAI:

Off-the-shelf Tools: Using ready-made AI models “as is” (for example, ChatGPT) without deep customization.
Customized Enterprise Applications: Integrating an AI model with a company’s internal, proprietary data and processes, tailoring it to meet unique business needs.

In this piece, we focus on the second scenario. We explore practical steps for deploying GenAI models on corporate data to create real value and mitigate risk. Some of today’s most popular GenAI models include OpenAI’s GPT-4, Anthropic’s Claude, Google’s Gemini, and Meta’s LLaMA 2.

In today’s fast-paced market, many companies feel pressured to integrate AI or risk falling behind. Yet, according to a Deloitte report, only about 30% of organizations ever move beyond the exploration phase. Why? It’s often not just fear of costly missteps—it’s a lack of the necessary ingredients for success. Without the right data strategy, skilled talent, clear application plans, and robust risk management, even the most promising AI initiatives can stall. This leaves many businesses uncertain and hesitant, unsure how to confidently turn ambition into tangible value.

Moving forward isn’t just about keeping pace—it’s about securing a long-term advantage. As Ajay Agrawal notes, “Because AI technology improves with use, whoever gets ahead first will gain a sustained edge over the competition.” In other words, the sooner you start turning experimentation into execution, the more value you’ll reap as your models improve over time.

This ‘flywheel effect’ means that every incremental piece of data can enhance model performance, further extending competitive advantage.

Still, no one has to remain in that uncertain state. By focusing on four key areas—data, talent, strategy, and risk—you can move from hesitation to action, from anxiety to achievement. Instead of feeling stuck in a cycle of indecision, you can begin to harness AI in ways that not only safeguard your business but also help it thrive in a competitive landscape.

Four Key Pillars

1. Data: The Bedrock of AI Success

AI models are only as good as the data they rely on. Without well-structured, secure, and properly permissioned data, insights remain limited, trust erodes, and your investment may never pay off. By establishing clear data governance and quality standards, you create the stable foundation needed for AI solutions that reliably support informed decision-making.

2. Talent: Bridging the Skills Gap

A shortage of specialized skills often keeps AI projects from taking off. According to a recent McKinsey report, as organizations set generative AI goals, the demand for “gen AI–literate” employees grows. Businesses must attract the right talent—and offer them meaningful, fulfilling roles—to keep them engaged. Partnering with experienced firms—like Codelink, which has guided more than 13 organizations through successful AI projects—helps bridge these gaps. With the right talent in place, you gain the confidence and capability to move from big ideas to measurable outcomes.

3. Strategy: Knowing Where (and Where Not) to Deploy AI

GenAI excels at pattern recognition but doesn’t genuinely understand what it’s “saying.” It’s effective in familiar domains but may falter in new, complex situations that demand nuance. Zillow’s attempt to automate its homebuying function revealed the risk of pushing AI beyond its comfort zone. Meanwhile, Domino’s found success by using AI in straightforward, well-understood areas to streamline operations. Start where AI can enhance—rather than replace—existing strengths and scale up as trust in the technology deepens.

4. Risk Mitigation: Tackling Six Core Challenges Head-On

A key component of successful Generative AI Deployment is proactive risk mitigation. When delivering custom AI solutions for our clients, we commonly encounter six major risk categories: Inaccuracies, Unpredictability, Bias, IP Concerns, Lack of Transparency, and Deception & Fraud. A recent Deloitte report urges organizations to “proceed with caution,” noting that GenAI can produce biased or factually incorrect content or draw on copyrighted material without proper authorization.

To help mitigate these issues—both at the input stage (the prompt) and the output stage (the model’s response)—we rely on a combination of AWS Bedrock Guardrails, Google’s AI Safety Guardrails, and open-source frameworks like Guardrails-AI. These solutions can intercept or filter requests before the model generates a response and review the output afterward to flag or remove problematic content.

AWS Bedrock Guardrails leverages Automated Reasoning to reduce factual errors from hallucinations while also filtering harmful content. Importantly, these filters can be adapted to align with an organization’s HR policies.
Guardrails-AI provides “jailbreak detection,” scanning input prompts for attempts to override restrictions or generate disallowed content—a valuable defense against Deception & Fraud. It can also monitor model outputs to identify unsafe or noncompliant language.
Google’s AI Safety Guardrails similarly offers pre-trained policies that can review both the prompt and the response, blocking undesirable or unsafe text to foster safer, more transparent LLM deployments.

While these examples illustrate some of the ways to mitigate AI-related risks, this is not an exhaustive review of every feature or functionality these tools provide. Moreover, these guardrail systems remain in preview or alpha stages, so they shouldn’t be viewed as infallible or the ultimate failsafe. To further minimize risk, it’s imperative to keep humans in the loop: human oversight can catch issues that automated tools miss. Additionally, “red teaming”—stress-testing models with challenging or adversarial prompts—is crucial for uncovering hidden vulnerabilities, ensuring a more robust and trustworthy AI deployment.

Conclusion

As you begin integrating generative AI into your organization, remember that success depends on robust data governance, skilled talent, a clear strategy, and proactive risk management. By methodically addressing each of these pillars, you can confidently transition from ambition to tangible value. The choice to act now isn't merely about staying competitive—it's about carving out a lasting edge in a rapidly evolving market.

At CodeLink, we have delivered AI solutions that drive competitive advantage—from MVPs to enterprise-scale deployments. Ready to take the next step? Book a 30-minute chat with us and discover how we can support your Generative AI initiatives.

Introducing New Features on Codest: Generate Flutter and React Native Apps!

CodeLink — Thu, 22 Aug 2024 07:20:59 +0000

Our recent newsletter introduced Codest, an AI tool that can generate NextJS apps from images.

Building on this success, our R&D team has expanded Codest’s capabilities to generate Flutter and React Native apps. We documented our progress and results in 2 previous blog articles (Generating Flutter App, Generate React Native App), where we promised these new features would soon be added to our PoC.

Today, we are thrilled to announce that our AI-powered tool, Codest, now supports the generation of Flutter and React Native apps from multiple images!

What's New?

Generate Flutter Apps: Our PoC now includes the ability to generate high-quality, modular Flutter code from images. This code separates layout and data, providing a solid foundation for developers to build upon.
Generate React Native Apps: Similar to our Flutter integration, you can now generate React Native apps, complete with reusable components and structured code.

Why Use Codest?

Codest has been proven to reduce development time by up to 20%, making it an amazing tool for developers to streamline their development process. Whether you’re working on mobile applications or web apps, Codest’s AI-driven approach ensures you get a head start with clean, modular code.

Below are some of the results we would love to share. You can see the original image on the left and the generated view on the right.

React Native

Flutter

Next.js

See It in Action!

We’ve put together 3 short introduction videos showcasing the main features and how you can use Codest to generate functional apps from images. Check out the video to see the magic happen!

React Native

Flutter

Next.js

Experience It Yourself

Visit codest.ai today to try out these new features.

Stay tuned for more updates as we continue to enhance Codest’s capabilities. Happy coding!