This as-told-to essay is based on a conversation with Anni Chen, who has worked in Amazon software engineering for about three-and-a-half years. It has been edited for length and clarity. Business Insider has verified her employment history.
AI helped me code, but more importantly, it helped with turning it into products. It’s the combination of grasping AI and translating it into scalable products that helped me get promoted faster.
I started off as a Software Engineer I, an entry-level role, in 2022. I was in the recommendations team working on serving recommendation widgets.
About two years ago, I started working on AI products on the side. That became huge and eventually spun off into its own team, which I’m a founding engineer of.
I was promoted in the recommendations team to Software Engineer II, and then I got promoted in the current team to senior engineer.
I focus on what we call memory, which powers personalization in generative AI experiences across Amazon.
AI writes 95% of my code
I started using AI as a side project to generate engaging titles for recommendation widgets when ChatGPT and Claude emerged. I saw how powerful it is in generating something really creative.
I started thinking: whenever I have a question or I want to code something up, I’ll just ask AI for help first before I attempt it.
I saw that the solution it came up with was leveling up my own code, and it helped me code more, too. Now I would say almost 95% of the code authored by me is written by AI.
I’m not just using AI to code; I also integrate AI’s output into products. I need to have a deep understanding of how AI works, what works well, and what doesn’t.
I have to be open and receptive to new models and tools coming out that can help with product iterations and make products better.
I work as a tech lead on large-scale LLM-driven systems in production environments, so I have a front-row seat to how AI-assisted workflows behave, not just in prototypes but under real-world scale and cross-team collaboration.
Top tips for vibe coding
The first tip is understanding the inner workings of LLMs and where they might fail.
LLMs are pre-trained — they’re trained on a large corpus, and it’s a probabilistic game. It’s followed by supervised fine-tuning, so the model will answer based on the structuring of a question and the answering format. Lastly, it’s followed by RLHF — reinforcement learning from human feedback.
By understanding these three steps, you can know, for example, when the LLM will not understand what you’re talking about, and when it needs domain knowledge from you. You will know when to use a new window or why hallucinations happen.
By understanding the limitations of the context window, you know when to break problems down. You will learn how to follow the structure to break things down into lower levels, and then you slowly focus on each component and generate.
By understanding the inner workings, you also know that you have to explain things to a peer. If you don’t explain in detail, it will default all those assumptions to the most common pattern, but that might not fit your use case.
My second tip: Think before vibe coding.
If you check the answer first, then your thoughts will be swayed by the answers. Compare your thoughts versus the LLM’s and see what the gaps are — what you didn’t know, and why the answer differs. From there, you know what implicit assumptions you haven’t told the LLM.
Thirdly, prompt for hard questions. Ask questions like what is the fallback when there is an error, or how this is going to scale? This is like a teacher asking a student, or a senior engineer asking a junior engineer to make sure the hard cases are covered. If you want the product to scale, think about it from day one and be conscious about asking those scaling questions.
Lastly, review and understand. Always review at each step, not just review after the whole code is generated. This ensures errors stop early rather than cascading all the way to the end, where you need to redo everything.
Creating wrong code is very dangerous. The presence of code makes people think, “Okay, this is good, it’s working.” But wrong code that enters production can cause more damage than the absence of functionality.
Understanding code is still important
You have to understand your own code. AI lowers the barrier to writing code, but not the responsibility for understanding it.
If something goes wrong and the code was committed by you, you’re the one responsible.
Imagine your code breaks in production, and you need to fix it, and you say, “I also don’t know, AI told me.” That’s not the correct way.
I don’t think we can entrust AI with such high-stakes tasks yet.
Understanding becomes easier with AI because it’s also a perfect learning opportunity. You can simply open another window and ask it to explain the concept.
If you ask in the same window about what it produced, it will explain only in that context. But you want to understand the concept more generally and see whether it makes sense to apply in this case.
Do you have a story to share about coding with AI? Contact this reporter at [email protected].
