DEV Community: Ran Dror

What I’m Starting to Look for in Engineers

Ran Dror — Sun, 24 May 2026 23:06:33 +0000

I think AI is starting to fundamentally change what strong engineering looks like.

And honestly, I don’t think the biggest shift is coding speed.

It’s ownership.

Because writing code is becoming dramatically cheaper.

But deeply understanding the problem, the customer, the tradeoffs, the scope, and whether something actually creates value is becoming dramatically more important.

So when I think about engineers today, I increasingly look for people who operate more like mini product owners or mini founders.

People who don’t just wait for tasks.

People who try to understand why something should exist in the first place.

Ownership also means not treating development like isolated ticket execution.

Strong engineers increasingly need to navigate ambiguity across the organization:
talk to other teams, understand dependencies, ask difficult questions, unblock decisions, and actively pull the information they need.

Because building the right thing often requires coordinating people, context, and decisions — not only generating implementation.

1. Reduce Ambiguity Aggressively

Before starting implementation, I increasingly expect engineers to reduce ambiguity aggressively.

Talk to PMs.

Talk to designers.

Understand the customer case.

Challenge the scope.

Figure out what actually matters and what can be simplified.

Because once implementation becomes cheap, understanding the problem becomes dramatically more valuable.

The best engineers I’ve worked with are usually the ones who help teams reach value faster — not necessarily the ones who write the most code.

2. Think Before Generating Code

I also think planning matters more now, not less.

Before generating code, understand the implementation strategy.

Compare approaches.

Read.

Ask AI.

Discuss tradeoffs with teammates.

And most importantly, understand what kind of system you are actually building.

An isolated MVP, a customer-specific workflow, and long-term core infrastructure are completely different engineering problems.

Not every idea deserves the same level of engineering investment from day one.

3. The Workflow Is Changing

At this point, I increasingly expect engineers to use AI continuously during development.

Engineers should stop treating manual coding as the default way software gets built.

More and more, the process becomes:
telling AI what to build, reviewing the result, correcting it, refining it, validating it, and repeating the loop until the implementation behaves exactly as intended.

The engineer’s role increasingly becomes:
direction, judgment, validation, architecture, and decision making.

If something is repetitive, automate it.

If something can be accelerated safely, accelerate it.

If a workflow repeats itself, turn it into a reusable process and share it with the team.

The value is no longer in manually producing the code.

It’s in knowing what should be built, how to direct AI effectively, and how to verify that the result actually works.

4. Engineers Still Own Quality

AI generating code does not remove responsibility from engineers.

If anything, it increases it.

Because someone still needs to evaluate engineering quality — while also validating that the product behaves correctly, solves the user’s problem, and works reliably across real-world scenarios.

5. Learning Speed Matters More Than Ever

The pace of change right now is difficult to overstate.

The engineers who grow fastest are often not the ones who already know everything.

They’re the ones who continuously learn, adapt, compare approaches, and evolve their workflows.

AI also lowers the cost of learning itself.

Which means curiosity becomes an even more valuable skill.

Honestly, I think the role is becoming more interdisciplinary.

Part engineer.

Part product thinker.

Part systems designer.

And I also think this definition may change again very quickly.

But right now, the engineers who stand out the most to me are usually the ones who combine strong engineering judgment with ownership, product understanding, and the ability to work effectively with AI.

Because increasingly, the job is not writing the code itself.

It’s making sure the right thing gets built — and that it actually works for users.

AI Rewards the People Closest to the Problem

Ran Dror — Sun, 24 May 2026 22:16:28 +0000

One of the interesting things happening right now is that some of the most effective people building software with AI are not necessarily engineers.

They’re often founders, CEOs, PMs, operators, or people deeply connected to the business itself.

And I don’t think that’s accidental.

Because what makes their prototypes useful is usually not technical perfection.

It’s context.

They understand:

the customer
the workflow
the priorities
the pain points
what actually matters
and what can safely be ignored for now

Historically, turning that understanding into software required a long translation process through engineering teams.

But AI dramatically lowers the cost of turning ideas into working product surfaces.

And maybe that changes what creates leverage in software teams.

Not less engineering quality.

But more product understanding.

More context.

More judgment.

More ability to evaluate whether something actually creates value for users.

Because if AI increasingly handles more of the implementation layer, then deeply understanding the problem may become even more valuable than understanding every implementation detail immediately.

That doesn’t mean engineering disappears.

Production systems still require scalability, security, reliability, integration, and operational stability.

But maybe the people who create the most value in the AI era will not only be the ones who write the best code.

Maybe they’ll be the ones who best understand what is actually worth building in the first place.

AI Makes Building Cheap. Our Product Architectures Still Assume It’s Expensive.

