<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Kasper Junge</title>
    <link>https://kasperjunge.com</link>
    <description>Thoughts on AI, software engineering, and building things.</description>
    <language>en</language>
    <lastBuildDate>Fri, 10 Jul 2026 12:00:00 +0000</lastBuildDate>
    <atom:link href="https://kasperjunge.com/feed.xml" rel="self" type="application/rss+xml"/>
    <item>
      <title>Capitalism Gone Wrong</title>
      <link>https://kasperjunge.com/blog/capitalism-gone-wrong/</link>
      <guid>https://kasperjunge.com/blog/capitalism-gone-wrong/</guid>
      <pubDate>Fri, 10 Jul 2026 12:00:00 +0000</pubDate>
      <description></description>
      <content:encoded><![CDATA[<p>I recently read this <a href="https://ec.europa.eu/commission/presscorner/detail/en/ip_26_1579">press release from the European Commission</a>:</p>
<p>“The Commission’s investigation indicates that Meta did not adequately assess the risks of its addictive design on the physical and mental wellbeing of users, including minors and vulnerable adults.”</p>
<p>That made me think of the following quote from Mark Zuckerberg during Meta’s <a href="https://s21.q4cdn.com/399680738/files/doc_financials/2024/q3/META-Q3-2024-Earnings-Call-Transcript.pdf">Q3 2024 earnings call</a> on October 30, 2024:</p>
<p>“Improvements to our AI-driven feed and video recommendations have led to an 8% increase in time spent on Facebook and a 6% increase on Instagram this year alone.”</p>
<p>Later, during a <a href="https://s21.q4cdn.com/399680738/files/doc_financials/2024/q3/META-Q3-2024-Follow-Up-Call-Transcript.pdf">follow-up call</a> for the same earnings report, Meta CFO Susan Li said:</p>
<p>“We’re still seeing strong returns as improvements to both engagement and ad performance translate to revenue gains. I think Mark mentioned that this year the ranking improvements we’ve made have delivered an 8% increase in time spent on Facebook, a 6% increase on Instagram.”</p>
<p>I think Zuckerberg and Li make the relationship pretty clear. They are not even trying to hide it — and I suppose it is not a secret at all: The more time users spend on Facebook and Instagram, the more money Meta makes.</p>
<p>Based on these quotes, Meta seems to be very good at optimizing for increased time spent on its platforms. In fact, it almost sounds as though they have a dial in their AI recommendation systems that they can turn to increase the amount of time users spend on their services.</p>
<p>I do not have the exact numbers, but it would not surprise me if the increase in time spent that Zuckerberg mentions — at Meta’s scale — translates into more than 100 million additional hours per day.</p>
<p>One hundred million hours a day.</p>
<p>I wonder how that time is being spent. Doomscrolling?</p>
<p>I also wonder how well Meta understands what users are doing during that additional time — and what other activities its apps are competing with. I imagine they are competing with time spent building IRL relationships, doing productive work, exercising and, yes, even sleeping.</p>
<p>At this scale, could you argue that improvements to AI recommendation systems like this are simply pulling productivity out of Western economies by encouraging people to engage with social media instead of getting things done?</p>
<p>I personally believe that the business model of ad-driven social media platforms such as Meta is deeply broken.</p>
<p>I also believe that these companies reflect far too little on the impact they have on the world when they tweak AI systems operating at this scale to increase engagement and revenue.</p>
<p>Of course, I also understand the problem from Meta’s perspective. This is their entire business model, and they have investors to satisfy.</p>
<p>I am sure Facebook did not begin as a project designed to steal people’s time. It began as a cool app that people genuinely loved. As with many software products, retention was a useful metric because it indicated that people liked and engaged with the product. Once advertising entered the picture, however, retention became directly correlated with revenue.</p>
<p>The problem is that Meta has become exceptionally good at optimizing for retention, using AI and world-class product teams.</p>
<p>It also seems likely to me that some people inside Meta are living in a bubble in which they tell one another a positive story about the impact of their work. As a result, they may not be sufficiently in touch with — or reflective about — the real impact their business model has on the world.</p>
<p>In my opinion, there is no doubt that Meta’s services are addictive. I believe this business model has been taken too far.</p>
<p>This is a sad example of capitalism gone wrong.</p>
<p>At the same time, I understand the incentives behind Meta’s efforts to tell a positive story about its impact on the world. But in my opinion, the right thing for the company to do would be to honestly reflect on the negative effects of its business model and think seriously about how it could move toward more ethical sources of future growth — something that genuinely benefits society.</p>
<p>I believe that less aggressively engagement-optimized versions of Instagram and Facebook could become more ethical products. The problem is that it has been taken too far. I sincerely hope that EU regulation — even though it often has a bad reputation — can help show the way forward for these types of systems and products.</p>]]></content:encoded>
    </item>
    <item>
      <title>We Don’t Have to Be This Bad at Improving Society</title>
      <link>https://kasperjunge.com/blog/we-dont-have-to-be-this-bad-at-improving-society/</link>
      <guid>https://kasperjunge.com/blog/we-dont-have-to-be-this-bad-at-improving-society/</guid>
      <pubDate>Wed, 01 Jul 2026 12:00:00 +0000</pubDate>
      <description>Major political reforms and big product bets fail for the same reason: too much decision risk taken in one huge bet. Working in small learnable chunks and defining outcomes instead of outputs can change that.</description>
      <content:encoded><![CDATA[<p>I recently became very curious about the concept of decision risk.</p>
<p>I’m currently reading Entreprenørstaten — The Entrepreneurial State in English — by Sigge Winther Nielsen. It explores the remarkably poor track record of major political reforms in Danish politics. Time and again, large initiatives end up going terribly wrong.</p>
<p>I’ve seen countless examples of the same thing in the private sector. Product teams build at full speed, only to create something that nobody wants to buy or use. It ends up being a total waste of time and money.</p>
<p>This is closely related to the concept of decision risk.</p>
<p>In situations of high uncertainty, many people excuse poor decisions to launch major initiatives that ends up failing by arguing that there wasn’t enough information available, so there was nothing they could have done to reduce the risk. I strongly disagree.</p>
<p>I believe it is absolutely possible to reduce decision risk, even in highly uncertain situations.</p>
<p>The technique is to organize the work into the smallest possible learnable chunks and continuously alternate between doing and learning. And I really mean the smallest possible chunks in terms of the resources you invest. Instead of making one huge bet, you spend smaller amounts of money on small iterations, learn from each one, and adjust as you go.</p>
<p>This way of working requires leaders to define the outcome to be achieved—not the output to be delivered. The team close to the domain and learning should be hill-climbing toward a desired outcome rather than implementing a predetermined solution.</p>
<p>When someone in a position of power specifies the output, despite not being the person doing the implementation, they’re making the arrogant assumption that they already know the right solution before getting close enough to the problem to understand it.</p>
<p>To be honest, it’s painful to read Sigge’s book. Politics is deeply broken when it comes to effectively solving society’s biggest and most important problems.</p>
<p>However, I’m pretty convinced that it doesn’t have to be this way, and I choose to be optimistic that things can change.</p>
<p>I’m super curious about ideas, insights, and ways of thinking that could improve how political reforms are carried out in Danish politics today. </p>
<p>Is it possible to identify the root causes of what’s broken in the current political system and develop mechanisms to address those issues, making political reforms more effective to solve important problems in society? This seems like a super valuable meta problem to solve and that is the kind of question that really stimulates my systems-thinking-addicted brain. I simply refuse to believe it has to be this way.</p>]]></content:encoded>
    </item>
    <item>
      <title>We want to enable knowledge workers to securely delegate work to AI agents</title>
      <link>https://kasperjunge.com/blog/computerlove-vision/</link>
      <guid>https://kasperjunge.com/blog/computerlove-vision/</guid>
      <pubDate>Thu, 11 Jun 2026 12:00:00 +0000</pubDate>
      <description>The vision and strategy for computerlove.tech: two bottlenecks stand between knowledge workers and real secure delegation to AI agents, skill and infrastructure, and everything we do attacks one of the two.</description>
      <content:encoded><![CDATA[<p>I want to write down what we are actually about at computerlove.tech. Not because anything changed, but because being vocal about a vision is how it starts to live in other people's minds, and I would rather have people know exactly what we stand for than have them guess.</p>
<p>So here it is: our vision is to enable knowledge workers to securely delegate work to AI agents.</p>
<p>That sentence is short, but every word in it is doing work, so let me unpack it. Between that vision and reality we have identified two bottlenecks, and everything we do as a company is ideally addressing one of the two.</p>
<h2>The first bottleneck is skill</h2>
<p>We have spent the last year teaching developers how to develop software using AI agents, around 600 of them by now, and a year is forever in this industry. What we see every single week is the same struggle. The hard part is not prompting, and it is not the tools. The hard part is the delegation itself.</p>
<p>Developers are used to being individual contributors. They do the work with their own hands, and their instincts are tuned for that. What agents demand of them is something else entirely: clarifying the task, planning it, specifying it, structuring the work, and caring about the environment around the agent so it is set up to do great work. These are leadership activities. A developer working with agents is going from individual contributor to leader, a leader of agents, and that shift is genuinely weird for most people. It is a new way of working, and nobody learns it by reading about it.</p>
<p>And now this way of working is arriving for everyone. With tools like Claude Cowork, delegating work to agents is becoming available to all knowledge workers, not just developers. They will have to learn the same techniques the developers are learning now, but they are not as technical, so they cannot build their own scaffolding and wire everything together the way developers can. Which leads directly to the second bottleneck.</p>
<h2>The second bottleneck is infrastructure</h2>
<p>Agents are most effective when they can reach the tools you actually do your job with: your email, your calendar, the CRM, Slack or Teams, and all the systems you touch on a normal working day. Most of that software was built for humans clicking around in interfaces. It is not legible to agents, and there is a huge amount of infrastructure work to be done before it is, in connectivity, in making systems readable and operable for agents, in everything around it.</p>
<p>But access cuts both ways. The same access that gives a knowledge worker superpowers can also let an agent do things it was never supposed to do. My favorite example is maybe a little sci-fi: HAL 9000 from 2001: A Space Odyssey is basically an AI agent with access to the spaceship's systems, including the life support of the crew in hibernation, and we all know how that goes. The realistic examples are less cinematic but the same shape. An agent accidentally sends an email containing information that should have stayed internal. A customer support agent has access to data across users, and suddenly one customer can query another customer's data. A lot of this is good old permissioning, deciding what you grant an agent access to and what you don't, but agents introduce a whole new class of security questions on top of it.</p>
<p>This balance between superpowers and security is exactly the concern we hear from leaders, again and again. If you want delegation to actually happen inside an enterprise, security is not a feature you bolt on afterwards. It is the thing that makes the rest possible. That is why the word securely sits in the middle of our vision and not in the footnotes.</p>
<h2>What we are doing about it</h2>
<p>Our strategy has two legs, one for each bottleneck.</p>
<p>The first leg is upskilling. We teach workshops for software developers working with tools like Claude Code, Codex and Cursor, and for general knowledge workers working with tools like Claude Cowork. Teaching makes us a living, so we do not have to raise funding, which is nice, but it does more than that. Every workshop is also discovery, because we learn an enormous amount about the market every time we are out talking to people about where they actually struggle. And honestly, we are just passionate about helping people learn this technology.</p>
<p>The second leg is building product in the AI agent infrastructure space. Our current thesis is a single gateway that enterprise employees and AI agents connect to, and that gives every employee and every agent secure, governed access to exactly the systems they have been granted, with fine-grained control on every single endpoint. I say thesis deliberately. We have not built it out in the industry yet, and we are humble about this being a new space. We know the vision and we know what we want to enable, but we would rather discover the right solution by implementing real things for real customers than settle on whatever we imagined from the office. That is what we are most eager to do right now: get out there and start solving real technical problems for real organizations.</p>
<h2>Why us</h2>
<p>You could say the space of governed agent access is getting crowded, and on paper it is. But we keep meeting companies that struggle with exactly this, and if there were a clear solution they could just go and pick, they would have picked it. They haven't.</p>
<p>We also think we bring a perspective that is hard to copy. We have been teaching this way of working for a year, to hundreds of developers, and we have watched up close what people actually struggle with in organizations when they try to delegate work to agents. Now the same shift is reaching every knowledge worker, and those workers will need the infrastructure built for them.</p>
<p>And there is one more thing our customers keep asking for: a neutral third party. They do not want to lock themselves to Anthropic, OpenAI, Microsoft or any of the hyperscalers. They want a solution that is independent of any one tool and any one agent, from someone whose only interest is making the delegation work safely. We can be exactly that.</p>
<h2>What I want you to take away</h2>
<p>I want this picture to exist in your head: computerlove.tech is the company that wants to enable knowledge workers to securely delegate work to AI agents, and we currently believe that the most effective way we can help companies get there now is by upskilling developers and knowledge workers, and by building the infrastructure that makes delegation safe. If that picture is useful to someone in your network, pass it on.</p>
<p>And if you are working in this space yourself, whether you are standing in front of these problems inside your organization or building things to solve them, reach out and connect. We want to talk to the people who are wrestling with the same questions, because that is how we make progress: by solving real problems together.</p>]]></content:encoded>
    </item>
    <item>
      <title>Everyone got excited they can suddenly code, and completely missed the point</title>
      <link>https://kasperjunge.com/blog/should-pms-code-with-agents/</link>
      <guid>https://kasperjunge.com/blog/should-pms-code-with-agents/</guid>
      <pubDate>Wed, 10 Jun 2026 12:00:00 +0000</pubDate>
      <description>Coding agents made software cheap to build. That just exposed the bottleneck that was always there: deciding what to build. A rant about broken product orgs, why PMs should use agents for discovery and not delivery, and why your best people will walk.</description>
      <content:encoded><![CDATA[<p>Everyone got excited they can suddenly code, and completely missed the point.</p>
<p>Coding agents showed up, software got cheap to build overnight, and a whole industry lit up: now the PMs can ship too, now the business can prototype, now everyone's an engineer. And almost nobody stopped to ask the only question that actually matters:</p>
<p>If we can suddenly build anything, what should we build?</p>
<p>Because here's the thing nobody wants to say out loud: deciding what to build has always been a bottleneck. A massive one. In most organizations it's every bit as expensive as writing the software was, it's just been hidden in the haze of software being slow and costly to produce. When delivery took months, bad product thinking was invisible. It got absorbed into the timeline. Now delivery is fast, the haze is lifting, and what's underneath is ugly.</p>
<p>You can pour as much AI as you want into a dev team. If the bottleneck is context trapped in a Jira ticket, it won't help. Your org is the bottleneck. And it doesn't have to be this way.</p>
<h2>The two-line ticket</h2>
<p>You know the dysfunction. A developer opens Jira and finds a task: one or two vague sentences, handed down from "the business." No description of the problem, no sense of who has it or why it matters. Just a thing to build, and a quiet expectation to build it.</p>
<p>That ticket is the symptom of an entire broken operating model. "The business" thinks, the PM translates, the developers deliver. An assembly line. And at every handoff, context evaporates.</p>
<p>The developer never gets near the actual human with the actual problem. So they can't think. They can't be creative about the solution, because the only information they're allowed is whatever survived compression into two sentences. And that's a tragedy, because a developer who understands the user can see opportunities literally no one else can see, opportunities that live in what's technically possible. Same as a designer sees things from their lens, and a domain expert from theirs. Cut everyone off from the user and you don't just slow things down. You amputate the entire team's ability to discover the good ideas in the first place.</p>
<p>This was always wasteful. Agents just made the waste impossible to ignore.</p>
<h2>So should PMs build software with agents?</h2>
<p>This is where the hype crowd wants a yes. And there's a version of yes I'll give you.</p>
<p>Coding agents are a phenomenal discovery tool. A PM who spins up a high-fidelity prototype to put something real in front of users, to learn what people actually want and will actually pay for, is using agents exactly right. That's the job getting easier, and I'm all for it.</p>
<p>But the moment a PM starts using agents for delivery, shipping production features, becoming a one-person delivery shop, they've gotten it backwards. Not because they'll write bad code. Because they're spending the scarcest resource in the entire company on the wrong thing.</p>
<p>The PM's job is the bottleneck now. "What should we build?" is the constraint everything else waits on. A PM burning their hours on delivery, when discovery is what's strangling the org, isn't being heroic. It's a prioritization failure. Discovery, not delivery. That's the whole line.</p>
<h2>This is fixable, and most leaders don't even know it</h2>
<p>There's a better way to work. Smart people have already written the playbook, so go read Marty Cagan if you want it spelled out. You don't have to adopt it perfectly. You don't walk into a company and swap the entire operating model on a Tuesday. It's a direction, not a dogma.</p>
<p>But here's what kills me: most senior leaders at companies that build software have no idea this conversation even exists. They think software development is pure delivery. Tickets in, features out, measure the throughput. They have never been told there's a way of working that gets dramatically more innovation, more value, more revenue out of the same people. So they keep optimizing the delivery line and wonder why nothing they ship matters.</p>
<h2>If this is your every day</h2>
<p>Then this is for you.</p>
<p>Stop wasting your career inside organizations that don't know any of this. It is a genuine waste of your one professional life to spend it building things nobody wants and nobody buys, in a system that won't let you get near the problem. Seek out the companies that do this well. Chase impact, not the salary ceiling. And if your job consistently has you shipping into the void, leave.</p>
<p>Leaders, you're meant to overhear this one. Your best people understand exactly what I'm describing, and they will walk. Fix this, or watch them go.</p>
<p>And to everyone who feels this every single day: there are a lot of us. Enough to make this a movement. We have the talent in Europe to build software that genuinely helps people, that innovates, that generates real revenue. We're just wasting it on broken process.</p>
<p>Let's stop. Let's make EU great again.</p>
<p>Rant over.</p>]]></content:encoded>
    </item>
    <item>
      <title>Hello World</title>
      <link>https://kasperjunge.com/blog/hello-world/</link>
      <guid>https://kasperjunge.com/blog/hello-world/</guid>
      <pubDate>Thu, 22 Jan 2026 12:00:00 +0000</pubDate>
      <description>Welcome to my new blog. A fresh start for sharing thoughts on AI, software engineering, and building things.</description>
      <content:encoded><![CDATA[<p>Welcome to my new blog.</p>
<p>After years of writing on Medium and other platforms, I decided to build something simple and owned. No analytics, no cookies, no complexity — just words on a page.</p>
<h2>What to expect</h2>
<p>I'll be writing about:</p>
<ul>
<li>AI and LLMs — practical insights from building with them daily</li>
<li>Agentic coding — how AI is changing the way we write software</li>
<li>Open source — projects I'm working on and lessons learned</li>
<li>Random thoughts — whatever seems worth sharing</li>
</ul>
<h2>Why now?</h2>
<p>The tools for building on the web have never been simpler. This entire site is just HTML and CSS — no frameworks, no build steps, no dependencies. It loads fast and will work for years.</p>
<p>Sometimes the best technology is the simplest.</p>
<h2>Let's connect</h2>
<p>Find me on <a href="https://x.com/JungeKasper">X</a> or <a href="https://www.linkedin.com/in/kasper-juunge/">LinkedIn</a>. I'd love to hear from you.</p>]]></content:encoded>
    </item>
  </channel>
</rss>
