AI Adoption Needs Practice, Not Another Tool Announcement

Alexander Reitz · May 26, 2026 · 11 min read

Coding AgentsAI

Giving people access to coding agents was the straightforward part.

The harder part started afterwards: getting engineers to open a real repo, give the agent enough context, and let it help with work that mattered. Real code. Real tickets. Real team pain.

At AutoScout24 Group, adoption was uneven in a familiar way. Some engineers were already deep into agentic coding. A larger group had tried ChatGPT or Copilot for small snippets. Another group had not really started yet, mostly because they were busy, skeptical, or did not know where to begin.

Tool access alone was not going to move the needle.

In the same series, my colleague Anderson Carneiro wrote about how we use live coding sessions to make learning visible across the engineering org. My colleague Dominik Bermühler wrote about how we are turning reusable agent workflows into a skills marketplace. This post is about the bit between those two: how we help teams do the reps until AI-assisted development becomes normal work, not a side experiment.

#The adoption problem

There is a version of AI adoption that looks good in a status update:

• The tools are enabled.
• A Slack announcement went out.
• A few demos were shared.
• Everyone is expected to try it when they find time.

Then the day-to-day work barely changes.

I wanted a more concrete target: engineers using AI while they work in the repo, not only in a chat tab next to it. Inside the IDE or CLI, with enough context to write tests, debug unfamiliar code, refactor the rough edges, and explain what changed before review.

We use a simple mental model for this:

• Level 0: not using AI
• Level 1: chat-style prompting for questions or snippets
• Level 2: using AI inside the development environment on real code
• Level 3: operating coding agents with repo context, AGENTS.md, and custom skills
• Level 4: orchestrating multiple agents across larger work

The important part: we are not trying to turn every engineer into a Level 4 agent operator overnight. That would be unrealistic, and honestly a bit annoying. The main target is to move engineers from Level 0 or 1 to Level 2. Once someone uses AI on real code and sees where it helps, the more advanced patterns become much easier to teach.

#Platform Docs: pragmatic on purpose

The first piece is a self-paced learning path on Platform Docs.

For readers outside AutoScout24 Group: Platform Docs is our internal documentation hub. The Platform teams use it to give builders one place for onboarding material, platform engineering standards, security and reliability guidance, AI tooling docs, troubleshooting notes, and the practical “how do I do this here?” answers that should not live only in Slack.

For AI, the role of Platform Docs is simple: one place for the baseline.

That sounds less event-like than a hackathon, but it matters. Engineers need one place that answers the basic questions:

• Which tools should I use?
• How do I set them up?
• What is approved for my role?
• What data can I share with the model?
• How do I start using this on a real task?
• What does a good prompt look like in our codebase?

We made the guidance opinionated. That was intentional.

When a tool space moves this fast, people do not want a shopping list of options. They want a sane default. Use this for coding. Use that for product work. Avoid random tools unless there is a real business reason. If something is unclear, ask before installing it yourself.

The training path has a mandatory baseline and optional deeper modules.

Module 1: Setup and foundations. Everyone gets the tools working and completes a first AI-assisted task. This is the floor.

Module 2: Context engineering and feature building. How to give the agent useful repo context, write better feature prompts, use AGENTS.md, and build something end to end.

Module 3: Testing, debugging, and quality. Use AI for the work people often postpone: test coverage, bug investigation, SonarQube issues, and unfamiliar code.

Module 4: Advanced workflows. Planning, implementation phases, subagents, larger refactors, and workflow management.

#Short videos from engineers

The videos are created by engineers for engineers. We look for developers who are already using these tools on real work, record short sessions with them, and share those centrally. That makes the examples more relatable: same repos, same tickets, same constraints.

Most videos are around ten minutes. Long enough to explain one thing properly, short enough that someone can watch it between meetings. The more stable material lives in docs. Videos are for workflows and demos. Scripts are reviewed before recording, so the learning path does not become a pile of random screen recordings.

There is also a small culture shift in this. People who would not have called themselves trainers are now recording useful demos, improving their home setup, buying a better mic, and sharing what they learned in a format others can reuse. That sounds minor, but it changes the quality of internal knowledge sharing.

Still, training has a limit. I have seen engineers understand the idea in a video and still hesitate when the agent confidently goes in the wrong direction because they forgot to mention a constraint.

That is why we built the AI Coding Assistant Experience Day.

#The AI Experience Day

The Experience Day is a reusable hands-on format for teams.

The premise is simple: your team brings real pain points, we bring the structure and facilitation, and everyone spends a day building with AI.

There are three phases.

1. Brainstorm. A few days before the hack day, the team spends one hour surfacing real problems. The prompt is not “what AI use case should we invent?” It is much more practical:

• What repetitive task do you keep doing manually?
• What has been sitting in the backlog because it is tedious?
• What part of your workflow annoys you?
• What would you build if the cost of building it was close to zero?
• Is there a codebase you have been avoiding because it is hard to navigate?

That framing matters. AI adoption gets much more concrete when it starts from frustration.

