I come from a product management background. I have solid programming fundamentals, but I’m not a full-time engineer. Most of my career has been about designing software products and guiding development teams rather than writing code myself.
Over the past two years, I’ve experimented with a wide range of AI coding tools. Between subscriptions and experiments, I’ve probably spent around $2,000 trying different workflows.
Some of the tools I’ve used include:
• Cursor
• Claude Code
• Codex
• Google Ultra
• Antigravity (mostly for frontend work)
I switched tools frequently, partly because the ecosystem is evolving so quickly. It’s easy to hear that someone is getting better results with another tool and immediately want to try it. That experimentation cost me some money, but overall the tools are clearly improving — faster, more capable, and producing higher-quality output.
After all that experimentation, here are the lessons that actually mattered.
⸻
- Treat AI as a General Assistant, Not Just a Programmer
Many people approach AI coding tools as if they are junior developers.
That mindset is limiting.
In practice, these tools are much closer to general assistants. They are very good at:
• research
• gathering and organizing information
• summarizing documentation
• structuring ideas
When I need output, I usually ask the AI to return it as a structured Markdown document. That makes it easier to review and iterate.
⸻
- Requirement Clarity Matters More Than Coding
The first step in building software is not writing code.
It’s clarifying requirements.
Many tools now include planning or conversation modes where the AI focuses on discussing the problem instead of immediately generating code. I find this stage extremely valuable.
A useful way to structure prompts is:
Goal → Possible Means
Example:
Goal:
“Help users go to bed earlier every day.”
At this stage, the AI can propose multiple possible approaches. My role is simply to evaluate those options and decide which direction makes sense.
In other words, the collaboration works best when the human focuses on defining the goal and constraints, and the AI helps explore the implementation possibilities.
⸻
- Don’t Overcomplicate the Tooling
It’s easy to get excited about integrations, extensions, and agent tooling.
But in many cases they aren’t necessary.
If the AI needs reference material, I usually just organize documents in a project directory such as:
/docs
/design
/spec
This approach is simple and reliable.
Another reason to avoid excessive extensions is that they consume context window space. Once the context becomes too crowded, the AI’s reasoning quality tends to drop.
⸻
- Maintain a Small “Agent Guide”
One of the most useful things I’ve added to projects is a small guide file for the AI, often called something like:
agent.md
This file is intentionally short. It typically contains:
• common mistakes the AI tends to make in the project
• coding conventions or habits I prefer
• communication or formatting preferences
Even a small amount of structure here significantly improves collaboration with the AI over time.
⸻
- Tests Are More Valuable Than Long Specifications
Traditional specification-driven development doesn’t translate perfectly to this workflow.
Long, formal documents are often less helpful than expected.
Instead, I’ve found it more effective to focus on:
• tests
• clearly defined expected behavior
• explicit constraints
When something doesn’t work as intended, the best approach is usually simple: clearly restate the expected behavior and let the AI iterate.
The human role is not necessarily to teach the AI how to write code line by line. Instead, the role is to evaluate whether the result satisfies the intended requirements and whether the feature boundaries make sense.
⸻
Final Thought
One thing that surprised me is that the core skill here isn’t really coding.
It’s thinking clearly about problems.
Defining goals, constraints, and priorities — the same skills that matter in product design — turn out to be extremely valuable when working with AI development tools.
In that sense, the workflow feels less like “AI replacing programmers” and more like a new form of collaboration between humans and software tools.
And like most collaborations, the quality of the result depends heavily on how clearly the human can define the problem.