DEV Community: Christoffer Madsen

I Built Something Good With AI. Now Some Developer Communities Don't Want to See It.

Christoffer Madsen — Sun, 26 Jul 2026 20:53:41 +0000

I recently tried to share an open-source project I've been working on called Open Vectorizer.

It's a raster-to-SVG vectorization engine written in Rust. It runs locally, compiles to WebAssembly, has a reproducible benchmark suite, and competes surprisingly well with established tools like Potrace and VTracer.

I wanted people to see it.

More importantly, I wanted contributors.

That's where things got weird.

First, Hacker News

Open Vectorizer felt like a natural fit for Show HN.

It's open source. It's technical. There's an interesting algorithm behind it. There are benchmarks people can reproduce and argue about, which I'm told is approximately 73% of Hacker News' renewable energy supply.

Except I couldn't submit a Show HN.

Hacker News is temporarily restricting Show HN submissions from newer users because of a large influx of people unfamiliar with the community.

Fair enough.

Annoying, but understandable.

So I tried Reddit.

Then r/rust

Open Vectorizer is written in Rust, so r/rust seemed like an even more obvious place to share it.

The post was automatically removed.

The subreddit now requires project submissions to certify that they do not contain significant AI-generated content.

And that's something I can't honestly certify.

Open Vectorizer has been developed with substantial AI assistance.

So I didn't repost it.

Then r/opensource

Surely an MIT-licensed project actively looking for contributors belongs in an open-source community.

Their rules include:

All AI-generated content is low-effort and ban worthy.

At this point I had to appreciate the situation.

I had an open-source project.

I wanted humans to contribute to it.

And some of the communities containing exactly those humans didn't want me to tell them about it because machines had helped write it.

Here's the problem

I actually understand why these rules exist.

AI has made it incredibly cheap to produce software-shaped objects.

You can ask an agent to build a database, publish 20,000 lines to GitHub an hour later, write a triumphant launch post and have absolutely no idea whether the thing works.

Developer communities are being flooded with this stuff.

That's a real problem.

But I think we're using the wrong filter.

"Was AI used to write this?" is increasingly becoming a poor proxy for "Is this low-effort garbage?"

Those are not the same question.

What does "AI-generated" even mean anymore?

Imagine five developers.

Developer A writes everything manually but uses IDE autocomplete.

Developer B uses GitHub Copilot for completions.

Developer C asks an agent to implement individual functions from detailed specifications.

Developer D designs the architecture, writes tests, evaluates results and delegates much of the implementation to coding agents.

Developer E types:

make me a vectorizer

They publish whatever comes back.

Which projects are AI-generated?

There's an obvious difference between D and E.

But drawing the line based on how many characters were physically typed by a human doesn't capture that difference particularly well.

And that distinction is only going to become harder to make.

Open Vectorizer is a useful example

The first version of Open Vectorizer wasn't good enough.

It followed a relatively conventional vectorization pipeline: find pixel boundaries, simplify them and fit curves.

The results weren't terrible.

They also weren't good.

Circles weren't quite circular. Sharp geometry got damaged. Small raster imperfections became vector imperfections.

Eventually I stopped working on it.

Later, I revisited the problem with AI assistance.

We investigated whether machine learning was the answer. We discussed training a small vision model on synthetic SVG-to-PNG data.

It probably could have worked.

I decided against it.

Instead, the underlying deterministic algorithm was redesigned.

The important realization was that anti-aliased pixels aren't simply noise to discard. They contain information about how much of the original geometry covered each pixel.

Open Vectorizer now uses that information to reconstruct boundaries at sub-pixel precision. It detects corners and geometric primitives, generates candidate representations, rasterizes those candidates back into pixels and measures how accurately they reproduce the source.

That's how it can take a rasterized circle and produce an actual SVG circle instead of a vaguely circular collection of Bézier points.

AI helped develop that system.

The vectorizer itself doesn't use AI.

So is Open Vectorizer AI-generated software?

Apparently, yes.

But that description tells you remarkably little about its quality.

Then the AI found a bug that made our benchmark look better

This happened while preparing a visual comparison for the project.

The benchmark compares Open Vectorizer against Potrace and VTracer. One metric is the number of vector nodes required to represent the result.

