A friend of mine recently took on their first internship as a design engineer. I just started my first role as a senior design engineer. I wanted to capture my workflows and experience with AI-assisted engineering and make it clear what I think is a good path forward.

And you’re already ahead of the curve – because everything about AI engineering is a loop.

The Loop is Everything

If you’re doing design engineering, one of the things that makes your role really special is that you’re focused on these really tight loops: build something, show it to someone, collect feedback, and then be in a position to iterate.

Be a little bit extra customer obsessed. Some companies have an unfair advantage when they have people who aren’t only shipping, but looking to connect with their customers and staying accountable to an outcome in a very short amount of time. It’s not the only way to do the work, but for some types of work, it’s a very powerful way to add momentum to the team.

So you’re looking for opportunities to:

• Build stuff
• Get in front of users
• Be accountable to their experience
• Iterate

Start Close to Home

The best place to practice this is to start small and start somewhere at home. Building tools for yourself—date night planning apps, meal planning apps, personal tools—can be really fun. You can show your friends and family, they can try it out, you can collect feedback and start to build up that taste and get a sense for when those loops work well and when they don’t.

There’s nothing wrong with being ambitious and wanting to build a business, wanting to monetize it, and all those things. That’s great. But just be intentional about what you’re trying to do. Are you trying to learn how to be a design engineer? Are you trying to learn how to build and ship things? Or are you trying to learn how to start a business? These are different skills.

Start Small (Smaller Than You Think)

Building an app is a lot of fun and a great way to force yourself to go through and learn all these different ideas and techniques. But you could start a bit smaller and build a tool.

Remember: we want to get really good at the loop. A tool can just be an index.html file. Even the apps I build often start off as an index.html file—just a simple webpage that I can generate which demonstrates the concept I’m thinking of in a way that I can play with and quickly share with someone to see how they use it.

My first thing I ever made was a bookmarklet, which is just a snippet of JavaScript. What you’re doing is you’re reducing that loop. You’re still learning about the loop, and you’re able to iterate fast.

When You’re Ready to Build an App

Building an app is trickier than building a tool because now you start to think about things like deployment, where you’re deploying it, databases—and those things can be overwhelming.

The best way to approach it: look for starter code.

Head out to repositories on GitHub and find code that’s already working. Bring that into your Cursor environment or Claude Code and say to it: “Help me get this running on my computer.” Play around a bit, experience it, ask questions, build up a mental model of how it works. Then you’ll be in a position to start modifying it.

If you just ask Cursor or something like that to generate something from scratch, often there’s not enough context and you might get subpar results. It’s a lot easier for an AI tool to modify working code than to create heaps of new code from scratch.

Some repositories I would recommend: check out Next.js examples. There are lots of examples—you can probably find something that gets you pretty close to what you want to start with.

Find a Mentor

Easier said than done, but try to find a friendly person in your life who’s got some experience in programming, or even just someone who’s a few rungs ahead of you in this stuff that you can talk to.

Express your interest, explain what you’ve been doing, and ask them directly if they’d be willing to help.

Real engineers understand that the highest thing they can be doing is making sure the next engineer is a bit faster, a bit safer, and a bit more informed. You’ll know you found the right one if they say yes.

Planning for Bigger Loops

Now you’re doing a bigger loop. You’re building something out, you’ve got this idea, you’re really fleshing it out. You need to be doing bigger loops with better planning.

Planning is becoming pretty standard in AI-assisted development. Sit down and use the plan tool in Cursor or Claude Code and make sure you’ve got a really clear list of what you need to do. Ask lots of questions about the plan to make sure you’ve got a good mental model of how it’s going to do things.

A good plan is:

• Small, incremental steps that are easy for a large language model to follow
• Clear about how to verify each step as you go

This is a key skill: breaking down user needs, turning those into requirements, and making sure the requirements are easy to verify when it gets down to code. Your capability to do this will depend a lot on your experience writing tickets and working in a developer team. But it’s something you can practice. You just need to start.

Use Version Control

Use some kind of version control to make sure that as you work on your project, you can work on branches and do draft work.

My workflow: I’ll make a draft branch for a feature I’m working on and ask my agent to write stuff to the draft branch. I can rely a lot on the agents to use Git on my behalf, and you’ll learn about Git very quickly this way.

