Why The Hard Part Of Agentic Engineering Isn’t The Technology

Gaurav Singal is Chief Technology Officer at ConstructConnect, a Roper Technologies company.

getty​​In early 2026, we started seeing results inside ConstructConnect that caught our attention.

A senior engineer solved a deployment problem in two weeks that had sat unresolved for two years. Another engineer, working on our flagship product, delivered in five weeks what had been estimated at 17. Roughly 87% of the commits came through his agent.

The productivity gain did not come from longer hours. The engineers had changed how they approached the work. They were using agents to produce the first drafts of code, tests, merge request descriptions and other engineering work. Their role shifted to providing context, directing the work, reviewing the output and applying judgement.

That raised a bigger question for us: Could we make this the normal way of working across engineering?

Over the next 12 weeks, we rolled out agentic engineering across the organization. By the end of the program, 94% of our engineers were actively working with the stack.

However, providing the technology turned out to be the easy part, with most of our effort going into changing habits, creating confidence and helping engineers learn a very different way to work.​​ Here are four lessons from this experience: ​

​Six weeks before the broader rollout, we created what we called lighthouse teams: small groups willing to go first, work through the rough edges and share what they learned.

We already knew that the technology worked, but we needed engineers to see it working for themselves. Once teams watched their peers ship meaningful work faster, engineers began asking how to get started. By the time the broader program launched, we had already created internal demand.

With this model, I suggest creating a network of AI champions across your teams. These are the engineers who have spent significant time working with agents and have credibility with their peers. When you are asking people to change, a respected colleague saying, “Let me show you how I do this,” carries more weight than an executive mandate.

We also changed what it meant to complete training. Attendance was not enough. An engineer was done only when they had produced five tangible artifacts:​

1. A context file committed to an active repository

2. A reusable agent procedure for work their team performs regularly

3. An enforcement rule built into the tooling

4. A real sprint story delivered end-to-end using an agentic workflow

5. A CI/CD job that automatically runs one of their reusable skills

We wanted engineers learning through work they would actually perform after the training ended. Since these artifacts lived in source control, they also became reusable organizational assets. If one engineer built a strong procedure for generating test plans, another team member could build on it instead of starting over.

That is an important design choice for leaders. Training should leave something behind. Ask people to create reusable context, workflows, rules or automation that make the next engineer more productive.

We closed the first wave with a two-day hackfest: more than 40 prototypes in 33 hours.

Teams built a conversational interface for our takeoff product, natural-language search for construction projects and several other ideas tied directly to customer needs. One team improved model accuracy in 33 hours by an amount of work that previously would have taken roughly a quarter.

As agents become part of the workflow, however, engineers need to develop a different kind of judgment. They need to know what context to provide, how to break a problem into smaller pieces and when its output is good enough to move forward.

That judgment comes from repetition. If you are rolling this out, move people into real production work sooner than feels comfortable. Classroom training can create familiarity, but experience creates confidence.​​

From day one, we made adoption visible through a shared dashboard and regular updates from our champions. The dashboard helped us see where adoption was accelerating, where teams were struggling and where people needed more support. We could make adjustments within hours or days rather than discovering issues at the end of the program.

Visibility creates a shared sense of progress. Teams could see the change happening across the organization rather than experiencing it as another isolated corporate initiative.

For leaders, the lesson is to measure adoption in a way that helps you learn, not simply report. The useful questions are: Where is this working? Where is it getting stuck? What are our strongest teams doing differently?

There is a lot of conversation about which model to use, which harness to deploy and which platform to standardize on. We spent time on all of those decisions.

​But the questions that determined whether the transformation worked were mostly about people and solid change management. You can give an engineering organization access to agentic tools very quickly. Getting the organization to work differently is the real transformation.​​

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?