# As I said, Alea AIcta est. > Source: > Published: 2026-08-23 18:58:44+00:00 An argument against the intensive use of AI in development is appearing more and more often, and it could be paraphrased like this: "the more code agents generate, the further developers move away from the codebase they are supposed to understand and maintain." And the argument is not without merit. If an AI agent generates thousands of lines of code and the developer only enters the process at the end to review the diff, a problem quickly emerges that goes beyond code quality. The developer starts losing the mental model of the system they are building. Code review can then genuinely become like looking for a needle in a haystack. You are reviewing code you did not write, trying to identify a few potentially dangerous decisions among hundreds or thousands of lines and, more importantly, trying to understand afterward how the system changed while you were not actively involved in that change. If that is what AI-assisted development looks like, it is perfectly understandable that after some time someone might say: this is no longer how I want to work. But that is only one possible AI workflow. AI should not be viewed only as an API we call from an application to perform a specific task. As a conversational interface, AI can become a serious counterpart in the development process itself. Through an ongoing conversation, we can provide context, revisit previous decisions, consider alternatives, challenge suggestions, ask for explanations, and gradually develop a solution. That is a different role from a traditional API integration. An API allows AI to become part of the product. A web interface and conversation with AI allow it to become part of the development workflow - an interface through which the developer thinks, explores, decides, and builds. In AI-Native development, that distinction matters. AI is not only something the application uses. It can also be something through which the developer builds the application itself. There is a major difference between handing an agent a task and coming back after it has produced several thousand lines of code, and developing an application incrementally, step by step, through continuous interaction with AI. In that case, AI is not a distant generator whose output you try to understand afterward. It is part of a process in which you first understand the problem, then the current state of the application, define the next step, consider possible solutions, implement one, verify the result, and only then move forward. That way of working does not remove the need to understand the codebase. Quite the opposite. Every next step requires you to read, reconsider, and extend what is already there. If you lose the mental model of the system, the problem did not arise because you did not personally type every line. It arose because you handed the development process over to something that started operating outside your understanding. There is also an assumption that we care less about code we did not write ourselves. That may be someone's genuine personal experience, but I do not think a general rule follows from it. Ownership has never had to mean: I personally typed every character in this repository. In serious development, we have been working for decades with frameworks, libraries, open-source packages, legacy code, code written by colleagues, and systems started by someone else. We can still fully take responsibility for the product we are building. The principle does not have to be any different with AI-generated code. When you develop incrementally, extending the same codebase step by step, you continuously read and think about what is already there. You know why a particular part was added, what decision it represents, how it fits into the rest of the system, and what it may change in the next step. AI-generated code therefore does not automatically have to become "someone else's code." As you integrate and extend it sequentially, the mental model of the codebase can grow along with it. Ownership starts to disappear only when you stop understanding the decisions you are accepting, not when you stop being the person who physically turns them into syntax. A more serious argument is that relying heavily on AI can slow a developer's professional growth. It can. If you consistently delegate a skill, you will probably develop it less. If you no longer have to solve a certain type of problem manually, it is entirely possible that you will become weaker at that specific activity than you would have become if you had practiced it every day. But that does not mean you stop developing. The question is: **what are you developing instead?** A developer who can move across a much broader part of an application with the help of AI may spend less time mastering the syntax of a single framework, but more time thinking about architecture, systems, products, users, different technology layers, and the consequences of the decisions being made. That is not automatically progress. AI does not guarantee that someone will become a better engineer simply because they produce more. But it is not automatically stagnation either. It may simply mean that the type of capability we are developing has changed. So the question is not only: **"Am I learning less because of AI?"** A much more useful question is: **"What have I decided not to learn in the same way anymore, and what am I learning instead?"** This may be the most important distinction. AI can certainly create distance between a developer and the process of writing code itself. You spend less time at the syntax level. You spend less time manually assembling functions. Part of the implementation that once required hours can now emerge through several iterations of conversation with AI. But distance from syntax is not necessarily distance from the application. The opposite can happen. If you spend less time on mechanical implementation, you may have more room to understand the application as a product: what it is trying to do, why a particular part exists, how different parts of the system affect one another, where complexity is increasing, and whether the feature you are currently building should exist at all. The developer does not have to become less connected to the work. They can become less connected to an individual line of code while becoming much more connected to the system as a whole. Of course, only if AI is not used as a black-box code factory. Context, conversation, smaller steps, continuous decisions, verification, and understanding what is changing become more important precisely because generation is no longer the most expensive part of the process. That is why the conclusion "AI is distancing me from the code, so I am going to stop using it" seems like a completely legitimate personal decision to me, but not the only possible response to the problem being described. There is another possibility. Maybe we do not need to return to the old way of development in order to preserve understanding, ownership, and professional growth. Maybe we need to change the way we use AI. If implementation keeps getting cheaper, the value of a developer will not disappear simply because they no longer have to manually produce every line. It will shift toward understanding the problem, the product, and the system, toward decision-making, controlling complexity, verifying results, and taking responsibility for what is delivered. That requires a different workflow. It probably requires a different developer profile as well. AI-generated code does not have to become someone else's code. But it has to remain part of a system we understand and are prepared to take responsibility for. In active discussions about AI and development, I keep noticing another recurring theme. Developers with ten, fifteen, or twenty years of experience increasingly talk about the feeling that AI is pushing them aside, that something they spent years building knowledge and experience around is suddenly becoming available to a much wider group of people. That reaction is understandable. For years, a large part of a developer's professional value was tied directly to what they knew how to do, how quickly they could write code, how well they knew a particular framework, or how many problems they could solve based on experience that someone else did not yet have. AI changes the economics of that knowledge. It does not erase experience, but it reduces the exclusivity of many capabilities that once required years of work. Something a developer once needed substantial experience to approach can now be started by another developer with a few well-structured questions to AI. That can easily create the feeling that twenty years of work have suddenly been devalued. But perhaps the value of experience has not decreased. Perhaps the place where that value becomes visible has simply changed. Experience no longer has to prove itself primarily through the amount of code someone can produce independently. It can show itself through understanding systems, recognizing the consequences of decisions, assessing risk, product judgment, controlling complexity, and directing the much greater productive capacity of AI toward an outcome that actually makes sense. In that case, the problem is not that the senior developer has become unnecessary. The problem may be that what makes someone senior is changing. All of this, in my view, leads to a more important conclusion: we are not simply watching the arrival of another tool for developers. A new development paradigm is emerging. **AI-Native Software Engineering.** **AI-Native Software Engineer.** **AI-Native Development.** **AI-Native Developer.** AI is no longer an addition to the existing workflow that we can switch on when convenient and then continue working as before. It changes how products are created, how quickly an idea can become an implementation, where the bottleneck is, which capabilities become more valuable, and what we expect from a developer in the first place. In this paradigm, writing code remains part of the job, but it no longer has to be its central value. Understanding the problem and the product, architecture, context, the ability to guide AI through development, verification, decision-making, and ownership of the final outcome are becoming increasingly important. This is not a question of whether we like the change. The paradigm has already changed. Do not try to evaluate the new paradigm by the rules of the old one. Developers who accept it will have to develop a different professional profile. Those who try to preserve the previous model of work as the only "real development" risk becoming outdated over time - not because they no longer know anything, but because they are offering the market capabilities whose relative value has changed. That is why I do not see AI-Native as a marketing label for a developer who uses ChatGPT or Cursor. I see it as a new definition of the job. **As I said, Alea AIcta est.**