DEV Community: Bjørn Nordlund

We get feedback too late

Bjørn Nordlund — Tue, 16 Jun 2026 22:15:27 +0000

We talk a lot about shipping faster now, but I think the more interesting question is how fast we learn that we are building the wrong thing.

Most teams do get feedback. They do beta tests, they invite a few customers, they open a channel somewhere, and then they can say the feature was validated before GA. But if we are honest, a lot of the time the feedback comes after the important decisions are already made.

You work on something for six months. Architecture is decided, workflows are decided, the internal demo has gone well, the release date is starting to feel real. Then you run a beta for a couple of weeks, collect a handful of comments, fix the obvious bugs, maybe polish one screen, and ship. The beta was there, but it was too late to change the shape of the thing.

That pattern is everywhere. I have done it plenty of times. We call it feedback, but often it is closer to release insurance.

The problem is not that we do not ask

The problem is that we ask when the cost of listening is already too high.

When you are early, feedback is useful because you can still throw things away. When you are late, feedback becomes uncomfortable because every real answer implies rework. So we naturally start filtering for what can fit into the plan we already have.

This is why I am interested in feedback loops that happen while the idea is still soft. Not more surveys. Not more dashboards. Just faster contact with reality.

Before you spend months building the feature, can you show someone the workflow? Before you decide what needs documentation, can you watch where people get lost? Before you argue about what users will do, can you compare your guesses with a few real attempts?

That sounds obvious, but it is surprisingly hard in normal product work. The actual product is messy. The knowledge is split between PMs, designers, support, engineers, sales, and users. A lot of the discussion happens around screenshots, remembered demos, old tickets, and whatever someone can describe in a meeting.

Why I am building Cartographer

Cartographer started from a simple idea: show the system how an application works by using it, then let it build a map of screens, actions, and flows.

The AI part is useful when it can help us get to criticism earlier. Not friendly generic feedback like "this looks good, maybe improve onboarding", but more realistic reviews grounded in how the product actually works. What would a busy admin notice? Where would a new user get stuck? What would someone misunderstand because the current flow teaches the wrong thing?

That is different from asking a model to review a screenshot or a static mockup. If the system has seen the real product, the review can be about the product in context. It can see the screens before and after, the actions that are available, the paths people need to take, and the awkward places where the product says one thing but behaves like another.

This is also where I think it can be faster and in some ways more real than starting with a Figma prototype. Figma is great, and I want Cartographer to integrate with it, because teams already design and test there. But a Figma prototype often starts as an idealized version of the product. Cartographer starts from the actual thing users are already fighting with. The old flows, the weird naming, the missing empty states, the settings page nobody wants to touch. That context matters if you want critical feedback instead of design feedback only.

If a team can record the current product in a few minutes, they have something concrete to look at together. If they can generate a proposed flow or prototype from that map, they have something to review before committing months to it. If they can ask for critical persona reviews and then compare those expectations with real user feedback, the conversation becomes less about who sounds most convincing in the room.

I want the team to be able to say: this is how the product works today, this is the change we think matters, this is where different users are likely to struggle, this is what the AI review warned us about, and this is what actually happened when someone tried it.

Quality is not slow

When the tools get faster it is easy to just make more of everything. More prototypes, more docs, more tickets, more code, more ideas to look at. I get why that feels useful, and I do it too, but I do not think more output is the thing most teams are missing.

But I do not think quantity is the interesting part. A team drowning in half finished ideas does not need ten more. It needs a faster way to find the one thing that matters and a safer way to stop doing the rest.

For me, quality means the important problems are visible early. It means feedback is not a ceremony near the end, but part of how the work moves. It means you can ship a small slice, learn something real, and let that change the next slice.

It also means working more like a team. Not one person disappearing into Cursor for a week and coming back with a mountain of plausible code. More shared context, more discussion, more disagreement before the thing hardens.

That is the part I want Cartographer to help with. Not replace the people. Not automate the product judgement. Just make the thing in front of us concrete enough that we can talk about it properly.

What I want to test

The current version lets you record an application with a Chrome extension, build a map, edit it, generate documentation, create prototypes, run persona reviews, and collect real feedback from testers.

