I made a small side project (blog post, Github) to analyze international index funds, timeboxed to 4 hours. It makes a good spike since it has reasonable coverage of fullstack work: light but reasonable React frontend, NextJS backend routes, several different API integrations (yahoo finance, federal reserve economic data), and some basic caching.

I’m pretty impressed. It’s at least a 5x time savings, probably more since it’s been a while since I did frontend dev. Most of my time went into finding and fixing bugs, and secondarily to finding the right APIs and data sources to use. I quickly stopped reviewing code closely since it’s so fast to “accept all” and then test it out; if it doesn’t work, restore a checkpoint and give it more deliberate instructions. It largely works well even with colloquial prompting such as “Let’s add api data fetching using the yahoo finance api”. When I follow up with “I get CORS errors fetching from yahoo finance”, Cursor figures out that it needs to generate a next js api route.

Development Methodology

  1. Initialize react app with npx create-next-app@latest
  2. Write a small requirements file
  3. Leverage Cursor’s compose mode with the prompt Help me build the Index Fund app based on the 'requirements.md' file. The UI should be similar to the attached UI, attaching the files in compose/ as well as a screenshot of the Yahoo Finance UI for S&P 500.
  4. Iterate to add each feature at a time
    • Starting with fetching live data from Yahoo Finance: provide the sample json response to reduce hallucination, and the prompt: Let's add api data fetching using the yahoo finance api
    • Fix CORS issues: I get CORS errors fetching from yahoo finance
    • Iterate: keep fixing bugs & incrementally adding new features, for example
      • We don't need realtime data, just data up to 5y and of course for "all"
      • Let's add code to properly calculate the 52 week range
      • Use this example yahoo finance response and ensure all fields examined by data-fetcher.ts are correct (and attach the example json response)
      • I want to allow users to select as many index funds for comparison in the graph as they'd like, beyond the S&P 500. What should that visually look like?
  5. Intermediate commands not recorded, but can see feature development in the commit history (Github)

Opportunities for Improvement

The productivity boost was great, but after the first couple hours I felt development velocity slowing down & bugs increasing as I asked it to extend functionality instead of writing mostly new code.

  1. Gradually reducing dev velocity: primarily caused by bugs as it enhances existing code or integrates into existing code. Adding all-new code (e.g. new nextjs route, or react service, or new component) stays fast
  2. Inconsistent project structure & organization: sometimes creates arbitrary folders for new util files, puts methods in incorrect files, tends to overall prefer creating new files with new code instead of parsimonious new code + refactor existing code
  3. Code style: spaghetti code & (small, harmless) hallucination
    • Spaghetti: Cursor kludged a lot of code into the IndexChart component. I didn’t stress about it for this project since I planned for it to be a one-time proof of concept, but for a longer-term side project I would want to refactor more. This code unifying data fetching from services, derived data computation, and data visualization was the main cause of nontrivial bugs (nontrivial = copy-pasting the error message into the Compose window can’t fix it).
    • Refactoring: Telling it to refactor out logical components has limited efficacy. o1 appears to do better than the default Claude (while being much slower), but still not great. Most effective is tactically e.g. “move these lines to a new method” or “refactor these params into a class”, or frankly just do it directly.
    • Code Cleanup: It doesn’t notice when vars are unused, or become superfluous after some new feature is added. I think this is aligned with “hallucination” – it produces structs that are “typically right” for the problem domain, but if I’m focusing on a subset of e.g. financial analysis then I have to tell it to remove particular vars, or normalize specific fields, etc

Potential Solutions

Based on this small spike and what I’ve since read, here is what I would try in the future.

  1. Project Organization
  2. Dev Velocity: primarily caused by insufficient context or difficulty tracking context across multiple files
    • Consider a Cursor memory file (reddit thread)
    • Break down work more using md files (reddit thread, blog + HN discussion, another blog, yet another blog)
      • Author a simpler requirements.md that has e.g. core visualization, and author small mds for each additional feature slice
        • Consider using o1 or o3 mini to break down larger features into smaller slices
      • Alternatively, have cursor record the incremental work itself – goal is that the mds should provide token-efficient context for the whole project without requiring it to load every line of code
  3. Dev velocity & code style:
    • Break down work more using md files (see above)
    • More example files (e.g. API response json files)
    • Review diffs more closely: will be easier & less code to review with smaller units of work
    • Spend more time on refactors & code cleanups: provide tactical instructions for refactoring out small methods, remove particular variables, and/or refactor “by hand” directly

Request For Comment

What have your experiences been? I’m especially curious about continued / longer-term dev process, and about pure backend dev. Can compare & contrast with Github Copilot in VSCode, or other alternatives.