More often than most leaders would like to acknowledge, a scene occurs in engineering meetings. Someone pulls up a model response from earlier in the week that the AI confidently generated and that initially appeared correct, and they attempt to explain why it acted that way. The room becomes silent. No one has a clear response. Once, it was successful. It doesn’t now. The logic isn’t there, but the log is.
That moment is more important than it might seem, and it is starting to define modern software development. After years of developing systems where Input A plus Code B equals Output C, engineers are now using tools that don’t adhere to those guidelines. The profession hasn’t fully embraced the gradual erosion of the determinism that initially made programming feel like engineering.
| Field | Detail |
|---|---|
| Subject | AI Adoption Challenges in Engineering Teams |
| Key Figure | Chris Parsons — CTO & AI Consultant |
| Core Problem | Gap between AI tool usage and genuine AI engineering capability |
| Industry Context | Over two years of rapid AI adoption across software teams globally |
| Central Concept | AI is non-deterministic — same input can produce different outputs each run |
| Key Distinction | Using AI tools ≠ Engineering AI systems |
| Organizational Scale | Gower Street Engineering team grew from small unit to 50+ engineers under Parsons |
| Recommended Practice | Log every AI interaction; review manually; apply meta-prompting |
| Affected Roles | ML Engineers, AI Infrastructure Specialists, Engineering Managers, CTOs |
| Broader Implication | AI is reshaping engineering toward higher abstraction and syst |
Introducing new tools is insufficient, according to Chris Parsons, a CTO and AI consultant who helped grow an engineering organization at Gower Street beyond fifty employees. What counts is whether or not teams truly comprehend how those tools function, and most of the time they don’t. Well, not just yet. Adoption is often seen by engineering leaders as a procurement issue.
Purchase the appropriate software, implement it, and observe an increase in productivity. Parsons takes a long time to explain why that frame is completely incorrect.
The fundamental problem is that generative AI behaves differently from conventional software. You might see significantly different results if you run the same prompt twice. Teams create internal prototypes, thoroughly test them, see encouraging outcomes, and then deploy them to production only to find that real users, with their erratic wording, edge cases, and peculiar follow-up questions, produce behavior that the model never displayed during testing.
No amount of internal testing may be able to adequately prepare a team for what occurs when a model is introduced to the real world.
Adoption of AI is genuinely challenging because of this, unlike earlier technological advancements. Although there was a steep learning curve when teams adopted new IDEs or cloud platforms, the underlying logic remained deterministic. A bug could be tracked back to its origin. Under certain circumstances, you could ensure a certain result. Senior engineers frequently feel the loss of that guarantee the most.
Parsons has observed an odd trend: junior engineers often ship functional AI agents more quickly than their more seasoned peers. When you consider it, the explanation isn’t all that shocking. Senior engineers have an innate desire to control every decision point, eliminate ambiguity, and engineer away the probabilistic nature of the model. They battle it. They break it in the process of fighting it.
Beyond the difficulties faced by any one team, a more profound conceptual change is taking place here. For many years, control was the most important aspect of software engineering. According to Parsons, engineers owned the roads, the lights, and the data flow, making them traffic controllers. Agent engineering radically alters that relationship.
They are now dispatchers, giving directions to a driver who may choose to drive faster on the sidewalk or take a shortcut. Experienced engineers’ discomfort is not a sign of weakness. It is the result of years of training that points in the wrong direction.
What does it really look like to deal with this new reality? Parsons begins with an almost embarrassingly basic step: log everything. Every exchange, every model reaction, every pipeline stage. Next, manually review the logs to determine what is truly going on. Responses are frequently not very good at first. Quite awful at times. Sometimes unexpectedly awful in ways that are difficult to anticipate beforehand.
Since it’s slow and unglamorous, most teams avoid this type of honest accounting, but it’s also the source of true understanding. By monitoring AI performance in the same manner as engineering efficiency—positive interactions, error rates, and response patterns—teams can obtain real data about the behavior of their own systems, which is something they seldom have in the early stages.
Meta-prompting, or using the AI itself to enhance the prompts, is one strategy Parsons promotes but doesn’t receive enough attention. The idea is to let the model ask clarifying questions one at a time, gradually building context, rather than attempting to write flawless instructions from the beginning. As time goes on, teams can ask the AI what details it would have liked to have known at the beginning of the conversation and make adjustments from there.
It is not a one-time configuration; rather, it is an iterative process. Even though most organizations haven’t yet, there is a feeling that this kind of approach—collaborative, evolving, treating the AI as something more like a thinking participant than a tool—is where the field is headed.
All of this tension is reflected in the talent market. Hiring managers in the technology industry are describing an odd paradox: jobs for machine learning engineers are still open for months, despite the fact that AI is frequently mentioned on resumes. According to CTOs, very few applicants truly know how to use AI in production.
Since tutorials and courses typically prioritize model training over the infrastructure, data pipelines, monitoring systems, and reliability engineering that real production AI actually requires, it is still unclear if the education ecosystem will catch up quickly enough to close this gap. Building a system around an API is not the same as knowing how to call it.
It’s difficult to ignore the fact that the profession is experiencing more than just a skills gap as all of this is happening. From assembly to frameworks to AI-assisted development, engineering is always progressing toward higher levels of abstraction, but this specific step alters not only how work is done but also what understanding means.
The engineers who are most adept at using AI tools will not be the ones who define the next ten years. They will be able to provide an explanation for the model’s actions during the meeting and then use that explanation to accomplish something beneficial.
