What does software development with AI agents look like?

An agentic factory is a software factory where AI agents analyze, build, test and deliver real work, inside an environment with context, tools, controls and human approvals. At ConnectIA 2026, Diego de Fuentes, CTO of GeneXus Consulting, shared how we brought AI agents into software development this year: what we decided, what we tested and what we had to fix along the way.

The talk was called “The factory ahead: from Software Factory to Agentic Factory” and was presented on October 31, 2026 at ConnectIA, at LATU (Montevideo, Uruguay), an event where GeneXus Consulting was the main sponsor. It was not a lecture on agents or a ranking of models, but the recent story of how we changed the way we build software for our clients. This article follows that story, month by month, and the two examples shown live.

What changed in January 2026?

Back from the holidays, on January 6, the tools we already knew were completing entire tasks at a very different level of quality. The announcements had come earlier: Claude Opus 4.5 on November 24, 2025 and GPT-5.2-Codex on December 18, with more reach in refactors, migrations and long-running tasks.

The question was practical: was our process ready to work with agents that completed entire tasks? We were not starting from scratch. We had our own tools so AI could query a GeneXus Knowledge Base, read objects and understand dependencies. What was still hard was generating and modifying objects with the precision a real project demands.

With that diagnosis, the first-quarter plan had two lines of work moving together:

• Technical capability: improve the tooling to read, edit and generate GeneXus objects reliably.
• Way of working: build our own AI-DLC, a development lifecycle designed for agents, with stages, exit criteria, validation and deliverables.

The AI-DLC organized the work in six steps: understand the request, analyze and specify, design the solution, build, test and verify, and deliver evidence. All of it on a shared context, with quality criteria and human approvals. The goal was not to produce a mountain of documents, but a process that another person or agent could pick up and verify.

What did the first pilot on real projects show?

While we were designing the process, models kept advancing: between February and April came parallel sessions, more coding and tool-use capability, and routines that run on a schedule or a trigger. Some of the manual aids we were building fell short within a few weeks.

In May we took the AI-DLC to a team working on several real projects, with incidents, existing code and client commitments. The most interesting result was not a productivity figure. We gave the agent a problem and it came back with a solution: it analyzed, changed the code, ran it and verified it within the same task. If something failed, it adjusted and verified again, without a person directing each step.

The pilot also exposed a limitation: not every project can follow a single rigid flow.

Project type	Path
New development	Need, design, build and testing.
Migration	Inventory, conversion, parity and acceptance.
Maintenance	Reproduce, diagnose, fix and run regression tests.

That is why we share capabilities, tools and controls, but the work graph (the map of which agent or person does each step, in what order and where work goes back if something fails) changes from project to project.

What is a harness and why does it matter more than the model?

The harness is the environment that lets an agent work without asking for help all the time: context, tools, persistent state, permissions, an execution environment and ways to verify its results. The concept already existed in the industry. What changed in July was our focus: we started to look at all those pieces as one integrated system.

As adoption grew, another need appeared: understanding how AI was being used. At first we handed out licenses on demand. Then we built an internal application that shows plans, token or credit consumption, chat or CLI usage, agents used, prompt patterns and daily activity. The conclusion was clear: consuming more does not mean delivering more value. Next, we want to cross usage with delivery quality and results.

The more work is delegated, the more it matters to know under what conditions it happens. Agent governance answers four questions:

• Access: what information and tools can it use?
• Limits: what can it do on its own and what requires approval?
• Cost: how much does one run consume?
• Evidence: what changed, what was tested and what was recorded?

How do unattended agents work?

In September we took another leap: from short tasks to complete goals. An unattended agent receives a goal, organizes its own execution, keeps going for much longer and stops when it finishes or when it hits a blocker. That is when workflows, graphs and DevAgents became central.

Monitoring is external to the agent. Nobody needs to watch its screen, but we do need to know what it is doing, what it achieved and when it needs a person. That same month, the market started offering these capabilities as part of its platforms: cloud sessions, long-running agents and agent sequences with reviewable steps.

What do AI agents do in our software development today?

By October, agents take part in many activities of the process, and several already run without continuous intervention:

1. Development.
2. Migrations.
3. Bug analysis.
4. Reverse spec: rebuilding the specification of an existing system.
5. Testing and review.
6. Wikis and documentation.
7. Reports and progress updates.
8. Presentations.

What matters is not the catalog of agents, but how much work can be delegated, how it is verified and how it fits into processes with clear owners. Every path shares the same harness, with evidence, evals and human controls to make decisions and mitigate risk. It is not a finished end-to-end factory: it is a factory that keeps maturing, and it already supports our custom software development projects.

