You ask for a feature. The AI writes the code and it works.
You ask for a second feature, and the AI quietly breaks the first one.
You try to get it fixed, the AI starts guessing instead of checking, and within a couple of hours you’re staring at a 2,000-line file of spaghetti code that you don’t have the skills to untangle. The context window is full, the AI is confused, and you have no clean way to backtrack.

As a non-developer, I had to accept that my job isn’t to write code. My job is to be the tech lead, the product manager, and the QA tester, all at once.

It’s basically the job I did leading teams at Capgemini Engineering, minus the technical expertise I used to lean on to sanity-check my own team.

To do that without losing control of the project, I built a fairly rigid tool stack and a management method to go with it.

Here’s what that looks like, and here’s where it’s already bitten me.

The stack : building a real developer environment

If you treat an LLM like a chat window, you get chat-window results: fine for a one-off script, unusable for a real product. To get something reliable, you need to give the AI a structured local environment. Here’s the setup I run before any coding starts:

• Claude Code (the engine): Anthropic’s command-line tool, running directly in my terminal. It reads files, runs the test suite, and executes commands on its own, instead of me copy-pasting code back and forth from a chat window.

• A dedicated developer account: I don’t run Claude Code on my personal account. It runs on a separate account with its own integrations, its own skills, and its own SMTP so it can send email under its own identity, not mine.

• OpenProject (the brain): This is where the project structure actually lives: epics, task groups, individual tasks, subtasks, bugs. Claude has direct API access, so it pulls its own task list, updates its own progress, and logs bugs as it finds them. It can (and must by defined requirements) also assign tasks to the humans on the project (UX validation, legal sign-off, PR merging) instead of pretending it can do those itself.

• GitHub (the vault): Every clean step gets committed and pushed. If something breaks, we roll back to the last known-good commit immediately rather than trying to patch our way out.

• Obsidian (the viewer): Claude Code works natively with Markdown, so I keep Obsidian open on a second screen to read, link, and skim the documentation the AI generates as it works. I also have a small end-of-session skill that checks every project document has a symlink into my Obsidian vault, so nothing important is ever just sitting orphaned in a repo I’ll forget to open.

The methodology: Waterfall not Agile

Here’s my genuinely held opinion after a year of doing this : you cannot run a pure “agile” process with an AI. Agile works because humans have judgment and can pivot mid-sprint on gut feel. An AI doesn’t have that. It needs strict, sequential guardrails, or it will confidently wander off in a direction nobody asked for. So I use a hybrid: upfront design, then disciplined execution. Nothing gets coded until we’ve walked the full path below.

1. Functional specifications

We write down exactly what the software needs to do: every user flow, every edge case. I lean hard on examples from other websites or apps to anchor the request in something concrete, because “make it intuitive” means nothing to an LLM. We also set the “boring-but-critical” requirements up front: accessibility, interoperability, target devices, target users, OWASP rules, GDPR Compliances....

2. Constraints and compliance

We set the technical fences. My hard rule: open-source only, and only if the license is genuinely compatible with commercial use (permissive licenses like MIT or Apache, never restrictive copyleft like GPL). We also check the library is actually maintained. A stale, half-abandoned open-source package is a liability whether or not the license checks out.

3. Architecture and design

The functional spec (around 60 pages, in its final form) gets broken down into a technical architecture document (roughly 20 pages). From there, a design pass carves the work into discrete, coherent technical blocks, sequenced in OpenProject.
Early on, I had a rule that every single block, no matter how small, got a full review pass from a specialized Architect agent plus either a UX/UI or Legal agent. It felt rigorous. It also turned out to be a mistake I had to walk back (more on that below).

4. Test-driven development (TDD)

We don’t write application code first. We write the tests. Claude generates the test suite for a task, runs it to confirm it fails, and only then writes the minimal code to make it pass. That way, a change made three weeks from now can’t silently break something built on day one, the test suite catches it immediately.
You don’t need to understand exactly what TDD is (I barely did when I started). You just need to require it of your agent, every time, no exceptions.

The source of truth and the decision log