While regenerating the comparison, the coding agent discovered that our node-counting implementation was wrong.

Different SVG generators close paths differently.

Our benchmark accidentally gave Open Vectorizer one fewer node than it deserved on closed paths while charging Potrace an extra node.

That's quite an inconvenient bug when you're trying to demonstrate that your software produces simpler geometry.

So we fixed it.

We regenerated the tables.

Open Vectorizer's numbers got worse.

VTracer went from beating it on node count in 2 of 17 cases to beating it in 5.

We documented why several of those cases occur and added the underlying inefficiency to the project's TODO list.

The accuracy results, incidentally, still reproduced exactly.

That's the development process I want from software, regardless of whether the person finding the bug contains carbon.

Judge the artifact

Maybe the questions we should be asking about AI-assisted open-source projects are different.

Instead of:

Did AI write significant portions of this?

Ask:

Can the maintainer explain the architecture?
Is the source available?
Are there meaningful tests?
Can its claims be independently reproduced?
Are benchmarks transparent?
Are weaknesses disclosed?
Does the maintainer review and take responsibility for changes?
Are bug reports actually understood and fixed?
Is the project maintained after the initial generation?
Can contributors challenge technical decisions?

Those questions tell me considerably more about whether I want to use or contribute to a project.

And they work equally well for human-written software.

Humans, inconveniently, have been producing terrible code since decades before ChatGPT arrived.

AI assistance doesn't remove responsibility

This isn't an argument that AI-generated code is automatically good.

Quite the opposite.

If I use a coding agent and it introduces a vulnerability, that's my problem.

If it produces an algorithm I don't understand, I shouldn't ship it.

If it invents benchmark results, I am responsible for publishing false information.

Using AI shouldn't reduce the standard.

It should increase the burden on the maintainer to demonstrate that the result actually works.

That's why reproducibility matters.

That's why tests matter.

That's why admitting where your competitor beats you matters.

"I used AI" isn't a defense against bad engineering.

But neither should it automatically invalidate good engineering.

The irony for open source

The strangest part of this experience is that I specifically want Open Vectorizer to become less dependent on me and my coding agents.

I want someone who knows computational geometry to look at the curve fitting and tell me it's stupid.

I want a Rust developer to make the coverage decomposition faster.

I want someone who understands SVG internals better than I do to improve stroke reconstruction.

I want someone to submit an algorithm I hadn't considered.

In other words:

I want human contributors.

But to find them, I need to be able to show humans the project.

Rejecting AI-assisted projects categorically creates a strange loop where projects developed by individuals with AI assistance have fewer opportunities to evolve into genuinely collaborative open-source projects.

That seems counterproductive.

We need a better distinction

I don't think developer communities should simply throw their doors open to unlimited AI-generated project spam.

Nobody wants that.

Moderation is necessary.

But perhaps the distinction shouldn't be:

Human-generated vs AI-generated.

Maybe it should increasingly be:

Maintained engineering vs generated slop.

Did somebody actually make decisions?

Did they evaluate the output?

Did they understand it?

Did they test it?

Will they maintain it?

Can they defend its claims?

Are they accountable for what they published?

Those are harder questions to moderate.

Unfortunately, they're also the questions that matter.

Because AI-assisted development isn't going away.

And as the tools improve, determining whether a particular function was typed by a human, generated by Copilot, implemented by Claude from a specification, or refactored by an autonomous agent will become increasingly meaningless.

The software still has to work.

Someone still has to be responsible for it.

And if it does something interesting, I'd still like to be allowed to tell other developers about it.

(AI was used to write this article)

Working 30% on a 100% Job: What I Learned as a Solo Developer

Christoffer Madsen — Tue, 25 Nov 2025 13:31:18 +0000

There’s something I wish more employers understood — something I didn’t fully have the words for until I lived through it myself:

when a developer says the work requires a full-time position, they’re not exaggerating. They’re telling you what it actually takes to build the thing you’re asking for.

I learned that lesson from the inside, as the developer whose role didn’t match the expectations placed on it.

Stepping into a system built on shaky ground

A while back, I joined a small Norwegian company as their only developer. They handled services related to cemeteries and memorials, and they had a system that had grown organically over the years. The database was… let’s say “creatively structured,” and every architectural decision seemed to lean in a different direction.