Ran Dror — Sun, 24 May 2026 21:51:44 +0000

One of the strange things happening right now is that people can suddenly build surprisingly useful software with AI.

Founders are building internal tools with Claude.

PMs are prototyping workflows in a weekend.

Small teams are generating working features faster than organizations can even review them.

And it raises a very reasonable question:

If useful software can now be built so quickly, why do mature product teams still move so slowly?

Part of the answer is that large products are not isolated systems.

In a small prototype, a feature mostly needs to work by itself.

But in mature products, features need to safely coexist with everything already there: permissions, workflows, integrations, edge cases, monitoring, and operational constraints.

And most importantly: features don’t only need to work individually.

They need to work together.

This is why complexity often feels closer to n² than to n.

If you have 10 features, you are not only managing 10 features.

You are also managing the interactions between them.

That is where mature products become slow.

Not because teams forgot how to build — but because every new thing has to safely coexist with everything already there.

At some point, shipping software becomes less about building the feature itself — and more about safely integrating it into a living system.

Maybe We Need a Different Layer for Experimentation

I’ve been wondering whether AI pushes us toward a different product architecture model.

Not replacing the core product.

But adding a safer experimentation layer around it.

Tools like Base44, Lovable, and similar AI builders already demonstrate how fast isolated software creation can become.

The problem is that mature products are not isolated environments.

So maybe the opportunity is not turning entire products into vibe-coded systems —

but creating safer modular layers where that speed becomes possible without destabilizing the core product itself.

The goal is not rebuilding the entire system around AI-generated software.

It’s creating safer boundaries for experimentation inside existing products.

Imagine a product with stable foundations: authentication, permissions, APIs, shared design primitives, and strict operational boundaries.

And on top of that, lightweight modular “boxes” that can be developed independently using AI.

These boxes would remain operationally isolated, use restricted interfaces to existing services, mostly operate in readonly mode, and maintain their own isolated logic and storage.

In many cases, each box could function as a small end-to-end product surface: its own UI, workflows, logic, and isolated data layer — connected to the core product through controlled interfaces.

Users shouldn’t necessarily feel like they’re constantly moving between separate applications.

The experience can still feel unified, even if the experimentation layer remains operationally isolated underneath.

The goal would not be perfect engineering.

The goal would be fast learning.

In that stage, the mindset can also be different.

You don’t always need to fully understand or perfect the internal implementation.

You need to define the input, evaluate the output, and test it against enough realistic cases to know whether it actually creates value.

If the experiment consistently works across real scenarios, maybe that is enough to keep learning.

If it matures, then you can decide whether it deserves deeper engineering, stronger guarantees, and tighter integration into the core product.

PMs, founders, or small teams could rapidly test workflows, internal tools, AI experiences, or customer-specific functionality without introducing major risk into the core product itself.

And if an experiment fails?

You remove the box.

Minimal cleanup.

Minimal blast radius.

Minimal organizational overhead.

AI May Change What We Optimize For

I think a lot of software organizations still operate under assumptions from a world where building was expensive.

So naturally, we optimized for long-term maintainability, scalability, system quality, and centralized control.

And those things still matter.

But AI dramatically changes the cost of experimentation.

Which means the bottleneck may shift somewhere else: learning speed, iteration speed, organizational flexibility, and safe experimentation.

That doesn’t mean every company should suddenly let AI generate random production systems.

There are still real problems to solve: governance, security, consistency, maintainability, observability, and architecture sprawl.

But I do think many teams are underestimating how much product experimentation itself is about to change.

Because maybe not every idea needs to become part of the core product immediately.

Maybe products need safer ways to explore ideas before fully integrating them into the core product.

AI Can Generate Interfaces on the Fly. But Users Still Need Orientation.

Ran Dror — Sun, 24 May 2026 20:48:27 +0000

Why should software even have fixed interfaces anymore?

Last week, Google announced new “Generative UI” capabilities for Search — dynamically generating interfaces, visual tools, simulations, and layouts in real-time as part of the answer itself.

And honestly, the demos are impressive.

If AI can generate the perfect UI for the exact context, maybe every experience should become fully dynamic.

But I think this direction also exposes a deeper challenge.

Because historically, great software products were not only powerful.

They were predictable.

Users learned them over time.

They built habits, intuition, and trust.

The interface itself became familiar.

But AI is pushing software toward something much more fluid:

generated interfaces
conversational interactions
adaptive workflows
contextual layouts

Why force every user into the same experience if software can adapt itself dynamically?

But flexibility alone is not what makes products feel good to use.

Great UX Is Not Just Flexibility

Humans don’t only need powerful systems.

They also need consistency, guidance, structure, familiar flows, and predictable behavior.

