14 Tips for Working and Developing With AI

Published on Jul 29, 2026, filed under development, ai. (Share this post, e.g., on Mastodon.)

When used well, AI is a great enabler and productivity multiplier (still, we need to advocate for ethical, sustainable, and responsible use). Personally, I use and explore AI tooling to develop and maintain websites and WDLC- and defense-related tooling, and do so every day. Here are some additional things I learned over the past months that have helped make me both more efficient and effective. Let’s dive straight in.

1. Stay away from your own turf. Rule #1 of professional AI use: You don’t use AI to produce what you’re best at. If you’re fantastic at HTML, you keep writing your own HTML code. If you’re a star CSS developer, you code CSS by hand. And as a JavaScript or TypeScript expert, you stay sharp by writing JS and TS yourself, too. Unless your main expertise isn’t sought anymore, you should keep honing it.

2. In some other cases, do it yourself, too: Especially with code review feedback, you may be tempted to pass it straight back to an agent. Don’t. Review the feedback, learn from it. Try to catch mistakes the AI may be making.

3. Prepare. Preparation is half the outcome. You provide context (files, folders), goal, constraints, examples, anything relevant to what’s to be built up-front. All this context is useful to provide you with a better result, faster.

4. Re-think agents files: The ground has been shifting here ever since research suggested AGENTS.md may have no to slightly adverse effects and that /init may not be helpful. Watch this space and potentially adjust your use of agent files.

5. Use “CLARIFY.” As per James Wilton in The AI Teaching Revolution, the following mnemonic can guide working with AI:

   1. Clarity: Be specific about what you want.
   2. Length: Specify how much detail you need.
   3. Adaptability: Ask for multiple perspectives or approaches.
   4. Role: Tell the AI what expertise to draw from.
   5. Instructions: Be clear about format and structure.
   6. Feedback: Build on AI responses iteratively.
   7. Yielding: Know when to step back and think independently.

   I’m sure you’ve heard of and applied some of this, and that you’ve also grown out of some of this by now, but what I like about “CLARIFY” is yielding—knowing when (and that) to step back eventually.

6. Ask to be asked questions: This is one of my favorites, guarding against hidden assumptions and being too confident in what I’m asking to be done: Ask to be asked for clarification, if anything is unclear. (I’m currently testing this as a brief instruction in my AGENTS.md—I’ll report back here if possible.)

7. Ask to evaluate the prompt: Consider asking the LLM for feedback on the prompt. I save this for high-stakes work and usually don’t need it, but have it in the back of my mind to fine-tune requests.

8. Try “psychological tricks”: Last year, in I Accidentally Made Claude 45% Smarter—Here’s How, “Ichiro” presented a few prompting techniques. I couldn’t observe any qualitative difference and wouldn’t be surprised if this doesn’t work (anymore)—but try it out yourself.

9. If needed, prompt the AI to focus on the material at hand: Dylan Davis has a good video about this, The 3-Rule Prompt That Stops ChatGPT, Gemini, and Claude From Guessing, explaining how you can work with a few short prompts to keep the AI from hallucinating specifically when analyzing documents.

10. Use AI for code reviews. As one of the greatest use cases for AI, use it for code reviews. Until I’ve found suitable non-US alternatives, I like to use CodeRabbit for reviews and got to appreciate GitHub Copilot as well, but occasionally also use a local LLM to review changes on branches. The number of times this has surfaced things I missed—in areas I’m not an expert in but still understand enough about what’s going on—is tremendous. I believe not using AI in code reviews, if only complementary, is actually reckless by now. And yes, I mean it. (Which still doesn’t mean we don’t need to change how we go about AI.)

11. Ask to code-review the AI’s own changes: Apart from using other AI tools to review one’s own and AI changes, it’s also an option to ask the same AI (or another instance of an AI) to review. I’ve identified a few issues and opportunities this way and while I prefer using other tools for these types of reviews, using the same AI is an option, too.

12. Trust but verify: Apart from your own head, also use other LLMs to probe and check results. Depending on the criticality and complexity of the task, this can be quick: Ask to provide a quick independent investigation and assessment of the problem, or have the solution double-checked.

13. Use AI for refactorings. Refactorings are another prime use case for AI, though the more complex the refactoring is, the more crucial it is to use a high-quality model. It’s also important to still oversee, test, and optimize both process and result, something I believe is useful to do in general.

14. Keep trying and evaluating tools: The market is still in motion, yet in the imperial West, US solutions get most of the attention. The former means that for both general and specific purposes, better solutions may emerge; the latter means that there are other players, too, notably Asian and European solutions. It absolutely behooves us to keep trying things out—I believe AI in the 2020s is an excellent opportunity, indeed, to build a “continuous evaluation” muscle. (For moving away from the US, project-ai.org has one helpful article on “building (US) AI independence.”)

_ I tend to make these posts speed-runs, and it’s hard to capture “everything.” That is, take these as spontaneous ideas to inform your own use of AI. As always, drop me a line if you have feedback (AI-critics are welcome—I’m with you—but are still asked to be constructive) or if you’ve written similar posts (which I might feature over at Frontend Dogma!).

About Me

I’m Jens (long: Jens Oliver Meiert), and I’m an engineering lead, guerrilla philosopher, and indie publisher. I’ve worked as a technical lead and engineering manager at various companies, including Google; I’m an open-source developer and a contributor to web standards (like HTML, CSS, WCAG); and I write and review books for O’Reilly and Frontend Dogma.

I love trying things, not only in web development and engineering management, but also with respect to politics and philosophy. Here on meiert.com I talk about some of my experiences and perspectives. (Please share feedback—interpret charitably, keep it friendly, but do be critical.)