AI has made it easier to produce working software.

That part is real.

It can write code, draft documents, research a topic, scaffold a prototype, and debug a problem faster than most teams can finish writing a decent ticket.

But faster building doesn't automatically mean better product decisions.

That's the part I keep coming back to.

For decades, software teams optimized around delivery. Requirements, design, development, QA, release. Waterfall softened into Agile. Agile grew into DevOps. The practices changed, but the assumption underneath stayed pretty stable:

building software is expensive, so plan carefully before you start.

That made sense because, for a long time, it was true.

Now that assumption is breaking.

AI is doing to software what calculators did to accounting. It isn't eliminating the job. It's moving the job up a level. The syntax, boilerplate, first draft, and some of the debugging are getting offloaded.

The work doesn't disappear.

The bottleneck moves.

Learning is still expensive

Here's what didn't get cheaper:

• understanding what people actually need
• getting stakeholders aligned
• deciding what evidence would change your mind
• putting something real in front of users
• reading the signal without fooling yourself

The old question was:

Can we build it fast enough?

The new question is:

Do we understand the problem well enough?

That sounds like a small shift, but it changes the work.

It changes what strong engineers spend time on. It changes what product people need from engineering. It changes how teams should define "done."

If the code ships but nobody learns anything, did the team actually move forward?

Sometimes yes.

Often no.

Users don't know until they can touch it

People are not great at specifying requirements up front.

Not because they're difficult.

Because they're human.

Most of us don't know how we feel about something until we can react to a version of it. A mockup. A prototype. A rough slice. A real workflow with sharp edges.

So the fastest path to learning usually isn't a better requirements document.

It's getting working software in front of people sooner.

But only if you know what you're trying to learn.

That's the step teams skip.

We jump from problem to implementation:

Users need X, so build X.

A product engineering loop adds the missing middle:

We believe doing X will cause Y because Z.

Now the work has a hypothesis. Now feedback has something to test against. Now shipping becomes part of a learning loop instead of just the end of a delivery pipeline.

Problem.

Hypothesis.

Working software.

User feedback.

Then back around again.

The question for a modern software team is not just how fast you can ship.

It's how fast you can run that loop without losing the evidence.

The companies pulling ahead are learning systems

This is already happening.

PostHog has engineers talking to users, digging into metrics, and shipping experiments without always waiting for a product manager to translate the work.

Amazon runs thousands of experiments.

Netflix's advantage was never just the recommendation algorithm. It was the system for learning what to put in front of people.

Feature flags, A/B tests, canary deploys, and audience segmentation are not exotic anymore. There are open source tools and commercial tools for all of it.

The gap is usually not tooling.

The gap is the habit of thinking in experiments instead of features.

That habit matters more as AI makes implementation cheaper.

Because if you get very fast at shipping without getting better at learning, you create a new problem: noise.

Too many changes in flight. Too many overlapping experiments. Users hit six new things in a week, and no one can tell what actually moved the outcome.

Speed without experimental discipline just gives you more noise faster.

Engineering and product are converging

This is why I like the phrase Product Engineering.

Engineering starts with technology and learns empathy.

Product starts with empathy and learns how things get built.

AI makes the overlap more valuable because the scarce person is increasingly the one who can hold both sides together:

• What problem are we solving?
• What do we believe will happen?
• What is the thinnest thing we can put in front of someone?
• What evidence would make us keep going, change direction, or stop?

I've started thinking of this person as a Software Scientist.

Not a job title.

A discipline.

Code is the instrument.

The market is the lab.

User behavior is the data.

If a hypothesis is wrong, the code wasn't wasted. It did its job. It answered the question.

That is a hard mindset shift for teams trained to treat shipped code as the primary output.

But in a product engineering world, speed-to-data matters more than speed-to-code.

The missing artifact is the lab notebook

There is one more piece that I think teams underestimate.

If software development is becoming more experimental, where does the experiment get recorded?

Most teams have places for pieces of it:

• Jira has the ticket
• GitHub has the pull request
• Slack has the discussion
• analytics has the metric
• an AI chat has the reasoning
• someone's memory has the tradeoff

That works until it doesn't.

Someone goes on vacation. The thread disappears. The AI chat is gone. The next person picks up the ticket and has to reconstruct the experiment from fragments.

Scientists don't just run experiments.

They keep lab notebooks.

Not because the notebook is the point.

Because the notebook lets the next experiment build on the last one.

That's how I think about imdone.

Jira and GitHub track work.

A lab notebook tracks hypotheses, decisions, evidence, and learnings.

For product engineering teams, those things need to live close to the work. Close enough that a human can pick them up later. Close enough that an AI agent can use them without guessing. Close enough that the team doesn't start from zero every time.

If you want to see how imdone keeps Jira or GitHub work in a local markdown workspace, the CLI docs are here: imdone.io/docs/imdone-cli

What to try next

You don't need a new title or a new process to start.

On your next piece of work, ask one question:

How can we run the loop a little faster?

Maybe that means writing a real hypothesis before you build.

Maybe it means putting a rough version in front of a user this week instead of next month.

Maybe it means adding a feature flag, a PostHog event, or a simple way to capture what happened.

Maybe it means keeping better notes so the next person doesn't have to rediscover what you already learned.

AI is making it easier to build.

The teams that win will be the ones that get better at learning.

That is the work now.