Running Cornell Generative AI like a startup

Cornell Generative AI is a student club that builds AI software for real users. I joined in spring 2025, served as lead engineer and New Member Education chair, and I'm now president. The club has 40+ members across engineering, research and business.

Student clubs tend to drift into discussion groups, and they lose what they know every time a class graduates. We avoid that by giving the club the jobs a small company has: hiring, onboarding, sales, delivery and an engineering direction someone has to own. Our fall info session put it this way:

We run the club like the companies we want to build. A low stakes AI-native startup.

Hiring

Candidates come to an info session or a coffee chat with someone on the e-board, then go through two rounds.

Round 1 for developers is a take-home. A team of one to three builds any AI app they want and submits the code with a video demo. That tells us more than a résumé does: whether someone finishes things, what they choose to build, and how they explain it.

Round 2 is an interview with a project deep dive and a system design discussion. This fall I rebuilt the technical half around agent design, replacing a more general client-scenario discussion. Candidates design a small agent system out loud: which tools it needs, what each tool returns to the model, and where a subagent fits. They get a prep packet ahead of time that covers the core ideas, and the interview checks whether they can apply those ideas, not whether they can recite definitions.

We rank candidates on dedication first, then initiative, then technical skill, then creativity. Our info session deck says it directly: "We'll take a strong learner over a long résumé." The fall 2026 cycle brought in 13 new engineers.

Onboarding

Before I was president, I designed the club's New Member Education program. It runs for four to five weeks before a new member joins a project team. It covers APIs, HTTP and databases; embeddings, vector databases and retrieval-augmented generation; context management; model basics and agent harnesses; and tool calling, MCP and agent skills, so project teams don't have to teach the basics.

Sales and delivery

Through spring 2026, the club's main product was client work. Our partner-facing Partnership Overview offers companies three ways to work with us: as a client, as a campus ambassador partner, or as a sponsor. It lays out a four-step path from intro call to kickoff. Its guiding rule is to start small and prove reliability: "A focused, low-risk first step is easy to say yes to."

Two of the projects we delivered show what that looked like.

QuickFi (Spring 2025 to Spring 2026, 13 contributors). QuickFi runs a lending platform for business equipment finance. We built two agents for its operations team. One validates borrowers' insurance certificates. The other runs due diligence on vendors and rolls independent checks into a risk report that a person reviews. On the vendor agent I built the Dun & Bradstreet integration, the conflict-of-interest detection (for example, a borrower who owns the vendor), and the risk scoring. QuickFi asked the club back in 2026 to extend the vendor pipeline.

Investcorp (Spring 2026, 12 contributors in two teams). We picked two self-contained pilots that could be built without weeks of security reviews. Both ran on Investcorp's own Azure infrastructure from day one, so portfolio data never left their cloud and there was no migration at the end. One pilot was an ESG materiality classifier that sorts news about portfolio companies by credit impact and produces a weekly report. It runs weekly instead of in real time because credit events build over days and weeks. That pilot grew into an analyst workspace the credit team uses. I worked on its news ingestion and first-layer classification, and built a chat interface on top of it.

This year I also opened sponsorship conversations with Databricks and Moonshot AI for compute and API credits. Neither has closed yet.

The pivot to our own products

By summer 2026 the e-board saw a problem with client work. It brought a lot of structural friction: corporate onboarding, tool restrictions and approval cycles. The clients owned the deliverables, so members finished a semester with little public proof of their work. During our outreach at the start of the summer we also found that large companies already have strong internal technical teams, plus security concerns about working with students.

In our mid-summer e-board check-in I argued that we should lead our own building instead of waiting on client timelines. For fall 2026 we reorganized around self-led work in three tracks: open-source contributions, production software for students, and applied research. Another e-board member and I lead the student-products track. We gave up the clean "we build for finance firms" story and the client relationships that came with it. In exchange, members now own what they build and can show it publicly, and a team's pace depends on its own commitment instead of how fast a client replies.

My reasoning for the student-products track, from the announcement to members: "the modern software engineering skill gap is no longer simply about whether someone can build a personally useful project. It is increasingly about whether they can deliver that product to real users, operate it reliably at scale, and develop it with a coherent product vision." The first product in that track is Outreach CRM, which I built alone under Stuart Labs and pitched to the club in August 2026. The club is its first organization, and it is in a private pilot.

What I built for the club

A 40+ person club creates a lot of admin work, and I treated it as a build target. I wrote the specs for the club's internal operations platform and built it with coding agents, over 56 commits between June and October 2026. It sits behind Google sign-in limited to Cornell accounts and includes:

• attendance tracking, a club calendar synced from Google Calendar, and a member roster
• project hubs with per-team files from Google Drive
• notifications delivered as Slack DMs and an in-app inbox, with recipients fixed at send time
• weekly SMART-goal standups, where an admin reviews each cycle before it reaches members
• a remote MCP server, so members can ask their own AI agents about the club, their team and its projects
• a shared library of agent skills that members and their agents can read and edit

The architecture is deliberately plain: a Node http server with no framework, a React front end loaded from a CDN with no build step, and Postgres on Railway. One person can run it. The cost is that front-end errors only show up when a page loads, so I moved the logic worth testing into plain modules with their own unit tests.

The MCP server took the most care. It runs its own OAuth 2.1 flow with PKCE and dynamic client registration, and it hands human sign-in to the platform's existing Cornell login. It checks identity and team membership again on every tool call, so a role change takes effect immediately, and members only see the teams they belong to. The skills library stores each skill in a GitHub repo, where every edit is a commit authored by the member who made it. That gives us history, diffs and attribution without building any of it.

I also refreshed the club's new public website and wrote its Outreach CRM post. Other members built most of that site.

What's next

This is my final year. I built the roster, calendar, standups and skills library so they can outlast my time here. Next I want new student-products teams to start from the platform's MCP server and skills library instead of a blank repo.