“We can’t really do cowboy style”
Plugsurfing is part of Corpay, a publicly listed company that runs serious transaction and financial data infrastructure. That sets a clear context for how new tools get adopted.
There are security standards to meet, data practices to respect, and approval processes for new tooling. None of that stops adoption. It shapes the pace.
Once access is in place, the team moves quickly.
“We want to really adopt the new technologies. People are raring to go.”
That combination, careful access and active use, is the starting point for everything else in this story.
From writing code to shaping outcomes
The clearest shift Abhinav Goel describes is in where engineering effort goes. Less of it is spent typing code. More of it is spent on the work that decides whether the code does the right thing in the first place.
That means defining the problem properly. Giving the AI tool enough context about the system, the domain, and the goal. Reviewing what comes back. Catching the places where a solution looks fine on the surface but creates problems further down in the platform.
If an AI tool asks for clarification before it starts building, that is a strength, not a failure. It means the tool is catching ambiguity early, before effort goes into solving the wrong problem.
“We are not testing human intelligence here. We are testing AI effectiveness.”
There is a real risk on the other side of this, too. If AI agents push out too much code, the review burden moves onto engineers and the team slows down instead of speeding up. The engineering team is experimenting with an orchestration layer between the agents and the engineers, designed to manage context between steps, reduce the time engineers spend monitoring agents, and let an agent pick up where it left off instead of starting from zero every time.
“AI is doing a lot of work, but where is the human effort going into this entire process?”
Measuring what actually matters
Abbe is direct about what does not work as a measurement: counting code.
Pull request volume can go up. Lines of code can go up. The number of tickets marked done can go up. Neither of those numbers tell you whether the team shipped anything that mattered to a driver, a partner, or the business.
“Lines of code are immaterial if the business impact is not there.”
The harder question, and the more useful one, is whether AI-assisted work creates more product capacity, ships features people actually use, and frees up time that can go into things the team could not do before.
That is a measurement problem the team is still working through. The engineering team has started classifying pull requests by how much AI contributed to the work, with the engineers themselves doing the labeling. It is not automated and it is not perfect, but it makes the contribution visible enough to learn from.
The other half of the picture, mapping that work back to business outcomes, is harder. AI is a transformation for the whole company, not just engineering. The impact starts with sales and ends with operations, the full cycle, and good long-term measurements will take time to develop across all of it.
The rise of the product engineer
Looking further out, Abbe expects the most valuable engineering skill to change.
Knowing a specific programming language deeply will matter less as AI handles more of the implementation layer. What will matter more is domain knowledge: understanding the EV charging business, the P3 platform, the downstream effects of a change, and the actual problem behind the request.
“It will be more like becoming a product engineer rather than a particular technology engineer.”
The same logic runs the other direction. Product managers benefit from being closer to the technology, because AI makes prototyping cheap enough that ideas can be tested before a full business case is built. The overlap between product and engineering work gets more important, not less.
What this opens up
The most interesting part of this shift is not the work that gets done faster. It is the work that becomes possible at all.
When implementation effort comes down, teams can run more experiments, test more ideas, and explore directions they could not afford to explore before. The same headcount can take on problems that used to sit on the backlog indefinitely.
“How can we grow the business rather than solving a problem that AI will take care of?”
There is a culture side to this too. When AI takes on the repetitive work, a small team can stay small without losing what made small worth it: less bureaucracy, more autonomy, and a clearer view of what everyone is actually doing.
That is the question the rest of this series tries to answer in practice. In the coming weeks, we’ll hear from teammates across product, data, support, sales, operations, and marketing on what AI has changed in their day-to-day, and what they are now doing that was not on the table before.
