Before I joined Atomic as a software designer, I spent about 10 years doing front-end development. I was usually involved in projects from kickoff to launch. I built out websites in WordPress or Craft CMS, using editors like Sublime Text or VS Code.
My typical stack also included Docker for local environments and Tower for Git, since I’ve never loved managing Git in the command line. Even though I’ve moved into design, I still enjoy coding passion projects when I have time.
It’s been a few years since I’ve written code regularly, and a lot of the setup details have faded. I still understand the high-level concepts, but things like which dependencies to install, how to structure files, or what goes where in the config aren’t second nature anymore. A coworker recently laughed when they saw me using NPM—apparently that’s “retro” now? Everyone’s using pnpm or something… I’m not even sure what the modern standard is anymore.
Inspired by an AI Hackathon
This past weekend, I went to an internal AI hackathon led by Drew Colthorp, our development practice lead in the Grand Rapids office. It focused on building apps with LLMs using tools like LangChain, LangGraph, and Streamlit. I paired with Drew, and we built a small app that helped users submit ticket information through a chat interface powered by GPT.
I focused on writing the system instructions for the LLM—defining the business rules, outlining what it should and shouldn’t do, and giving it examples to guide its responses. It was less about crafting a conversational flow and more about setting boundaries and expectations: what kinds of information to look for, how to interpret vague user input, and when to ask follow-up questions. Drew took care of the code—setting up the app, connecting the model, and making it all work in Streamlit.
By the end of the hackathon, we had built something surprisingly solid for a 1-day project. I mentioned to Drew that I didn’t feel like I’d contributed much since I hadn’t written any code.
He admitted Cursor did a lot of the heavy lifting, since he hadn’t touched much Python in a while.
That made me curious…
Trying Cursor on My Own
After the hackathon, I wanted to dig in and really understand what we’d built. My usual approach? Open the files, break everything down, comment each line, and rebuild it from scratch. I’ve always had a strong drive to make things—that’s what got me into coding in the first place—but I’m often my own worst enemy. Not out of perfectionism, but because my brain refuses to move on without a solid mental model. I’d fall down rabbit holes trying to understand everything—from project structure all the way down to how a computer chip even processes instructions—before I felt “ready” to actually build.
This time, knowing Drew hadn’t written much code manually, I decided to cut myself some slack and just try Cursor out. I downloaded it, created a new folder for my project, opened the terminal inside Cursor, and navigated to that folder. From there, I typed a prompt into the AI panel:
“I’d like to create a web app that uses ChatGPT models and Streamlit to display a chat interface.”
Cursor’s Response: Generating a Project for Me from Scratch
I fully expected to be given instructions and guidance by Cursors AI, but it just started building. It set up the folder structure, created an app.py, wrote a README with clear instructions on how to run the app, and included separate pages for editing prompts. It also handled installing the necessary packages. I didn’t need to write any code or terminal commands to get the app scaffolded.
Where It Worked (and Didn’t)
The project wasn’t perfect. Some of the styling was off, and there was a bit of unnecessary code included. But I was able to clean it up by asking the AI to remove sections or explain how things worked. When I hit errors, I copied them into the panel and got back helpful suggestions. It felt more like debugging through conversation than trial and error.
I also used Cursor’s terminal to handle Git tasks like commits and resolving merge conflicts. I usually prefer tools like Tower that show a visual diff, but for a smaller project like this, it was convenient to be able to just ask Cursor to help me fix something or remind me of a command I forgot. It saved me from having to look things up or switch tools.
Final Thoughts
For someone like me, who has some development experience but isn’t writing code every day, Cursor was a great way to jump back in. I don’t think it’s quite meant for non-developers or people with only a design background—especially if you’re trying to build something more visual. But, if you have enough context to describe what you want to build, it’s a powerful tool for getting started.
It opens up new possibilities for faster prototyping and building low-fidelity, functional proof-of-concept apps—especially when working with AI. It won’t replace collaboration between designers and developers, but it will reshape how we work together.