With all the hype around AI, it can be difficult to know which aspects of AI technology are actually being implemented inside enterprises. To find out, I spoke with Brian Wald, who heads up GitLab’s Field CTO team and is in regular contact with enterprise IT departments.
Wald described the Field CTO role at GitLab as one that provides strategic, high-level advisory support to businesses undergoing digital transformations. They tend to focus on DevOps, cloud infrastructure, and (now of course) AI technology. Additionally, his team of nine Field CTOs feeds back industry trends and customer insights to GitLab’s product and engineering teams.
As for AI specifically, Wald explained that GitLab began investing in AI and machine learning about three years ago — with an initial focus on leveraging its large codebase to support development processes. But over time, it switched to focusing on the “post-commit” stages.
“What we see is that post-commit — you know, once people have made the code change — there [are] a number of steps that take a super long time for it to get into production. And we’re looking at how can we minimize that time span [using AI],” Wald said.
This is where his Field CTO team came in. Based on customer feedback, Wald explained, GitLab shifted its AI efforts toward automating time-consuming tasks like code reviews, security audits, and CI pipeline troubleshooting. This approach was particularly useful for teams in regulated, high-compliance environments — which is one of the areas the company focuses on.
From Coding to Architecting
One of the trends Wald and his team of Field CTOs have identified in the AI era is a shift in the type of work required of enterprise development teams. As AI becomes more capable of generating code — especially when given proper structure, prompts and context — developers are shifting their focus toward higher-level responsibilities, Wald noted. In large organizations, especially in regulated industries like finance, developers are now acting more like architects: spending more time on upfront design, defining business logic, and creating high-context environments to guide AI-generated code.
“Your senior engineers or your lead development teams, they’re spending more of their time saying, ‘Okay, here’s how this connects into our subsystems. Here’s the business logic that’s associated [with] it’. And building out high context windows, so that when the developers go and build these tasks, it’s using that context as a way to build better code.”
Wald added that organizations are also wary of the quality of code being generated by AI assistant software. This means that enterprise developers are increasingly taking on quality assurance and code review roles, ensuring that AI-written code meets organizational standards, uses approved libraries, and maintains security and efficiency.
“…you become kind of the orchestrators of the code, versus the writers of the code.”
– Brian Wald, Global Head, Field CTO at GitLab
“So you become kind of the orchestrators of the code, versus the writers of the code,” Wald said. “[On] the front end, you’re doing a lot more analysis and building out plans. [On] the back end, you’re doing a lot of ‘let’s review this and make sure this actually makes sense’ and [that] we’re not creating more technical debt.”
I asked whether software developers are taking on these new “code orchestrator” tasks, or is it being done by existing IT architects?
In some cases, Wald replied, developers are naturally evolving into these roles without formal recognition — they’re just spending less time writing code and more time on architectural or planning tasks. But in more mature organizations, this shift is being formally acknowledged and acted upon. These companies are restructuring their teams, explicitly defining architect roles that work closely with product managers to design systems rather than write code.
“So you have, like, a PM and an architect who are sitting together doing a lot of this development,” he explained, adding that their job is to create a “blueprint” for the code generation.
Does Vibe Coding Belong in the Enterprise?
So with less code writing happening now in enterprises, it begs the question: Are organizations taking up “vibe coding,” the practice of prompting an AI system to create software?
Proceed with caution seems to be the motto in enterprise environments. Wald noted that some organizations have even banned the use of vibe coding for “brownfield” applications (where there is existing software complexity), due to the risk of unintended consequences. Other organizations are embracing vibe coding, but in more controlled ways.
“Where I see that [vibe coding] being very valuable is on the rapid prototyping, the high fidelity mock-ups and wire framing,” Wald said. “It does an extremely good job of doing that type of stuff. And new applications — I want to spin up a new application, and here’s the architecture, here’s the tools that I want you to use, go spin up the foundation of this. Using vibe coding to do that can get you 90% of the way there in 10% of the time.”
“…don’t have it go and try to do some big, massive task — it’s going to fail miserably.”
– Wald on vibe coding in the enterprise
But with existing applications, there is much more caution within enterprise environments.
“When it comes to solving things in our existing business applications, you may want to use [vibe coding] to help redesign a function, but don’t have it go and try to do some big, massive task — it’s going to fail miserably.”
Agentic Systems: Early Days
The other big catchphrase this year has been “agentic systems.” I asked Wald how enterprises are practically deploying AI agent technologies.
Again, he emphasized that enterprises are focused on structured implementations, rather than open experimentation. Enterprises are not letting every developer freely use AI agents, he said. Instead, they’re forming centralized “AI enablement” teams, which often overlap with platform engineering or DevOps teams.
The AI enablement teams are building predefined, contextual workflows and agents tailored to company needs — he mentioned remediation bots as a recurring example within enterprises. These bots identify issues in logs or observability pipelines, and assign responsibility to fix.
AI enablement teams are building predefined, contextual workflows and agents tailored to company needs.
He added that enterprise IT teams typically have strict policies around data privacy, IP protection, and model hosting. So there are various questions that have to be addressed.
“Can we use this AI LLM model? Where is it hosted? What is it doing? Is it the right model with the right either RAG or MCP server, to give the context [of] our organization in there without exposing IP risk? And so they’re still in that stage of things, but allowing their teams to […] do things inside those guardrails.”
In other words, it’s still early days for agentic systems.
Advice for Developers
Finally, I asked Wald if he has advice for developers within enterprise. Should they pivot to becoming IT architects? Or are there other ways they can upskill as software engineers?
Wald emphasized that understanding the fundamentals of software engineering is still crucial, along with getting your head around LLMs.
“The best engineers who are using AI today have a really, really strong underlying fundamental understanding of the code that they’re writing and what they’re doing prior to that. Like, there’s this notion that [AI is] going to allow non-technical people to be able to write code; and although that’s true with vibe coding and they can get pretty far, they always hit a wall. And it’s because they don’t really understand what’s happening inside the code, and they can’t analyze that, and they can’t say, ‘yeah, I don’t think that’s the right decision here, let me give you some more context.’”
Developers now need to understand business logic deeply.
In terms of adapting to the shift from coding to orchestrating, Wald said that developers now need to understand business logic deeply — which historically hasn’t always been the case, because often that was the responsibility of a product manager.
“Now you have to be not just an architect for engineering, but you also have to understand the business side of it as well — so that you’re making the right decision, so you can tell the AI what it needs to do so that it works with the output of the product more effectively.”
Originally published at The New Stack: https://thenewstack.io/the-field-cto-view-ai-vibe-coding-and-developer-skillsets/