A Summer of Building Stuff

Today, four teams are starting the summer at Stevens Institute of Technology’s School of Business with the following core mission: build stuff with real-world value, with AI as a full partner in the process. This is the beta test of our Build Studio. In the studio we will work with partners in industry, government, and civil society to build products, services, organizations, and communities that (I know it sounds corny, but it’s true!) make the world a better place. The beta test, if successful, will lead to a set of course offerings, and will be followed, in the fall, by a build sprint (a business-y hackathon), video/audio content, and an advisory council.

One of the impetuses for doing this is that increasingly our partners in industry are asking for graduates with hands-on experience. Some of them say—“we’d like to hire recent graduates, but ideally we need people with at least three years of industry experience.” Welp, creating recent graduates with three years of industry experience is mathematically impossible, but we’ll do what we can to make sure our college kids graduates with as much practical experience as possible.

In many ways I think this is just a continuation of a long-term trend of individuals needing to take on more responsibility (and cost) for their education to become employable. I think it is problematic in many ways to optimize education too much towards the labor market, but I think part of what is happening here is also that we are moving from an emphasis of “knowing stuff,” or even “doing stuff,” to “building stuff.” I don’t think this stands in contradiction with the traditional goals of a liberal arts education—to become a thoughtful, well-read citizen who can engage with social and economic life in a full and rich manner. Rather, I think the capacity to envision social, technical, and economic realities and then bring to bear a full set of capabilities to realize those visions is a central capacity that young (and old) humans need to develop and sustain.

Build Culture

Hence, the build studio is not just a mechanism for developing new cool AI-enabled gizmos, it is also a vehicle for creating what I call a “build culture.” Such a culture has four components: build constantly, develop an entrepreneurial mindset, embrace experimentation, and center humans Let’s talk briefly about each of these in turn.

The four components of build culture

The first component, “build constantly,” is a mindset where you are constantly looking at things in the world that don’t work, or that could work differently, and imagine what you might build to make it better, more convenient, more interesting, more fun or exciting. A lot of time, at least in our build studio, that is going to mean software or hardware, such as the AI agent, quadcopter, and ground vehicle we are working on this summer. I also think that it means text, audio, video, images, art, poetry—any artifact that you would want to see in the world. I want us all to move away from asking the question of “what can I buy?” and towards “what can I build?” This mindset puts us in a creative relationship with the world, rather than a passive one.

The second component, “develop an entrepreneurial mindset,” is closely related to the principle of “build constantly,” but different from it. While building artifacts is central to a deeply human way of engaging with the world, working together to make that happen is also crucial. Therefore, you also need to think about how you can create startups, businesses, organizations, communities, and other social and economic arrangements around the artifacts that you build. Sometimes these will make money, sometimes not. What is crucial is that you create more than just an artifact sitting in a garage or a drawer—you must create a constellation of people engaging with the artifact. Doing this will often involve failure, and lots of it.

The third component, “embrace experimentation,” addresses such failure. From an experimental point of view, failure is not, well, failure. Rather, failure is a signal that conveys that a particular hypothesis or approach to the world does not seem to work as expected. This is not a disappointment but rather input into the next round of experimentation. Embracing experimentation means expecting failure and then working through it repeatedly. Students sometimes think that this is a stage to be overcome through education and experience. Rest assured, failure will follow you for the rest of your life. Embrace it, and you will probably succeed once in a while.

The fourth component, “center humans,” reminds us what this is all about. Artifacts are secondary to humans, and so are LLM-based agents as well, by the way. The point of human life is to learn, explore, and achieve together with other humans. This means taking care of each other when the going gets rough and being there for others when life sucks. It also means bringing people along on your adventures. In a build culture we are always asking ourselves—who is this artifact useful for? I use the term “useful” in a broad sense, sometimes as a tool for achieving some instrumental end such as making money, and sometimes for humanistic ends such as delight, joy, love, creativity, exploration and togetherness. We also ask ourselves, “who can I bring along?” The second question is quite often more important than the first one.

A build culture produces people who build interesting stuff together with others, and who are not deterred by temporary failure. I think it’s a good way of engaging with an increasingly complex and challenging world. I am pleased to see the students at Stevens willingly take up this challenge.

The Projects

In the beta test of the build studio I am running this summer we are working with four different teams engaged in four different projects. The first team is building a voice-commanded drone for OSHA-oriented tasks: a quadcopter you can talk to, describe a workplace hazard, and send to investigate. The second team is building an autonomous off-road vehicle that navigates without maps, lanes, or predictable surfaces, for disaster response, forestry, and environments where infrastructure doesn’t exist. The third is building an AI research agent: an autonomous thinking partner for academic work, designed to surface the assumptions researchers can’t see in their own reasoning and make the logic of knowledge construction more transparent. The fourth team is doing something different. They’re making a video documentary about how young people today experience AI: how it shows up in their daily lives, how it shapes their sense of what’s possible, and how they imagine their futures in a world being reshaped around them.

Each of these projects will be going through a design process, which leans heavily on well-established concepts such as design thinking and human-centered design. These methodologies have become commonplace, and they are no longer subversive or revolutionary. Most firms that find themselves at the cutting edge of design and product development have embraced the principles of human-centeredness, iterative refinement, prototyping in the wild, and collaborative development.