Once the branch is in a good state, I’ll ask Cursor or Claude Code to create a new branch for me which implements the same feature without any regressions and has a nice commit history. This becomes a very nice log of the feature and makes it easy for the codebase and Git repo to stay maintained.

Using Code at Work

One of the main reasons I’m pointing people to try and build stuff close to home is that it can be quite challenging getting onboarded into your workplace code.

Depending on where you work, the culture of your engineering team, and the age of your codebase, things can be complicated. If you’re working at a reasonable-size company, your codebase could be 10 years old. There might be lots of steps to work through to get set up, and it’s frustrating for engineers—and very frustrating for design engineers who might not necessarily have all the background and skills to get up and running.

There’s this idea that design engineers can come in and make some quick PRs doing CSS tweaks and text copy tweaks. But it really depends on the maturity of your codebase, if there are tests, who’s going to be able to support you implementing them.

One way to get around this: build tools or maybe look at writing code that you can put in index.html files, or even building small apps in new repos that you can use to demonstrate ideas. Build up momentum and your relationship with the engineering teams to navigate how you deploy to production.

This is a bit of an industry-wide shift. Lots of engineers are thinking about this. If it’s hard for you to understand the codebase and get set up, it’s probably going to be really hard for a coding agent. There’s going to be downward pressure on the whole industry to improve and make this easier. You can feel the shift coming—making these apps easier to work on is going to be important.

Use High Quality Models

You really, really need to use high-quality models. Opus 4.5 is what I recommend to everyone getting started.

Yes, it’s more expensive than something like Sonnet 4.5. But you’re worth it. In some ways, it’ll probably save you a lot of tokens because it’s going to do smarter things and help fill in your knowledge gaps.

I really encourage you to use the latest, highest-capability model. Right now, that’s Claude Opus 4.5. It’s really great because it’s very agentic, very good at basically engaging with your tools, building up good context, and creating context for you as well. I’m frequently impressed by the quality of its code and its quality of analysis. That’s the model I would recommend.

I usually describe positive AI experiences through this framework of the three Cs. Context, Consent and Capability.

Context: the model has a reasonable context window size and can understand and keep track of things within its window Consent: being able to identify risks and problems and giving the user accurate descriptions and seeking consent when it was required. Capability, being able to reason effectively,  multimodal, act agentically by using tool calls to build its own context

Opus 4.5 floored me because it excels at all 3 cs and it introduced me to a fourth C.  Consistency.  It does all those things consistently, all day – till you get tired and go to bed. Like you can’t go back to the previous gens because you just know that you’ll just see sparks of what 4.5 is.

Compare Yourself to Your Past Self

In the age of AI, it’s very easy to get caught in hype cycles and feel like you’re getting left behind or that you need to hurry up. People keep saying things like “it’s so over” and “you’re not gonna make it.”

But here’s the thing: if you’ve gotten this far reading this article, you’re on the very edge of this. You’re so ahead of the curve. Don’t worry about it. Just take it slow.

Focus on the loop. The loop of iteration. That’s going to be the through line for all of this. People who understand the users, understand divergent and convergent thinking, and can navigate the loop—that’s what’s going to be meaningful long-term for this work.

A Quick Note on iOS and Android Apps

Hold off doing native app development when you’re just getting started.

I know it’s very tempting to dive into iOS and Android development. I would say hang out just a little bit longer—the tooling for it is not quite there. Building up capability in web is really great because you can experience the agent loop a lot easier.

If you’re ready for a challenge, by all means build an iOS app. But if you’re interested in doing hardware stuff, consider other options. Pretty much any other kind of hardware is going to be easier to build upon than mobile apps.

The Path Forward

This isn’t about becoming the best engineer in the world overnight. It’s about finding your rhythm, building things that matter to people close to you, and getting really good at the loop: build, ship, collect feedback, iterate.

Start with an index.html file. Build a bookmarklet. Clone a Next.js example and modify it. Find a mentor a few rungs ahead. Use version control. Use the best models. And most importantly, stay focused on getting things in front of users and iterating.

You’re not behind. You’re right on time. Welcome to the trail.