AI Harness at Scale with Maxim Salnikov

🎧 New Señors @ Scale Episode

This week, I spoke with Maxim Salnikov, AI Dev Tools Solution Engineer at Microsoft, where he leads AI native development enablement for more than 100 enterprise customers of Microsoft and GitHub in Norway. Maxim has been building commercial web solutions since the late 90s, switched from engineering into developer relations after discovering the conference and meetup ecosystem, and joined Microsoft seven and a half years ago. His job now is to sit with real dev teams — in finance, energy, agriculture, and pure software companies — and talk about how they actually build things.

In this episode, we dig into why startups outpace enterprises on AI adoption and what closes the gap, how to handle the developer who tried Copilot once in 2023 and wrote it off, what an AI harness actually is and why the layer you build yourself is the one that matters, the two new job titles he sees emerging, and why a repo full of unowned agent skills is a problem you should treat like an unaudited package.json.

⚙️ Main Takeaways

1. Adoption is a change management problem, and licenses are the easy part

The single most repeated point in the conversation.

• The tooling isn't the blocker: "In many cases, this is not a technological problem, because tooling is here, licenses are here. I mean, it's very straightforward how to start."
• What actually blocks it: "To be truly AI native dev team and organization, you need to change processes. You need to do this classic change management. And sometimes this is exactly the blocker."
• Why it isn't obvious: "It's harder to change rather than just, hey, just install this or that program, instrument your code base and start prompting. No, it doesn't work that simple."
• Who moves fastest: Teams that have to move fast — startups — are a couple of steps ahead, and among enterprises the software companies lead. The banks, energy firms and agriculture companies where software is one unit among many are more conservative by default.

2. Nobody pushes back at the company level; individuals do, and they have a reason

His approach to AI skeptics is more generous than most.

• Where the resistance lives: No official company or unit-level refusal in his experience — management is pushing hard — "but at the same time, some pushback and the skepticism and pessimism can happen on individual level. And I fully understand that."
• Why it's usually fair: It's nearly always a bad experience from the past. Someone tried a tool, got mediocre or wrong code, and stopped. That's enough to demotivate anyone from experimenting further.
• His only ask: "Hey, just give one more try." Two things changed — a genuine quality leap on the reasoning model side since around late last autumn, and a harness around the model that's evolving extremely fast.
• The compounding argument: "If we compare just one single prompt, the same prompt today and half a year ago, towards different models, it's already big difference. But if you add proper code-base instrumentation on top of that, you might change your opinion as an AI skeptic."
• Who converts: The engineering mindset, not the credential. "Sometimes there are people without formal software engineering education, but what differentiates them is curiosity."

3. Code is a secondary artifact; the harness is what you build

The reframe he wants technical leadership to communicate explicitly.

• The admission that has to come first: That software development is genuinely different now, and there's no going back to how it was before 2021 and 2022. "This is, by the way, a serious step, just to admit that it's different."
• The second admission: That roles and responsibilities changed with it — and that building the AI native infrastructure (prompts, instructions, custom agents, agent skills) is not side work to do when you have spare time. "Vice versa, it should be the core of today's engineering job."
• What doesn't change: "Developers are here to solve issues, to build value for the company. With AI, without AI doesn't matter." He cites Jensen Huang on engineers existing to solve problems and to find new ones worth solving.
• What does change: "If you felt yourself more like coder — someone told you implement this algorithm and you just implemented this in the code — that kind of job most likely will disappear." Fine as a way to start a career and build muscle memory, not as a destination.
• The line to put in front of your team: "Your primary artifact, what you build as a software engineer, is the harness around it." And say out loud that nobody is being measured on lines of code.

4. Budget for enablement, not just for licenses and tokens

The investment argument, aimed squarely at leadership.

• What executive sponsorship isn't: "I'm not talking here about some extra pizzas for after work hours for all kinds of AI hackathons. No, it doesn't work that simple."
• Why the CEO has to care: "If there is a super passionate technical lead but the CEO is not somehow interested in making this company AI native, it will not fly."
• The competitive argument that lands: Everyone can buy the same licenses. "What makes a difference is your specific skill set, your specific harness level you build around these generic tools."
• The line item people forget: "Please reserve some extra dollars, work hours for proper enablement of your team." Reserved time for developers to upskill, deliberately, on the schedule.
• Why it never ends: "There is no time point when you say, okay, now I'm educated developer. If you apply the same techniques, skills that you gained maybe half a year ago, if you do not evolve this, you are just yesterday's developer."

5. The AI superheroes team is an anti-pattern

The organizational mistake he sees teams make with the best intentions.