When you start a new session, the AI remembers nothing from yesterday. Left to guess, it will happily start rebuilding systems that already exist. To stop that, we keep a strict source of truth:

1. The active task list in OpenProject. Tasks currently underway are detailed and annotated. Everything further out stays high-level until it’s been through Architecture, UX/UI, and legal review.

2. Two core documents, in Markdown for efficiency: the functional spec, and the architecture doc.

At the start of every session, Claude’s first job is to read these. They’re the absolute boundary of the workspace, nothing gets built outside them.

We deliberately don’t rely on hidden memory files like .claude, .memory, or one giant journal.md. Those get cluttered, get overwritten, or just get ignored by the model once the file is long enough.

Instead, every real decision gets its own small, numbered Markdown file in a /decisions folder the moment it’s made. Pick a database structure, choose a library, change a flow: it gets a short file, something like:

• Context: Why we needed to change the login flow.

• Options considered: Pros and cons of each approach.

• Decision: What we chose, and why.

• Consequences: What this affects downstream.

That builds a clean, unchangeable history of the project. If the AI ever loops, or if a human developer eventually joins the project, this trail is the map of why the software looks the way it does, not just what it does.

Where this actually broke (the part I’d leave out if I were trying to look good)

A few things went wrong, and we adapt the guardrail because of that :

The review process got heavier than the thing it was reviewing.

For a while, every task, regardless of how small or how risky, triggered a full pre-dev architecture review, a legal and security pass, TDD, a second legal and security pass, and its own decision file. It felt thorough right up until I did the math: at that rate, the full project was on pace for somewhere around 900 decision files. Worse, that whole heavyweight process still missed the worst bug of one particular sprint, a real case where a live user session was never actually wired into an endpoint, so it would have silently failed for every real user while looking completely fine in review. Both review passes rated it a minor issue. It was a human reading the code line by line, not the process, that caught it.

So we rebuilt the trigger: instead of “big block gets full review,” it’s now a quick three-question score before any work starts.

• Does this introduce something architecturally new?

• Does it touch sensitive data?

• Is it hard to undo if wrong?

Only if one of those is a real yes does the heavy process kick in.
Boring, low-risk changes get a lightweight checklist instead.

We also added two blunt rules directly because of that missed bug: never mock the exact function your test is supposed to be exercising, and any new endpoint needs one smoke test run against the real, fully running stack before it’s called done. Neither rule would have existed without that specific failure.
And don’t ask me to explain those exact rules, because and can’t clearly understand them. They come from “end of session” email reporting (another specific skill I create) where I ask for a Resume of the session, lesson learned, and Token usage

Agents get stuck in loops, and it looks exactly like the agent thinking. Agents get stuck, and “working hard” looks exactly like “stuck forever.” An agent might fall silent, appearing to think deeply, when it’s actually trapped by a blocked lock file.
To prevent this silent drift, we set a strict limit: if a 5-minute task isn’t done after 3 times its expected duration (15 minutes), Claude intervene. The fix isn’t clever, we just check the lock, Principal agent look at what’s actually happening, and recover it. It always does.

Never type a real secret into a command, even to your own AI. Early on I’d paste an API key or a token straight into a terminal command for Claude to use. That’s a bad habit independent of AI: it can end up in shell history, in logs, in a pasted screenshot. The fix is boring: secrets live in a permission-locked file the agent is allowed to read, never typed inline. Once I made that a hard rule, I stopped having to think about it at all, which is really the point of a rule like this.
f you ask Claude how to securely store API keys and passwords, it will happily lecture you on textbook security protocols.
Instead of overcomplicating it, the practical move is simple. We set up a dedicated Vaultwarden account specifically for the AI. This gives the agent secure, isolated access to the exact credentials it needs, while keeping your master vault completely safe and out of reach.

The specialist agents aren’t always right, and that’s fine. The legal agent occasionally flags something completely irrelevant to the actual regulation at hand. The point isn’t that these agents are infallible reviewers, it’s that they catch real things often enough to be worth the noise, and I’m still the one who reads their output and decides what matters.