I wanted to do good work, so I began the slow process of rebuilding, refactoring, and trying to bring some order to the chaos.

But I was hired at just 30% employment.

That number quickly became its own kind of constraint. Every task required more context-switching. Every bug meant reacquainting myself with parts of the system I hadn’t touched in weeks. Things that should have been straightforward became long, fragmented stretches of work that never quite fit together cleanly.

Expectations that didn’t match reality

Despite the part-time contract, the expectations were… not part-time.

There was a steady stream of pressure to move faster, fix more, deliver more. “Why isn’t this ready yet?” became a familiar question. I explained — more than once — that the work required more hours. That rebuilding a shaky system isn’t something you can do in small bursts. That software needs focus, not fragmented leftovers.

I was told repeatedly that my position would be increased. “Soon,” or “next month,” or “once a few things settle internally.”

But those promises never became reality.

The quiet feeling of being set up to fail

Looking back now, I can see the imbalance more clearly. They wanted stability built on top of a foundation that needed replacing. They wanted polish when I barely had time to sketch prototypes. They wanted full-time output while keeping me in a part-time role.

At the time, I pushed through because I cared. When you’re the only developer, you carry the work in your mind even when you’re not being paid for it. You want the system to succeed, even when the conditions make that nearly impossible.

And then things fell apart

Eventually, progress slowed — not because of lack of willingness, but because there were simply not enough hours to solve the problems in front of me. The system wasn’t where they wanted it to be. It had bugs. It needed more refinement.

All of that was true.

But the missing piece was the time I never received.

In the end, I was let go — just three days before my parental leave.
It took a while for the silence of that moment to settle.

What I took with me

I’m not sharing this to blame or to vent. I’m sharing it because I know other developers end up in similar situations:
the lone engineer carrying an entire product, expected to deliver more than the hours, support, or structure will ever realistically allow.

If there’s one thing this experience taught me, it’s this:

When a developer tells you the work requires a full-time position, listen.
They’re not asking for more hours for themselves — they’re asking for enough space to build something stable, reliable, and meaningful.

I’ve carried that lesson with me into every role since.
And if it helps even one other developer recognize the signs earlier than I did, then the experience becomes something I can look back on with a little more clarity — and a lot more purpose.

The Quiet Threat of AI “Undress” Apps

Christoffer Madsen — Mon, 24 Nov 2025 11:21:54 +0000

Why the tech matters far less than the harm

AI tools that supposedly “remove clothes” from photos aren’t new, but their leap into the mainstream signals something more troubling than a technical novelty. What used to live on the fringes—crude, hidden, and hard to access—is now polished, widespread, and nearly impossible to contain in an open-source world. But focusing on the tools themselves misses the point. The problem isn’t the AI. It’s what this trend reveals about consent, power, and the normalization of digital violations.

This is a human problem wearing a technological mask.

A Violation Without Physical Contact

Non-consensual sexual imagery has always been a form of harm. AI doesn’t change that—it expands it. These apps fabricate what they show, yet the emotional shock, shame, and reputational damage often mirror the impact of actual voyeurism.

For victims, whether the image is “real” is irrelevant.
Being unwillingly sexualized is still a violation.

And that’s precisely why this technology is corrosive. It makes a harmful act effortless. No skill, no risk, no access to private photos—just a single image and a few seconds of processing.

Consent Doesn’t Scale. Technology Does.

Consent is contextual and inherently human. It doesn’t scale. But AI does. Frictionlessly.

A single everyday photo—your LinkedIn picture, a selfie, a family snapshot—can be turned into something sexualized and permanent. What used to be ordinary digital presence is now ammunition.

And as always, the groups most targeted offline—women, minors, LGBTQ individuals, people of color, and anyone marginalized—face the greatest risk online.

The Social Fallout We Aren’t Ready For

Policymakers are busy debating the boundaries of AI innovation, but these apps expose an older fracture in our culture:

1. Non-consensual behavior becomes normalized.
When creating sexualized images becomes trivial, expectations of privacy erode with it.

2. Visual truth becomes unreliable.
If fabrication is cheap, weaponizing it becomes easy. Blackmail, defamation, and “proof” lose meaning.

3. The psychological toll is real.
Even knowing an image is fake doesn’t erase the humiliation or fear.

