About 47,000 people from 186 countries used Codex to build more than 8,000 projects. What emerged was more than a showcase of advances in AI coding.

While scrolling through Threads, I stopped at a post that caught my attention.

OpenAI had announced eight winners from Build Week, a global event where participants used Codex to turn ideas into working projects.

The winning projects covered remarkably different areas: a digital museum that reconstructs ancient Chinese machines in 3D, a tool for practicing Vietnamese pronunciation, a system that helps veterinary clinics triage phone calls, a prototype designed to support cardiac arrest response, and an app that assists people with speech impairments.

My first reaction was simple.

“You can build all of this with Codex?”

But as I looked more closely at the eight projects, something else stood out.

What mattered was not simply how technically complex the projects were. It was the problems their creators had chosen to solve.

OpenAI also emphasized this point in its presentation of the winners: many of the projects began with problems the creators already understood deeply through their own work, expertise, or personal experience.

As AI becomes increasingly capable of writing code, perhaps one of the most important human skills will no longer be simply knowing what can be built, but recognizing which problems are worth solving.

What Did 47,000 Participants from 186 Countries Build?

OpenAI Build Week was a global event in which developers, creators, entrepreneurs, students, and others used Codex to turn ideas into functioning projects.

According to OpenAI, about 47,000 people from 186 countries participated, submitting more than 8,000 projects over eight days. The event also included seven digital events and 60 in-person community events.

Eight winners were ultimately selected across four categories: Education, Work & Productivity, Apps for Your Life, and Developer Tools.

The first-place winner in Education, Mechanica, is a digital museum that allows users to interact with reconstructed ancient Chinese machines rather than simply viewing them.

The team recreated four historical machines, including an astronomical clock tower and a loom, using fragmented historical records. Where historians disagree on how the machines may have worked, the project does not present one interpretation as absolute fact. Instead, it allows users to explore multiple possibilities.

Codex helped the team work in areas that were outside their existing expertise, including 3D modeling, physics, and animation.

The second-place Education project, Dấu, focuses on one of the most difficult aspects of learning Vietnamese: tones.

When a learner speaks a word, the app visualizes the pitch contour and compares it with a native-speaker reference, helping the learner identify what needs to be corrected.

What is particularly interesting is that the system does not hand every decision over to generative AI. Tone evaluation is handled through deterministic signal processing, while GPT-5.6 provides learning guidance. When there is not enough evidence to make a reliable judgment, the system asks the learner to try again rather than inventing an answer.

The goal, in other words, is not to use AI everywhere.

It is to decide where AI should be used—and where it should not.

An App Built by a 61-Year-Old Veterinarian with No Coding Experience

One of the projects that stood out most to me was veTriage, the first-place winner in Work & Productivity.

Its creator, Erin Downes, is a 61-year-old veterinarian and veterinary hospital owner who, according to OpenAI, had no previous coding experience.

Her clinic, Paoli Vetcare, had seen the number of veterinarians fall from three to one. Yet phone calls from worried pet owners continued to come in.

Drawing on decades of clinical and hospital management experience, Downes created veTriage.

The app helps reception staff gather relevant medical history, identify urgent warning signs, and escalate cases to a veterinarian when necessary. Importantly, the system is designed so that non-medical staff are not asked to make medical decisions themselves.

The tool is now being piloted in her clinic.

What makes this example significant is not that a developer discovered a new problem.

It is that someone who already understood the problem deeply was able to turn that knowledge into working software.

In the past, even when someone knew exactly what kind of service was needed, turning an idea into software required considerable technical expertise and resources.

In this case, domain expertise came first.

Codex helped translate that expertise into a functioning workflow.

OpenAI describes this as an example of how people closest to difficult real-world workflows may increasingly be able to build the systems they need themselves.

A Cardiac Arrest Support System Built Between Hospital Shifts

The second-place Work & Productivity project, Pulse, follows a similar pattern.

It is a research prototype created by Mohamed Mostafa Mohamed Labib Abu Taleb, a cardiologist working in Cairo, who developed the system independently between hospital shifts.

During a cardiac arrest, medical teams must simultaneously track CPR cycles, heart rhythms, defibrillation, medication timing, interruptions in chest compressions, and many other clinical events.

Pulse listens to the spoken activity around a resuscitation effort and records these clinical events, helping the team track what has already happened and what should be checked next.

But the system follows an important principle:

AI does not replace the physician's judgment.

