§ 01 · Why Vogue and Code

“The wall is crumbling. I want to be the person who helps the right people walk through it.”

Anders, thank you for sitting down with us. The obvious first question. Why did a senior engineer with your background take over a publication aimed at absolute beginners?

Because for fifteen years I sat on the wrong side of the wall and I am tired of pretending it is a meritocracy. Look, the engineering profession that I grew up in was real. The work was hard. The systems mattered. People who built them well deserved their salaries. But somewhere along the way the industry started telling itself that the reason developers were valuable was the syntax. The brackets. The semicolons. The ability to remember whether Python lists are zero-indexed at three in the morning. That was always nonsense. The reason developers were valuable was the thinking. Understanding what the system was supposed to do, why, for whom, in what order. The syntax was just the medium. Now we have tools that can write the syntax. The thinking still belongs to humans. The wall is crumbling. I want to be the person who helps the right people walk through it. Specifically the designers, the marketers, the operators, the career-switchers, the people the industry has spent twenty years telling they were not the right kind of person to build software. They were always the right kind of person. They just did not have the tooling.

Strong opening. Let’s back up. Tell us about the engineering career first. People reading this want to know who they are taking advice from.

Sure. I studied computer science at KTH in Stockholm, finished in 2010, started at Klarna almost immediately. That was when Klarna was still mostly a Swedish payments company, before the international expansion really kicked in. I worked on the merchant integration side. Wrote a lot of Java. Learned how to think about money, which I still believe is the single best technical training a young engineer can have because money is the one domain where if your code is wrong the bug has a dollar value attached and you cannot hide from it.

You moved from Klarna to Stripe. When?

2015. The Stockholm office had just opened. Stripe was already what Stripe is now in terms of engineering culture but it was earlier on the international scale-up curve. I worked on fraud detection infrastructure for the first three years and then moved to a team building developer experience tooling for the API. Stripe is the place where I learned what good engineering culture actually looks like. Not the rituals, not the standups, the underlying thing. Pay extreme attention to the interface, the documentation, the error messages. Treat your developer users with respect. Write less code, but write it carefully. That stuck with me.

And then Lovable.

I left Stripe in 2022. Took six months off, partly because I needed it and partly because I was watching the AI tooling wave start to roll in and I wanted to think about what came next. Joined Lovable in late 2023, when it was still small. I was one of the early engineers on the platform team. We were building an AI-native app builder, which on the surface sounds like a hundred other companies but the bet was specific. The bet was that natural language prompts plus a constrained code-generation pipeline could let non-engineers build genuine production applications. Not toys. Real things. That bet has played out interestingly. Lovable is now a real company with real revenue and real users who are not engineers building real products. I worked there for two years. I left in early 2026 because I wanted to teach what I had learned to a broader audience than Lovable’s product could reach.

§ 02 · What Stripe Taught Him

“Good engineering is mostly about respect.”

Take us inside Stripe. What specifically did you learn there that you carry into Vogue and Code?

Three things. The first is respect for the user. At Stripe the users were other developers, integrating with our API. Internal company culture made it close to a sin to ship an unclear error message. If a developer hit our endpoint with malformed data, the response we sent back was supposed to explain what they did wrong, why, and how to fix it. Not in a condescending way. In the way you would explain something to a colleague. That ethos — that the person on the other side of your code is a real human trying to do their job, and your job is to make their day better — is the thing I want to carry into beginner education. The audience for Vogue and Code is not stupid. They are smart people who have not been given the tools yet. Talk to them with respect. Explain things clearly. Do not hide complexity behind jargon when you could explain it in plain words.

What is the second?

Write less code, but write it carefully. Stripe had a culture where if you submitted a 2,000-line pull request, you would get pushback — not because long PRs are wrong, but because most of them mean the engineer did not think hard enough about what they were actually trying to do. The best engineers I worked with at Stripe shipped surprisingly little code. They thought a lot, they read existing code carefully, and then they wrote the thirty lines that solved the actual problem. That principle — thinking is the work, syntax is just the artefact — is true whether you are writing Go at Stripe or using a no-code tool. The mode of operation is the same. Decide what you want. Decide it precisely. The implementation follows.

And the third?

Documentation is product. At most companies, documentation is what the engineers write after the work is done, badly, on a Friday afternoon, because it is required. At Stripe, documentation was treated as a first-class part of the engineering output. The docs team and the engineering teams worked together. The API reference was as carefully designed as the API itself. The way a developer integrating Stripe experienced the product was through the docs as much as through the code. That changed how I think about teaching. The lesson is the product. The blog post is the product. If the documentation is bad, the underlying thing might be brilliant but nobody will use it. Vogue and Code is, in that sense, a documentation project. We are documenting how non-engineers can build software, and the documentation is the entire product.

