# Balancing risk and speed in AI-assisted frontend development (for Ethereum dApps)

## Why This Guide?

Web3 frontends are tricky - contract calls, wallet connections, transactions, and one wrong move could cost users their funds. The Ethereum/Web3 community rightly distrusts AI tools for such sensitive development, given the constant news of exploits and hacks.

I'm not a professional developer, but I have spent several months figuring out how to makes such tools work reliably. Instead of dismissing AI tools, I believe they can be used effectively and safely with the right approach.

This guide is for founders and product managers who understand smart contracts and want to ship quickly. It's for those who are bold enough to experiment while being mindful of the risks.

## Introduction

When it comes to frontend development for Web3, there are two main categories of AI tools right now that are able to help you build webapps with real code that can be handed over to an actual software developer:

### 1. AI-Integrated IDEs
Tools like Cursor, VS Code with Copilot, Fleet, Windsurf, Trae and Tabnine that integrate AI directly into your development environment. They excel at precise code generation and type safety, letting you code alongside the AI rather than having it code for you.

### 2. Browser-Based Generators
Tools like Lovable, Bolt, v0 and Buildglare that generate complete frontends from prompts. They're great at creating beautiful, coherent UIs quickly but can be less precise and sometimes hallucinate incorrect content.

For this guide, I'm just going to focus on Lovable and Cursor to represent each of these categories of solutions.

## Choosing Your Approach

After using these tools intensively for several months, I think there are three main approaches that one could take:

#### 1. The Trustfall Approach (Lovable Only)
Perfect for simple NFT/Token pages or quick prototypes. Requires minimal development knowledge - just understanding of Web3 concepts and contract interactions.

#### 2. The Manual Approach (Cursor Only)
Best for complex DeFi applications where you need precise control and type safety. Requires intermediate to advanced development knowledge.

#### 3. The Balanced Approach (Lovable + Cursor)
Ideal for full-featured dApps where you want both good UI and safety. Requires basic to intermediate development knowledge and understanding of both tools.

This guide will show you the three main ways to code fully-functioning frontends effectively using these tools, and the tips on how to navigate the pitfalls of each approach.

> **Note on implementation details**
> This is an AI-centric guide which means we only discuss high-level approaches and strategies rather than specific commands. For detailed implementation steps, command syntax, or specific tool configurations, just ask the AI chat in your chosen development environment (Cursor, Lovable, etc.) or ChatGPT/Claude/DeepSeek :)

## Development Approaches

### 1. The Trustfall Approach (Lovable Only)

A rapid prototyping approach that lets you generate complete frontends from natural language prompts, focusing on UI/UX and quick deployment.

**Pros:**

- Fastest way to get a working frontend
- Beautiful, coherent UI design
- No coding knowledge required
- Great for simple contract interactions

**Cons:**

- Less control over implementation
- Can hallucinate incorrect content
- Limited error handling
- May need manual fixes