By wrapping the AI in real project management, a disciplined design process, and a history a human can actually read, you move from prompting a chatbot to genuinely engineering software, badly at first, then less badly.

The more projects I run this way, from the DogSphere app I’m building with my daughter, to my own site at kairostech.fr, to the F3I European grants monitoring tool, the more I notice I’m using the exact same instincts I used managing teams at Capgemini. Except now I’ve also become the QA department.
There’s still plenty to sharpen, test agents that wander off, review agents that miss the point, process that gets too heavy before you notice.

But it’s a genuinely fun way to build things, and every mistake above taught me something the tidy version of this post wouldn’t have.

Every major provider now says in his Terms & Conditions “you own the output” … if copyright can be claimed

Anthropic, OpenAI, Google, Mistral, DeepSeek, all near-identical wording. But if you’re integrating generated content into a real product, the risk rest in what surrounds it.

What are the difference between AI Providers ?

→ Indemnification if output infringes someone’s IP : Anthropic, OpenAI, Mistral and Google offer it on enterprise/API tiers. DeepSeek offers none, you carry 100% of the infringement risk.

→ Training on your data : Gemini and Claude free tiers train by default and paid/API/Workspace tiers don’t. DeepSeek reserves broad rights to reuse inputs/outputs to “improve services” … understand this as = your prompts may not stay yours.

→ Data residency : Mistral (EU) and Anthropic/OpenAI/Google (US, with EU data options) are worlds apart from DeepSeek, which stores data in China (cloud version obviously), a real problem if you handle client or personal data under GDPR.

But a contract (Terms) can’t hand you a right that doesn’t legally exist. And that’s where it gets interesting when we look at the different laws.

What the Laws says

In the US, the Copyright Office and courts (2025-Thaler v. Perlmutter) require human authorship. Works with "sufficient human authorship" (substantial edits, creative arrangement, etc.) can be copyrighted but the bar is fairly high (documented iterative human edits, not just a prompt)

In France we have droit d'auteur built around the author's "personality" (empreinte de la personnalité) that confirm a purely machine-generated work has no personne behind it, so no copyright attaches.

EU-wide, the Court of Justice (Infopaq, Painer) has held that copyright protection requires the "author's own intellectual creation" which is interpreted as requiring human creative choices.

Neither French or EU law currently recognizes AI as an author. If a human meaningfully selects, arranges, or edits the output, that human contribution can be protected, but the AI-generated "core" itself generally can't.

The lesson : AI vendor’s terms are the easy part, and not the legal vacuum reported by certain media outlets.

If there is a copyright to transfer, it’s yours.

The real constraints are the many (with difference to come internationally ?) copyright law . Pure AI output sits in a legal gray zone with weak or no protection almost everywhere, while human-edited/curated output appear capable of being protected and patented under standard conditions.

Looks clear and easy for you ? It’s not…

I'm definitely not a lawyer, but even after doing my homework, reading all those text and articles I still can't answer this simple question : Do I truly own my company's logo (kairostech.fr) if it was generated through a series of 4 AI prompts ?

And who owns this image, generated by OpenAI with a single super creative expert prompt ?

The Plant Garden Bridge, Grenoble

First point of interest, located in the Parc du Jardin des Plantes in downtown Grenoble, is a concrete bridge built by Louis VICAT and his son Joseph.
This achievement marks the first demonstration of the innovative technology developed by the young family-owned company VICAT, which has since grown into one of the world leaders, now producing over 20 million tonnes of cement annually.
A significant detail: this discovery of industrial cement was never patented to allow for broader development of their invention. As Louis VICAT explained, ‘The glory of being useful outweighs that of being wealthy.

The Solar Clock into the Lycée Stendhal

A few steps further, you’ll come across a college founded by the Jesuits in 1651, which still serves students up to high school level today. On Saturdays, visitors can admire an extraordinary interior sundial, constructed in 1673 by Father Bonfa.
This unique timepiece, the only one of its kind in the world, is a remarkable reflecting sundial that uses two small fixed mirrors to channel sunlight inside. The walls of a staircase are decorated with several astronomical tables, displaying solar time, sunrise and sunset hours, moon phases, and the zodiac signs.