§ 03 · What Klarna Taught Him

“Scale exposes every shortcut you took.”

Klarna gets less attention from international tech press than Stripe. What did you learn there that Stripe could not have taught you?

Scale. Klarna was already doing serious volume when I joined, and the volume kept growing the entire time I was there. What I learned at Klarna that Stripe could not have taught me was what happens to a codebase — and a team — when you actually have to handle the load. Every shortcut you took in year one becomes an incident in year three. Every design decision you made because it was convenient becomes someone’s on-call nightmare. Every minor data inconsistency you let slide compounds into a multi-million-euro reconciliation problem at the end of the quarter. That experience shaped how I think about beginners getting into software, because it taught me what actually matters in the long run and what does not. Spoiler: most of what beginners worry about does not matter. The things that matter are clarity of intent, simplicity of design, and the discipline to throw things away when they stop being useful.

What did you see at Klarna that the no-code-revolution conversation tends to miss?

The middle ground. The conversation now is binary — either you are a Real Engineer writing code or you are a no-code person clicking around in Bubble. That dichotomy is wrong. At Klarna we had an enormous internal universe of business analysts, ops people, finance folks, fraud investigators — all of whom needed to query data, build small tools, automate workflows. They were not engineers in the formal sense. They did not write Java. But they wrote SQL queries that ran the company. They built spreadsheet models that drove the merchant pricing. They configured rule engines that handled fraud decisions. They were technical workers. The industry just refused to call them that because they did not have engineering titles. That whole population is exactly who Vogue and Code is for. People who already do technical work, who just have not been recognised as technical workers, who have been told they cannot build “real” software when in fact they have been building real software for years.

§ 04 · What Lovable Taught Him

“The non-engineers were not asking for shortcuts. They were asking for translation.”

And Lovable. That is the most direct precursor to Vogue and Code. What did you see there that shaped this publication?

Lovable showed me what was possible when you took the “you need a CS degree to build software” assumption and shot it. Day one. Watched it die. The user base we built up was almost entirely people who had been told their whole working lives that they could not build. Designers who wanted to ship a portfolio site that actually worked instead of a Squarespace clone. Marketers who wanted to build internal tools for their team. Founders without technical co-founders who wanted to prove out a product before raising. Operators in companies who wanted to automate the workflow nobody on the engineering team had time to build for them. Those people were not asking for shortcuts. They were asking for translation. They had the ideas, the user empathy, the design taste, the business judgement. They just did not have the implementation layer. Lovable gave them that, in a constrained way. And what struck me, watching those users, was that the work they produced was often better than the equivalent work coming out of an engineering team. Because they cared about the problem. They were not building because building was the job. They were building because they needed the thing.

And that is the thesis of Vogue and Code.

That is the thesis. Software is not built best by the people who are technically most fluent. It is built best by the people who care most about the problem and have just enough tooling to express what they want. The technical fluency follows. Or it does not, and that is fine too — you can ship a successful product using nothing but no-code tools, and the world is full of seven-figure businesses running on Webflow and Airtable. The fluency is optional. The caring is not.

§ 05 · The 90% Panic

“Half a useful warning, half a panic-cycle headline.”

Let’s talk about something we have to address head-on. There is a stat circulating that ninety percent of all code will be AI-generated by 2026. Developer panic is real. People are writing essays about whether the profession is over. What is your actual take?

Half a useful warning, half a panic-cycle headline. Let me unpack both halves. The useful warning is that the part of the developer job that involved typing out boilerplate — CRUD endpoints, scaffold code, basic test stubs, standard configuration, the long tail of stuff you used to copy from Stack Overflow — is genuinely being automated. That part of the job is over. Pretending otherwise is denial. If your career was built on being faster than the next person at typing out a Spring Boot service, your career is in trouble. That is the real signal underneath the ninety-percent stat.

And the panic-cycle half?

The framing “ninety percent of code is AI-generated” is a headline number that confuses several different things. It does not mean ninety percent of software is being shipped without human involvement. It does not mean engineers are no longer needed. It means that of the literal characters that end up in a codebase, a large fraction of them were initially proposed by an AI tool and then accepted, modified, or rejected by a human. That has been true to some degree since IDE autocomplete was invented. The transition from autocomplete to Copilot to chat-based code assistance is a continuum, not a cliff. The job is changing. It is not vanishing. The senior engineers I respect most are using AI tools constantly and shipping more, better, faster than they did three years ago. They are not less employable. They are more employable.

What about the juniors? That seems to be the part of the discourse where people are most worried.

