Intelligence is automated. Judgment is scarce.

Something interesting is happening to how we build software.

Not too long ago, if I had an idea for a product, getting it into a working state meant spending a considerable amount of time in Figma, setting up a project, writing components, figuring out state management, connecting APIs, and dealing with all the little things that come with building software. Today, I can describe an idea to an agent and have a working prototype in minutes.

Not just a static mockup, but an actual application with a frontend, backend, database, authentication, and a reasonably good-looking interface. And if something doesn’t work, I can ask the agent to fix it. Or ask it again, for the fifth time (we’ve all been there).

It’s pretty incredible, but the more I work this way, the more I’ve been thinking about something: Intelligence is automated. Judgment is scarce.

I think this is becoming one of the most important shifts in how we design and build software. Not because AI is necessarily replacing designers or developers, but because the work that used to take most of our time is suddenly becoming much cheaper. And when that happens, the things that make someone good at building software start to change.

The way we build has changed

For a long time, building software was largely constrained by execution. You could have a great idea, but turning it into something real required a particular set of skills, a lot of time, and usually a team of people.

If you were a designer, you could create beautiful interfaces, but getting them to work meant involving developers. If you were a developer, you could build almost anything, but making it look and feel good was a different challenge. And if you happened to do both, well, you still had only so many hours in a day.

A lot of the work was translating between different representations of the same idea. An idea became a wireframe, a wireframe became a high-fidelity design, that design became a set of components, and those components eventually became a working application. Each step involved decisions, but also a lot of repetitive execution.

Now, agents are starting to collapse those steps. You can go from a prompt to a working interface, from a screenshot to code, or from a rough product description to a database schema and API endpoints. You can also point an agent at an existing codebase and ask it to implement a feature, write tests, and fix whatever breaks along the way.

Even the boundary between design and development is becoming less clear. Tools can generate multiple interface directions, create components, write the logic behind them, and run the application to check the result.

Of course, the results aren’t always great. Agents still misunderstand requirements, introduce bugs, make strange design decisions, and confidently implement things nobody asked for. But they’re getting better, and the direction is becoming hard to ignore.

The cost of producing software is falling. The cost of knowing what software to produce isn’t falling nearly as fast.

And that’s where things get interesting.

When everything becomes easy to make

Imagine you’re building a dashboard for a SaaS product. You ask an agent to create one, and it gives you a pretty convincing result: sidebar navigation, charts, tables, filters, analytics cards, settings pages, and maybe even a dark mode toggle, because apparently every dashboard needs one.

Everything looks polished enough. But then you start asking questions. Why are these the metrics on the dashboard? Does the user actually need six charts? What is the most important action someone should take when they open this page? Should this information even be a dashboard, or would a simple weekly summary be more useful?

The agent can generate the interface, but the interface itself doesn’t answer these questions. And this isn’t just a design problem. The same thing happens with code.

An agent can implement a feature exactly as requested, follow the existing architecture, write tests, and open a pull request. But should that feature exist in the first place? Does it solve the actual problem, or just the problem as described in the prompt? Is the abstraction necessary? Is the complexity worth maintaining? Would removing something from the product be a better solution than adding something new?

These questions existed before AI, of course. The difference is that execution used to create a natural pause between having an idea and shipping it.

When something took two weeks to build, you had a pretty good reason to think about whether it was worth building. When it takes twenty minutes, it’s tempting to just build it and find out. Sometimes that’s exactly the right approach, and fast experiments are incredibly valuable. But sometimes it also means we end up producing a lot more software without necessarily producing better software.

We’ve removed a bottleneck, but we haven’t automatically improved the decisions that came before it.

The intelligence layer is becoming a commodity

For most of the history of software development, knowing how to implement something was a huge part of the value a developer brought. Knowing the right algorithms, understanding frameworks, remembering APIs, debugging obscure errors, and figuring out how different systems fit together.

