AI Reflections of a New Grad Engineer

Author: Claire Yang, Checkout Engineering, Affirm

Motivations

I joined Affirm in August 2025 as a new grad engineer through the Early Career Engineering Program. That same month, Affirm adopted Cursor, and since then much has changed from trying Cursor for the first time, to onboarding onto Claude in February, to now having AI integrated into almost every part of my workflow.

As I’ve talked to more people about it, it’s been interesting to notice how widely experiences vary among those with different years of experience B.C. (Before Claude). Likewise, I imagine being a new grad this year will feel different than when I started just one year ago. I want to share these reflections to invite conversation around how working with AI differs across career stages and how that can influence the way we adapt to it. I hope that this can also inform the way we onboard and guide new engineers into an AI-integrated workplace.

Summarizing My Experience

My own experience diving into the agentic tooling world has shifted a lot through the year. While I don’t think these dynamics are necessarily unique to new engineers, I do think they are more pronounced when you have spent less time working without AI. As I relied more on automation, it often felt like I was walking a tightrope between embracing that acceleration and recognizing that if I want to build my own foundational capabilities, I can’t rely on tooling to the same extent as a more experienced engineer.

Timeline

In school, I viewed blatant use of AI as an embarrassing thing — I took pride in being able to do things myself, and to be fair, generative AI tools were still quite bad at the time. My AI coding usage was limited to prompting ChatGPT or similar AI chatbots, but these tools lived outside any codebase and could only help me with concepts or isolated pieces of code.

Once I started working, AI tooling was rapidly improving, and I became quite content using Cursor where I would scope my work into prompts, accept changes line-by-line, and then put it out for review. I accepted a shift into a new AI-enthusiastic workspace and did my best to learn how to make it useful to me.

In February, Affirm’s AI retooling week introduced me to the agentic powers of Claude Code, unlocking a new level of workflow automation that I had never experienced before. AI could write the code, test it, review it, respond to feedback, and integrate with other platforms, and suddenly tasks that had previously required me to stop and think between each stage could now be strung together into large automated workflows.

Reflection 1 — My cognitive effort shifted to post-implementation

When I shifted my workflow to rely more heavily on Claude, I promptly (no pun intended) realized that evaluating AI output was becoming the most essential skill in my workflow. While parts of this process could be automated, I still had to continue building my own understanding and judgment.

I imagine that pre-AI, much of a new engineer’s productive struggle occurred before and during implementation. It meant asking many questions to a human mentor, scouring reference PRs, and being knee-deep in the code piecing together what needs to be done and where to put it before even starting on a solution.

As Claude guided my planning and took over implementation, I worried that I was skipping those steps to my learning. I was constantly reminded that it takes a much lower threshold of understanding to convince myself that I understood a solution proposed to me vs. to actually complete it myself.

As a result, I noticed my cognitive effort pivot significantly to post-implementation. I spent roughly 80% of my time in this stage because even if I thought I understood a task, much of the implementation would be unfamiliar to me, and each AI explanation I received was also unfamiliar to me. My time and mental effort funneled into thinking through code after AI had completed it (tracing through my own diff, asking the AI questions about why it did things a certain way, responding to bot and human comments, etc.).

I wish I had realized sooner that this was essentially the same expected “struggle stage” that came from being a new engineer, only now living in post-implementation, and that this was also an appropriate stage to be asking more questions and admitting (to a human) where I was unsure of my AI.

Reflection 2 — My building outpaced my learning

By March, I had gotten much more comfortable and creative with my new friend Claude Code. My terminals were color coded, my Buildkite tests were being monitored on a loop, and I was working on a large project that I was tackling many steps at a time thanks to new levels of multitasking unlocked by AI.

However, even though I reviewed the code I produced, I still found myself making incorrect judgments. I would constantly question my Claude, but I didn’t always have the experience to know when its guidance was leading me down the wrong path.

My PRs were getting many comments, each of which I would human-review, then cross-reference with AI, and then occasionally spend way too long trying to understand the AI’s recommendations.

It became clear that there were many places where AI could not replace human guidance for a new engineer. It didn’t always reason well about where new things should live, didn’t have an intuition for readability, strayed from established team patterns, added long unnecessary comments, and would gleefully write more and more code, even when the same information could be derived from existing logic. These were just some examples I gathered from review comments on one of my March PRs.

Of course, these were not fixed limitations of AI, and its capabilities have continued to evolve. But the broader challenge still stands: using AI effectively depends in part on knowing what context to provide and what questions to ask, both of which draw on existing familiarity with a team’s work and engineering best practices.

Learnings

This leads me to the learnings I would share with my February-self and any early career engineer feeling similarly to what I wrote above.

Learning 1 — Understanding code through review is increasingly replacing understanding code through writing

While it’s entirely true that you should own your AI’s output and are responsible for not putting out slop, it is a skill in itself to be able to recognize slop. In AI-first workflows, learning to review AI-generated code is becoming an entry-level necessity, arguably as important as learning to write code. And if entry-level expectations are shifting toward generating code, then guidance should also shift to help engineers learn how to review their AI-generated work.