Justifiably worried. The junior developer market is genuinely broken right now and I am not going to pretend it is not. Companies that used to hire entry-level engineers to do the grunt work are now using AI tools for the grunt work and skipping the entry-level hire entirely. That is real. The pipeline problem people are describing — if nobody can become a junior, nobody becomes a senior — is also real. I do not have a tidy answer for how that resolves at the industry level. What I do have is advice for individuals reading this in 2026 who are trying to enter the field. The path that worked in 2018 does not work now. The path that works now is to enter the field as someone who already builds. Build a portfolio of small projects using no-code, low-code, and AI-assisted tools. Show that you can ship something useful, end to end, with what you have. Companies are not hiring people to learn to code on the job anymore. They are hiring people who can already produce. So produce. Start now. Do not wait until you feel ready. You will never feel ready.

§ 06 · Disagreements With His Own Industry

“Most engineering blog content is engineers writing for other engineers, and I think it is hurting the industry.”

What do you think the engineering industry gets most wrong about itself right now?

That engineers are the only legitimate audience for engineering content. Walk into any developer-focused publication, podcast, conference, and you will find engineers talking to engineers about engineering, in language only engineers can understand. That is a feedback loop. It tells everyone outside the loop that they do not belong, which is the wall I started this interview talking about. The defensive version of that loop is the “real engineer” gatekeeping, where someone using Webflow or Bubble gets dismissed as a fake builder because they did not write the underlying React themselves. That gatekeeping is corrosive. It pushes capable people out of building. It tells designers that their work is somehow less valuable than the backend developer’s work, even when the designer’s contribution to the final product is bigger. It impoverishes the industry.

Anything you disagree with about the AI tooling discourse specifically?

The doomerism is overcooked. Yes, there is real labour market dislocation. Yes, the junior pipeline is a problem. But the framing that “the craft is dying” misses the point. The craft of software was never about syntax. The craft was about clear thinking, careful design, attention to the user, willingness to throw away your first idea and try again. None of that has been automated. None of it is going to be automated by current LLM techniques. The people who romanticise the manual writing of code are mistaking the medium for the work. The work is still there. The medium has changed. Carpentry is still carpentry whether you are using a hand plane or a router. Writing is still writing whether you are using a typewriter or a word processor. Software engineering is still software engineering whether you are typing every character yourself or directing a model to type most of them. The romance of the typewriter is fine. It is just not the work.

§ 07 · Practical Advice

“Build something this week. Not next year. This week.”

Pretend a designer with no coding background is reading this and asking, “OK, where do I actually start?” What is your answer?

Pick one specific thing you want to build. Not a general “I want to learn to code” goal. A specific thing. A landing page for a side project, a tool that pulls data from one place and puts it in another, a small app that solves a problem you actually have. Then pick the simplest tool that could plausibly build that specific thing, and start. The tool will be wrong. You will hit walls. That is fine. The wall is where the learning happens. The mistake people make is trying to learn the toolchain before they have a project. That is studying without applying. Applied learning is six times faster than studying. Pick the project first. Pick the tool second. Start before you are ready.

What about people who genuinely want to learn to write code rather than just use no-code tools?

Same answer with a slight modification. Pick a specific project, and pick the language and framework that best fit that project, and start. For someone in 2026 with no background, I would recommend Python as the starting language because the syntax is unusually readable, the ecosystem is huge, and the AI coding assistants work especially well with it. Pick something you actually want to do — maybe automate a daily task, scrape a website, send yourself a customised newsletter, summarise your own emails — and build that thing badly, then build it better, then build it well. Use AI tools the whole time to ask questions. Treat the AI like a patient tutor sitting next to you who will explain any concept as many times as you ask. That is genuinely how I would learn to code today if I were starting from scratch.

What is the most important thing you learned about teaching that you did not know going in?

That confidence matters more than competence at the start. Most people who fail to learn to build software fail because they convinced themselves they were not the kind of person who could. The technical content is not the bottleneck. The internal monologue is the bottleneck. Most of my job as an editor here is going to be giving people permission to think of themselves as builders. The teaching is secondary. The reframing is primary.

§ 08 · Closing

“If this resonates, you are already the kind of person we are writing for.”

Last question. What does success look like for Vogue and Code over the next twelve months?

If at the end of 2026 we have given a few thousand people the confidence to ship something they would not have shipped otherwise, we have done our job. That is the metric. Not pageviews. Not subscribers. Not affiliate revenue. Ships. People building things they were not building before. People publishing their first website, automating their first workflow, deploying their first script, prompting their first AI agent into production. Every one of those is a win. Every one is someone who walked through the wall. I want a lot of those in 2026. That is what I came here to do.

Anders, thank you.

Thank you. Tell the readers to write to me if anything in this conversation resonated. The interesting part of running an editorial publication is talking to the people who read it. That is what I am here for.