Example 1: how does the agent network resolve an incident?

A single request can involve several agents and three human decisions. This is the path of an incident that comes in through Mantis or Redmine:

1. Analysis: the analyzer agent queries the ticket and its history through MCP, and reviews the code and its dependencies.
2. Solution: the solution agent retrieves previous specifications from Git and the GeneXus KB, and writes the spec with its test plan.
3. First human approval: a person validates the scope and the test plan.
4. Planning: one agent splits the change into units and another builds the plan with order, dependencies and success criteria.
5. Second human approval: a person signs off on the execution plan.
6. Unattended execution: the DevAgent works with three code generators and three testers on parallel branches. If a test fails, only that branch is fixed.
7. Third human approval: a person reviews the merge request and approves the consolidated merge.
8. Delivery: the DevOps agent runs security, package and quality checks, and the pipeline deploys the solution to a test environment.

Each agent records evidence and evals, and the ticket is updated with full delivery traceability. The level of control can vary with risk: a screen label does not need the same treatment as a change to authentication or sensitive data.

Example 2: how is a legacy system migrated with an unattended DevAgent?

The second graph showed a legacy system migration with AI. Before signing, the agents prepare the client’s inputs, measure complexity and put together a proposal with three possible target options. Once the project starts, they prepare the source, agree on a strategy and rebuild the specification of each delivery. There are three human decisions: the target, the strategy and the spec.

What changes after the spec is approved is the goal. The DevAgent receives a complete goal, finishing all the approved specifications for that delivery, and does not ask for permission for each unit of work. It plans units and bolts, builds, tests, evaluates and repeats until the scope is met, or it stops and escalates if it hits a blocker it cannot resolve. An external monitor tracks progress, retries and alerts.

How does the process improve from one run to the next?

There are two improvement cycles. Within a run, the loop is short: execute, evaluate with tests and criteria, and correct with another attempt or a new route. Between runs, an improvement agent uses traces, tests and evals to detect recurring failures and propose changes to skills, instructions, tools or workflows.

Those proposals are reviewed by an AI Engineer, who decides what to adopt based on risk. That way, the next run benefits from an improvement to the harness, not just a one-off fix. It is continuous improvement assisted by agents and governed by people: the system does not change itself.

What did we learn building an agentic factory?

These are lessons from real work, not a universal methodology:

1. Test on real projects. A demo is enough to get excited; a real case shows what is missing.
2. Prepare the tools. A good model needs context, access, tooling and a harness.
3. Validate behavior. Compiling does not guarantee the system does what is expected.
4. Govern and build in an improvement cycle. Evaluations, monitoring, human reviews and reusable harness improvements.

And the process we designed this year will most likely not be next year’s.

What comes next for AI agents in software development?

The latest trends widen the focus: less prescribed detail and more verifiable results. Four lines point to what comes next:

• Goal-driven workflows: the agent receives an outcome to achieve and organizes the actions needed.
• Graphs and long-running work: coordinated specialists, with state, retries and continuity.
• Risk-based verification and gates: evidence and risk determine where to verify and ask for approval.
• Harness with self-improvement cycles: an agent proposes changes to skills and workflows, and an AI Engineer reviews and adopts them.

Specifications are still useful, but their depth depends on the work and the risk.

The talk closed with three decisions to move forward with people and agents:

• Start now, learn and improve: pick a well-scoped case, with supervision and clear limits, and turn each experience into an improvement of the shared method.
• Manage people and agents: set goals, decide what to delegate and evaluate results with evidence. We are still accountable.
• Adapt and evolve: the way we work in IT is changing, so we need to review how we work and build in what we learn.

Frequently asked questions

1. What is the difference between a traditional software factory and an agentic factory?

In a traditional software factory, people carry out every stage of development. In an agentic factory, AI agents analyze, build, test and deliver inside a shared harness, while people set goals, approve the risk points and evaluate results with evidence.

2. What is a harness for AI agents?

It is the environment that lets an agent work in a verifiable way: context, tools, persistent state, permissions, an execution environment and ways to check its results.

3. Where do people step in if agents work unattended?

In the decisions: they approve the specification and test plan, the execution plan and the merge request. They also supervise through external monitoring and review the changes the improvement agent proposes before adopting them.

If you are figuring out where to start, our guide on how to prioritize artificial intelligence use cases and our AI Solutions for Business can help.