There is no best AI tool

When we talk to other property owners about the systems we’re building with AI, they often ask which tools we use. We could answer with a list, but the more we build, the less that would explain. The choice depends on the job and how far we have come with it.

Our first large system for property operations was built in Lovable, with Supabase as the database layer. We use it to track controls, rounds, deviations, components and maintenance across our buildings. It is an evidence-driven operations and compliance system, in daily use, with a core that is built, tested and locked.

We have started working in Claude Code on what surrounds that core: an action log to compare estimated costs with actual outcomes, a public channel for fault reports, and the groundwork for agents that will read and act on the system’s data. Lovable served us well, and what we built there remains in place.

Alongside the operations system, we test other systems and workflows for property operations. RENAVID’s own platform, company systems, and the workflows and agents around them started directly in code, mostly with Codex and Claude Code. We have ended up using more tools, often for different kinds of problem. We have favorites, but many of these tools are not competing for the same job.

Building version 3 in Lovable

In the first week of version 3, we locked a schema of 12 tables and 18 enums before building any interface. We put constraints directly in the database, decided how requirements would be frozen into work orders, and built logic that prevented certain mistakes from being made at all.

At times we had to steer Lovable very explicitly, telling it to run exactly the SQL we gave it and change nothing. We then verified the result ourselves, directly in Supabase. The architecture was our responsibility throughout, and as we came to depend on the system, we needed to be sure it had been thought through.

Lovable let us go from an operational idea to something running very quickly. We could test it against real data and find out what we had got right or wrong while we were still shaping the system around our operation.

Once the component library was in place, inventorying two of our properties took between 30 and 45 minutes, remotely. That inventory later surfaced the 4.2 million SEK in deferred maintenance we wrote about in our first article. Calling the Lovable phase a prototype stage would leave out the system we now use to run those properties.

Lovable worked very well for our internal operation. That experience has changed our view of what a non-developer can build and run, though it gives us no basis for recommending the same tool for every business. We chose Lovable and built. We made no systematic comparison against Bolt, Replit, v0, Base44 or the other alternatives, so we cannot rank them after the fact.

Changing a system in daily use

By the time we started version 3, the first two versions had taught us a great deal. We still had decisions to make about the model: which parts should be reusable, how controls would relate to buildings, how evidence would be stored, and how the pieces would connect over time. No-code let us build, test and adjust without every change becoming a development project of its own.

Working at that speed still required a clear data model, firm rules about what could change, and verification of what got built. We had to know which parts were critical to the operation.

Now we know much more precisely what the next functions should do. The action log has defined rules. We know what a fault report must contain and what boundaries a future agent will have to stay inside. A bad change also costs more now that the system is part of daily operations.

We want to work closer to the codebase, see how a change affects several parts at once, read the diff and run the tests before we let it through. Lovable supports GitHub, branches and pull requests, so those features alone do not explain the move. We spend less of our time discovering what an idea should look like now. Much of the work is making a defined change to a structure that already exists, with consequences we need to understand. We have chosen Claude Code for that work.

RENAVID’s platform had different requirements from the start, so we chose code without a no-code phase. The operations system gave us reasons to start in Lovable and, later, to move some work into Claude Code. Neither project gives us a universal sequence to follow. Lovable remains useful for application work, while other qualities have become more valuable for the changes we are preparing around the locked system.

The chat models we use for research, analysis and decisions serve yet another purpose. And there are systems we still want to buy. Accounting is a standardized, regulated area where established products do the job better than anything we should reasonably try to build ourselves. AI has expanded the range of things we can sensibly build. We still have to decide which problems are worth owning.

Fault reports and work across systems

In our work, Lovable handles the application: screens, the database behind them, and server-side functions that connect to outside services. It does that well and keeps extending what it supports. Its documentation now covers connectors to outside tools and services, and publishing an app as an MCP server so other agents can call it. For a new screen over an existing table, or a form that writes to the database and triggers an email, Lovable is still faster for us. We still use it for that work.

The public fault-reporting channel needs a form, which Lovable could readily build. We also plan to add triage after a report arrives. The intended flow is for an agent to read the report, check it against the component register and the unit’s history, then draft a triage for a person to decide on. That requires a program outside the app that can read and write the system’s data under strict rules. We need to define exactly what it will be allowed to do.

Claude Code’s documentation describes connecting agents to databases and APIs through MCP, hooks that intercept an agent at fixed points to enforce rules, and an Agent SDK for building an agent with the same loop and permissions that govern which tools it may call without asking.

We plan to use those controls to require explicit approval before any migration can touch the core tables. The intended triage agent will be allowed to read fault reports and component history, but not close a work order. We want those permissions enforced in code. The rules behind our evidence gate will apply to agents as well as people.

There is also work between our own systems. Connecting the operations system, the planned source-monitoring agent for our newsletter, and the company’s knowledge repository means working across separate builds. We need to read code on both sides, change several files, run the tests and check the diff before anything merges. Claude Code runs in the terminal, in the editor and in GitHub Actions, so a review can also run on a pull request without someone sitting at the keyboard.