That is a lot of pieces, and some of them are rough. I am not trying to pretend this is a finished product. What I am trying to find out is whether this kind of workflow can make feedback feel closer to the work, instead of something that happens after everyone has already moved on.

The useful version of Cartographer is not the one with the longest feature list. It is the one where a team can look at the product as it is, try an idea early, get a critical read on it, and still have time to change direction.

I do not see this as competing with user testing based on Figma. I think it should connect to it. Sometimes the right thing is a Figma prototype and a structured user test. Sometimes the fastest useful thing is to record the existing product, generate a rough version of the change, and ask for criticism before design work gets too polished. The important part is not which artifact wins. The important part is that feedback happens while it can still change the work.

That is the direction I want to take it. If you try it, I would love to hear what feels useful, what feels like noise, and where this could fit into how your team already works.

Web app: cartographer-six.vercel.app | GitHub

Your agent writes code fast. But who challenges the decisions?

Bjørn Nordlund — Wed, 06 May 2026 10:31:55 +0000

A user reports the dashboard is slow. The spec says "improve dashboard load time." In twenty minutes your agent has built a caching layer, a new read-optimized table, and a background job system. The code looks clean, PR looks good, it gets approved. Nobody asks if this could just be an unindexed query.

You're sitting alone with your agent

You're sitting there with Cursor or whatever, building fast, you are in the flow, and there's nobody pushing back. No PM going "wait, that's not what the customer asked for." No teammate saying "didn't we agree on something different last week?" Just you and the agent, and the agent does what you tell it to. The specs live in Jira or someone's head and you're not checking it while you code. The features drift, and nobody notices until it has shipped.

Code reviews don't always help. So much AI generated code, we see the diff and maybe a PR description. But by the time code is in a PR you've already kind of agreed that the thing should exist, so nobody questions "are we building the right thing?".

Specs next to your code

Keeping specs close to the code isn't a new idea. There's been executable specs and living documentation forever. Spec-driven development is getting more attention now with AI agents. Whether you vibe code, write specs first or code first, it doesn't matter that much. The point is to have something that says what you're building and why.

I (or Cursor and I) built a skill for this. A few markdown files per feature in a specs/ folder: who it's for, why it exists, what counts as done. It works like a kind of agent memory that lives in your repo instead of disappearing in a chat thread. The agent maintains it as part of normal coding, reads the specs before making changes, and keeps them in sync when you change direction.

npx skills add bjornno/skills --skill storyline

Getting people to confront the hard questions

But specs nobody challenges are just documentation. What I wanted to solve is how do you get people to confront the hard questions while there is still time to change direction.

The skill has a review mode. Say "start review" and the agent reads your specs and diff. It finds the most important risk and confronts you with it. Yes, No, or Unsure. Then it walks you through the discussion.

This works best when it's not just you. Get the team around a screen, pull in the PM, designer, whoever. Start the review, share your screen, and let it drive. The agent asks, the team decides.

Here's how it could look:

Premature implementation

The spec says "improve load time" but there's no evidence the root cause was identified. A caching layer, a new table, and a job system were built before anyone checked if it's just one unindexed query.

Are you comfortable investing in this architecture without profiling the actual bottleneck first?

Yes / No / Unsure

Maybe someone says: "wait, did anyone run EXPLAIN on that query?" Or the PM says "the user only complained about one page, not the whole dashboard." It will ask follow-up questions based on what you answered, until there's an actual decision. The decision is added back to the specs in specs/reviews/ so you keep the history, instead of a Slack thread nobody will find again.

Hosted reviews

Sometimes you can't get everyone around a screen. Different timezones, or you just want a review on every PR automatically. I built a hosted version for that with the same review logic but as a Web App and a GitHub Action. Log in with your GitHub account.

Tell me what's missing

If you know of something that does this better, I want to hear about it. I've looked around and haven't found this combination of "agent maintains specs and then uses them to challenge decisions" but I might have missed it. Try it and tell me if this actually helps or if this is just me deep down in my AI rabbit hole together with Cursor. The point is getting people to think and talk, not to use more tokens.

Install: npx skills add bjornno/skills --skill storyline | GitHub
Hosted Reviews: npx storyline-review create | storyline-review.vercel.app