4. Public complacency grows.
Frequent exposure—headlines, memes, viral demos—makes us treat violations as spectacle rather than harm.

The Tech Isn’t the Problem—We Are

It’s tempting to call this an AI ethics issue, but that softens the responsibility. AI didn’t invent exploitation; it lowered the bar for it. The real issue is the willingness of people to cross boundaries they would never cross face-to-face.

Technology doesn’t reshape our values so much as it reveals them.

The popularity of these tools shows that a significant number of people are comfortable violating someone’s digital autonomy—and once those boundaries crumble online, the physical world isn’t far behind.

What Needs to Change

No single solution will fix this, but several shifts can make a difference:

Clear laws that treat synthetic sexual content of real individuals as a violation—no matter how “fake” it is.
Cultural norms that regard using someone’s image without consent as abuse, not entertainment.
Better education on consent as an ongoing, specific agreement—not a permission slip for image manipulation.
Platforms with real accountability and fast, decisive takedown processes.

But most crucially, we need a collective understanding that digital boundaries matter just as much as physical ones.

The Bigger Question

AI didn’t create the impulse to sexualize someone without their consent; it simply removed the difficulty. What we’re confronting isn’t a technological leap but an ethical one.

The real question isn’t how these tools work.
It’s what their popularity reveals about us—and whether we’re willing to push back against a culture that treats a person’s image as public property rather than part of their identity.

The Tool I Finally Built to Escape My Terminal Chaos

Christoffer Madsen — Wed, 19 Nov 2025 23:05:20 +0000

There was a stretch of days where my terminal tabs felt like they were slowly multiplying behind my back.

I’d open a new project “just to try something,” hop into a client repo to fix a bug, jump into another folder because I remembered I needed to update something “real quick,” then spin up yet another experimental idea at 1 a.m. before bed. Suddenly I had four different terminals open, each running something important, each shouting logs at me, and absolutely no memory of which script belonged to which project.

And honestly?
I love creating projects.
That’s half the reason my workflow got so chaotic in the first place.

But eventually I realized a pattern:
I wasn’t spending time coding — I was spending time managing coding.

I wanted one place, a calm little command center, where I could see all my projects, what scripts they had, what was running, what wasn’t, and what was broken. No more guessing. No more hunting. No more “oh cool, I’m on the wrong branch again.”

So I built the tool I always wished I had — one place to manage all my local projects without drowning in terminals.

Why I Built Localhost Hub

At first it started with a simple frustration:
I was tired of typing npm run dev in the wrong directory.

Then it was the constant flipping between terminals.
Then it was forgetting which ports were in use.
Then it was accidentally installing dependencies in the wrong folder.
Then it was juggling frontend and backend manually every morning like some weird ritual.

And eventually I hit that moment every developer recognizes:

“Okay… this is dumb. I should automate this.”

That’s where Localhost Hub began — not as a product idea, but as the tool I needed to stay sane.

What I Wanted From It (and Why)

Here’s how the app works, but explained in the way it grew out of my own annoyances:

1. “Just scan my projects, please.”

My Projects folder is basically a nesting doll of ideas, experiments, client work, half-built things, and “I’ll come back to this someday” repos.

So I built directory scanning — point the app at a folder and it finds every package.json inside it.

No more babysitting directories.

2. “Let me run scripts without thinking about them.”

If a project has scripts, Localhost Hub lists them with start/stop buttons.

That’s it. No remembering names. No mistyping. No wondering if something is still running in a ghost terminal.

3. “If I’m starting the frontend, I probably want the backend too.”

My daily routine used to be:

cd frontend
npm run dev
cd ../backend
npm run dev
oh wait, wrong backend, cd ../backend-api
npm run dev

You get the idea.

So I added Workspaces — a way to bundle scripts across multiple projects and launch them together in one click.

4. “Please just tell me what’s broken.”

Sometimes I’d run a project and it would explode immediately because I forgot to:

install dependencies
pull changes
switch branches
or clean up something messy

So Localhost Hub shows small, quiet cues:
git status, package checks, expected ports, detected URLs.

Nothing fancy — just enough so I don’t get blindsided.

5. “Let me stay in the same mental space.”