Before we let it change the operations system, we gave Claude Code one job: read the whole repository and return an architecture overview and a list of proposals, without touching a file. Its plan mode supports that. We wanted to see how it understood a system it had not built.

For an agent, an integration or a change across a system we depend on, we prefer working directly with the repository, diffs, tests and explicit permissions. For a new part of the application, Lovable still gets us there faster. Our choice rests on how the work fits the tool, without requiring us to establish a hard limit on what either can do.

What the studies say about coding agents

We also expect to keep these systems in service through several changes of tools.

JetBrains’ latest Developer Ecosystem Survey covered just over 15,000 professional developers. Ninety percent now use coding agents at work at least weekly, and 68 percent daily. Claude Code use rose from 18 percent in January 2026 to 39 percent between May and July. Codex went from 3 to 16 percent over the same period. Professional practice has changed quickly, though adoption figures tell us little about what to choose for our next project.

Figure 01 · Coding-agent use among professional developers, 2026

Claude Code — January 18%

Claude Code — May to July 39%

Codex — January 3%

Codex — May to July 16%

OpenAI released GPT-6 Astra on September 3, 2026. It is designed for coding, research, computer use and longer jobs involving several tools and many steps. In OpenAI’s own tests, it sets a new high on Terminal-Bench 4.0, a test of advanced terminal tasks, at 57.9 percent, with Claude Fable 5.1 at 55.8.

Two days earlier, Every had tested Fable 5.1 on an application of its own, built with AI, that had kept crashing in production. The task in its Senior Engineer Benchmark is to rewrite the real-time core without breaking the rest. That resembles the work we care about once a system is in use. Fable 5 had scored 91 out of 100. Fable 5.1 scored 41 and 49 in two runs. Astra scored 71 when it was added on September 3.

Every makes clear that these runs had different conditions. After its first plan, Fable 5 received an extra instruction to carry on, implement the solution and run verification. The later models got a single attempt from the original prompt, so the scores cannot be read as a ranking. For us, the comparison raises questions about the whole setup: the task, the context supplied, the tools available, how long the model can work, and how the result is verified.

Astra’s behavior over long jobs is relevant to our codebase for a different reason. In Codex, it can now retain and retrieve information from earlier context windows. Previously, a long session had to be compressed into a summary, risking the loss of details about earlier attempts or requirements. An agent working over an established system needs to remember why a fix failed or which requirement drove a decision. We have not seen a leaderboard measure that.

Productivity is harder to judge than a benchmark score, too. In METR’s 2025 study, experienced open-source developers using that year’s AI tools on familiar codebases were 19 percent slower on average, even though they believed AI had made them faster. In its February 2026 update, METR said current tools most likely do make developers faster, but measuring the effect had become harder. Developers were declining to participate because they might be assigned work without AI. Between 30 and 50 percent said they were withholding certain tasks for the same reason. As the tools became embedded in their work, recruiting participants and getting a representative set of tasks became more difficult. METR still declines to put a firm number on the gain.

DORA’s research found higher delivery throughput in organizations with heavy AI use, alongside higher instability. Some of the time saved producing code moves further down the process, into review and verification. DORA describes AI as an amplifier of the development system already in place. For our operations system, faster changes only help if we can check that they are the changes we intended and that the system still works.

Choosing tools for our own operation

Our decisions usually come back to three questions.

Where is the uncertainty? When we need to see a working system before we can make the next decision, a short path from idea to product is worth paying for. No-code has been extremely useful to us at that stage.

What does a bad change cost? Once the structure is known and we depend on it, we want to work closer to the codebase and tests, with a clear view of each change. Claude Code is our current choice for some of that work. The requirement is to be able to inspect and verify what happens.

Should this system be ours at all? Our operation, processes or knowledge sometimes make a system of our own worth having. For standard problems with good established products, we would still rather buy.

We would have made some of these choices differently six months ago. As the tools change, we will have to reconsider them while continuing to run the systems we have already built.

Why our teaching starts in Lovable

We considered starting what we teach with Claude Code, since much of our own work now happens there. We decided to keep Lovable as the starting point for the first systems in RENAVID. For someone who knows property operations but is not a developer, describing a process, seeing it work and improving it with real data remains the strongest starting point we know. Our own systems have taken that path into daily use.

What we teach today takes the reader through the locked version 3 system and ends there. Later RENAVID work will include code-based workflows where the job calls for them, including agents and integrations. How that work becomes future material is still open. Our experience gives us no fixed feature count or number of tables at which a reader should move from one tool to another.

We do not want to teach a “RENAVID stack” that readers are expected to keep using. Some of our tools may have changed by the time someone follows the same work.

The first thing we did in Claude Code was ask it to change nothing. The action log we are preparing already has defined tables and rules, and we know what getting them wrong would cost. We will decide what to use for the build after it when we get there.