2. Hack. On the day itself, people pick a problem, form small groups or work solo, and build. A facilitator stays close enough to unblock people, but not so close that it turns into a classroom. The goal is to get hands dirty.

3. Show and tell. At the end, teams show what they built and what they learned. A failed attempt counts if the team can explain what happened. “This did not work, and now we know why” is still useful.

This is not a competition. No judging, no prizes, no polished demo theatre. The point is to create the first real experience where people use AI on work they recognize.

#What teams build

The strongest ideas are usually not glamorous.

In the first boards we saw ideas like:

• an AWS FinOps agent for cost scanning and alerts
• automated sprint reports
• AI-assisted debugging for pipeline failures
• MCP servers for Platform Docs
• repo-specific AGENTS.md files
• generated tests for services with low coverage
• scripts for repetitive setup or operational tasks
• documentation for code nobody wanted to touch

One example from my own team surprised me. They built a skill that creates an interactive training page inside a repository. The agent reads a complex service, turns the structure into a guided HTML walkthrough, and ends with a small quiz. Pass it and you get a tiny certificate that you understood the service. It is not the kind of thing we would have planned in a normal training backlog, but it solved a real problem: the team had knowledge gaps in a complex repo and needed a better way to onboard people into it.

None of that is synthetic training material. It is the normal backlog of things engineers know would help, but rarely get enough focus time for.

For me, that is the useful shift. AI lowers the cost of unglamorous work. Once the cost drops, teams can finally attack a category of work that usually loses against feature pressure: cleanup, tests, docs, onboarding, small tools, better runbooks.

The facilitator role is mostly scope control. Some ideas are too big for a day. Some are too small to teach anything. The trick is to find a slice that can be demonstrated by the afternoon.

“Rewrite the whole service” is too much.

“Use AI to understand the service, document the current flow, and refactor one painful module with tests” is a good one-day target.

#The rules we repeat

The advice we give during the day is deliberately basic.

Start with a clear prompt. Tell the agent what you are building, what the repo looks like, and what “done” means.

Work in small steps. Ask for a plan first. Then implement piece by piece. Big vague prompts produce big vague failures.

Give context. Point the agent at the ticket, the repo, existing patterns, and AGENTS.md. Grammar matters less than useful context. A messy braindump is often better than a polished but empty prompt.

Do not fight bad output. If the agent goes wrong, stop and redirect. Manually patching bad AI output while pretending the agent is still helping is one of the easiest ways to waste the day.

And failure is allowed. This part is important. Some tasks are bad fits for the current tools. Some repos have missing context. Some ideas collapse once people try them. Part of the goal is to learn where the current boundaries are and how far a team can push the tools before the workflow stops making sense. That is still useful. It prevents magical thinking and makes the next attempt sharper.

#What we learned so far

Setup friction kills momentum. If someone spends the first two hours fixing credentials, the day is basically gone. The setup module and pre-checks are not admin overhead. They are part of adoption.

Real problems beat generic exercises. People care more when the output could remove something annoying from their actual week. A generic workshop exercise may teach the tool, but it rarely changes behavior.

Managers matter more than expected. If an Engineering Manager treats AI as a side hobby, the team will too. EMs do not need to become the strongest users, but they need enough hands-on experience to coach properly. That is why we are also planning an EM-specific Experience Day around Jira refinement, PR reviews, 1:1 prep, planning, and writing.

The first win is the hardest. After someone has used an agent to build, debug, or refactor something real, the conversation changes. They stop asking whether AI is useful in abstract terms and start asking where else it fits.

Training completion is not adoption. Watching a video is easy to track. It is also a weak signal. Better signals are harder but more honest: IDE and CLI usage, repos with AGENTS.md, teams using AI in retros, engineers sharing prompts, and actual workflow changes.

#How the pieces fit together

No single format carries this alone.

The live sessions create visibility and community. Engineers see real workflows from other teams, including the messy parts.

The Platform Docs create the baseline. People know what to use, how to set it up, and where the boundaries are.

The Experience Day creates practice. Teams apply the tooling to their own work while the support is close by.

The skills marketplace captures reusable patterns. Once a team finds a useful workflow, it can become a shared skill instead of another private prompt in someone’s notes.

The manager track is meant to keep it from fading after the initial excitement. Adoption has to show up in 1:1s, retros, onboarding, and engineering growth conversations. Otherwise it stays optional in the worst way: everyone agrees it matters, but nobody owns the behavior change.

#The honest part

This is still challenging.

The tools change fast. Some content will age. Some teams will move faster than others. Some engineers are skeptical for good reasons. Measuring real adoption is also harder than counting course completions.

But the direction is clear.

AI-assisted development will become a normal engineering capability. Not because every demo is impressive, and not because leadership says so, but because the cost of many software tasks is changing. The teams that learn how to use that well will move differently.

Our job is to make that shift practical.

Not another announcement. Not another abstract strategy deck. Give people the tools, the docs, the examples, and then a full day to use AI on something that actually bothers them.

That is where adoption starts to feel real.