The same was true in design. Understanding layout, typography, color, interaction patterns, design systems, accessibility, and the countless small details that make an interface usable required years of practice.

These things still matter, but access to that knowledge has changed dramatically.

I no longer need to remember the exact syntax for an API I’ve used twice. I can ask an agent. I don’t need to manually build five variations of a component to explore different directions. I can generate them and compare. I can also ask an agent to explain an unfamiliar codebase, evaluate architectural approaches, or point out accessibility issues in a design.

Some suggestions will be useful, some will be wrong, and a few will look correct right up until the moment you try to ship them. Still, we now have access to an enormous amount of technical capability on demand. A lot of what previously required specialized knowledge and hours of work can be generated, explained, or attempted almost instantly.

That’s a fundamental change, but there’s an important distinction here: having access to intelligence is not the same as knowing how to use it well.

An agent can give you five architectural approaches, but which one fits the product you’re building, the team maintaining it, and the constraints you’ll have six months from now? It can produce ten design directions, but which one communicates the right thing to your users?

The same goes for product decisions. An agent can suggest onboarding flows, personalization, analytics, notifications, AI features, and a settings page. The harder question is which of those actually makes the product better.

The problem increasingly isn’t generating possibilities. It’s choosing between them.

Judgment is the new bottleneck

I’ve been thinking about judgment as the ability to make good decisions when there’s no single obviously correct answer. And software development is full of those situations.

Should we build something custom or use an existing library? Should an interaction be explicit or happen automatically? Is this feature worth the additional complexity? Does this design need more polish, or does it need a completely different approach? Should we optimize for flexibility now or simplicity today?

You can ask an agent any of these questions, and it’ll probably give you a reasonable-sounding answer. But the right decision depends on context: who the users are, what they’re trying to accomplish, what the business cares about, which constraints are real, and what trade-offs are acceptable.

And perhaps most importantly, what we’re willing to leave out.

This is where I think designers and developers have an opportunity to become much more valuable. Not because we’re the only ones capable of making decisions, and certainly not because AI can’t help with reasoning, but because having more possible solutions makes choosing between them more important.

When you can generate ten good-looking interfaces in a few minutes, the ability to recognize the right one matters more. When you can implement five different architectures in an afternoon, understanding which one you should actually maintain matters more. And when building a feature becomes cheap, the discipline to not build it becomes surprisingly valuable.

That’s judgment. And unlike code generation, it doesn’t become reliable simply because you have more tokens to spend.

What happens to design?

As someone who works across design and development, I find this part especially interesting.

For a long time, much of design work involved creating artifacts: wireframes, mockups, prototypes, design systems, and handoff documents. These artifacts were necessary because they helped communicate what should eventually be built. But what happens when you can communicate an idea by building a working version of it?

Instead of spending a day designing a flow and another day prototyping it, you can have an agent generate a functional version and start interacting with it immediately. You can test assumptions much earlier, explore more directions, and discover that an interaction feels wrong before spending a week implementing it.

That’s a huge improvement, but it also exposes something we’ve always known about design: the value of design was never just the ability to produce screens.

It was understanding the problem, deciding what matters, organizing information, making trade-offs, and shaping an experience that works for real people. A generated interface can be visually impressive and still be fundamentally wrong. It might have excellent spacing, consistent typography, beautiful components, and absolutely no understanding of what the user needs to do.

And because the output looks finished, it’s sometimes harder to notice the underlying problem. That’s a new kind of trap.

We used to look at rough wireframes and know there was still a lot to figure out. Now we can look at a polished AI-generated prototype and mistake visual completeness for product completeness. The design looks done, even when the thinking behind it isn’t.

And what happens to development?

I think something similar is happening in engineering. Writing code is becoming a smaller part of the overall process of building software. Or, more precisely, writing every line of code yourself is becoming less necessary for many kinds of work.

The developer increasingly becomes the person who defines the problem, establishes constraints, guides implementation, evaluates output, and makes sure the system behaves the way it should.

