Build the Machine That Builds the Applications
What OutSystems developers need to change to thrive in the agentic space, and why the window to do it is open right now
AI Agents have arrived, and I watched my Low Code team react: some people changed fast, while others are not there yet.
I have been working on changing how my team works, but the wider OutSystems community needs to change too, and faster than most of us think.
The comfort of Low Code
I've been building enterprise software for 25 years, and for a big part of that time OutSystems has been my home. I love the platform because it lets us start a project in low code and finish it in Low Code, and most of our projects fit that shape perfectly. That, however, is exactly the problem.
When the tool gives you everything you need, you stop looking beyond it. I don't have numbers to prove it, but I have years of watching good developers live very comfortably inside the Low Code space. They are rarely exposed to anything outside it. Over time, curiosity fades, along with the habit of spending a few hours a week on things that are not on the backlog.
OutSystems is partly responsible for this, in the best possible way, because it made us productive. But there is something I keep repeating to my team: you cannot take the developer out of the Low Code developer. Low Code is how we build, but being a developer is who we are, and developers who stop being curious get left behind.
I'll be honest about my own path here. Working beyond Low Code, in .NET, Azure and other stacks, gave me more agility when agents arrived. I already knew where my gaps were, so I knew what to learn to fill them.
My team is changing
Some of my developers already work in a different way every day. They use AI to do their jobs better, make the most of it, and challenge how we have always done things. They are the proof that this way of working pays off.
Others are not there yet, and there are valid reasons for that:
Time. Project deadlines don't pause for learning.
Mindset. Change is uncomfortable.
Availability. The people who could learn are often the busiest.
Background knowledge. Someone who has only known Low Code has more ground to cover.
None of these is a lack of talent, and all of them can be solved.
You won't prompt your way into an application
There is a misconception I hear all the time: people think the agentic space is about getting good at prompting, as if a clever prompt were enough to get an app. That is not how it works.
We are not going to build applications with prompt engineering. We are going to build applications by building the machine that builds the applications.
Prompting is where everyone starts, and that is fine. But a real agentic pipeline is not one prompt. It is a set of skills, activities and agents, each doing one job well, chained together to take you from a requirement to working software. Someone has to design, build, test, govern and improve that machine, and that someone should be you.
What you need to learn
So what does a Low Code developer need to change? I see three groups of skills.
First, the bare minimum of AI. You don't need a PhD, but you do need to understand how models are created, how you interact with them, what they are good at and where they fail. You need to know the common patterns for using them, especially when you work with their APIs directly. Without this foundation, everything else feels like magic, and you can't build reliable systems on magic.
Second, learning to put agents to work on your behalf. Harnesses like Claude Code, Cursor and AWS Kiro change the way you reach a deliverable. The goal is often the same as before, but the path is completely different. You stop doing every step yourself and start designing the steps an agent will do for you. That means writing skills, wiring tools through MCP, deciding what runs in isolation and what needs the full conversation, and checking that the output is actually right. It is a different way of thinking, and it takes practice.
Third, the human skills. This one surprises people. For years, many developers worked like a mouse in a basement, waiting for specifications to be slid under the door, and that model is over. When agents can do much of the building, the value moves to understanding what to build and why. You need to get out of your chair, talk to the business and the customer, and ask why, then ask why again. The developers who master this will be the ones designing the machines, while the ones who don't will fall behind.
What this looks like in practice
Let me make this concrete with something I designed and implemented at my own organization.
At Accelerated Focus, I maintain a plugin repository for our Low Code team, built on Claude. It is a collection of skills that encode how we work. One skill acts as an OutSystems 11 architecture advisor, a consultant you can go back and forth with while you design. On one of our customer projects, I have an agent that runs every day on a schedule inside Claude. It uses ODC AX (Agent Experience) to look into the factory and see what people have been publishing and how often, and then a skill writes those insights into an artifact in a format I defined, so I can follow how the developers are performing without chasing anyone for updates. Each skill has a carefully written description, because that description decides when the agent picks it up, and if you get it wrong the skill never fires.
None of this is prompt engineering. It is plain engineering, the same discipline we have always had, pointed at a new target, and it is exactly the kind of work I want every developer on my team to be able to do.
The best moment, though, came from someone on my team. I asked one of my team members to take O11 AX and pull as much information as he could from a module and its application. Instead of stopping at the extraction, he built a skill around it. That skill now feeds a contextual graph of our applications, a map our agents can use to understand what already exists before they touch anything. He went from using a tool to building part of the machine, and that is the shift I'm talking about.
The gap is our window
Here is the part that gives me hope: there is a gap today between what you can already do with agents and what organizations are ready to absorb. The technology is moving faster than companies can change their processes, contracts and teams. Most of our customers are not yet asking for agentic delivery. Some are already dreaming of having it.
I don't see that gap as a problem but as a gift, because mastering this takes months, not days. The gap is the time we have to learn before agentic delivery becomes the default. If you start now, you will be ready when your organization catches up, but if you wait for your company to ask you, you will be learning in a hurry while someone else is already delivering.
So this is my call out: get out of your chair and use the window.
The questions we need to answer
I'll finish with questions, not answers. I have ideas about all of them, but I think the questions matter more right now.
What will team sizes look like when one developer can run a machine that does the work of many? How will we organize our delivery model? Do we put an agentic flow on top of the agile framework we already know, or do we rebuild it? What do we keep? What do we replace? What do we remove entirely?
I don't think anyone has the full answer yet, but I know who will help find it: the developers who started building the machine early.
I truly hope that includes you!
end of article
Comments