AI Is Turning Engineers Into Product Thinkers

For most of the history of software, an engineer's core question was how. How do we build this, how do we make it fast, how do we make it scale. What to build was mostly someone else's job.

AI-assisted development is changing that question. When an AI agent can produce a working feature in an afternoon, the hard part is no longer the how. It is knowing, precisely, what you want and why. The best engineers today spend less energy on syntax and frameworks and more on the questions a product owner asks: what problem are we solving, for whom, and how will we know it works?

That is a quiet change, but it reshapes what it means to be good at this job.

The old division of labor

Traditional delivery split the work cleanly. Product managers and business analysts gathered needs and wrote requirements. Engineers turned those requirements into code. Engineering excellence was measured mostly in technical terms: clean architecture, performance, the right framework, elegant solutions to hard problems.

Gaps in the requirements were common, and they were survivable. Building took weeks, so engineers found the gaps along the way, walked over to ask a question, and adjusted. A good engineer quietly filled in what the document left out, using judgment and context. The vagueness got absorbed in the slow work of building.

Machines do what you say, not what you mean

AI agents change that dynamic because they are fast and literal. Give an agent an ambiguous instruction and it will not stop to ask what you meant. It will make a reasonable-sounding assumption and build a complete, working, confident version of the wrong thing in minutes.

The vagueness a human used to absorb over weeks now gets baked into the software at machine speed. What comes out is only as clear as what went in. An engineer who can't state precisely what a feature should do, including its edge cases and constraints, will get output that looks finished and is subtly wrong.

The new center of gravity is intent

So the engineer's attention moves upstream. Before any code exists, the strongest engineers now work out:

• What problem the feature solves, for whom, and what success looks like for that person.
• What it must never do: the data it can't touch and the rules it has to respect.
• What happens at the edges, when inputs are missing, wrong, or unusual.
• How we will know it works, written down as tests or evaluations before the build starts.

That last point matters most. Writing the test first is writing the requirement in a form a machine can check. It turns "the system should handle missing patient records gracefully" into something that either passes or fails.

After the build, the engineer reviews the result against that intent. The question moves from "is this code clean?" to "is this the right thing, and does it do what we meant?" Those are product questions.

Clarity, not volume

None of this means a return to the eighty-page requirements document. The specification is coming back, but in a different form.

The tooling world has noticed. A category of "spec-driven development" tools has grown up around AI coding agents, including GitHub's open-source Spec Kit and Amazon's Kiro. Spec Kit's own guidance puts the idea in one line: "define what and why before deciding how to build it."

The specs that work in this world are short and testable. The people closest to the build write them, and they evolve as working software reveals what was missing, instead of being signed off and filed. A one-page statement of intent with sharp acceptance criteria beats a long document nobody can verify.

Technical depth still matters

This is a shift in emphasis. Engineering skill is not being retired. Technical depth is exactly what lets an engineer tell good output from output that only looks good. An agent can produce code that runs and passes a shallow test while hiding a security gap, a performance problem, or a design that won't survive the next feature.

Spotting that takes real expertise. The engineers who thrive now have both: the product instinct to define the right thing, and the technical judgment to recognize when the machine built it wrong.

What this means for the organizations we build for

For anyone buying software, this shift is good news. Every handoff between business intent and working code used to be a chance for meaning to get lost. When engineers think like product owners, there are fewer translation layers. The person writing the spec for the agent understands what the clinician, the health plan member, or the operations team actually needs.

In healthcare, that matters more than almost anywhere. Requirements here carry regulatory weight. A vague instruction about how patient data is handled, or how a claim is adjudicated, can become a compliance issue. Precision of intent is part of building safely.

At Vicert, that is the kind of engineer we believe healthcare software needs: technically deep, and fluent in the questions a product owner asks. As AI takes on more of the typing, an engineer's value increasingly lives in the clarity of their thinking. That is a change worth building a team around.