Flipping between terminals, editors, and logs adds friction.
So inside Localhost Hub each project gets a simple dashboard:

scripts
real-time logs
packages
ports/processes
git cleanliness

All in one view, all in one place.

Not groundbreaking.
Just less mental context-switching.

What Surprised Me

The first time I used the app on my own messy setup, I didn’t expect the feeling of… calm.

It wasn’t about speed.
It wasn’t about convenience.
It was about clarity — not having dev environments scattered across terminal tabs and nested folders.

I had built something that let me focus again.

And that’s when I realized:
Sometimes the best tools aren’t the ones with the most features — they’re the ones that remove friction you’ve been carrying around for years.

Closing Thoughts

If you’re the kind of developer who loves starting new projects, or bounces between multiple repos daily, or constantly loses track of what’s running where… you might know exactly the pain that led me to build this.

Localhost Hub wasn’t meant to be “the next big dev tool.”
It was meant to be a tool that makes my own messy, creative workflow feel more manageable — and maybe it’ll resonate with someone else too.

If you’ve built something similar, or have your own hacks for taming local development chaos, I’d genuinely love to hear them. These little personal tools are often the most honest things we create.

UPDATE: If anyone is interested in trying this tool then it's available on GitHub. I have releases for .Deb and .AppImage. If you code on Mac or Windows then building on them is supported if you clone. I just don't use any of them and can't vouch for if it works well.

What’s a project you’re genuinely proud of?

Christoffer Madsen — Thu, 13 Nov 2025 12:43:14 +0000

I’ve been thinking a lot lately about how we, as developers and creators, show up online.

In my earlier posts, I talked about how hard it can be to share our work — not because we don’t build things, but because showing them to the world feels like stepping into a spotlight we’re not always ready for.

But something happened recently that made me want to flip the perspective a bit.

I want to give you the mic this time.

Before I do that, I’ll go first — because I know how much easier it feels when someone else breaks the ice.

My proudest project (right now)

Out of everything I’ve built, big or small, the thing I’m most proud of right now is Get Out There — a tiny little web app meant to help introverted or anxious creators become more comfortable posting online.

It’s simple on purpose:

One gentle daily challenge
No social pressure
Anonymous by default
No likes, no followers, no scoreboard

Just small, steady steps toward visibility.

It’s not the most complex thing I’ve ever built technically — but it’s the one that feels the most human. And that’s what makes me proud of it.

Not because it’s perfect.
Not because it’s popular.
But because it’s something I built from a place of honesty… and people told me it made them feel seen.

That means more to me than any clever code ever could.

Now I want to hear from you

Seriously.

What’s a project — big or small — that you feel proud of?

It doesn’t have to be polished.
It doesn’t have to be a portfolio piece.
It doesn’t even have to be “finished.”

It can be:

The first thing you ever shipped
A weird tool only you use
Something you built to solve your own problem
A small design that made you smile
A repo you keep tinkering with when no one is watching
A failed experiment that taught you something important

Or just a moment where you surprised yourself.

Whatever it is — I’d love to hear about it.

Not to judge.
Not to rank.
Not to compare.

Just to celebrate the fact that you made something.
And that’s worth something.

Why this matters

We’re surrounded by polished launches, big announcements, and “success stories.”
But most creativity doesn’t look like that.

Most of it happens in quiet rooms.
Late at night.
In small bursts.
On half-finished ideas.
In notebooks.
In VS Code tabs we never close.

And we rarely get to hear about those.

So today, I’d love to see the things that don’t always get shared — the ones people build because they care, because they’re curious, or because it just felt good.

Your turn

What’s a project you’re proud of?

Leave it in the comments.
Share a link if you want.
Or just describe it.
Or keep it vague.

Whatever feels comfortable — I’m here for it.

Let’s make a small space where showing up feels… a little bit easier.

I’ll be here reading every one.

I use AI when I code. And sometimes it makes me feel like I’m cheating.

Christoffer Madsen — Mon, 10 Nov 2025 19:53:15 +0000

I’ve been building things for a long time.
Websites, apps, experiments.
Some finished, most quietly left in folders with names like “v3-final-final”.

But the funny thing is:
I actually feel more capable than I used to.

I can make things faster now.
I can try ideas without worrying whether I’ll “get stuck.”
I can build things I would have been too overwhelmed to even attempt before.

