A professional engineer, I finally started using AI

I am a professional engineer with 20 years of experience and have fully embraced AI coding in the last 9 months. Wanted to share my real world learnings regarding scaling AI coding in the form of what not to do. By scaling I mean: (1) working in a team, i.e. more than 1 person involved in a project, (2) dealing with larger complicated production systems and codebases. While some of the learnings will apply for solo and hobby builders, I found them to be more important for professional development.

1. **Do not allow short-cuts on quality.** Absolutely no shortcuts here for the sake of output, period. Intentionally keeping “quality” broad - whatever the quality bar is in your organization, it must not go down. AI is still not good at producing production-grade code. From what I have experienced, this is the #1 reason people may get resentment to AI (or to you by extension). Letting some poorly written AI-slop into the codebase is a slippery slope, even if you start with seemingly benign weirdly looking unit tests.
2. **Do not work on a single task at a time**. The real and significant productivity win of AI-coding for professional engineers comes from building things in parallel. Yes, that oftentimes means more overhead, sometimes more pre-planning, more breaking down the work, more communications with product people, etc. Whatever it takes in your org, you need to have a pool of projects/tasks to work in parallel on. And learn how to execute in parallel efficiently. Code reviews may (will?) become a bottleneck, rule #1 helps with that to some extent.
3. **Do not stick with the knowns**. The field is changing so rapidly, that you should not just rely on what you know. E.g. I use quite a few non-hype tools because they work for *me* \- Junie from Jetbrains as AI agent, Devplan for prompts and rules generation, Langfuse for AI traces (although that one may be picking up popularity), Makefiles for building apps, Apple as my main email provider (yeah, the last 2 are kind of unrelated, but you got the point). If you cannot make Cursor work for you, either figure out how to make it work really well, or explore something else. The thing is, nobody yet figured out what’s the best approach and finding that one tool that works for your org may yield huge performance benefits.
4. **Do not chat with coding-assistant**. Well, you can and should chat about trivial changes, but most communications and anything complex should be in the form of prepared PRDs, tech requirements, rules, etc. Keeping recommendations and guidelines externally allows you to easily re-start with corrected requirements or carry over some learnings to the next project. Much harder to do when that context is buried somewhere in the chat history. There are a lot of other reasons I found for reducing chats: AI is better at writing fresh code than refactoring existing (at least now), reduces context switching, less often get into rabbit holes, teaches you to create better requirements to increase chances of good outcome from the first try. Much of it subjective, but overall I have been much more productive once I figured out that approach.
5. **Do not be scared**. There is so much fear-mongering going around now that AI will replace engineers, but AI is just a tool that automates some work and so far all automations people invented need human operators. While it is hard to predict where we will land in a few years, it is clear right now that embracing AI-coding in a smart way can significantly increase productivity for engineers *who care*.
6. **Do not ship that AI-slop**. See #1. Really, do not let unvetted AI-written code in, read every single line. Maybe it will be good enough some time in the future, but not now.

I have previously described my whole flow working with AI here - [https://www.reddit.com/r/vibecoding/comments/1ljbu34/how\_i\_scaled\_myself\_23x\_with\_ai\_from\_an\_engineer](https://www.reddit.com/r/vibecoding/comments/1ljbu34/how_i_scaled_myself_23x_with_ai_from_an_engineer/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) . Received a lot of questions about it so wanted to share main takeaways in a shorter form.

What are the main “not-to-do” advice you found that you follow? Also would be curious to hear if others agree or disagree with #4 above since I have not seen a lot of external validation for that one.