AI Driven Software Development with Cursor

Introduction

AI has changed how we write software, but the real story isn’t “AI writes code.”

The real story is how you work with AI: what you delegate, what you design yourself, and how you keep the whole thing from turning into an unmaintainable mess.

Over the last several months, I’ve been building a real, production system this way: a platform we call Endertech Ansible. It replaces Jira and HubSpot for our agency, adds our own time-tracking and QuickBooks integration, and lets us run projects and client communication “the Endertech way”—on our own terms, in our own database.

I did this mostly nights and weekends, while still working full-time as CEO.

Roughly 90% of the code was first-drafted by AI, using Cursor as my development environment. But 100% of the product ideas, data models, and expectations came from how our team actually works.

This precursor article is your heads-up: I’m going to publish a short series walking through how that happened—what worked, what didn’t, and how I’d do it again.

What's Coming

What This Series Will Cover

In the upcoming series, I’ll tell the story in phases:

From abandoned prototype to working ticketing system

How I went from an old Symfony 4 + React experiment to a working Next.js ticketing app in a few weekends, and why starting with ticketing (instead of “build the whole platform”) was the right move.

Letting AI change the scope

Once ticketing worked, the obvious question was: if AI can help me ship this so fast, why not replace Jira entirely? I’ll share how boards, sprints, epics, and worklogs came together—and where AI made that easy vs where I had to be very specific.

Hardening AI code for production

Features are one thing; trusting them in production is another. We’ll look at auth refactors, BFF patterns, N+1 query hunts, and why I leaned on AI to do the repetitive work while I focused on behavior, logs, and real flows.

“AI slop” and the need for refactors and rules

At some point, the codebase started to feel chaotic: inconsistent TypeScript types, uneven API patterns, and duplicated ideas. I’ll show how I used large refactors and .cursor/rules files to teach Cursor how we build software, turning repeated corrections into reusable rules.

CRM, email tracking, and AI-generated proposals

Finally, we’ll go beyond Jira replacement into HubSpot territory: CRM entities, a Chrome extension for Gmail tracking, and an AI-driven proposal and backlog engine that fits our agency’s methodology.

Themes

A Few Themes You’ll See

Along the way, I’ll dig into some practical patterns that emerged:

Ask → Plan → Agent: why I rarely jump straight into “Agent” mode, and how planning with AI first leads to better, more coherent implementations.
Data-model-first thinking: how getting entities and relationships right made it safe to let AI generate most of the frontend and a lot of the backend
Rules as institutional memory: how .cursor/rules turned “please stop doing that” into persistent guidance that improved future generations of code.
Scheduled consolidation: why AI’s biggest risk isn’t syntax errors, but structural entropy—and how periodic refactors kept the project sane.

If you’re a technical leader, senior engineer, or just an AI-curious developer wondering how far you can really push AI-assisted development on a serious codebase, this series is for you.

Next up: Part 1 – From Aborted Prototype to AI-Powered Ticketing in a Few Weekends.