Stop Treating AI Like a Tool. Start Onboarding It Like a Developer.
I’m a senior level engineer and programmer that runs a small tech business, and most of my work falls into two categories.
- Solo development, or
- Collaboration with clients.
Now, inevitably, AI has become a hot topic in those circles, and as a someone who’s been moving towards using AI as a coding tool, the reactions I get are mixed.
Some, like me, have fully embraced it. Others are using it in the most minimal capacity so they can say they use AI, and others are downright stubborn and have sworn them off.
And while those reactions are noted, that isn’t what I want to talk about. I want to talk about how developers and programmers are treating AI when they adopt them.
Don’t worry. I’m not here to criticize. I am here however, to offer some guidance and a few recommendations from a rather unique perspective.
See, having to alternate between being a solo dev and collaboration, (and being a programmer that gets onboarded quite often with various clients), has offered me some insight about the use of AI.
I do believe that a lot of developers are approaching AI completely backwards.
Most people treat AI like a prompt machine. They open it up and immediately start throwing instructions at it like:
“Write this function.”
“Fix this bug.”
“Generate this module.”
And sure, it works, but when you use AI that way, you’re basically treating it like a smarter autocomplete, and leaving a lot of capability on the table.
If you want AI to actually accelerate your development workflow, then you have to change how you think about it. You have to stop treating it like a tool and start treating it like what it effectively is – a developer that just joined your team.
When I made that change, I wrote more code and got more programming done in 3 days, than I did in 3 months. Using AI the right way becomes a force multiplier.
That said, if you’ve ever onboarded a developer before, you already know the first thing you don’t do is throw them into production code and say “go build something.”
You bring them up to speed first, you let them learn how you think, and you let them read through code you’ve written.
You explain decisions, philosophy, preferences, and all of the little things that experienced developers know actually shape a codebase over time.
So, if someone asked me today for advice on working with AI as a developer, I’d probably tell them to approach it in four stages.
Not as prompts, but as onboarding.
STEP ONE: Let the AI learn you.
Before I let AI write a single line of code, I spend time letting it understand how I work.
I let it analyze projects I’ve built before. I answer its questions about how I structure things. I explain how I approach problems, how I document code, how I make architectural decisions.
Things like:
- Do I prefer verbose commenting or minimal comments?
- Do I optimize for readability or cleverness?
- How do I structure modules?
- What do I do after writing code – patch notes, changelogs, documentation?
These details matter more than people think. Great developers don’t just write code, they follow processes and philosophies that shape the systems they build.
Once the AI understands those things, I usually have it generate something simple but powerful – a rules file that becomes the anchor for working with me.
It captures coding conventions, documentation expectations, architectural preferences – the way I think about software.
Every session starts from that baseline, so the AI isn’t guessing how I work – it knows.
STEP TWO: Let the AI learn the project.
Once the AI understands you, the next step is helping it understand the project.
And this is where a lot of developers rush ahead too quickly. They start prompting for code before the AI even understands what the system is supposed to do, but AI isn’t as “out of the box” as people assume.
Instead, spend a little time explaining the project like you would to a developer joining your team.
- What is the goal?
- What should the finished system look like?
- What environment will it run in?
- Who will use it?
- What constraints exist?
- and more…
Just like I did with the rules file, once we’ve talked through those things, I have the AI generate a scope document for the project – not because I desperately need another document, but because forcing the AI to summarize the system tells me whether it actually understands it.
Then I create another document that ends up being even more valuable over time. I call it a working conventions file.
This isn’t about the project itself, but about how the AI and I collaborate
It records things like how tasks are requested, how code updates are presented, when improvements should be discussed before implementing them, and so on.
If you’re working across multiple projects like I do, this becomes a living document that evolves over time as you discover little nuances in how you and the AI work together.
STEP THREE: Start with small tasks.
Once the AI understands you and the project, don’t jump straight into building features.
Start small and let it analyze the existing codebase and summarize what it sees. Then have it identify things like syntax errors, unused variables, or unreferenced functions.
Ask it where the code could be improved, and discuss those ideas before implementing anything.
What you’re doing in this phase is letting the AI gain familiarity with the environment, exactly the same way a new developer would.
After I’ve had those conversations, I usually ask a simple question: “Based on what we’ve learned so far, is there anything we should add to the rules or working conventions?“
Then we update those documents.
It sounds small, but the collaboration improves immediately.
STEP FOUR: Build a living task list.
Once the AI understands you, understands the project, and understands how you work together, that’s when things get interesting… and fun!
Have it generate a living task list for the project. This becomes a prioritized backlog of things that could improve the system as well as tasks that need to be done.
I’m talking about:
- Refactors
- Features
- Performance improvements
- Cleanup tasks
- And more
Because now that the AI now understands the full scope of the project, it can actually prioritize those tasks intelligently, then you can start working through them together.
From your task list, let it complete a few tasks while you guide it and review the output, correct mistakes, adjust the approach, etc.
It’s just like mentoring a developer.
Over time the collaboration becomes faster and more accurate because the AI now has context for how decisions are made in your environment.
That’s it. Those four things will make a world of difference.
Some Additional Insight…
If you’ve been a senior developer or worked in tech leadership for a while, this whole process should feel familiar, because it’s just developer onboarding.
It’s the same process every engineering team uses when someone new joins a project.
Now, regarding the reactions to AI, this little insight of mine actually leads to something else that’s important to understand.
Programming has always evolved.
Once upon a time programming meant flipping switches on machines.
- Then it was wiring plugboards.
- Then it became feeding punch cards into computers.
- Then assembly.
- Then higher level languages.
And eventually we reached a point where programming became synonymous with writing code manually – to me, that definition was always temporary.
Writing code is just one task in the much larger job of building systems.
Even if AI wrote every line of code in a project tomorrow, developers would still have to plan systems, design architecture, debug failures, test behavior, deploy software, and maintain everything over time.
The craft of programming was never just typing code.
What’s happening now is that the typing part is becoming less important, and programming is shifting toward something else – orchestrating intelligent tools to build systems.
And honestly, that’s not a downgrade; it’s the next evolution.
If you’re a senior developer, you probably already see it happening and most of us understand that writing code was never the whole job anyway.
But if you’re earlier in your career, this shift matters. Why?
Because the worst identity you can build right now is, “I write the best code.“
A much better identity is this, “I design systems and orchestrate intelligent tools.“
That mindset will age extremely well.
When it comes to environment, personally, after experimenting with a few different setups, I’ve settled on Codex and VS Code for my development environment. I don’t think Anthropic is quite there yet, but I’ll keep an eye on them and continue to test.
That said, when you onboard AI properly and let it learn how you think, something interesting happens – it stops feeling like a tool, and starts feeling like you’re working with another developer.
And that’s when things start moving fast.