A project that was built this way is [Immutable Frontends](https://immutable-frontends.eth.limo).


> **Use this when:**
>
> - Building simple NFT/Token pages
> - Creating quick prototypes
> - Working with single contract interactions
> - Need a beautiful UI without coding

**Implementation Guide:**

1. **A Big Bang Setup Prompt**

Boldly stuff everything Lovable would need to know into a single prompt. Yes, the context window is big enough for that.

   # START PROMPT 1: Contract Integration

   Create a new React project with the following contract integration:

   Contract Details:

   - Address: 0x123...
   - ABI: [...]
   - Network: Ethereum Mainnet
   - Contract code:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract NFTMint {
uint256 public constant MINT_PRICE = 0.1 ether;
uint256 public totalSupply;

event Minted(address indexed to, uint256 indexed tokenId, uint256 price);

function mint() external payable {
require(msg.value >= MINT_PRICE, "Insufficient payment");
uint256 tokenId = totalSupply++;
_mint(msg.sender, tokenId);
emit Minted(msg.sender, tokenId, msg.value);
}

function _mint(address to, uint256 tokenId) internal {
// Mint implementation
}
}

   Subgraph Details:
   - Endpoint: https://api.thegraph.com/subgraphs/name/your-subgraph
   - Queries:

query GetNFTs {
nfts(first: 10) {
id
tokenURI
owner
}
}
query GetPastMints {
mints(first: 20, orderBy: timestamp, orderDirection: desc) {
id
tokenId
minter
timestamp
price
}
}

   
   Implement the following components using the contract and subgraph details above:

   1. Mint Button Component:
      - Connect to contract using wagmi
      - Show mint price from contract
      - Handle mint transaction
      - Display loading/success/error states

   2. NFT Display Component:
      - Use GetNFTs query to show NFTs
      - Display NFT images and metadata
      - Show last successful mints

   3. Past Mints Component:
      - Use GetPastMints query to show recent mints
      - Display mint history in a table
      - Show mint price in ETH
      - Format timestamps
      - Truncate addresses
   
   # END PROMPT 1

> **Note:** If you're lucky, you might have a functioning frontend right away! If it doesn't behave as expected, start over with a slightly less ambitious prompt. For small tweaks, use additional prompts to polish the functionality.

2. **Styling and Polish**

Once you got the functionalities down, it's safe to start making the frontend look as you would like it to.

   # START PROMPT 2: UI Styling

   Style the components with the following requirements:

   Make the entire webapp look Barbie themed

   1. Mint Button:

      - Primary button with hover effect
      - Loading spinner during transaction
      - Success/error toast notifications
      - Price display in ETH with icon

   2. NFT Display:

      - Grid layout for NFTs
      - Card design with hover effects
      - Loading skeleton
      - Responsive design (mobile first)

   3. Past Mints:
      - Table layout with hover rows
      - Sortable columns
      - Loading skeleton
      - Mobile-responsive table
      - Truncated addresses with copy button

   # END PROMPT 2

> **Tip:** Check out the [Lovable prompting handbook](https://lovable.dev/blog/2025-01-16-lovable-prompting-handbook) for more tips and tricks on getting things right.

### 2. The Manual Approach (Cursor Only)

A precise, developer-centric approach that gives you complete control over the implementation while leveraging AI assistance.

**Pros:**

- Complete control over implementation and frameworks
- Better type safety and contract integration
- Easier to maintain and debug
- Better for complex DeFi features

**Cons:**

- Slower development speed
- No ability to use Lovable for UI improvements later
- Requires intermediate to advanced development skills
- More setup and configuration required

> **Use this when:**
>
> - Building complex DeFi applications
> - Working with multiple contract interactions
> - Need precise control over implementation
> - Require strong type safety

**Implementation Guide:**

1. **Project Setup**

   # START PROMPT 1: Project Initialization

   Initiate a new [FRAMEWORK] project with TypeScript.
   Use [yarn/npm] for dependency management.

   Required dependencies:

   - Web3: [WEB3_LIBRARY] (ethers.js, viem, web3.js)
   - State Management: [STATE_MANAGER] (react-query, zustand, redux)
   - UI Components: [UI_LIBRARY] (tailwind, chakra, mui)
   - Type Generation: [TYPE_GENERATOR] (typechain, abitype)

   # END PROMPT 1

After setting up the project structure, we need to generate TypeScript types for our contracts.

   # START PROMPT 2: Contract Type Generation

   Generate typings for @Contract1.sol and @Contract2.sol using typechain

   # END PROMPT 2

2. **Component Development**

> **Note:** Components generated by a single prompt tend to be more coherent than those generated separately. Start with the largest step possible, and if it doesn't work as expected, rollback and try with something slightly smaller.

Let's start with a full-feature implementation approach:

   # START PROMPT 3: Full Feature Implementation

   Generate a DEX swapping UI for contract 0x2dw8F...DRe83 using the types and functions in src/types. It should have:

   - List of past swaps from the last 4 hours using the Swap event
   - Simple interface for selecting two tokens to swap
   - Transaction history display
   - Swap execution functionality

   # END PROMPT 3

If you prefer more control, we can break this down into smaller components:

   # START PROMPT 4: Transaction List Component

   Create a 'TransactionList' component that:

   - Uses function X in src/types to retrieve Swap events
   - Displays past 4 hours of swaps
   - Formats and displays information neatly

   # END PROMPT 4

   # START PROMPT 5: Token Selection Component

   Create a Dropdown list component that:

   - Allows users to select from ERC20 tokens
   - Supports both 'from' and 'to' token selection
   - Integrates with the DEX interface

   # END PROMPT 5

   # START PROMPT 6: Swap Interface Component

   Create a Swapper component that:

   - Uses the previously created Dropdown for token selection
   - Implements swap functionality between selected tokens
   - Includes a Swap button that triggers wallet signature
   - Handles transaction states and errors

   # END PROMPT 6

> **Tip:** When working with complex features, consider breaking them down into smaller, manageable components. This makes it easier to debug and maintain, even though it might take more prompts to complete.

### 3. The Balanced Approach (Lovable + Cursor)

A hybrid approach that combines rapid UI generation with precise contract integration, leveraging the strengths of both tools.

**Pros:**

- Good balance of speed and control
- Beautiful UI with type safety
- Flexible development process
- Best of both worlds

**Cons:**

- Requires understanding both tools
- More complex workflow
- Need to manage two environments
- Limited to Lovable-supported frameworks (e.g., Vite)

> **Use this when:**
>
> - Building full-featured dApps
> - Need both good UI and safety
> - Want flexibility in development
> - Have basic to intermediate knowledge of software development

A project that was built with this approach is [Escrowly](https://escrowly.eth.limo/).


**Implementation Guide:**

1. **Initial Setup**

   # START PROMPT 1: Project Initialization

   Create a bare webapp with nothing except the word 'BLANK' on the landing page.

   # END PROMPT 1

After Lovable creates the initial project, publish it to GitHub and pull it to your local machine. This setup allows you to seamlessly switch between Lovable and Cursor, with changes syncing automatically through GitHub.

2. **Contract Integration**

   # START PROMPT 2: Contract Type Generation

   Generate typings for the @MyContract1_ABI.json ABI file using typechain

   # END PROMPT 2

After generating the types, create a documentation file for Lovable:

   # START PROMPT 3: Contract Documentation

   Create a README_Lovable.md file that:

   - Documents all contract functions and their usage
   - Includes input/output formats
   - Provides context for UI generation
   - Uses contract comments and docstrings

   # END PROMPT 3

3. **UI Generation and Polish**

   # START PROMPT 4: Full Feature Implementation

   Generate a webapp that allows users to:

   - View past NFT mint transactions from contract 0xhaE3...E24f
   - Place bids for upcoming Nouns NFT auctions
   - Follow the context in README_Lovable.md for function usage

   # END PROMPT 4

> **Note:** If the result isn't coherent, rollback and try with a more focused prompt. You can always add more features incrementally.

> **Tip:** Keep your GitHub repository in sync between Lovable and Cursor. This allows you to leverage each tool's strengths while maintaining a single source of truth.

---

Got any questions or suggestions to add to this article? Find me on [LinkedIn](https://www.linkedin.com/in/guangmian-kung/) or [Telegram](t.me/daisugist)!