You can already see this tension appearing in product discussions today.

If users can simply ask an AI questions directly, do we still need dashboards at all?

And in some cases, maybe we don’t.

But dashboards also provide something important: consistency.

People learn them over time.

They know where to look.

Teams align around shared definitions and metrics.

And users build trust in workflows that behave predictably.

That determinism matters more than we sometimes realize.

Chat interfaces expose this problem very quickly.

Users often don’t know:

what to ask
how to ask it
what’s possible
or whether the result they received is even correct

And fully generated interfaces may create a similar kind of friction.

If the interface constantly changes:

where does familiarity come from?
where does trust come from?
how do workflows become repeatable?

Great UX is not just about flexibility.

It’s about helping users feel oriented.

The Next UX Challenge

I don’t think the future of software is static UI.

But I also don’t think it’s completely fluid interfaces generated from scratch every time.

The products that win will probably balance adaptation with consistency.

What’s interesting is that dynamic interfaces may actually increase the importance of stable foundations.

Because if experiences become more adaptive, users still need consistency somewhere:

in interactions
in patterns
in behavior
and in the mental models products create over time

Maybe the future is not fully generated UX.

Maybe it’s adaptive experiences built on top of stable foundations.

And if interfaces become increasingly dynamic and generated in real-time, the more interesting question may be:

How do we preserve the things that made great software feel trustworthy in the first place?

Google announcement:

https://blog.google/products-and-platforms/products/search/search-io-2026/#agentic-coding

AI Won’t Reward Companies for Building More Software

Ran Dror — Sun, 24 May 2026 19:16:28 +0000

A lot of people think AI will change software because it helps us build faster.

And it will.

But I’m not sure that’s the most interesting change.

Because even before AI, large software companies could already build almost anything they wanted.

And still, most products failed.

Not because they couldn’t ship fast enough.

But because building software is not the same thing as building something people actually want to use.

For years, startups already understood this.

That’s why people talked about:

MVPs
Product-Market Fit
fast iteration
customer feedback

Long before AI.

So maybe AI doesn’t change what matters.

Maybe it simply exposes it more clearly.

Because if software becomes dramatically easier to build, then the bottleneck shifts somewhere else.

And that raises a more interesting question:

What becomes valuable when building is no longer the hard part?

More Software Doesn’t Automatically Create More Value

AI may dramatically lower the cost of creating software.

Which means we’re probably about to get:

more products
more features
more AI tools
more interfaces
more complexity

And I think many companies will react in the same way:

build more
ship faster
add more AI capabilities

But more capabilities don’t automatically create better products.

In many cases, they create the opposite:

confusion
friction
cognitive overload

The best products rarely win because they have the most buttons.

They win because they make complicated things feel simple.

The Real Value of Software

Think about navigation apps.

Technically, most of them do very similar things:

maps
routing
traffic
directions

But users still strongly prefer certain ones.

Not because they understand the algorithms.

Because some products simply feel easier, clearer, and more trustworthy.

The value of software is often not the capability itself.

It’s helping people navigate complexity successfully.

Maybe that’s why UX still matters so much.

Not because of visuals.

But because good products guide people.

They reduce ambiguity.

They create confidence.

They help users complete tasks successfully without needing to fully understand the complexity underneath.

In that sense, great software often feels less like a tool — and more like a recipe.

Maybe AI Changes What Great Products Look Like

A lot of people assume the future interface is just chat.

Maybe.

But chat also creates new friction.

Users don’t always know:

what to ask
how to ask it
or even what’s possible

Traditional UX still has enormous value.

Good products guide users step-by-step.

They reduce cognitive load.

They help people navigate complexity successfully.

In many cases, the real value of software is not:

“Can this technically be done?”

But:

“Can this be done simply, clearly, and reliably?”

I also think AI may push products to become more adaptive.

Because people don’t actually work the same way.

Some users want:

speed
flexibility
advanced control

Others want:

structure
simplicity
guidance
clear flows

Maybe the future isn't one perfect product for everyone.

Maybe the future is software that adapts more intelligently to different people and different ways of working.

The Bottleneck Shifts Somewhere Else

If AI dramatically lowers the cost of building software, then the bottleneck shifts somewhere else.

Toward:

understanding people
reducing complexity
designing better experiences
learning faster
building trust

And maybe that changes how companies should use AI in the first place.

Maybe the biggest opportunity AI creates is not building more software.

Maybe it’s reducing the cost of exploration.

The ability to:

test ideas faster
learn faster
adapt faster
refine products faster

Because if software creation becomes cheap, then understanding people becomes even more valuable.

Maybe the companies that win in the AI era won’t be the ones building the most software.

Maybe they’ll be the ones learning the fastest.

Curious how others think about this.