Want more content like this? Sign up for our monthly newsletter.
Hi, my name is Shirley Zhang, and I’m a Master’s student studying Computer Science at Stanford University. Before Stanford, I finished my undergraduate degree at Northwestern in three years. I did not graduate knowing exactly what I wanted to do. I mostly knew that I did not know enough yet to succeed in the tech industry, which was one reason I decided to pursue a master’s degree.
That feeling of not knowing enough followed me for a while, especially in the new age of AI, where the lines of what “knowing enough” means keep blurring.
I received my internship offer relatively late in the school year after a rough year of recruiting. By then, I was studying for finals and had already booked my flight home. The start date meant precisely three days between my last final and the start of my internship.
I remember thinking: maybe this will be the experience that proves whether I can succeed in tech.
That is a lot of pressure to put on one internship. It is also a very effective way to make yourself nervous before you have even started.
What I learned over the following months was not that self-doubt disappears when you gain more experience. I had assumed that eventually I would know enough, the uncertainty would settle, and I would feel like I was standing on solid ground. Instead, I learned how to keep moving while self-doubt was still present—and while the ground underneath the project was moving too. I learned to work through ambiguity, communicate before I felt perfectly prepared, use AI as a thinking partner, and keep building anyway.
Chaos is not evidence that you are failing
On my first day at Ironclad, I was asked to help build a proof of concept for Touchless Contracting and prepare a demo within a week.
Touchless Contracting is a joint Deloitte and Ironclad initiative exploring how agent-enabled workflows could remove manual steps from contracting while keeping people involved where judgment is still required. The long-term vision is an intelligent agent capable of orchestrating intake, drafting, negotiation, approval, and execution while remaining native to existing Ironclad workflows.
Our initial proof of concept focused on a smaller question: could an orchestrating agent understand a natural-language procurement request, identify the appropriate agreement type, gather the missing business context, and guide the request toward the right contracting workflow? The challenge wasn’t simply generating a contract—it was determining what information mattered, what decisions could be automated, and where human judgment should remain essential.
Over the course of the internship, I helped build an orchestration pipeline that progressively enriched requests with missing context, classified them, retrieved relevant organizational knowledge, and generated structured outputs that downstream contracting workflows could act upon. What made the project especially interesting was that the product itself was still evolving while we were building it.
I had limited instructions and a short timeline. The project also involved conversations with Deloitte and later expanded to internal alignment across teams. As we learned more, priorities shifted, assumptions had to be revisited, and features we initially considered central became less important while smaller ideas unexpectedly became core parts of the experience. The problem wasn’t simply to build something that worked—it was to continuously redefine what “working” meant as our understanding of the product evolved.
At school, I was used to receiving a well-defined assignment, completing it, and turning it in. In a startup environment, the assignment itself can evolve while you are working on it. Earlier in college, I probably would have viewed those changes as rework—as evidence that I had built the wrong thing. During this internship, I started viewing them differently. Every iteration narrowed our understanding of the problem space.
I kept waiting, at first, for things to settle—for the point when we understood the problem well enough that I could simply build the answer.
One phrase my mentor and Ironclad’s Head of AI, Mingsheng Hong, used has stayed with me: we are building on moving ground.
That phrase gave a name to what I had been experiencing. Instead of waiting for the requirements to settle, I learned to build systems that could evolve alongside them. Product priorities would shift, new constraints would emerge, and conversations would reveal assumptions we hadn’t considered. Rather than resisting that uncertainty, I started treating it as part of the engineering process.
I also want to give Mingsheng a special shoutout here. He was pivotal in teaching me to do my own thinking while helping me turn abstract questions into concrete next steps. When I brought him a vague concern, he rarely answered it for me immediately. Instead, he helped me clarify what I was actually asking, what information was missing, and what I could do next.
Looking back, I realized I actually thrive when the ground is moving. Ambiguity gave me room to explore, ask questions, and help shape the problem instead of only implementing a solution that had already been decided. I stopped seeing changing requirements as signs that we were failing and started seeing them as evidence that we were learning. Engineering wasn’t simply implementing requirements—it was helping discover what those requirements should be.
Ask questions, but do not outsource your thinking
One of the most common pieces of advice given to interns is to ask questions. I agree with it, but I think it is incomplete.
The deeper advice is: keep asking questions—but make sure they’re the right ones.
When our proof of concept began to gain momentum, the work expanded beyond building a demo. We had to align internally with teams working to bring agentic workflows into Ironclad’s main platform. Those teams already had product directions, design decisions, technical constraints, and priorities of their own. My role was not to arrive with a new system and overwrite what they had designed. It was to understand where our work could support theirs, identify what was genuinely reusable, and be careful not to overstep the ownership of teams that had been thinking about these problems longer than I had.
That required a different kind of engineering than I expected. I had to ask questions such as:
- What problem is this team actually trying to solve?
- Which assumptions are still open?
- Am I offering useful support, or am I accidentally creating another competing design?
No one hands you a complete map of an organization on your first day. People may explain their titles or immediate responsibilities, but they do not always explain how their work connects to everyone else’s, what tradeoffs they are carrying, or why a seemingly small decision matters to their team.
Asking was only half the work. I also had to build my own context and intuition by listening carefully, reading existing materials, following decisions across conversations, and observing how people approached the problem. I had to reserve some of the thinking for myself—to develop the mental muscles that let me distinguish a real gap from something I simply did not understand yet.
At first, I was hesitant to speak up. I was the intern, and I worried that I would ramble or bring up something off topic. I thought I needed to understand everything before I could contribute meaningfully.
Over time, I learned that contributing does not require having complete certainty. It requires paying enough attention to identify what is unclear, what information is missing, and what might be useful to the people around you. It also requires knowing when a question is the right next step and when I should spend more time thinking before asking someone else to explain the answer.
I also had to learn when to share what I was working on, with whom, and in what format. A meeting might be the fastest way to resolve a question, but people can quickly lose the surrounding context afterward. Sometimes the best follow-up was a short message. Sometimes it was a written summary, a diagram, or a Loom video walking through the current state of a project.
Communication was not just reporting what I had done. It was making sure other people could understand the problem, the decisions, and the remaining uncertainty without having to reconstruct everything themselves. I stopped thinking of communication as something that happened after the engineering work—it was part of the engineering work. When a project spans multiple stakeholders, everyone develops a slightly different mental model of the system. Workflow diagrams, Loom videos, and design summaries became just as valuable as code because they helped everyone move together.
And when I did not know where to begin, I learned to ask Glean. Not to avoid thinking, but to make the next question sharper. I was slowly realizing that the answer to uncertainty was not to somehow know everything. It was to get better at figuring out what I needed to know next.
Use AI as a thinking partner, not an autopilot
Another major part of my internship was learning how to work with AI more intentionally.
Working at an AI-forward company changed my relationship with AI. Ironclad’s work is fundamentally connected to helping people work more efficiently, so AI was not only something I was building—it was also part of how I tracked context, automated repetitive tasks, and thought through problems. I had to learn when AI would genuinely help and when it would only add noise. Knowing when to use AI became just as important as knowing how to use it.
I found the most useful role for AI wasn’t producing final outputs—it was helping me think more clearly about what the output should be. Before meetings, I used it to organize what I already knew and identify better questions. Afterward, I used it to connect new information back to the broader project and challenge my own assumptions. AI became less of an answer engine and more of a thinking companion.
One joke I made throughout the summer was that I wished I could upload everyone’s consciousness into Glean so I could ask questions without scheduling another meeting. Obviously that isn’t possible, but it reflects something I came to appreciate: engineering isn’t limited by access to code—it is often limited by access to context. AI helped lower that barrier by making it easier to organize information, reconnect ideas, and arrive at conversations with better questions.
Using AI effectively also meant staying engaged. Early on, I was uncomfortable watching AI generate code I didn’t fully understand. Eventually I realized I could spend that time investigating related questions, documenting decisions, or planning the next step. AI wasn’t replacing my work—it was changing where my attention was most valuable.
The biggest lesson I took away was that AI should expand my thinking, not replace it. The more capable these tools become, the more valuable it becomes to know what deserves human judgment, curiosity, and responsibility.
Building an AI product also changed the questions I asked about AI itself. Instead of asking whether a response looked correct, I started asking where it came from, what assumptions it relied on, how uncertainty should be communicated, and where people should remain involved. Those questions became especially important on a project centered on legal workflows, where explainability and trust matter just as much as automation.
In a way, this was another version of building on moving ground. AI could help me move faster, but moving faster only mattered if I was still paying attention to where I was going. The more capable these tools become, the more important it becomes to know which questions—and which decisions—should remain ours.
The questions that move you forward
When I started this internship, I wondered whether I was prepared to succeed in the technology industry. Somewhere in the back of my mind was the question I had been carrying for years: Did I know enough to succeed?
I do not think I am leaving this internship with a permanent answer.
I realized I had been asking myself the wrong question.
Throughout college, I kept wondering, Do I know enough to succeed? It sounds like a useful question, but it isn’t one I can actually answer before I begin. I think part of me imagined there would eventually be a point when I had learned enough, the uncertainty would disappear, and I would finally feel like I was standing on solid ground.
But the ground does not stop moving.
During this internship, that question slowly changed into smaller ones.
What do I need to understand before I take the next step?
Who should I learn from?
What assumption am I making?
What can I build today that helps us learn something tomorrow?
Those questions had answers. More importantly, they moved the project—and me—forward.
Maybe that is what building on moving ground actually means. Not learning enough that uncertainty disappears, but learning how to move through it. I started this internship asking whether I knew enough to succeed. I’m leaving with a different question: What do I need to understand next?
The ground will keep moving.
I think I know now that I can keep building on it.
Ironclad is not a law firm, and this post does not constitute or contain legal advice. To evaluate the accuracy, sufficiency, or reliability of the ideas and guidance reflected here, or the applicability of these materials to your business, you should consult with a licensed attorney.