There’s still plenty of engineering involved. You need to understand architecture, security, performance, data modeling, failure modes, and the consequences of technical decisions. In fact, some of these skills become even more important when an agent can introduce hundreds of lines of code in one go.

It’s easy to generate complexity, and much harder to recognize unnecessary complexity before it becomes part of your system.

I’ve also noticed that the better I understand the problem and the underlying technology, the better I can work with agents. I can give more precise instructions, catch incorrect assumptions, recognize when a proposed approach is overengineered, and know when something needs a closer look.

The agent handles more of the typing, but I still need to understand what we’re building.

And that raises an interesting question for how we learn development. If agents can produce code faster than we can read it, how do we make sure we develop the understanding needed to evaluate it?

I don’t think the answer is to avoid using agents. It’s to be intentional about where we delegate execution and where we continue doing the thinking ourselves. Because the ability to generate code isn’t particularly useful if you can’t tell whether the code is good.

The danger of becoming a great prompter and a poor thinker

There’s a temptation to reduce this entire shift to prompt engineering. Learn how to write better prompts, set up the right agents, give them the right tools, and automate as much as possible.

And yes, knowing how to work effectively with agents is becoming an important skill. But I don’t think that’s the end goal.

Imagine two people working with the same model. One asks it to build a project management app with dashboards, tasks, timelines, notifications, team management, and AI-powered insights. The other spends time understanding a particular team’s workflow, discovers that their biggest problem is knowing what’s blocked, and builds a tiny tool that makes blockers impossible to miss.

The first person might end up with a much more impressive demo. The second might end up with a much more useful product.

Both had access to the same intelligence. The difference was in how they understood the problem.

This is why I think taste, curiosity, product sense, and critical thinking will become increasingly important. Not taste in the sense of simply preferring beautiful interfaces, but taste as the ability to recognize quality, coherence, simplicity, and usefulness.

It’s the ability to look at something that technically works and say, “This still isn’t right,” and then understand why.

More building, less building for the sake of building

One thing I don’t want to lose in all of this is the joy of making things.

I love that I can now explore ideas that would previously have taken days or weeks. A small tool for a personal workflow, a weird interaction I’ve been thinking about, an experiment with a new framework, or a prototype that probably won’t go anywhere. The barrier to trying things is lower than it’s ever been, and I think that’s wonderful.

We should absolutely take advantage of it, but we should also recognize that faster execution changes what deserves our attention.

If creating the first version becomes easy, perhaps we can spend more time understanding users. If generating components becomes easy, perhaps we can spend more time refining interactions. If writing boilerplate becomes easy, perhaps we can spend more time thinking about architecture. And if exploring ideas becomes cheap, perhaps we can afford to discard more of them.

Maybe that’s the real opportunity here. Not to fill every saved hour with more features, more code, and more output, but to use some of that time to make better decisions.

The next competitive advantage

I don’t think technical skill is going away, and I don’t think designers or developers are suddenly becoming irrelevant. But I do think the definition of being good at these jobs is shifting.

Someone who can write excellent code will still be valuable. Someone who can create beautiful interfaces will still be valuable. But someone who can identify the right problem, understand the constraints, make thoughtful trade-offs, and use agents to bring a good solution to life might have a much bigger advantage than before.

Because when everyone can build, building alone stops being enough.

We’ll probably see a lot more software being created: more prototypes, more experiments, more products, and more features. Some of it will be excellent, and a lot of it will be unnecessary. Increasingly, the difference won’t come down to who had access to the best tools or who could produce the most code. It’ll come down to who knew what was worth making.

That’s the part I’m most interested in.

We have more information than we could ever consume, and increasingly capable systems that can reason, design, and write code alongside us. The bottleneck is moving, and I think we’re only beginning to understand what that means for the people who build software.

Intelligence is automated. Judgment is scarce.

And perhaps the most important skill we can develop now isn’t learning how to make more things. It’s learning how to decide what deserves to be made.