The way that we engage in design processes is always relative to the tools that we have at hand, and the materials that we use. Increasingly, this means using AI tools. Claude Code, Codex, Cursor, Loveable, Replit (and an ever-increasing range of AI-enabled software development harnesses) can write code autonomously. Anthropic and others are also developing specific tools focused on design, such as Claude Design. We still haven’t figured out, however, how to work with these tools in a way that realizes build cultures in meaningful ways.

The Rise of AI Tools

It’s not that nobody has thought about how to use AI tools. In contrast, there is a large and growing library of books about AI and work. For example, Ethan Mollick’s Co-Intelligence (2024) provides some basic, yet useful, pointers on how to work with AI. Mollick discusses the idea of the “jagged frontier“ of AI capability. This means that at times an LLM may perform astonishingly well at one task, and in the next moment, fail miserably at a task that from the perspective of a human seems relatively similar to the prior task. Navigating this jagged frontier makes working with AI quite difficult.

What I have not seen being addressed in detail is how we can work with AI as we design and build products using a human-centered approach. Much experimentation is happening in offices, garages, and around kitchen tables, so people are figuring this out. Yet, I still think we need to write down some formalized accounts of the best practices that people are discovering along the way. The beta testing we are doing this summer of the build studio is an attempt to do just that.

We’ll see what comes out of it, but at this point I can already lay out some high-level principles: iteration and human judgement. First, iteration, comes from my experience of working with AI tools to write code and prose over the last few years. I am increasingly finding that simply delegating a task to an AI tool and expecting it to complete it end to end will deliver poor results. The best results seem to occur when I work together with one or more AI tools to iteratively refine an artifact, all the while insert as much context and direction as I possibly can.

Second, human judgement. I often find that AI tools have poor judgments relative to a task that I am trying to coax the tool into doing. Partially this is an alignment problem—it is difficult to align an AI tool towards what you really want, and most often the AI tools aligns quite well with the prompt and context that you provide, which often gets you a myopically focused artifact that doesn’t deliver the value you had hoped for. Therefore, I find that the clearer I am about what the outline, or gestalt, of the artifact that I am trying to create is, the better the AI can help me achieve that. This comes down to human taste and judgment—developing and maintaining these are critical for humans to be successful in working with AI tools. If you don’t know what you want out of an engagement with AI tools, you are probably not going to get anything that you, well, want.

Four Pitfalls of Building with AI Tools

Nonetheless, even if you can work effectively with AI tools, iterating together with them while applying your own judgment consistently, it is still easy to get things wrong. Working with AI tools tend to propel you towards one out of four different failure modes: hallucination, confident misdirection, cognitive offloading, and creativity reduction.

Hallucination. AI systems generate confident outputs that are factually wrong. The sneaky thing is that often they are not obviously wrong, but wrong in the way that passes a quick read and only reveals itself under scrutiny. Teams that move fast and don’t verify will build on false foundations. Now, in my experience hallucinations have gone down quite a bit over the last 12 months, but it still happens.

Confident misdirection. AI leads you convincingly in the wrong direction through, for example, a persuasive framing that misses the real problem or a well-reasoned rationale for a solution nobody needs. The danger is proportional to how fluently the output is written. The better AI gets at generating text, the more important it becomes to evaluate the argument, not just the prose. I’ve found, for example, that I can no longer evaluate the quality of a text through skimming it. What used to work, i.e., looking for odd formatting, bad grammar, spelling errors, typos, etc., does not seem to help me any longer.

Cognitive offloading. The more you rely on AI to think, the less you think yourself. This is perhaps not a short-term problem, but it is a huge long-term problem. Over time, there is potential for AI to erode our cognitive abilities, in a similar way to how smartphones have degraded our attention spans. The teams that will struggle this summer will be the ones who use AI to avoid hard thinking, not the ones who use it to do hard thinking faster.

Creativity reduction. AI narrows the option space toward the probable, which we increasingly are seeing evidence for (e.g., here and here). When you ask it to generate ideas, it generates ideas that fit existing patterns. In another post I wrote about how to potentially avoid this happening, but I think we still need to develop practices, toolsets, and institutional guardrails to guard against this pitfall. Much more work remains to be done.

I don’t necessarily think that these are reasons to avoid AI completely in design and build processes. I think these pitfalls are a call to creating cultures, processes, methodologies, artifacts, infrastructures, and institutions that help us to leverage AI in the best way possible. The beta testing we are doing in the build studio this summer is part of trying to figure that out.

Building a Build Studio

This summer is a beta test in the literal sense: we are running the process to see what breaks, so we can fix it before we formally launch the build studio and the various course offerings, hackathons (or build sprints), and other related activities this fall. This means that things will be fairly unstructured, and we will be prototyping as we go. It also means that we are, kind of, in stealth mode right now. I am working behind the scenes to set up a “skunkworks” advisory council that will help us to build industry connections.

In a sense, the build studio itself is the fifth project that we are running this summer. We are using the build studio approach to build the build studio. This means that we are doing everything at the same time—building the projects, creating networks in our local community, engaging in digital storytelling.

An important outcome of this beta test is to answer the question: “how do you build things together with intelligent machines?” While we will be using human-centered design, we will also work to update it interactively as we move through the summer to incorporate AI usage at every step, as well as combat the four pitfalls related to building with AI that we identified above.