The helical garage, Grenoble

On the way to the next site on our list, we pass through a small street called Rue Bressieux. Tucked away at number 6 is a hidden gem: an Art Deco helical garage, constructed in 1932 using reinforced concrete (from VICAT). Spanning nearly 1,400m², this architectural marvel was designed to accommodate over 250 cars and is still used today.

Quai des Arts, Grenoble

Long before the Street Art Festival emerged in Grenoble, there was a place where street artists could freely express themselves. Along river Isère, nestled beneath the freeway, a cycling path runs beside a nearly 1 km-long wall, completely covered with graffiti, stencils, stickers, posters, and other artistic creations. This scenic ride starts near the Parc des Dauphins and is best enjoyed during the day to avoid the less welcoming crowd that gathers in the evenings and at night.

The Burning Fountain

We now head toward the village of Saint-Barthélemy-du-Gua to explore a curiosity long regarded as the work of the devil and feared by the locals. The Fontaine Ardente is, in fact, a gas blaze that originates from an underground pocket of methane, emerging along the banks of a stream. The walk to the creek takes only a few minutes, but this geological phenomenon is certainly worth a visit Remember to bring a lighter and paper to restart the flame if it rained the day before).

Facteur Cheval’s Palais, Hauterives

The Palais Idéal du Facteur Cheval is a monument classified as Naïve Art, built in Hauterives by postman Ferdinand Cheval from 1879 to 1912. Standing at 12 meters high, this palace is constructed entirely from stones collected by the postman during his mail delivery rounds, assembled by hand with lime.
This structure is incredible and impressive, yet at times unsettling due to the visible madness of its creator. He took advantage of the end of his career as a postman to continue collecting stones and build his tomb using the same technique.

Ice diving, Chamrousse

To end on a refreshing note, we head to Chamrousse, the legendary site of the 1968 Winter Olympics. Beneath the summit, at an altitude of 1,998 meters, you’ll find a series of three lakes, the Lacs Robert, where, in winter, it is possible to dive beneath the ice and observe the fish sleeping on the sandy bottom. This dive does not require prior diving knowledge, but it does require a certain amount of courage to descend through the small hole in the ice.

Grenoble is an amazing city, and the diversity of these unusual activities shows this well, I think…

“Dad, why isn’t there an app where dog owners can just see who’s out walking right now?” she asked.

In the past, a fun idea like that would have just stayed a dinnertime conversation. Turning a kid’s concept into actual software used to require months of coding expertise, a lot of money, or a brutal learning curve. But it’s 2026, and the tools have changed. Armed with her idea and a terminal with Claude Code, we decided to see if we could actually build it.

What followed was a great father-daughter project that showed us exactly what modern AI can do, and more importantly, what it still can’t do.

Step 1: Talking it out with a digital expert

We didn’t start by writing code. We started by interviewing with an AI assistant.

My daughter explained her vision, and we had Claude ask us questions to challenge the idea. It didn’t just nod and agree. It started asking the kind of practical questions a human expert would ask: how do you protect user privacy while sharing live locations on a map? How do you handle the “not friendly dog” indicator without causing neighborhood drama? What happens when two dogs cross paths and one of them has a track record of snapping at people?

That last question is what got interesting. Claude’s first instinct was blunt: a public flag on a dog’s profile, visible to everyone, something like “reported aggressive.” My daughter hated it immediately. “That’s going to start a war between neighbors,” she said. We ended up redesigning it as something much quieter: a private, personal blacklist , you can mute a specific dog or owner for yourself, and if you cross paths again the app just nudges you, nobody else ever sees it. No public shaming, no drama, just a personal filter. That single conversation became one of the more elaborate parts of the app.

Within about an hour, this back-and-forth conversation was automatically put together into what developers call a functional specification document. It was incredible for my daughter to see her random thoughts organized into a real, professional roadmap.

Step 2: Building the prototype in a few sessions

With the plan locked in, we moved on to the actual development. Using Claude Code directly in our computer terminal, we went from an empty folder to a working prototype in a handful of focused sessions spread over a few weeks.

