The Agentic Builder

As a refresher, the three concepts behind this article

The Shannon–Weaver communication model describes communication as a process between a sender and a receiver in which the intended message can be distorted by noise. The Kübler-Ross change curve, although originally developed in the context of grief, offers a useful metaphor for the emotional uncertainty, experimentation and gradual acceptance that can accompany technological change. Hiatt’s ADKAR model complements this perspective by describing individual change through five stages: Awareness, Desire, Knowledge, Ability and Reinforcement. Together, these concepts help me reflect on how communication, emotion and learning shape my continuing development towards the role of an agentic builder.

Change was always Part of Software Engineering

Continuous change is normal in both software engineering and entrepreneurship. During my career, technologies and markets have appeared, matured and disappeared. I have moved from traditional Web applications to blockchain development on the Internet Computer, and from manually implementing most details towards developing with AI assistance. Learning has never been optional. A developer who refuses to move with the market loses relevance.

The current transition is different in scale. Five years ago, projects in my company often required at least three people. Today, one experienced developer can coordinate much of the work with AI within a technology stack he understands. I would not select Rust as a backend simply because an agent can produce Rust code. Generated code is not the same as organisational competence. As an entrepreneur, I see the productivity opportunity; as an engineer, I also see the technical debt, security and operational responsibility that remain after generation ends.

My role is moving from writing code towards becoming an accountable software architect and entrepreneur who coordinates agents across the development process. I call this role the agentic builder: a person with a software development background who coordinates agents, tools, data and infrastructure to deliver a complete solution. The responsibility does not move with the task. An agent has no legal personality and cannot become accountable for the result. The person who initiates and directs the work remains responsible.

My work is Becoming a Communication System

Claude Shannon published “A Mathematical Theory of Communication” in 1948. Warren Weaver wrote an accompanying essay in the 1949 book “The Mathematical Theory of Communication” that helped frame the model for a broader audience. Their model describes a source, a transmitter, a channel, a receiver and a destination. Noise can interfere with the message while it moves through the channel.

This model describes my daily interaction with coding agents surprisingly well. I begin with an intention. I encode that intention in a requirement, prompt or implementation plan. The agent receives the message through a channel made up of the prompt, available context, project rules and tools. It interprets the message and returns a plan, code, tests or documentation. I then provide feedback and the cycle begins again.

The main difficulty is often not the implementation. It is my intention and the agent's interpretation match. Missing legacy knowledge, ambiguous requirements, incorrect assumptions and excessive output all act as noise. An agent may propose stricter authentication than the established workflow requires. It may create a new service without first finding an existing one. It may recommend an npm package that does not fit the runtime of a legacy system. The answer can sound convincing while solving the wrong problem.

Too much text is one of the most persistent forms of noise in my current work. Models can process large contexts, but human attention remains limited. Long plans hide the decisions I need to review and increase token costs. I have not yet found one perfect rule for keeping this under control. Working effectively with agents requires me to become a more precise sender, critical receiver and better editor.

From Inspecting Code to Designing Control

My workflow has changed gradually. Before implementing a feature, I ask the agent to prepare a written plan. Every new module begins with a plan. When a module changes, I update the plan first and implement only the required steps. I review the complete plan, often through several rounds, before implementation starts.

I also use general rules to protect existing systems. The agent must search for existing services and components before proposing new ones. A new service or component requires approval. Changes should remain in a separate file or clearly bounded area where practical, with as little disturbance to proven legacy code as possible. A running system should not be modernised simply because the agent prefers a newer pattern. A security issue, credible potential bug, unsupported dependency or operational risk can justify change, but the decision must reflect the application's actual threat model and the risk created by the update itself.

Tests and documentation are now standard. At the beginning, I inspected most generated code. As the test suite and documentation grew, I shifted towards risk-based review, examining the parts that experience tells me deserve closer attention. Tests do not eliminate the need for judgment: the same agent can reproduce the very same misunderstanding in both implementation and testing. However, they shift control from pure intuition to reproducible evidence.

This is a deeper change than using a faster coding tool. I am learning to design the environment in which an agent works: its context, rules, permissions, acceptance criteria and stopping points. My craftsmanship is moving upwards from individual lines of code towards the architecture and governance of the entire process.

A Setback inside a Longer Transformation

One experience made the importance of control especially visible. In May 2025, I saw the presentation of Caffeine, an Internet Computer tool for creating applications through conversation. I later used it to build SoveriCMS. The system became functional after more than 70 prompts, but the managed backend canister eventually ran out of compute cycles and the content was no longer accessible. I lacked the operational control needed to resolve the problem directly. I lost trust in that approach and rebuilt SoveriCMS with Cursor. This implementation still powers soveri.at.

This example describes my experience in 2025, not Caffeine today, the product has evolved. Early success in any transformation can hide dependencies that later damage trust. My lesson was not to reject AI, it was to distinguish delegation from surrendering operational control.

Understanding my Change through the Learning Curve