And the reason is simple:

I use AI when I code.

I don’t hide that.
But I also don’t really talk about it.

Because sometimes it feels like cheating.

The quiet voice that shows up after the code runs

I’ll write something with the help of AI — something I understand, something that works — and for a few seconds I feel good about it.

And then the voice arrives:

“You didn’t really build this.”
“A real developer would have typed it themselves.”
“You’re just stitching together other people’s ideas.”
“If someone saw your process, they’d think you’re faking it.”

It’s strange how quickly pride can turn into doubt.

The code runs.
The feature works.
The idea became real.

And still, I feel like I’ve done something wrong.

I thought the struggle was the work

That’s the part I didn’t notice until recently.

I used to believe that the value of programming was in how hard it was.

That the more I struggled, the more it “counted.”

That if something came easily, it didn’t mean anything.

So when AI made parts of the work lighter, easier, gentler —
I didn’t feel smarter or faster.

I felt less real.

But the real point was never the keystrokes

It wasn’t about typing every line.
It wasn’t about remembering every syntax detail.
It wasn’t about wrestling with the same error for six hours to prove I deserved to make things.

The value was always in the thing I wanted to make.

The idea.
The intention.
The story.
The usefulness.
The feeling it gives someone else.

AI didn’t replace that.
It just removed some of the friction between imagination and reality.

And maybe that’s okay.

Maybe the creativity was mine the whole time

Maybe:

The idea was mine.
The direction was mine.
The decision-making was mine.
The understanding was mine.
The taste — the part that says “Yes, this feels right” — was mine.

Maybe AI didn’t make me less of a developer.

Maybe it made me more able to express the developer I already was.

If you feel this too

If you’ve ever looked at working code you wrote with help
and felt proud and ashamed at the same time,

you’re not alone.

A lot of us are quietly carrying that feeling.

And maybe the gentlest thing we can tell ourselves is:

The work was never about proving your worth.
It was about bringing something into the world that didn’t exist before.

And you did that.

That counts.

What I Learned After Building Dozens of Side Projects (Mostly By Accident)

Christoffer Madsen — Fri, 07 Nov 2025 16:44:14 +0000

Over the past few years, I’ve built a surprising amount of projects. Not all of them shipped. Some turned into real tools people use. Some became prototypes. Some died halfway through because I lost interest. But I noticed certain patterns — lessons that kept repeating no matter what I was building.

These are the things I wish someone had told me much earlier.

1. Clarity beats cleverness

Almost every time I got stuck, the solution wasn't a new library or pattern. It was something much simpler:

Rename a confusing variable.
Write the UI state in one place instead of six.
Remove a layer of abstraction that didn’t help.
Make the flow explicit instead of “smart.”

Code that is easy to understand is code you actually want to work on.
If I avoid my own code, I know I tried too hard to be clever.

2. The right stack is the one you can keep momentum in

I’ve built projects in:

Next.js
Vite + React
Electron
Supabase
MySQL
Node APIs
Rust experiments

The takeaway wasn’t “use Stack X.”

It was:

Pick the stack that makes the next step easy.

If the framework gets in the way, it’s the wrong framework for this project, even if it’s technically “better.”

Momentum > purity.

3. A project only becomes clear when it has a real audience

Whenever I tried to build something “for everyone,” everything was foggy:

What features?
What UI?
What workflow?

But the moment I defined a real user — like a coworker, a partner, or a local business — the design decisions made themselves.

“Real person, real problem” is the fastest way to clarity.

4. Reusability is a quiet superpower

Over time, I realized I was slowly building a toolkit:

UI components I keep reusing
Tailwind + React project structure I always return to
A few motion patterns that feel like “my style”
A mental model of how I like routing and data flow

Each new project is now faster to start than the last.

That’s the long game.

5. When motivation drops, the scope is wrong

Every time I stalled, one of these was true:

The next task was too big
I didn’t know what exactly to do next
I wasn’t seeing progress visually
I was building something abstract instead of tangible

Once I sliced the work smaller, motivation came back.

Motivation isn’t magic. It’s feedback.

6. Shipping something imperfect is better than polishing something imaginary

This one took time to accept.

It’s better to release something small and real than to keep perfecting something that doesn’t exist yet.

