TL;DR: AI has made building cheap. It has not made it cheap to know what to build, to check that it works, or to make it last. Four habits matter most: curiosity, ownership, long-term vision, and solid software engineering basics.

I often ask myself what makes a scientist effective in industry today. A few years ago, building a prototype took weeks: you wrote the data pipeline, the model, the tests, and the plots yourself. Today, an LLM can produce a working prototype in an afternoon. The bottleneck has moved. Writing code is no longer the scarce skill; judgment is.

In my previous post, I argued that GenAI amplifies existing work habits. So which habits are worth amplifying? Here are the four I keep coming back to:

  • Be curious: this is how you add value.
  • Take ownership: this is how you earn trust.
  • Have a long-term vision: this is how you compound.
  • Learn the basics of software engineering: this is how you execute.

Be curious

None of us understands everything we use. We do not write binary code, and most of us cannot explain the quantum physics behind a transistor. That is fine. Knowledge is infinitely deep, and the skill is knowing where to stop: go deep enough to build a mental model that lets you complete the task.

A good mental model starts from explicit assumptions. An engineer does not re-derive Newton’s laws before designing a bridge; they take them as given and reason from there. Do the same with your work. Know what you are assuming, what follows from it, and what breaks if an assumption is wrong.

This is where LLMs become dangerous. It is tempting to let the model understand the problem for you. Do not outsource your understanding. An LLM can write the solution, but you are the one who has to defend it when someone asks “why does this work?” or “what happens if I change this?”. If you cannot answer, you did not add value; you relayed it. Curiosity is what keeps you in charge.

Take ownership

In industry, a project should end in one of two ways: you deliver something people actually use, or you learn what not to do next time. The goal is not a sophisticated algorithm; it is an algorithm that solves a real problem. Do not get me wrong: I love sophisticated, elegant algorithms. I spent years in academia surrounded by very smart people building them. But in industry, among the solutions that work, we pick the one that is easiest to maintain. Do not over-engineer: sophistication has to earn its place.

With AI, one person can own an entire project, and we produce more than reviewers can check. Assume that everything you build goes straight to your users. This means you must drive the roadmap and anticipate problems before they arise. Will this still work at ten times the data? Will it survive edge cases you have not seen yet? Stay one step ahead: fix problems before anyone notices them. That is how you earn trust.

Have a long-term vision

Ten small tasks on ten different topics have less impact than ten small tasks toward one coherent goal. The effort is the same; the outcome is not. When tasks share a direction, what you learn in one feeds the next, and improvements compound.

AI makes this more important, not less. When starting something new costs an afternoon, it is easy to scatter: a prototype here, a quick analysis there, none of them going anywhere. Understand the vision of your project, then drive it.

Learn the basics of software engineering

You will be accountable for code you did not write. The model wrote it, you shipped it, and when it breaks in production, it is your name on it. The answer is not to read every line; it is to build harnesses and tests that tell you whether the code is correct. If you cannot verify it, you cannot own it.

You also need to understand how your code is structured: not what each line does, but how the pieces fit together. A simple test is to ask: how much code do I need to change to implement this feature? Clean code is not enough: good architecture is shaped by the problem it serves, so new features fit in naturally. You should never have to force a solution into the code. If you find yourself adding patches, if small features require large changes, or if one new feature breaks ten existing ones, the architecture no longer fits the problem. It is time to go back to the drawing board. An LLM can write the lines, but you own the architecture.

AI has made building cheap. It has not made understanding, judgment, or direction cheap. Those are now the job.