• The pattern: Concentrating AI expertise into a small squad. "Team of superheroes who can solve anything with AI, whom you say, if you have something to do with AI, just go to these folks."
• Why it fails: "It's wrong because it's not scalable." Those people can be excellent at prompting and skills and still have no chance of being experts in every part of the product.
• What the AI actually needs from you: Domain knowledge. "It's not always only instructions about technicalities. You would also include some knowledge about the domain you build project for."
• The consequence: Domain knowledge is becoming more crucial for developers, not less, and it can't be locked to specific individuals. "Better make sure that you provide good environment for everyone, every developer in the team to go and upskill in AI and try AI in action."

6. Two new job titles: context engineer and agent ops

Not mandatory for every team, but he sees both appearing.

• Context engineer: Alongside software, DevOps, database and QA engineers. Their job is understanding the domain deeply enough to know which parts of that knowledge are relevant to feed an agent in a given situation.
• Why they need seniority: "They need to really understand well how context flows into all these agentic loops." This is a technical role focused entirely on enabling other developers, which is what separates it from the superheroes anti-pattern.
• Agent ops: The counterpart to DevOps. Most developers today are, at best, aware of agentic AI and ask an agent to build things for them. "Might sound like a very progressive way of doing things, but in reality, this is kind of, so 2025."
• What the leading edge actually does: "The most advanced developers who are fully committed to agentic stuff, they orchestrate multiple agents." Workflows where agents hand work to each other, with human-in-the-loop intervention designed in — he's seen sophisticated agentic workflows implemented as GitHub Actions YAML with extensive pipelines.
• Why it becomes a role: Those pipelines need building and maintaining, they keep evolving, and they're full of edge cases. And it's brand new: "something that maybe didn't exist as knowledge, as skill just a year ago."
• His ask of technical leads: Look seriously at the time, effort and skills this consumes. "Don't think about it as something separate on top of software engineering skill. It's becoming the centerpiece skill and the rest is surrounded."

7. What an AI harness actually is

The clearest definition in the episode, built up in layers.

• The model alone isn't enough: Even the most capable model "is not that efficient if there is no proper system prompt that kind of triggers the conversation." Real commercial-grade system prompts are extensive and highly detailed.
• Tools make it agentic: "Even a super sophisticated system prompt, super sophisticated large language model is nothing without actions, without tools." Editing files, searching the web, reaching your hosting provider to deploy. "Agents need to act."
• The internal layer: That's what ships with a commercial tool — the system prompt, the agentic loop, the built-in tools. Copilot, Claude Code and the rest all have a strong one.
• The external layer: What you build between those generic capabilities and the specifics of your project. That's where the differentiation lives.
• Start small: "A good custom, specifically tailored agent skill is already your first step for having your external harness." From there, tools that manage agent memory, or small pieces of software that stream project knowledge from a wiki or Confluence into instructions agents can consume.

8. The VS Code team's real advantage is dozens of small internal tools

His key takeaway from Microsoft Build, and the most concrete version of the harness argument.

• The insight: "Just an incredible number of small and medium-sized developer tools they build for themselves." Not complex things — things that automate one more step of the work.
• A worked example: Tooling to triage GitHub issues efficiently. "You can imagine how many issues, pull requests, VS Code team has every single day because this is open source and the whole worldwide community contributes. They would not survive without some automation here and there."
• Who builds them: Largely AI-assisted themselves.
• The pattern behind it: Experimentation, with the tolerance for failure that implies. "If you know that your experiment will succeed, it's not an experiment." Explore in multiple directions and accept that most approaches get retired.

9. Treat agent skills like dependencies, not like loose markdown

The governance problem nobody budgets for, and the tool that fixes it.

• What he keeps finding: "Completely polluted code repository with dozens of agent skills. No one remembers where they came from. No one did any kind of quality check. No one can tell you is this skill in use or not." Same for custom agents nobody uses and nobody claims.
• The mental model: "Think about all these dev primitives as a substantial and very valuable part of your code base and apply the same techniques you apply to your code — collaboration, versioning, everything."
• The analogy that lands: "You check your package.json from time to time to understand, okay, do I have full control of what's going on there? Apply same thinking for all these tools."
• The tool: APM, an agent package manager, from the same author as the Agentic SDLC Handbook. "Instead of saying, yeah, there's just a couple of markdowns in my .github or .agents folder — no, you now have this agent package file like YAML where you list all these packages" and declare where each one comes from.
• The enterprise wrinkle: Pulling skills from a third-party repository isn't necessarily the recommended option. "You might want to organize your own repository of all these tools and pull these assets from your safe private internal boundary."

10. How to become an AI native engineer

His answer to the individual version of the question, in three moves.

