What should engineers build when AI writes the code?

At Framna, this shift is central to how we build. With Framna Build, agents write the code from shared specs, while our people and our partners make the decisions and shape the product together. That changes what we need from engineers. When building is no longer the bottleneck, the product is only as good as the understanding of the people directing the work.

That was the starting point for our engineering masterclass on the last day of Future Product Days 2026 in Copenhagen. For a full day, Erik Lindström, Head of Engineering, and Martin Johannesson, Principal Software Engineer, worked through one question with the room: what should engineers build, and why, now that AI writes much of the code?

This article collects what came out of the day. The short version: implementation is getting cheap. Judgment is not.

The masterclass in five points. Each one is unpacked below.

Software has moved up in abstraction before, from assembly to higher-level languages. Now we can describe what we want in plain language, and AI writes the code. Each step made writing code cheaper. None of them helped decide what is worth building.

The limiting factor is no longer writing the code. It's deciding what to build, finding out whether it helps, and knowing when to stop. When the wrong thing can be built faster than ever, those decisions matter more, not less.

Choosing the problem and knowing when to stop used to sit with product managers, designers and whoever wrote the ticket. That doesn't go away. Design and product still set the direction. But if engineers have to wait for every small call along the way, they get blocked, and the speed AI gives them goes to waste.

What helps is a team that shares enough understanding of the user and the business that engineers can make the everyday calls themselves. So engineers need two kinds of literacy beyond code. Business literacy: who pays, and why? And UX literacy: what is the user actually trying to do?

If engineers are going to make more of these decisions, they need to understand what users are trying to do. That means talking to users, and how you ask matters a lot.

Describe your solution and ask whether people like it, and you make it easy for them to say yes. A polite answer is not evidence. Ask about what actually happened instead.

"They loved the idea" only tells you how people reacted. "They showed us the spreadsheet they spend two hours updating every Friday" is evidence.

In many organizations, a user's need passes through several people before it reaches an engineer: support or sales, a product manager, a designer, and finally a ticket. Each handover loses some of what the user meant, and often adds someone's proposed solution.

One example from the day. A user tells support: "I need to change my address." The ticket says "Allow users to edit their saved address", and that is what gets built. But the user was away from home and wanted to redirect a delivery arriving tomorrow. The feature works as specified and still doesn't solve the problem.

With AI, there is now one more layer. The engineer describes the work, and the AI writes the code. The AI only knows what the engineer tells it, so the result can be no better than the engineer's understanding of the user. Prompt quality is context quality.

That makes it more important than ever for engineers to get close to users, for example by reading support tickets and app reviews, or by joining user interviews and customer calls. It's also why context is part of how we build at Framna: the more each team knows about its users and earlier decisions, the better the people directing the work, and the agents doing it, can build.

Every prototype should answer a specific question. So pick the lowest-fidelity way to answer it: a sketch, a fake door or a feature flag.

Prototypes now take an afternoon instead of a sprint, so build three rough versions instead of one polished one. Then decide whether to ship, kill or reframe. The bottleneck has moved from building things to evaluating them.

We see the same pattern in our survey of 530 people who design, build and lead digital products. 64% ship more than before, but only 43% deliver faster than a year ago. And a third name the speed of decision-making as one of the things slowing them down.

AI has made it cheaper to build almost anything. It hasn't made it any easier to know what's worth building. That part was always the real craft of engineering, and it is becoming the most valuable part.

One habit to take from the day: next time you are asked to build something that feels wrong, ask what the person is trying to accomplish. Then find the assumption that has to hold, and suggest a cheap way to test it.

We can run a version of the engineering masterclass with your own engineers, built around your product and the decisions in front of you.