For a long time, I used artificial intelligence every day without letting it lead substantial parts of development.
That may sound contradictory. In practice, AI was already present in almost everything: research, planning, writing, analysis, exploring ideas, code review, implementation examples and small refactors. Tools such as ChatGPT and GitHub Copilot quickly became a natural part of the work.
But there was a boundary I was slow to cross: letting coding agents take on larger tasks, change several files, propose plans, carry out changes and validate results.
I liked AI as support. As a copilot. I would give it a clear intention and ask for a block of code, an explanation, an architectural alternative or a local adjustment. It often did the heavy lifting of turning a decision I had made into written code. But I still worked in much the same way: I thought, decided, formed a plan in my head and used AI as a tool for speed.
AI made the work faster. It had not yet fundamentally changed how the work was designed.
When AI stops being autocomplete
That perception changed when the models became too good to treat as sophisticated autocomplete alone.
A simple question began to produce almost complete solutions. A small request would unblock two or three stalled tasks. A quick investigation revealed dependencies, risks and possible approaches that might have taken hours to uncover manually. Gradually, it became clear that the limit was no longer just the models’ capability. It was also how we guided them.
That was when I started looking more closely at coding agents, terminal tools and structured workflows.
Instead of asking only for one-off answers, I began studying how these tools actually worked: reading documentation, opening --help, understanding permissions, context, execution modes, limits, change reviews, tests and ways to regain control when something went wrong.
More important than learning to ask for code was learning to guide an agent towards producing something that could be reviewed.
And that led to an unexpected conclusion: AI made me value something I had associated for years with overhead, friction and bureaucracy.
Process.
Not process in the heavy sense, full of empty meetings and documents nobody reads. Process in the sense of clarity, context, intention, validation and memory.
When agents enter the workflow, many practices that seemed excessive for small teams start to make much more sense: concise documentation, success criteria, implementation plans, a QA plan, tests, reviews, a Definition of Done, decision records, repository instructions, files such as AGENTS.md and explicit working conventions.
This stops being ceremony. It becomes infrastructure.
The agent needs what people often leave implicit
An experienced person can work with a great deal of implicit context. They remember earlier decisions, know which files to avoid, understand nuances in the domain, recognise risks from past experience and adapt along the way.
An agent does not have that history in the same way. It needs explicit context. It needs to know which files to consider, which commands it may run, which patterns to follow, which tests validate the change, which decisions it should not make alone and what counts as an acceptable result.
That was where the question changed.
It was no longer simply: “How can I ask AI for code?”
It became: “How do I design a working system in which an agent can investigate, produce, validate and improve a delivery?”
This is the essence of what many now call agentic engineering.
It does not mean letting AI do everything. Nor does it mean accepting any result generated by a model and hoping it works. It is almost the opposite.
It means turning intention into a workflow.
A good agentic workflow starts with a clear task. That task goes through investigation. It then becomes a plan. The plan identifies risks, affected files, success criteria and the checks required. Only then does execution begin. Then validation. Then review. Then a record of what was done and learnt.
Put simply:
intention -> context -> plan -> execution -> validation -> review -> memory.
This flow may seem slower at first. But, when applied well, it reduces rework and ambiguity, and lets agents take on larger parts of the work without turning the project into a collection of disconnected changes.
AI shifts the centre of engineering
The central point is this: AI does not replace engineering. It shifts the centre of engineering.
For a long time, a large part of technical work involved writing code line by line. That work still exists, but more and more value moves to another layer: defining context, designing the execution flow, creating validation criteria, organising knowledge, reviewing decisions and ensuring that the final result makes sense for the product and its operation.
This changes the role of the people who build software.
The developer remains technical. They remain accountable. They still need to understand architecture, the domain, data, security, performance and user experience. But they also become someone who designs working systems for agents.
At Makers, this thinking extends beyond code.
The same logic appears in sales operations, CRM, customer service, marketing, analytics, forms, dashboards and internal processes. Having data is not enough. Having a tool that answers questions is not enough. Connecting a model to a channel and calling it automation is not enough.
The step forward happens when data, AI and human review enter a structured cycle:
- detect a signal;
- develop a hypothesis;
- prioritise an action;
- execute within clear limits;
- validate the result;
- learn for the next cycle.
Without a workflow, AI answers questions.
With a workflow, AI participates in a system of continuous improvement.
This applies to development, sales, customer service, BI, product and operations. The question changes from “How do we use AI for this task?” to “Which process can we redesign so that people, data and agents work better together?”
From tool to working system
When a company uses AI only as a response layer, it gains speed in individual tasks. When it uses AI within a well-designed process, it gains operational capacity: more context, consistency, traceability and accumulated learning.
That is why, for us, AI agents are more than a new interface. They create a new requirement for operational design.
The more autonomy we give systems, the more important their boundaries become. The faster an agent can execute, the more important it is to know what to validate. The more tasks we automate, the more important it becomes to preserve memory, judgement and ownership.
AI has not removed the need for process.
It has made good processes more important.
Perhaps this is one of the major professional changes of the coming years. Beyond learning to write better prompts or adopting the latest tool, we need to learn to design workflows in which agents operate with context, limits, validation and purpose.
In the end, the future does not necessarily belong to those who “use AI”.
It belongs to those who know how to turn work into a system.