Elisabeth Kübler-Ross published “On Death and Dying” in 1969. Her work concerned terminally ill people and was not created as an organisational change method. Later organisational adaptations use a curve with reactions such as shock, denial, frustration, experimentation and integration. The lowest point is often called the “valley of tears”. The stages are not a fixed sequence. People can skip, repeat or experience several of them at once.

With this limitation in mind, the curve helps me interpret my ongoing transformation. The first encounter with conversational application building created surprise and excitement. The SoveriCMS incident produced shock and a loss of trust in an approach that concealed too much operational responsibility. Rebuilding with Cursor marked a move into experimentation. I retained the architecture, code, deployment and decision authority while using AI where it added value.

Integration is now taking place through everyday practice. Planning documents, rules, tests, documentation and risk-based review have become part of my normal workflow. My AI engineering studies add theory to that practice and help me understand why the transition is not purely technical. Yet, I would not say that the change is complete. I am still learning how much context to provide, how to reduce output noise, how far to delegate and when direct inspection remains necessary. In agentic development, integration is not a final destination. It is the ability to continue learning without losing control.

Data Sovereignty Shapes what I can Accept

My acceptance of agentic development is inseparable from data sovereignty. For SOVERI, operational, personal and customer data should be stored in Europe, governed by European law and handled by European providers. Open-source technology is compatible with that position and can reduce dependency, but it does not guarantee sovereignty on its own.

Sovereignty also requires operational control: the ability to access, export, restore and migrate data without complete dependence on one managed service. Publicly available application code does not require the same isolation. Customer data, credentials, production logs and sensitive business knowledge must not enter an external agent's context without a justified and compliant arrangement.

This boundary is part of my change process. The question is no longer only whether an agent can complete a task. I must also ask which data it receives, which tools it may call, which action requires confirmation, where processing takes place, how the result can be verified and whether I can continue operating if the provider disappears.

Although this is my personal change, it does not take place in isolation. Similar transitions will affect people throughout organisations. My experience suggests that adoption grows when people understand the purpose of the change, receive time to learn and experiment, and retain meaningful control over their work.

Individual Change becomes Professional Capability

Jeff Hiatt's ADKAR model (2006) provides a useful structure because it focuses on individual change. Its five outcomes are: awareness, desire, knowledge, ability and reinforcement. The model does not describe my experience as one simple, completed sequence. It helps me identify what makes movement possible and where my transformation is still unfinished.

The three perspectives answer different questions. Shannon and Weaver help me ask whether meaning survived the noise. The change curve helps me recognise how I experience disruption. ADKAR helps me examine how awareness and motivation become knowledge, practical ability and a workflow reinforced through repeated use.

My Continuing Change through ADKAR

1. Awareness. I recognised that AI would change both software development and the economics of running a software company. Ignoring it would protect neither my profession nor my business.
2. Desire. I chose to participate in the change and innovate both roles. This was not blind enthusiasm for every tool, it was a decision to use AI without surrendering technical or entrepreneurial responsibility.
3. Knowledge. My studies, experiments and professional experience help me understand agents, communication, architecture, security and data sovereignty. Planning before implementation turns that knowledge into explicit decisions.
4. Ability. I apply the knowledge through written plans, bounded changes, approval rules, tests, documentation and risk-based review. The Caffeine setback also taught me that apparent functionality is not the same as operational control.
5. Reinforcement. The rebuilt SoveriCMS as an example, repeated planning workflow and growing test suite make the new practice durable. Reinforcement remains ongoing because I am still refining context, output length, review depth and delegation boundaries.

ADKAR does not replace the emotional perspective of the change curve. The curve helps me understand my reactions to change; ADKAR helps me understand how I turn that change into a new way of working. Communication connects both: it reduces avoidable noise, makes learning explicit and preserves the human judgment behind every delegated task.

My Change Remains in Progress

I do not see AI as the end of my profession or my business, and I have not stood still long enough to fear that outcome. Software engineering and entrepreneurship have always required movement. What is changing is the level at which I create value. I write less of the implementation myself and spend more time defining architecture, communicating intent, reviewing plans, designing controls and deciding what should not be delegated.

The three theoretical perspectives give me a language for this experience. Shannon and Weaver explain why clarity, feedback and noise now influence software quality so directly. The change curve reminds me that setbacks and uncertainty are part of adaptation rather than proof that the transformation has failed. ADKAR shows how awareness, motivation and learning become practical capabilities. Data sovereignty establishes the boundaries in which I am willing to continue.

The agentic builder is not a finished role. It is my current direction: an experienced software engineer and entrepreneur who keeps learning, coordinates increasingly capable tools and remains accountable for the system and business that result.

References

• Shannon, C. E. (1948). A Mathematical Theory of Communication. Bell System Technical Journal 27
• Kübler-Ross, E. (1969). On Death and Dying. Macmillan.
• Hiatt, J. M. (2006). ADKAR: A Model for Change in Business, Government and Our Community. Prosci Learning Center