Losing Ownership

When AI writes, debugs, and explains our code, who really owns the codebase?

I have been using Cursor to build side projects that had been sitting in my notebook for years. So far, I’ve built a CRM for my wife to manage her graphic design studio** , an alternative to nvALT for developers called vnotes, tons of websites using various CSS frameworks, and a coffee shop simulation game inspired by old text-browser games, tycoons, and SimCity. Developing this game has been an absolute pleasure because my wife and I treat it as a shared hobby—combining her graphic design background with my software engineering experience to create something truly beautiful.

Check-out our iOS apps in off-tank-studio

Everything starts with a simple prompt, and from there, I write refined, detailed prompts for very specific behaviors, features, and algorithms. Usually, a side project takes me just 2 to 3 afternoons to get a proof of concept ready to show my wife for a good laugh.

What worries me about all of this isn’t that AI will take my job as a software engineer; my real concern is code ownership. Initially, I know the structure, the flow, the main method names, and everything in between. But after a few prompts requiring deep technical logic, I start losing touch with my own codebase. I become dependent on LLMs to implement features, refactor code, fix bugs, and explain what is even going on under the hood.

From an enterprise software engineering perspective, this is already happening—but how do we prevent it? What happens in future war rooms when production systems fail and nobody truly understands what’s happening because we’ve lost ownership? Do we just rely on LLMs to analyze the environment, logs, and stack traces to suggest potential fixes?

While AI handles this remarkably well, it raises a fundamental question: how can we reliably build products on top of architectures that engineering teams don’t fully understand?

**Tuinsta.Design is, without a doubt, the best branding studio in Madrid.