Skip to content
May 1, 2026 · Taste Test

How to Think Like an Engineer

Vibe coding gets you a working first version in minutes. Going further, without AI breaking what already works, takes a systems mindset. Luis Sarmenta shares a tool-agnostic way to think about building with AI: be specific, break problems into components, and build up from small, well-understood parts. Demonstrated live by building a knitting app.

Presenter: Luis Sarmenta (Software Engineer, MIT PhD EECS) · Santa Clara University

Watch & slides

Talk recording

Watch on YouTube →

Slides

Open the slides →

The big idea

The talk opens with a story: Luis's son Joseph, not a CS major, vibe-coded a knitting pattern tracker. One prompt, five minutes, a working app. Then he tried to improve it, and AI kept breaking what already worked. The fix was not a better tool. It was thinking like an engineer. Here is what you take away:

  • See any app, problem, or system as a set of components: each with inputs, outputs, data and state, behavior, and connections to other parts.
  • Start with Why (goals and pain points, which only you can define), then What (features, components, scenarios), and let AI handle How (the code).
  • Write a clear design doc so AI gets your intent right the first time, and so you can understand and safely change what it builds.
  • Define scenarios and test cases (happy path, boundaries, failures, edge and race conditions) so AI can generate tests and fix its own code until they pass.
  • Apply the same mindset, spec, break down, build up, to anything, not just code.

The systems mindset

"Engineer thinking" comes down to three moves. They are tool-agnostic: they work whether you use Claude, Cursor, or whatever ships next quarter.

Move 1
Spec (be specific)
Describe what you want clearly and in order. Identify and remove ambiguity, so AI does not have to guess your intent.
Move 2
Break down (decompose)
Find the lists, steps, and parts, then their sub-lists, sub-steps, and sub-parts. Big problems become small, nameable pieces.
Move 3
Build up (compose)
Connect, encapsulate, and reuse small parts into bigger ones. Building blocks become components, then modules, then systems.

Why, then what, then how

Spec your project in that order. The key insight: the first part is yours, not the AI's.

  • Why (goals). Motivations, user journey, pain points, goals and non-goals, priorities, MVP. AI cannot tell you what you want or why. This is product-manager thinking, and it is on you.
  • What (system design). Features, components and how they connect, and scenarios (what if?). This is where engineer thinking makes the most difference.
  • How (methodology). Platforms and hard constraints. AI does the rest: the actual code. It is much better if you understand it too.

Worked example: a knitting app

Luis turns Joseph's knitting tracker into an engineering exercise: start from why, shrink to the smallest useful core, spec the parts, then build back up.

The why is the knitter's journey and pain points: losing count of nested repeats, forgetting which step you are on after a break, wanting to plan time. The MVP strips the full pattern tracker down to its smallest useful core: a stitch counter, just a number with Up, Down, and Reset. Then you build back up toward the full tracker.

Speccing the stitch counter as components

  • UI: a Count display plus "+", "-", and "0" buttons, each wired to an input below.
  • Count Manager: inputs Up, Down, Zero; output Count. Behaviors written IFTTT-style: on Up add 1, on Down subtract 1, on Zero reset, on change output the value.
  • Persistent Storage: a sub-component holding CurrentCount so the value survives quitting the app.
  • Scenarios to test: happy path (6 then Up is 7), boundaries (cannot go below 0; remembers the last value on restart), failures (corrupted storage resets to 0), and race conditions (simultaneous presses resolve sanely).

With that spec written down, AI can build the system for you, across web, iOS, and Android, generate tests for your scenarios, and fix its own code until the tests pass. The design doc, not the prompt, is the bulk of the engineer's work.

Try it yourself

Three exercises from the talk, in increasing order of ambition.

1. Build the stitch counter

Warm-up: spec to working app

Paste the component bullet lists from the slides into a doc, then ask Claude to build from it. You get a working counter (web, and optionally iOS and Android) plus generated tests, all traceable back to the spec you wrote.

2. Build the full knitting tracker

Build up from the MVP

Go beyond the counter: multiple levels of counters for nested repeats, letting the user track by needle or by round, and importing patterns from text, PDF, or an image with AI. Same method, more components.

3. Build the Chopsticks game

Apply it to something new

Chopsticks is a two-player counting hand game (attack, split, and the "remainder over five" rule). Spec it as components, then build it to play locally, remotely, or against an AI opponent.

Going further

Part of the AI Kitchen Taste Test series at Santa Clara University.
Questions? klukoff@scu.edu · Full schedule.