What changed when I started building StudyForge AI with AI in the loop

A few weeks ago, StudyForge AI didn't exist. No dashboard, no authentication, no database, no deployment. Just an empty folder and a half-formed idea that I wasn't sure would survive the weekend.

If you've built software for any length of time, you know the graveyard. Side projects don't usually die because the developer couldn't code them. They die in the gap between idea and working deployment, somewhere around configuring authentication, fixing environment variables, debugging the third weird CORS issue, and wondering why Git suddenly thinks your app is a submodule.

I've been there enough times to recognise it as the real failure mode. The hard part isn't writing the application logic; it's keeping momentum across the dozen small infrastructure decisions that sit between you and a working URL.

StudyForge was supposed to be different. Not because I was using AI, but because of how that changed what the actual work looked like.

What StudyForge is

The idea came from noticing that students don't need another chatbot. There are enough of those. What they need is structure, and most of the “AI for students” products I've seen feel less like a study tool and more like a social feed with an LLM bolted on.

I wanted to build something that felt like a workspace. The internal phrase I kept coming back to was “Academic Operating System”: a platform where a student could manage their courses, track assignments, upload study material, generate summaries, build flashcards, and have AI integrated naturally into that workflow rather than sitting above it as a chat window.

The stack

This is the most modern stack I've put together for a personal project. Frontend is Next.js App Router with TypeScript, Tailwind, and shadcn/ui for the component layer. Clerk handles authentication.

The backend is FastAPI with PostgreSQL, SQLAlchemy for the ORM, and Alembic for migrations. Postgres lives on Neon, the FastAPI service runs on Fly.io, and the Next.js frontend deploys to Vercel.

Nothing in there is exotic. The interesting part wasn't the choice of tools; it was how quickly they started fitting together once I had AI helping with the implementation layer.

What actually changed about the work

There's a lot of noise online about whether AI replaces software engineers or whether it's overhyped. My experience building StudyForge fell somewhere outside both positions.

The engineering work was still real. I still had to architect the application, structure the monorepo, decide on the routing patterns, debug a Fly.io deployment that wasn't respecting environment variables, work through CORS, make UI calls, and think about what the product was actually for. None of that disappeared.

What did change was the implementation friction. The repetitive scaffolding work, the CRUD plumbing, the boilerplate, the wiring up of familiar patterns: all of that compressed into much less time. I wasn't spending an evening setting up a SQLAlchemy session dependency injection pattern by hand; I was reviewing one, adjusting it, and moving on.

What I noticed was that the work shifted. Instead of being mostly implementation with some thinking on top, it became mostly thinking with implementation as the fast part. I spent more time on architecture and product decisions and less time typing out the obvious shape of a file I've written a dozen times before.

That's the shift I want to be honest about. It's not magic and it's not nothing.

The chaos didn't go anywhere

AI tooling doesn't remove the parts of software engineering that make you question your career choices.

At one point I had a Git repository inside a Git repository inside a monorepo. I'm still not entirely sure how I got there. Vercel got confused, my local Git got confused, and I sat staring at git status output trying to work out which level of nesting I was actually committing to.

There was a Vercel deployment that succeeded cleanly and then served a 404 because the monorepo root directory setting was wrong. There was the inevitable moment of seeing relation "courses" does not exist in the FastAPI logs and remembering I'd forgotten to run migrations against the production database. There was a Clerk webhook that worked locally and silently failed in production for reasons I had to chase through three different dashboards.

None of that is AI's problem to solve. It's just the texture of building things.

When the URL became real

The biggest psychological shift wasn't when the code compiled or when authentication started working. It was the moment I had a real, public URL pointing at the app: studyforge-ai-black.vercel.app.

Before that, StudyForge was a thing I was building. After that, it was a thing that existed. Other people could open it. That changes how I treat decisions about the project. I stopped being willing to ship half-finished states to main and started thinking about what someone would see if they followed a link there cold.

That's the moment a side project crosses from experiment to software, and it tends to happen before the product is anywhere near done.

Where the AI tooling actually fit

What I've found is that AI tools are most useful when the underlying architecture is already coherent. The better-structured the codebase, the better the prompts can be, and the better the output gets. When the architecture is muddy, you get muddy code back.

The division of labour that settled in for me looks roughly like this. The human side: deciding the architecture, designing the UX, debugging the things that span systems, making product calls, thinking about who this is actually for. The AI side: implementation of well-defined units, repetitive scaffolding, CRUD endpoints, component generation, boilerplate.

That split is doing well by both. The AI isn't making strategic calls; I'm not hand-writing a paginated table component for the hundredth time. The result is faster cycle time on the things that benefit from speed, without giving up control over the things that benefit from judgement.

A note on the UI tone

One thing I noticed while building was that the interface kept wanting to become noisier than I wanted it to be. Default component libraries have a slight tendency toward dashboard-as-spaceship aesthetics, and that's especially true of anything pitched as AI-powered.

StudyForge has settled into something calmer. Plenty of whitespace, restrained typography, a muted palette, and an emphasis on focus rather than density. It feels closer to a notebook than a control panel, and I think that matches what students actually need when they sit down to study.

Where this goes next

The version of StudyForge that's currently live has authenticated users, protected routes, PostgreSQL persistence, a working Courses CRUD, the FastAPI backend, and the deployment infrastructure end-to-end. That's the spine.

The next phase is assignments, study planning, an upload system for study material, AI-generated summaries, flashcard creation, and a revision workflow that ties them together. I'm treating the AI features as the last layer rather than the first, because the platform needs to be useful as a workspace before it's useful as an AI workspace.

What I take from this

I don't think AI tooling removes the need for software engineers. If anything, the parts of the job it doesn't do (architecture, judgement, product thinking, understanding the user) have become more important relative to the parts it does. The bottleneck has moved from “can you write the code” to “can you build a coherent system”, and those are different skills.

For me, that shift has made building feel different in a way I like. Not easier, just more focused on the parts I find genuinely interesting. Somewhere between the Git chaos, the failed deployments, the migration errors, and the small wins of seeing CRUD work end-to-end, StudyForge has become the most interesting personal project I've worked on in a long time.

The app is live at studyforge-ai-black.vercel.app if you want to have a look. The AI features aren't in yet; what you'll find is the spine I described above. I'll write more once those features start landing. That's where the real questions start.