Instead of trying spending hours hunting down typos in code or setting up complicated databases, we acted like directors. We gave the AI our plan, watched it write the code, and tested the features as they came out, directly on our smartphones. A live map with markers for parks and dog-friendly spots, a “who’s walking right now” layer that lights up amber dots when a neighbor starts a walk nearby, a chat for direct messages and for group conversations, and a little matchmaking screen that suggests compatible dogs to walk with based on temperament (nine personality traits, from “calm” to “rebellious,” with a simple compatibility matrix behind it).

One detail my daughter insisted on: if the same two dogs keep crossing paths at the same spot say, the app quietly creates a little group for them automatically. We ended up calling it “La Meute” (”The Pack”). It turned out to be everyone’s favorite feature during testing, and it’s the kind of thing that only exists because a 12-year-old understood how neighborhood friendships actually form: not through a search bar, but through bumping into the same people over and over.

Not everything the AI produced was right on the first try. During one of our testing passes, every single dog’s stats page showed zero kilometers walked, no matter how many walks we’d logged. It took us a while to track down: the demo data generator had created all the sample walks without actually linking them to the dogs that took them. The code that calculated the statistics was correct, it was being fed empty data. It was a good reminder that “the AI wrote it and it compiles” is not the same as “it works,” and that you still need real testing, on a real phone, with real data, to catch what a code review alone won’t.

We also hit a very real production bug once we moved off our laptops and onto an actual server: the map tiles simply refused to load. Everything worked perfectly on localhost and then broke the moment we deployed. It turned out our security headers (added by the AI, correctly, to harden the app) were stripping the referrer information that the map provider requires to serve tiles at all. Two lines of configuration, and it took us a full evening to find them, because the symptom (a blank grey map) gave no clue about the cause (a security header three layers away). That’s the kind of debugging where having an actual engineer’s instinct mattered more than any AI suggestion. And I’ll admit my daughter and myself are missing this skill so we loose a lot of time...

Before letting anyone outside the family touch it, we ran a full battery of automated tests (143 precisely), covering the backend, the frontend, and full user flows end to end, and didn’t move forward until every single one was green.
Today, that app is called Dogsphere. It’s currently in beta, running on a small rented server, installable straight to an Android home screen like a native app, and a handful of our actual neighbors are using it right now. Users can see when friends go on a walk, chat with each other, and coordinate their routes.

Seeing a 12-year-old’s idea become a solid reality in her neighbors’ pockets is a pretty amazing feeling as a dad.

The real lesson: AI B’s & C’s

Beyond the fun of a shared family project, this was the perfect way to show my daughter how AI actually works in the real world. There is a lot of hype out there, but building something yourself shows you the truth.

• First, AI is a co-pilot, not the creator. Claude Code didn’t know what our neighborhood dog owners needed, my daughter and I did. When we later imported real hiking trail data for our region so people could plan proper walks, the AI could fetch and process thousands of raw map fragments in seconds but it had no idea which ones were actually useful. We had to make the call ourselves to throw out over 4,000 unnamed, low-quality trail fragments and keep only the roughly 200 real, named trails worth showing. The AI completely depended on her empathy and local insight, and on our judgment about what data was actually worth trusting.

• Second, AI doesn’t have common sense. When we were designing the feature to avoid grumpy dogs, the AI initially suggested a blunt, harsh public flag. We had to step in and refine it into a private, softer mechanism to keep things polite. Humans have to provide the ethics and the social understanding and often, it’s the smallest details, like which words appear on a button, that make the difference between a helpful app and a divisive one.

• Finally, it means ideas matter more than ever. Now that the technical barrier to coding has reduce (collapsed ?), almost anyone can build an app. That means the real value isn’t the code itself anymore. The value is the quality of the idea, how well you understand the problem you’re trying to solve, and, as we learned the hard way, the discipline to actually test what gets built instead of trusting it on faith.

Dogsphere might just stay a small, friendly app for our local neighborhood, and that is completely fine.
The real win wasn’t the software.
It was watching my daughter realize that she has the power to take a thought from her head and turn it into something real.