It’s not another boring AI series
I am taking a small break from our AI Explained series.
Not because I ran out of things to explain. That would be a dangerous lie. But because #noHypeAI has so much more into it than just explaining AI behind the scenes.
Today I want to share with you my secrets of How I use AI as a developer every day.
Not “AI will replace devopers – it won’t (I’m 95% sure at least).
Not “10x engineer overnight”.
Not “click button, ship product, retire”.
Just boring, useful stuff.
And honestly, that is where I’m really falling for AI.
This will be just part one, as I have a lot of small tricks I learned along the way, so make sure you follow me on LinkedIn to stay updated about news!
Plan-execute-test-repeat
One of my main rules is simple:
Plan with expensive model. Execute with cheaper one.
When I am starting something unclear, messy, or risky, I want the stronger model involved.
Architecture decisions.
Refactoring plans.
Understanding legacy code.
Breaking a vague problem into steps.
Finding hidden assumptions.
Reviewing trade-offs.
That is where I want quality.
But once the plan is clear, I often switch to a cheaper or faster model for execution:
Generate boilerplate.
Write tests.
Rename things.
Create mapping code.
Update documentation.
Apply the same pattern across files.
The expensive model is the senior developer I ask:
“Are we solving the right problem?”
The cheaper model is the very patient junior developer I ask:
“Please do this 27 times without getting bored.”
Both are useful. Just not for the same job.
Understand the differences between AI models
Not all models specialise in the same thing. I realised, that Opus or Sonet will be much better for planning, while GPT Codex can do your coding beautifully.
Yes, Opus is expensive, but this is where I need power, where I need reliability – once the plan is solid, anything cheap (or even run locally will do the job)
But those opinions differ, and even in AI era Reddit is not dissapointing (wink, wink).
Keep updating your AI instructions.
Your skills.md, agent.md, project instructions, coding guidelines, whatever you call them — treat them as living documents.
Not corporate wiki living documents, where “living” means nobody has opened them since 2021.
Actually living.
Every time AI makes a mistake that you do not want repeated, ask yourself:
Should this become an instruction?
Example from real development work:
I was working with legacy code.
There were no proper AI skills or project instructions defined yet.
The codebase had manyObsoleteattributes.
AI created a class. Later, I decided that class should move into a package.
A human developer would probably remove the old class, or at least ask what to do with it.
The AI did something very “AI helpful”:
It kept the old class and marked it as obsolete.
Technically reasonable.
Contextually wrong.
Classic.
So the fix is not just “please undo that.”
The better fix is to update the instructions:
When moving code into a package, do not leave duplicate classes behind unless explicitly requested.
If compatibility is required, ask first.
Do not add Obsolete as a migration strategy unless that is part of the plan.
After refactoring, search for old implementations and remove or update them.That is the real productivity gain.
Not one perfect prompt.
A system that gets slightly better every week.
What to include
Things I like to include in skills.md or agent.md:
Project rules
What patterns are preferred?
What libraries are allowed?
What should never be introduced?
What naming conventions matter?
How are packages structured?
AI is much better when it does not need to rediscover your architecture every 15 minutes.
Refactoring rules
Should old code be deleted, deprecated, wrapped, or migrated?
Should public APIs remain backward compatible?
Should obsolete code be removed immediately or only after tests pass?
This is especially important in legacy systems, where “clean up” can mean five different things and four of them are dangerous.
Testing rules
Which test framework do you use?
What should be mocked?
What should not be mocked?
Do you prefer integration tests, unit tests, snapshot tests, approval tests?
Do not just ask AI to “write tests.”
That is how you get tests that technically test something, usually themselves.
Definition of done
Build passes.
Tests pass.
No duplicate implementations.
No unused files.
No accidental public API changes.
No new warnings.
Documentation updated if behavior changed.
This one is boring. It is also gold.
Review checklist
Ask AI to review its own changes against your checklist.
Not “is this good?”
That invites a confident fairy tale.
Ask:
Does this introduce duplicate code?
Did you remove the old implementation?
Did any obsolete APIs remain?
Did you update references?
Are there migration risks?
What should a human review carefully?
Much better.
Understand the Codebase Before Touching It
One of the most useful daily tricks is asking AI to explain a new codebase before changing anything. And it doesn’t only apply for new joiners in the team. That is cool for everyone!
I usually start with the high-level architecture, then map the main user flows, and only then connect those flows back to the actual classes, APIs, database tables, queues, jobs, or external services involved.
Ag prompt I use A LOT:
“You are a software architect. Explain this codebase to me before we change anything. Start with the high-level architecture, then describe the main user flows, especially what happens from UI/API entry point to persistence or external services. Identify the most important classes, modules, dependencies, and boundaries. Then highlight risks, legacy patterns, duplicated logic, obsolete code, weak abstractions, missing tests, and places where future changes are likely to break something. Finally, suggest practical improvement points, but separate safe quick wins from bigger refactoring ideas.”
Or more specific-flow-oriented
“You are a software architect and senior developer. Focus only on this user flow:
[describe the user action, for example: user submits an order / uploads a file / resets a password]. Explain the flow step by step, from the first UI or API entry point to validation, business logic, persistence, background jobs, external services, error handling, and response back to the user. Identify the key classes, methods, database tables, events, commands, queries, and dependencies involved. Highlight hidden assumptions, edge cases, duplicated logic, obsolete code, missing tests, security risks, performance risks, and places where this flow is hard to change. Finish with a practical improvement plan: quick safe fixes first, then larger refactoring ideas.”
It is not perfect, but it gives you a working mental model much faster than randomly opening files and hoping the architecture reveals itself like a shy forest animal.
Some other small tricks
here, I’ll just put some other small, useful tricks.
Ask (even yourself) for a plan before code.
Especially in old systems. If the plan is bad, the code will be worse, just faster.
Ask AI to explain the current code before changing it.
If it cannot explain the behavior, it probably should not refactor it yet.
Use AI for “search thinking.”
Not just “find usages,” but:
“What other places might be affected by this change?”
“What naming variants should I search for?”
“What hidden coupling could exist here?”
Ask for risks, not only solutions.
AI is naturally eager to help. Sometimes too eager. Make it be paranoid on purpose.
Make it produce checklists.
Checklists are underrated. They turn vague confidence into concrete verification.
Keep prompts close to the repo.
If an instruction matters more than once, it does not belong only in your chat history. Put it where the agent can reuse it.
What it is all about
For me, daily AI use is not about replacing development skill.
It is about reducing the boring parts, catching more edge cases, and making better use of my attention.
The developer still needs to decide what is correct.
The developer still owns the architecture.
The developer still needs taste, judgment, and enough suspicion to survive legacy code.
AI helps a lot.
But only when you treat it less like magic and more like a very fast teammate who needs clear working agreements.
That is my version of #noHypeAI:
Use the strong model when thinking is expensive.
Use the cheap model when repetition is expensive.
Keep improving the instructions.
And never trust a refactor that did not delete anything.
Do you have anyt favourite tricks for effective AI usage of yours? Share them in the comments!
Yo might be also interested in cutting costs, if so make sure to see our previous article on cost-savings. And stay tuned for pt.2.
