← Video Library · AI Strategy
AI Doesn’t Work? You Skipped This Step
Published May 23, 2025 · 25 views on YouTube
Key takeaways
- Treat a new AI tool like a new hire: it needs the same onboarding, environment access, and documentation a human teammate would get.
- A messy or undocumented development environment causes an AI system to go down rabbit holes instead of contributing usefully.
- AI systems are natural-language systems, so they need READMEs, architecture docs, and requirements written down, not tribal knowledge.
- A written 'definition of done' (acceptance criteria, tests, observability) should be repeated in your prompts so AI-generated code follows it.
Why do AI tools like Copilot fail to deliver results at companies?
Teams plug in a tool like Copilot, expect magic, and then find people aren’t shipping faster or using it much. According to Howdy.com co-founder Frank Licea, this happens because companies skip the same onboarding, environment setup, and documentation they’d give a new human hire — and an AI tool without that context can’t perform any better than a new employee would without it.
What does it mean to onboard an AI tool like a team member?
It means giving the AI system the same emphasis on setup and training a person would get on their first day. For developers, that starts with the development and deployment environment: it needs to be mostly automated and ready to go, so the AI can see deployment and environment scripts, understand where the database and caching systems live, and have enough context to actually contribute.
What documentation does an AI system need to be productive?
The same documentation you’d hand an intelligent senior engineer in their first week: READMEs, internal wiki or Confluence articles, and requirements documents. AI systems are natural-language systems, so they depend on language that describes how the architecture works. Without it, an AI system goes down rabbit holes and can’t contribute the way teams expect — whether that’s writing automated test cases, refactoring, or other work.
Why does team culture matter for AI-generated code?
Because the same standards used to hold humans accountable have to be written down and fed into the AI’s prompting process. If a team has a written “definition of done” — acceptance criteria, unit tests, integration tests, observability and metrics strategies — that same instruction set needs to go into the prompts given to tools like Cursor or Gemini. Without it, generated code won’t reliably follow the team’s engineering practices, because the code and architecture have to actively support those standards for the AI to pick up on the cues.
Full video transcript
Talk about treating AI like a team member, with onboarding, with training — what does that look like in practice? It’s a machine, it’s not a human. How should companies, from your perspective, be approaching AI adoption and treating an AI tool as its own team member?
Yeah, so this is something that we drill into the engineers that hop onto the Howdy platform, because we’re always keeping them up to date on the latest tools, techniques, and procedures for interacting with these emerging trends and technology. It essentially means that when you’re starting to adopt AI tools in really any kind of environment, but in particular a remote environment, you have to have the same emphasis on onboarding process and training that you would a person. And that sounds funny, but what we’ve seen is that many teams fall over when they just plug in a new AI tool — for example, Copilot — and they expect magic, especially management. Like, “I got everybody Copilot, and for whatever reason we’re not shipping faster, people aren’t using it as much. What’s going on?” We’ve seen this time and time again. You need to set up the right environment and context and guidance for adopting these kinds of AI tools.
So, some concrete tips and examples: the environment. If you’re talking about developers — maybe there’s an analogy for your teams — but for developers, it means the development environment needs to be set up and ready to go and mostly automated in the deployment code. So the deployment environment, the development environment needs to be set up in a way that’s mostly automated, because if you need an AI system to contribute to it, all of that stuff — it needs to also set up the development environment, and it needs to be able to see your deployment scripts or your environment scripts, read them to understand: okay, the database is over here, the caching system’s over here, and now it knows enough to actually contribute to your projects. So the same way you would need that on your first day — if you have all of those things set up correctly on your first day a developer joins, and at the click of a button they have the environment ready to go — it’s very similar for an AI system. They also need that environment to read.
It also needs, or these systems also need, all the documentation and the context content. So if you’re a developer and there’s not a lot of documentation about how things are architected or how you do things on your team — and those things your developer just has to figure out over the course of months or weeks — then an AI system is going to go down rabbit holes. An AI system is not going to contribute the way that you need it to, right — either automated test cases or refactoring or whatever. Your teammates can’t even do it. And these systems are natural language systems, so they need the language describing how your architecture works and stuff. Things like READMEs, things like Wikipedia articles or Confluence articles, requirements documents — all the things that you would feed to an intelligent senior engineer to get them productive in their first week. Well, guess what? You’ve got to have that for an AI system too. And a lot of people just think it’s black magic and it’ll work, and unfortunately it doesn’t, and then they get lackluster results.
And then the last one that I’ll mention is, I guess, the culture about the work is also super important. So if there’s a document describing “this is our definition of done” — our definition of done for the humans is that we have acceptance criteria, we have unit tests, we have integration tests, we have observability and metrics strategies, or whatever it happens to be — and you have that written down and it’s repeated over and over again, and the code and the architecture support all those things — guess what? Those are the same sort of instructions and prompts that you have to give to Cursor or Gemini or whatever model you happen to be using, or whatever IDE you’re using, so that when it does generate code, or touches files and this and that, it behaves in the same way. It won’t do it without it. You have to be good about the software engineering and the culture in your prompting systems and your documentation, so that the AI’s generated code can pick up on those cues and generate things with that context.