• Stay uncomfortable: "Keep being curious. Without that, it will just not fly. Never say, now I know enough. You better open new tab in the browser and search for what happens in this field yesterday while you were busy coding."
• Understand what those markdown files are: "They are markdown and just text for us humans, but for agents, they are executable code." Once that lands, everything else follows.
• Stop working one-to-one: "Think about yourself not one to one working with AI agent, because with today's level of tools, you can be an orchestrator of multiple agents running simultaneously." It's harder than it sounds and rarely works on the first attempt.
• The summary line: "Admit that your primary asset that you produce is a layer of context. And then AI agents can generate the code for you" — properly controlled and guardrailed by you.

🧠 What I Learned

• AI adoption in enterprises fails on process and change management, not on tooling — licenses and instrumentation are the trivial part.
• Pushback almost never comes from the company; it comes from individuals who had one bad experience with an early tool and reasonably wrote it off.
• The counter-argument isn't rhetoric: reasoning models improved sharply in late autumn, and code-base instrumentation changes the output on top of that.
• Technical leads have to admit publicly that the job changed, and that building prompts, instructions, custom agents and skills is core work rather than spare-time work.
• Executive sponsorship means budget for enablement hours, not hackathon pizza — and it has to reach the CEO or it won't fly.
• Everyone can buy the same licenses, so your harness and your team's skills are the only differentiators left.
• A dedicated AI superheroes squad doesn't scale, because AI capability without product domain knowledge produces worse instructions.
• Context engineer and agent ops are emerging as real job titles: one curates what goes into the agentic loop, the other builds and maintains multi-agent orchestration pipelines.
• A harness is the system prompt plus tools plus loop; the internal layer ships with your vendor, and the external layer you build is where the value is.
• The VS Code team's edge is dozens of small internal tools, many AI-assisted, doing things like triaging a firehose of community issues.
• Agent skills rot exactly like unaudited dependencies — version them, own them, and manage them with something like APM.
• Orchestrating multiple agents, rather than chatting with one, is the current dividing line between competent and leading-edge.

💬 Favorite Quotes

"In many cases, this is not a technological problem, because tooling is here, licenses are here."

"It's harder to change rather than just, hey, just install this or that program, instrument your code base and start prompting. No, it doesn't work that simple."

"Sometimes there are people without formal software engineering education, but what differentiates them is curiosity."

"Your primary artifact, what you build as a software engineer, is the harness around it."

"There is no time point when you say, okay, now I'm educated developer."

"What makes a difference is your specific skill set, your specific harness level you build around these generic tools."

"Team of superheroes who can solve anything with AI — it's wrong because it's not scalable."

"Even a super sophisticated system prompt, super sophisticated large language model is nothing without actions, without tools."

"They are markdown and just text for us humans, but for agents, they are executable code."

"Admit that your primary asset that you produce is a layer of context."

🎯 Also in this Episode

• Deciding on his career the first time he saw a computer in the early 90s, then building commercial web solutions from the late 90s onward
• The mid-career switch from engineering to developer relations, triggered by discovering meetups and conferences after two decades of heads-down coding
• GitHub Copilot reaching the public before ChatGPT — his first ever prompt was in Copilot, because ChatGPT didn't exist yet
• Why he still builds side projects and demos every day despite not being part of Microsoft's engineering org
• Anthropic's Fable 5 landing in GitHub Copilot and Microsoft Foundry the day before we recorded
• Why failure stories matter as much as success stories when he compiles patterns across a hundred customers
• The reference companies he won't name, where the internal knowledge is genuinely ahead of any blog post or conference talk
• His learning method: submit a conference talk on something you're not yet an expert in, then be forced to go deep — a trick I use for exactly the same reason
• His closing bet that in a year we'll look back at today's tooling and find it charmingly primitive

Resources

More from Maxim and the tools mentioned:

• Maxim on LinkedIn — Where he posts most on AI native development
• Maxim on X
• Maxim on GitHub
• Maxim on Sessionize
• Agentic SDLC Handbook — The free online book by a Microsoft colleague that he uses as a guide with customer teams
• APM (Agent Package Manager) — Package-level management for agent skills and dev primitives, from the same author
• GitHub Copilot, Azure DevOps, Visual Studio and VS Code — The tools that make up most of his day

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 44 minutes on why AI adoption is change management, what an AI harness actually is, the external layer worth building yourself, the context engineer and agent ops roles, and how to stop your agent skills from rotting.

Whether you're trying to move a conservative enterprise team, arguing for enablement budget, or wondering what the next rung above "I use an agent" looks like, this one is drawn from a hundred companies doing it in parallel.

Happy orchestrating,
Dan