Real things create momentum.
Unreleased things create stress.

Done is a feature.

7. The best workflow I’ve found is iterative conversation

My best projects followed a simple loop:

Outline idea (imperfect is fine)
Build a small working version
See it on screen
Adjust based on how it feels
Repeat

Planning is useful, but only if you actually build in between.

Thinking and building need to happen in cycles, not phases.

Final Thought

If I had to sum all of this up:

Progress comes from clarity, constraints, reusability, real users, and shipping in small steps — not from chasing the perfect architecture.

Side projects aren’t just about building products.

They’re how you train your taste.

If you’re working on something now: make the next step small, visible, and real. Then take that step.

If you got something from this, I’d love to hear what you’re currently building.
Drop it in the comments — I’ll actually read it. 🙌

We’re Now in the AI vs AI Resume War

Christoffer Madsen — Thu, 06 Nov 2025 19:11:35 +0000

Everyone knows companies are using AI to scan resumes now.
But we’re also at the point where applicants are using AI to write those resumes.

So we get this situation:

The applicant uses AI to make their resume stronger.
The recruiter uses AI to filter resumes faster.
HR uses another AI to detect whether the resume was written by AI.

And all of this still ends with:
“We’ll get back to you.”

It’s weird.

And kind of funny.
And also kind of depressing.

Because for applicants, job searching is emotional:

Hope
Stress
Trying to prove that you’re worth something
Taking rejection personally

For recruiters, it’s logistical:

Way too many candidates
Not enough time to review everyone
Pressure to reduce the stack quickly

So both sides start using AI.
Not to cheat — just to survive the process.

But then you get the contradiction:

“We can use AI to evaluate your resume, but if you used AI to write it, we might penalize you.”

Feels… uneven.

We’ve reached a point where the hiring pipeline is basically:

AI writes → AI evaluates → AI judges authenticity → humans maybe talk later

The process still pretends to be human.
But most of the interaction is now just AI negotiating with AI about humans.

I don’t think this is “bad” or “good.”
But it’s definitely something we should acknowledge instead of pretending nothing has changed.

What do you think? Is this just the natural evolution of hiring, or does it feel like something important is being lost?

I struggle to post online. So I built a tiny app to practice showing up.

Christoffer Madsen — Wed, 05 Nov 2025 11:52:58 +0000

I’ve been a web developer for years, but I’ve always had trouble sharing anything online.

It’s not that I don’t want to.
It’s that every time I try to post something, I get this wave of:

“Who cares?”
“This isn’t good enough.”
“People will think I’m faking it.”
“Someone smarter is going to call me out.”

So instead of posting, I’d just close the window.
Or save a draft.
Or promise myself I’d come back later.

And later never came.

The odd twist: I can build things — I just felt weird showing them

AI has actually made this stronger.
I use AI to assist with a lot of my code now.
I understand and modify everything, but I’m not typing everything by hand.

So the imposter syndrome whispers even louder:

“You didn’t really build this.”

Which is silly — because the point of building is to create, not to impress.

But brains do what brains do.

So I built something for myself

I made a tiny web app called Get Out There:
https://out.madsens.dev

The idea is very small:

You get one daily challenge.
The challenge is something gentle. Not content creation. Not exposure therapy.
Just showing up in a tiny way.

Examples:

Write a post you’ll never publish.

Leave one kind comment today.

Share something small you’re quietly proud of.

You can mark it complete, optionally reflect in private, and your comfort score and streak grow a little.

No followers.

No likes.

No performance.

Just gentle practice.

Why this works for me

Because posting isn’t actually about the post.

It’s about being okay existing publicly.

It’s like the gym.
You don’t start by deadlifting 180kg.
You start by touching the bar.

Small steps count.

And most days, the hardest part is simply showing up at all.

It's live if you want to try it

No signup.

Anonymous by default.

No pressure to share anything publicly.

Just quiet growth:

👉 https://out.madsens.dev

If this resonates with you

Then you’re likely the kind of person who makes cool things quietly — but the world never sees them.

And honestly?

The internet needs more people like you.

Not louder ones.

Just present ones.

So if you try it, let me know how it feels — privately, publicly, anonymously, whatever works.

I’ll be right there doing my own Day 1 again, too.