So how does a junior engineer build their ability to verify AI’s output?

A few ideas from my experience:

1. Ask questions on your own PRs if you are unsure of something (e.g. “Is this the right place for this function to live?”, “How does our team use this field — am I correctly understanding what it does?”)

• This could also be achieved by setting up a live code review with a mentor to ask questions about your own generated code, just as you might have sought help pre-AI in writing the code
• A side effect of encouraging AI code generation is that, even though much of the mental work lives post-implementation, a new engineer may be tempted to ask fewer questions. Once the code exists, they may feel expected to understand and own the output rather than share where they are still uncertain

2. Seek out engineering best practices and team patterns to use as reference points

3. Do code reviews without AI assistance to build your own ability to think critically about new code and ask questions to the author

4. Check with a human mentor before entering what may be an unnecessary AI rabbit hole

• For example, asking “This is what Claude suggested, is it worth looking into?” rather than forcing yourself to investigate every path that Claude opens up when it may not be relevant

Learning 2 — Invest in pre-implementation clarity to reduce post-implementation confusion

I’m sure we’ve all been in a situation where we are approaching an unfamiliar problem, ask our AI for help in understanding or planning the work, then realize later that it led us astray. While this is likely a universal experience, the risk exists pretty much everywhere for someone new to a team or to engineering. Trying to accelerate with AI too early can then end up adding work rather than reducing it.

What could investing in pre-implementation clarity look like?

1. Onboarding should prioritize a mini-curriculum of code and tooling walkthroughs

• Tracing through code by hand used to be an unavoidable part of figuring out what to build. Now, AI can piece together the relevant files for a task without you having to even open your IDE. But the value of understanding your codebase hasn’t diminished, so in the New AI Era, perhaps that exploration (and the time to do it) needs to become intentionally built into onboarding
• As one example, my mentor and I recently did a (no-AI) codebase walkthrough to create an updated diagram of our API flows. Even though it was slower than asking AI to draw it, tracing the code together was both more interesting and gave me a clearer mental model that immediately benefited both my own work and my understanding of my teammates’ work

2. Seek clarity from a human before turning an unfamiliar problem over to AI

• Humans still have AI beat when it comes to making complex information digestible for other humans. Syncing with someone familiar with the area can help you form a reliable understanding that you can then use to direct AI more effectively rather than relying on AI to build that understanding for you

3. Ensure deliberate planning before beginning implementation

• This includes clarifying the problem, understanding constraints and risks, and verifying assumptions, with or without the help of AI

Learning 3 — Allow your uncertainties to be visible, and slow down to address them

A major pitfall for a new engineer in the AI Era is masking uncertainties with too much AI-proofing (meaning, running every question and uncertainty through AI and regurgitating its response). There are definitely benefits to vetting your work with AI, such as catching glaring inaccuracies early and lowering the burden on human mentors, but there is also value in making your learning process visible, as this creates opportunities for others to correct your thinking or share their own tips and tricks.

How can you avoid this pitfall?

1. During PR reviews, limit the time you spend ping-ponging with AI on each comment you receive

• As a new engineer, you will make incorrect judgments and hold misconceptions with or without the help of AI. I would rather have just explained what I thought I understood, been wrong, and gotten corrected by my human mentors rather than going back and forth with AI trying to avoid “responding wrong”
• From a mentor’s perspective, I imagine it’s also harder in the era of AI-assisted work to tell where a new engineer could use guidance. Allowing these areas to surface rather than AI-proofing them away could help make those learning opportunities visible

2. For skills you have not yet built (and would like to build), allow yourself the time to practice them before relying on automation

• Maybe this is controversial as it raises the question of what manual skills will still matter in the New AI Era, but that could be its own blog post
• One example is learning how to reason through metrics. Let’s say an alert fires indicating that a key metric has dipped below its expected threshold. AI-agent-of-choice can now quickly interpret the alert configurations, read the graphs, and recommend a next step, but relying on automated triage right away makes it difficult to build your own instincts. Then when you are expected to use those instincts to verify AI’s conclusions, assess a metric without AI available, or configure alerts yourself, you may realize you never developed them

The goal is not to avoid automation, but to ensure that it does not conceal the gaps that mentorship and deliberate practice are meant to address.

Closing Thoughts

Over my past year at Affirm, I’ve seen how thoughtfully used AI can expand what I’m able to accomplish. These new possibilities also invite a shift in how we approach mentorship and onboarding to support a changing entry-level skillset.

I feel really grateful for the mentorship I’ve had access to in my first year, both through the Early Career Engineering Program’s in-person mentorship and my team’s dedication to my growth. That support has helped me develop these learnings and think critically about how I should and shouldn’t use AI. At the same time, I believe that the “correct balance” is a personal choice, and one that will likely keep shifting as I move through my career and as tooling continues to evolve.

There are many open questions about what it will mean to learn engineering in an AI-integrated workplace, more than can be addressed in one post. If you have been ruminating over similar questions, feel free to reach out, and I would love to hear your thoughts.