Building with AI: Amplifying Design
Dashboards are the pinnacle of every great product, right? 🙄 Well, I actually needed a small dashboard to see what features users of my lineup builder (opstillingen.dk) were using.
Now that I could dig into what was happening on a more granular level, I could make better decisions on what to pursue. That’s a task right there. Felt like it might as well belong alongside the basis of the decision.
Since then it got smarter - it now looks at the task descriptions, the project the tasks belongs to, and hands me a ready prompt.
The task manager is interesting to work with, I’ve patched together a lot of steps in the distributed flow of understanding a problem, thinking about it, shaping it, building the proposed solution and testing it.
Next thing is getting the full loop in place, adding the relevant data points to the individual tasks. Then, the events dashboard will lose it’s place again. I actually don’t need to see the data, what I need to know is that I act on the right things.
I get to decide excatly just how much confetti is needed when a task is complete. I need a lot of confetti.
Not everything is a task. Not everything is a note.
I’ve always juggled two tools when organising my work (and thoughts). I always begin with writing. Stream of conciousness style writing. It mirrors how I think, more than a jira task structure can ever do.
I’ve been using Apple Notes for thinking, and a task app for doing, and a constant low tax of moving things between them. The two were never really separate; I'd just been told they were by every app I've used.
So I put them together. Right next to the tasks, there's a scratchpad where I write loosely, the way you actually think: half-formed, contradictory, a question and its own answer two lines apart. When a sentence in there turns out to be a real piece of work, I highlight it and make a task from it on the spot.
None of that is clever engineering. It's a tool shaped like how I work, which is the whole privilege of building your own.
Claude this
The next thing it learned to do is where it stopped being a to-do list.
Each project I build has its own architecture written down: how it's structured, the rules it follows, the patterns I've committed to. When I open a task now, there's a button that says Claude this. It takes the task, reads that project's architecture, and hands back a prompt precise enough to paste straight into Claude Code and get the right thing built. Not a vague request. A brief that already knows the codebase it's going into.
So why not write the task description directly in Claude Code or wherever I hang out these days?
It requires a lot of precision to get anything to build in the right way. It needs specifiying, updating instructions, and all kinds of things that feels very far from feeling creative. Maybe that’s just me. Every project is differently structured, but my tasks are all the same. So having the task manager look up the context, and create the prompt based on all those constraints.. well, that feels right.
Large features requires a plan. Small features doesn’t. Bugs have a different structure than a new feature, etc.
And it compounds. Substantial changes adds to the architecture-files in the respective project. Every new project that adopts the same structure inherits the whole machine for free. I built it to scratch one itch and it quietly became infrastructure.
Projects contexts
projects/
│
├─ opstillingen/
│ ├─ ARCHITECTURE.md
│ ├─ ROADMAP.md
│ ├─ EVENTS.md
│ ├─ FORMATIONS.md
│ └─ INFRASTRUCTURE.md
│
├─ findenklub/
│ ├─ ARCHITECTURE.md
│ ├─ SEO.md
│ └─ AARGANG_REGLER.md
│
├─ danish-football-clubs/
│ ├─ ARCHITECTURE.md
│ ├─ SCRAPING.md
│ ├─ WORKFLOW.md
│ └─ VERSIONING.md
│
└─ unitwiz/
├─ ARCHITECTURE.md
├─ DESIGN.md
└─ ROADMAP.md
The button I haven't pressed
The obvious last step is to take my hand off it entirely: let it read the roadmap and just build, task after task, no prompt to paste, no me in the loop. The pipeline is most of the way there. I haven't switched it on.
Two things stop me, and neither is dramatic. The first is regression testing. Let it run loose and it will fix one thing while silently breaking three others, and I won't find out until something I cared about is already gone. The second is quieter and more honest: the scaffolding is only as good as I made it. And keep it. The moment it leaves too much up for interpretation, experience tells me it gets worse. It’s funny right - we can get AI to create anything, but the less specific we are about exactly what we want, the more useless it gets. It’s all about language. I wrote a piece on that a while ago.
So for now my contribution is a single press of a button, and that suits me. The deciding stays mine. The making is what I'm handing over.
How it’s built
A ShadCN React dashboard, the Claude API, and each project's own architecture docs as the context the agent reads. Notes and tasks share one store; "Claude this" composes a build-ready prompt against the relevant project. Vanilla everywhere it can be, no framework underneath the apps it serves.
Three live apps wired in so far. Every project built on the same structure inherits the machinery without extra work.
What didn't change
When I skip properly shaping a feature and dive into build mode because building is now so cheap, it goes wrong the same way it always did. I start asking the real questions too late, after I've already built the answer to the wrong one. Cheap production makes that trap more tempting, not less.
The work that mattered before, deciding what deserves to be built at all, is exactly the work that still matters, and the only work the machine can't do for me. That's the thing I keep relearning. Not everything needs to be executed on. It never did.
This is discovery work where I'm both the inventor and the subject. I build a thing, try it on, keep what earns its place and scrap what felt better in my head than in the browser. The task manager is the one that earned its place. It isn't finished, and the most interesting feature is the one I'm still too careful to turn on. That feels about right.
Building with AI: Amplifying Design
A task manager that can build too. It started as an events dashboard, now it has tasks that reads each project's architecture and hands back a prompt ready to build. Built solo to learn the tools, kept because it compounds.
2026
Personal projects
Dashboards are the pinnacle of every great product, right? 🙄 Well, I actually needed a small dashboard to see what features users of my lineup builder (opstillingen.dk) were using.
Now that I could dig into what was happening on a more granular level, I could make better decisions on what to pursue. That’s a task right there. Felt like it might as well belong alongside the basis of the decision.
Since then it got smarter - it now looks at the task descriptions, the project the tasks belongs to, and hands me a ready prompt.
The task manager is interesting to work with, I’ve patched together a lot of steps in the distributed flow of understanding a problem, thinking about it, shaping it, building the proposed solution and testing it.
Next thing is getting the full loop in place, adding the relevant data points to the individual tasks. Then, the events dashboard will lose it’s place again. I actually don’t need to see the data, what I need to know is that I act on the right things.
I get to decide excatly just how much confetti is needed when a task is complete. I need a lot of confetti.
Not everything is a task. Not everything is a note.
I’ve always juggled two tools when organising my work (and thoughts). I always begin with writing. Stream of conciousness style writing. It mirrors how I think, more than a jira task structure can ever do.
I’ve been using Apple Notes for thinking, and a task app for doing, and a constant low tax of moving things between them. The two were never really separate; I'd just been told they were by every app I've used.
So I put them together. Right next to the tasks, there's a scratchpad where I write loosely, the way you actually think: half-formed, contradictory, a question and its own answer two lines apart. When a sentence in there turns out to be a real piece of work, I highlight it and make a task from it on the spot.
None of that is clever engineering. It's a tool shaped like how I work, which is the whole privilege of building your own.
Claude this
The next thing it learned to do is where it stopped being a to-do list.
Each project I build has its own architecture written down: how it's structured, the rules it follows, the patterns I've committed to. When I open a task now, there's a button that says Claude this. It takes the task, reads that project's architecture, and hands back a prompt precise enough to paste straight into Claude Code and get the right thing built. Not a vague request. A brief that already knows the codebase it's going into.
So why not write the task description directly in Claude Code or wherever I hang out these days?
It requires a lot of precision to get anything to build in the right way. It needs specifiying, updating instructions, and all kinds of things that feels very far from feeling creative. Maybe that’s just me. Every project is differently structured, but my tasks are all the same. So having the task manager look up the context, and create the prompt based on all those constraints.. well, that feels right.
Large features requires a plan. Small features doesn’t. Bugs have a different structure than a new feature, etc.
And it compounds. Substantial changes adds to the architecture-files in the respective project. Every new project that adopts the same structure inherits the whole machine for free. I built it to scratch one itch and it quietly became infrastructure.
Projects contexts
projects/
│
├─ opstillingen/
│ ├─ ARCHITECTURE.md
│ ├─ ROADMAP.md
│ ├─ EVENTS.md
│ ├─ FORMATIONS.md
│ └─ INFRASTRUCTURE.md
│
├─ findenklub/
│ ├─ ARCHITECTURE.md
│ ├─ SEO.md
│ └─ AARGANG_REGLER.md
│
├─ danish-football-clubs/
│ ├─ ARCHITECTURE.md
│ ├─ SCRAPING.md
│ ├─ WORKFLOW.md
│ └─ VERSIONING.md
│
└─ unitwiz/
├─ ARCHITECTURE.md
├─ DESIGN.md
└─ ROADMAP.md
The button I haven't pressed
The obvious last step is to take my hand off it entirely: let it read the roadmap and just build, task after task, no prompt to paste, no me in the loop. The pipeline is most of the way there. I haven't switched it on.
Two things stop me, and neither is dramatic. The first is regression testing. Let it run loose and it will fix one thing while silently breaking three others, and I won't find out until something I cared about is already gone. The second is quieter and more honest: the scaffolding is only as good as I made it. And keep it. The moment it leaves too much up for interpretation, experience tells me it gets worse. It’s funny right - we can get AI to create anything, but the less specific we are about exactly what we want, the more useless it gets. It’s all about language. I wrote a piece on that a while ago.
So for now my contribution is a single press of a button, and that suits me. The deciding stays mine. The making is what I'm handing over.
How it’s built
A ShadCN React dashboard, the Claude API, and each project's own architecture docs as the context the agent reads. Notes and tasks share one store; "Claude this" composes a build-ready prompt against the relevant project. Vanilla everywhere it can be, no framework underneath the apps it serves.
Three live apps wired in so far. Every project built on the same structure inherits the machinery without extra work.
What didn't change
When I skip properly shaping a feature and dive into build mode because building is now so cheap, it goes wrong the same way it always did. I start asking the real questions too late, after I've already built the answer to the wrong one. Cheap production makes that trap more tempting, not less.
The work that mattered before, deciding what deserves to be built at all, is exactly the work that still matters, and the only work the machine can't do for me. That's the thing I keep relearning. Not everything needs to be executed on. It never did.
This is discovery work where I'm both the inventor and the subject. I build a thing, try it on, keep what earns its place and scrap what felt better in my head than in the browser. The task manager is the one that earned its place. It isn't finished, and the most interesting feature is the one I'm still too careful to turn on. That feels about right.
Building with AI: Amplifying Design
A task manager that can build too. It started as an events dashboard, now it has tasks that reads each project's architecture and hands back a prompt ready to build. Built solo to learn the tools, kept because it compounds.
2026
Personal projects
Dashboards are the pinnacle of every great product, right? 🙄 Well, I actually needed a small dashboard to see what features users of my lineup builder (opstillingen.dk) were using.
Now that I could dig into what was happening on a more granular level, I could make better decisions on what to pursue. That’s a task right there. Felt like it might as well belong alongside the basis of the decision.
Since then it got smarter - it now looks at the task descriptions, the project the tasks belongs to, and hands me a ready prompt.
The task manager is interesting to work with, I’ve patched together a lot of steps in the distributed flow of understanding a problem, thinking about it, shaping it, building the proposed solution and testing it.
Next thing is getting the full loop in place, adding the relevant data points to the individual tasks. Then, the events dashboard will lose it’s place again. I actually don’t need to see the data, what I need to know is that I act on the right things.
I get to decide excatly just how much confetti is needed when a task is complete. I need a lot of confetti.
Not everything is a task. Not everything is a note.
I’ve always juggled two tools when organising my work (and thoughts). I always begin with writing. Stream of conciousness style writing. It mirrors how I think, more than a jira task structure can ever do.
I’ve been using Apple Notes for thinking, and a task app for doing, and a constant low tax of moving things between them. The two were never really separate; I'd just been told they were by every app I've used.
So I put them together. Right next to the tasks, there's a scratchpad where I write loosely, the way you actually think: half-formed, contradictory, a question and its own answer two lines apart. When a sentence in there turns out to be a real piece of work, I highlight it and make a task from it on the spot.
None of that is clever engineering. It's a tool shaped like how I work, which is the whole privilege of building your own.
Claude this
The next thing it learned to do is where it stopped being a to-do list.
Each project I build has its own architecture written down: how it's structured, the rules it follows, the patterns I've committed to. When I open a task now, there's a button that says Claude this. It takes the task, reads that project's architecture, and hands back a prompt precise enough to paste straight into Claude Code and get the right thing built. Not a vague request. A brief that already knows the codebase it's going into.
So why not write the task description directly in Claude Code or wherever I hang out these days?
It requires a lot of precision to get anything to build in the right way. It needs specifiying, updating instructions, and all kinds of things that feels very far from feeling creative. Maybe that’s just me. Every project is differently structured, but my tasks are all the same. So having the task manager look up the context, and create the prompt based on all those constraints.. well, that feels right.
Large features requires a plan. Small features doesn’t. Bugs have a different structure than a new feature, etc.
And it compounds. Substantial changes adds to the architecture-files in the respective project. Every new project that adopts the same structure inherits the whole machine for free. I built it to scratch one itch and it quietly became infrastructure.
Projects contexts
projects/
│
├─ opstillingen/
│ ├─ ARCHITECTURE.md
│ ├─ ROADMAP.md
│ ├─ EVENTS.md
│ ├─ FORMATIONS.md
│ └─ INFRASTRUCTURE.md
│
├─ findenklub/
│ ├─ ARCHITECTURE.md
│ ├─ SEO.md
│ └─ AARGANG_REGLER.md
│
├─ danish-football-clubs/
│ ├─ ARCHITECTURE.md
│ ├─ SCRAPING.md
│ ├─ WORKFLOW.md
│ └─ VERSIONING.md
│
└─ unitwiz/
├─ ARCHITECTURE.md
├─ DESIGN.md
└─ ROADMAP.md
The button I haven't pressed
The obvious last step is to take my hand off it entirely: let it read the roadmap and just build, task after task, no prompt to paste, no me in the loop. The pipeline is most of the way there. I haven't switched it on.
Two things stop me, and neither is dramatic. The first is regression testing. Let it run loose and it will fix one thing while silently breaking three others, and I won't find out until something I cared about is already gone. The second is quieter and more honest: the scaffolding is only as good as I made it. And keep it. The moment it leaves too much up for interpretation, experience tells me it gets worse. It’s funny right - we can get AI to create anything, but the less specific we are about exactly what we want, the more useless it gets. It’s all about language. I wrote a piece on that a while ago.
So for now my contribution is a single press of a button, and that suits me. The deciding stays mine. The making is what I'm handing over.
How it’s built
A ShadCN React dashboard, the Claude API, and each project's own architecture docs as the context the agent reads. Notes and tasks share one store; "Claude this" composes a build-ready prompt against the relevant project. Vanilla everywhere it can be, no framework underneath the apps it serves.
Three live apps wired in so far. Every project built on the same structure inherits the machinery without extra work.
What didn't change
When I skip properly shaping a feature and dive into build mode because building is now so cheap, it goes wrong the same way it always did. I start asking the real questions too late, after I've already built the answer to the wrong one. Cheap production makes that trap more tempting, not less.
The work that mattered before, deciding what deserves to be built at all, is exactly the work that still matters, and the only work the machine can't do for me. That's the thing I keep relearning. Not everything needs to be executed on. It never did.
This is discovery work where I'm both the inventor and the subject. I build a thing, try it on, keep what earns its place and scrap what felt better in my head than in the browser. The task manager is the one that earned its place. It isn't finished, and the most interesting feature is the one I'm still too careful to turn on. That feels about right.