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

This article was originally published September 2026, in Forbes, by Gaurav Singal, Chief Technology Officer at ConstructConnect®. 

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: 

Let people see it working.

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.

Make training produce something.

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.

Give people real problems.

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.

Make progress visible.

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?

ConstructConnect Takeoff: A real-life example of these lessons in action.

These lessons did not stay inside engineering. We applied them to the creation of ConstructConnect Takeoff, an AI-powered, web-based construction estimating solution that runs in your browser with no desktop installation. Its tools automatically name and scale your sheets, then use AI to detect and measure items on your plans.

The result of the above work is a product built the way we now build everything. And, now, construction estimators get a first pass to review instead of a blank page.