GPT-5.6 is used to interpret complex, overlapping speech, while the actual resuscitation state is tracked through auditable deterministic code. When the available evidence is unclear, the system asks medical staff for confirmation.

The project demonstrates an important point.

Allowing AI to do more does not automatically make a system better.

Knowing What AI Should—and Should Not—Do

This question becomes even clearer in Second Voice, the first-place winner in Apps for Your Life.

Second Voice is designed to help people who experience difficulty communicating in real-time conversations because of dysarthria or physical limitations.

The system combines partial speech, prewritten phrases, and conversational context to suggest several possible sentences.

But the AI does not immediately speak on behalf of the user.

The user must first choose or edit the sentence before it is spoken aloud.

This prevents the AI from deciding the user's intent on its own.

In other words, the goal is not merely to ask how much AI can do for a person, but also how much control should remain with the person.

A similar design philosophy appears in Echo Canvas, the first-place Developer Tools project. GPT-5.6 is used to create and explain spatial scenes, while deterministic systems handle the actual geometry and acoustic calculations.

The second-place Developer Tools project, Sentinel, also combines multiple approaches. It scans MCP servers for vulnerabilities using static analysis, constrained GPT-5.6 review, and isolated Docker testing. The system places limits on the model so that it cannot cite nonexistent code or invent arbitrary execution tests.

Across these projects, a common principle becomes visible.

The winning entries are not simply examples of developers giving AI more responsibility.

Instead, many of them ask a more careful set of questions:

What should AI handle?
What should remain deterministic?
And where should human judgment remain in control?

AI Coding Is Moving Beyond Code Generation

Early AI coding tools were primarily designed to assist developers while they wrote software.

They could autocomplete code, generate functions, explain errors, or suggest fixes. A human developer remained in control of the overall process, while AI helped with individual parts of the work.

Today's coding agents are moving in a different direction.

Rather than simply suggesting code, they can increasingly understand a goal, examine a repository, plan a series of steps, modify files, run tests, and verify the results.

In other words, AI coding is evolving from generating code toward performing tasks.

This shift matters for more than developer productivity.

It may also expand the range of people who can turn an idea into functioning software.

OpenAI highlighted this possibility in its Build Week results: experienced developers may be able to attempt more complex systems, while people with expertise in entirely different fields may be able to transform their own knowledge into working tools.

I Am Not a Developer

This is also why I found Build Week particularly interesting.

I am not a developer.

I work in video production and teach AI in universities and other educational settings. I use a variety of generative AI tools, but software development and writing code have never been my primary field.

Until now, when discussing AI use, I have often focused on questions such as:

How should we ask AI questions to get better results?

How should prompts be structured?

How should we evaluate and use what AI generates?

Those questions still matter.

But looking at the Build Week projects makes me think there may be an even more important question that comes before them.

Not,

“What can I ask AI to do?”

but,

“What problems exist in the environment I know best?”

The veterinarian understood the problem of repeated calls in an understaffed clinic.

The cardiologist understood the complexity of tracking events during cardiac arrest response.

The Vietnamese-language project began with the difficulty of knowing exactly what is wrong when a learner mispronounces a tone.

The creator of Second Voice drew on a personal experience of being unable to communicate fully with a family member who had a speech disability.

AI did not discover those problems for them.

The problems were already present in their work and their lives.

As the Barrier to Building Falls, the Question Returns to Humans

None of this means that developers will become unnecessary simply because AI can write code.

If anything, the Build Week winners demonstrate the opposite.

Medical judgment was left with medical professionals. Acoustic calculations were handled by deterministic systems. AI was prevented from making final decisions about a user's intended speech.

As AI becomes more capable, the challenge may not be simply to use more AI.

It may be to design carefully where AI should be used and where it should stop.

Even so, one shift appears increasingly clear.

The technical barrier between an idea and a working product is beginning to fall.

If that continues, the questions we use to define competence in the AI era may also have to change.

How much code do you know?

How well can you write prompts?

Those abilities will still matter.

But they may no longer be enough.

Perhaps we will also need to ask:

What problems exist in the field I know well?

What frustrations do people repeatedly experience but have become so accustomed to that they no longer notice them?

Which parts of those problems require human judgment, and which parts could AI help solve?

And finally,

Can I turn that idea into something that actually works?

The eight OpenAI Build Week winners are interesting not simply because they demonstrate what can be built with Codex.

They point toward something more fundamental.

As AI lowers the technical barrier to building things, it is returning a more important question to humans:

What should we build?

And before that,

Why should we build it?