More and more AI announcements carry a line like this one: our newest model was built by AI, or at least by the previous generation of it. The phrase conjures a vivid picture of machines making better machines in a loop that quickens until humans are left watching. The reality of a model built by AI is more modest and, honestly, more interesting. Knowing what a claim of this kind usually means helps cut through both the hype and the fear.
What built by AI can actually mean
The phrase covers a range of activities, and the differences matter a great deal.
Writing code is the most common. AI coding assistants now produce a large share of the code in many projects. Engineers describe what they want, review the output, fix errors and merge it. A lab that says most of its code was built by AI may simply mean its engineers use these tools heavily.
Generating training data is another. Models can produce examples, explanations or practice problems that help train other models. Filtering and checking that material is crucial, since errors can compound from one generation to the next.
Testing and evaluation come next. AI can write tests, run experiments and summarise results, which speeds up routine tasks. Beyond that, models can suggest ideas such as architectures, settings or research directions, which humans then judge.
The most ambitious sense is autonomous research, where a system designs, runs and analyses experiments with little human input. That remains limited today and usually involves close supervision.
Why built by AI is not the same as self-improvement
Recursive self-improvement, in the dramatic sense, would mean a system that rewrites its own core intelligence, becomes better, then does it again, faster each time. Current practice looks quite different.
Human researchers still set goals, choose data, design experiments, judge results and decide what to release. The computing power, data and infrastructure needed for training are controlled by organisations. AI assistance speeds up parts of the work, much as compilers and search engines did before it.
There are also real bottlenecks that faster code writing does not remove. Hardware is scarce. High-quality data is hard to find. Training runs take time. And it is difficult to tell whether a model is genuinely better or merely tuned to a benchmark.
What the claim does tell us
It still means something. If a significant share of development work can be handled by assistants, small teams can build more and build it faster. Software engineering is shifting toward reviewing, specifying and testing, with less time spent typing routine code. Gaps between teams that adopt these tools well and teams that do not could widen.
It also hints at feedback effects. Better coding models help produce better tooling, which helps produce better models. That cycle is real, but it is gradual and held back by the limits above. A fair summary is that tools built by AI are speeding up engineers, not replacing the decisions that matter. You can read more about the underlying technology in this article on large language models.
Consider a small team that ships a product with a handful of engineers. If assistants draft the first version of most functions and write the tests, the team can try more ideas in a week than it once tried in a month. Nothing about that is mysterious, and nothing about it removes the need for people who understand the product and its users. It simply moves their effort from typing toward judging. That is the honest meaning of most software described as built by AI.
Reasons for caution
Quality and security come first. Generated code can hide subtle bugs or insecure patterns, so review and testing remain essential.
Over-trust is a close second. Teams may accept output without understanding it, which leaves them with systems that nobody fully grasps.
Measurement is murky when a project is described as built by AI. The percentage of code written by AI is a vague figure, because autocompleted lines, boilerplate and tests count the same as critical logic. Marketing adds noise as well. Statements about AI building AI make attractive headlines, so treat precise numbers and sweeping descriptions with scepticism unless the method is explained.
Skills matter too. Developers who rely heavily on assistants must keep their fundamentals strong, or they will struggle when something breaks and the assistant cannot fix it.
Questions worth asking, and advice for developers
When you read that a model was built by AI, a few questions sharpen your view.
- What fraction of the work was done by AI, and how was that measured?
- Which tasks still required human judgment?
- Were the results evaluated independently?
- Did the model make progress on hard problems or only on routine ones?
- What safeguards were used to check the output?
For developers, the practical advice is simple. Use assistants for what they do well: boilerplate, tests, refactoring, explanations and exploration. Review everything and keep security in mind. Write clear specifications, because the quality of the output often follows the quality of the instruction. Invest in understanding the systems you build, because accountability cannot be delegated to a tool.
AI helping to build AI is real, and it will matter. But it is a story of tools gradually shifting where human effort goes, not of an unstoppable loop. Keeping that distinction clear makes it easier to judge announcements, plan careers and think sensibly about the risks that truly deserve attention, whether a product is described as built by AI or built the old-fashioned way.
Related reading: Command-Line Coding Agents: What They Do and How to Use Them Safely and Why Big Platforms Retire Payments Apps and What It Means for Users.
