"The more AI writing floods in, the more people will look for a human touch" — Sunjae, who builds the developer blog Rilog
Nov 9, 2026
These days, as AI-written posts fill up blogs, one developer blog is setting out to gather writing with a human touch: Rilog. Alongside tech posts and troubleshooting notes, it holds developers' own thoughts, retrospectives and daily lives, and readers can comment right on a sentence to trade ideas. On the evening of November 7, we met Sunjae, one of the people building Rilog, over video.
Q. Tell us about Rilog.
At its core, it's a blog service. Four developers run it as a team project. With AI taking off the way it has, I felt a new demand had appeared for writing that feels human. Looking around, there was so much low-quality, mass-produced writing, and no developer service that stood for the opposite. So I thought we should build one ourselves. Beyond tech posts and troubleshooting write-ups, we wanted room for the developer as a person: their stories, hobbies, thoughts and retrospectives. There are two things that set it apart. The biggest is team blogs. You can create a team like an organization, and once it has a team profile, you can publish posts as a member of that team. Plenty of other platforms have this too, of course. The second is inline comments. Most blog services people use in Korea either don't have inline comments or barely use them. We wanted a culture of conversation, where thoughtful people write down and leave their own ideas, and while thinking about what would help, we added this feature. While reading, you can drag over the exact spot you want to respond to and comment right there. That culture seems to be forming just as we hoped, and lately more retrospectives are being posted than we expected, which is bringing new people in.
Q. What value do you want Rilog to give its users?
When the internet first arrived, people talked a lot about information overload. There was so much false information that you couldn't just take everything in. I think AI is similar. Drawings, writing, presentation scripts, books, music: AI does it all now. The world of AI slop is already here. I don't see AI slop itself as bad. There are places where it doesn't matter if it shows, and places where it's actually a strength. But in writing that reveals a person's own thinking, I don't think it should be allowed. The moment even a little gets mixed in, readers think, 'oh, it's just AI.' In that overload, people will want to find writing with a human touch again, because they already know what it's like to read something full of deep, personal thought. We're developers, so we focused on a developer blog. We wanted to build a developer culture where good writing gets published and people grow by sharing their views.
Q. You said you built it because you dislike AI mass-produced writing. Can you actually tell whether AI wrote something?
That's really hard. Writing is something we can't control. Luckily we don't have that kind of writing right now, but we think a lot about how to judge and filter for the culture we want in a quantitative way. That's our core challenge: how to make the culture we're aiming for actually real. There are plenty of skills that claim to find and fix AI slop, but I don't think they meet my bar. We can't know for sure whether something was written with AI, so in the end we have to judge probabilistically and improve through user feedback. We're also thinking about which posts should make it to trending.
Q. But as AI improves, won't even experts be unable to tell it apart from human writing?
I don't think what matters is how much AI was used. What matters is that the person's thinking comes across well and that people share their views around it. Even if AI gets so good that readers can't tell, if the writing helps me, its value has been delivered. Our team has a lot of meetings about this. Is what we dislike writing done by AI, or low-quality, mass-produced writing that nobody even reviewed? It's the latter, so we don't call something a bad post because a certain percentage of it was written by AI. That's why setting a standard is hard, and we keep thinking about it.
Q. You've probably heard that Rilog looks a lot like Velog. What sets it apart?
How to stand apart from existing blog platforms is something we've been thinking about steadily from the start. The most visible difference right now is inline comments. On Velog, comments go back and forth at the bottom of a post, but on Rilog you can select a specific sentence and leave your thoughts right there. We wanted a culture where reading doesn't simply end with the last line, and conversation centers on the ideas inside the post. Of course, we don't think this one feature alone is enough to set us apart. So while running the service, we keep watching what kinds of posts users like and how they talk to each other. What surprised us was that on Rilog, retrospectives about personal experiences and thoughts drew a better response than technical posts. We started as a blog for developers, but seeing this made us wonder whether we should stay within the developer category or grow into a space for a wider range of stories. There's no set answer yet. But rather than holding on to our original direction no matter what, we want to find what makes Rilog valuable based on how real users respond.
Q. Is there anything you wish had gone differently while building Rilog?
We work on Rilog intensely, with meetings every day and new features every day. If I had to name a personal failure, it's the UI. I didn't want to follow the usual blog UI, because I hated the idea of someone landing on it and thinking, 'it's just another blog platform.' We went as far as mockups asking whether thumbnails were really needed, or whether we could lay out only the titles in different sizes, horizontally and vertically, like typography. But people bring UX expectations and habits to blog services, so in the end we got a feed much like other blogs. It was an early decision we can't undo, but I do wish it had gone differently.
Q. When did you start developing?
That's a little hard to pin down. I started quite a while ago, around 2018, when I was pretty young. But the period of steadily studying development in depth and doing projects is harder to put a number on. There was my military service, and I'm not working at a company yet. I've done several projects, so I'd say more than two or three years.
Q. How has the way you build changed between 2018, before AI, and now?
I started developing simply because I love making things. In one line, the whole workflow from starting development to launching has completely changed. When I started, the things I had to think about when I wanted to build something new were very different. Back then, Stack Overflow, official docs and Googling were the main tools, and beyond that I watched courses on Inflearn, YouTube or Saenghwal Coding. But even after watching them, applying it to what I actually wanted to build was a separate problem. The core questions were at the code level: how to pass props, how to manage state. Now I don't think about 'how should I write this,' but 'how much should I hand off,' 'what should I check,' and 'with this policy, what are the edge cases.' The biggest bottleneck used to be implementation. It was tied directly to my skill, so I could only build as much as I knew. That huge cost has now dropped to almost zero, so I find myself thinking about the surrounding parts and a wider range of areas.
Q. What did you build before Rilog?
I built so many small things that it's hard to point to just one. It was before AI, so the quality wasn't great, and while I loved building, I never thought about promoting or running them. At most I'd send links to friends. From a product development point of view, if that's a failure, it's a failure. Still, I think those experiences gave me a feel for it. Because I'd planned, built and shipped things, building a project stopped feeling scary, and the hurdle got lower.
Q. Without a sense of design, even things built with AI look AI-made. Should developers and planners study design too?
I think it's absolutely good. Going forward, developers will need a feel for owning the whole product, and then they'll naturally start caring about UX, and after that, UI. If you have no sense of it at all, I think you should study it. It's not so important that it should come before development, but it's needed. As time goes on, the shape and feel of a product will matter more. I don't set aside time to study it either, but I'm really interested. When I have to build a specific feature, I think about the UX first. If I look up what the font size should be on mobile, it turns out there are established standards. Then I look them up and apply them. I study whenever I need to, and I spend quite a bit of time looking at other references and designs.
Q. What do you want to do next?
These days I'm very interested in AI, so I want to move toward full-stack and product engineering. I've always just loved making things. As a kid I built things with science kits. Then I found development, and it was a great tool for showing what I'd made. It suited me and I enjoyed it, so I kept going, and now a better tool for realizing myself has arrived in the world. If you're handed a better weapon, there's no reason not to use it. So my interest naturally shifted toward AI.
Q. How will developers, designers and planners be working a year from now?
A year from now? It sounds far away, but it's very close, because things change so fast. This is just my personal view, but when I talk about this, people take it very differently. Some strongly agree, and some say it will never happen. As an analogy, when C came out in the days of writing code in assembly, people stopped trying to master assembly. After Python came out, people studied its syntax and how to apply it to data analysis or image processing, rather than low-level principles like memory management. AI plays that role. A year from now, I think reading code will feel like studying machine code when C already exists. Today's development methods are built around people. We write tests because people make mistakes. If AI writes all the code, those methodologies and that culture will disappear. At the extreme, in a few years AI may get its own language for talking to other AI as efficiently as possible, one people can't even read. A year from now, I don't think people will type code by hand except in certain domains. The spec-driven development (SDD) we're hearing about lately may be an early model of that: define the spec first, and AI develops it. Seeing startups that began AI-native work that way made me think this direction might be right. A year from now, I think even companies that are conservative about AI will naturally follow the flow.
Q. Many people worry their jobs will disappear. Will they really be replaced?
I think saying jobs will disappear is thinking too narrowly about your own job title. A frontend developer tends to see the frontend role disappearing as their job disappearing. But if AI takes over that role, there will definitely be a role for handling that AI. The work itself stays the same. So you need to learn again to fit that role. Jobs get replaced and change, but overall I think the number of jobs will grow rather than shrink. In return, people have to learn actively for the growing roles and adapt in an AI-friendly way. Going further, I think the definition of roles itself will be rewritten. Even when you develop alone, there are stages: planning, building, verifying, launching and monitoring. I once saw a video saying roles would split along stages like those: people who love coming up with ideas, people who love quickly building and shipping prototypes, people who love building platforms that developers use. Right now, names like product builder and product engineer, and what those people do, are still in transition. But I just imagine that in a few years things will settle and split up that way.
Q. Finally, is there anything you'd like to say to readers?
I've been doing a lot of coffee chats lately, and one thing keeps coming up. AI is good at answers like 'here's how you should do it' or 'I compared them and this is the right one.' But it still doesn't seem able to answer 'why' on its own. As models improve, maybe a year from now it will be able to reason about 'why' to some extent. Even then, judging and thinking through the 'why' that AI offers will still be up to people. I think building that ability matters for developers right now. To do that you need to think actively, and keep asking 'why' even when AI gives you an answer. And for that, you need to write a lot. Not writing to show off, but writing for yourself, to keep a flexible mind that will survive in the future. That's what Rilog was built for from the start, and everyone on the team shares that value. If you take a look around, there are a lot of posts that make you go 'wow.' More people think deeply than you'd expect. There are about 288 posts in total right now, and probably fewer than 5% of them feel like AI slop. Most were written by people from scratch, so just getting the push of 'I should think like this too' while reading feels meaningful to me. There's also a mysterious 'dark comment squad' that leaves comments on everything you post. If you're curious how others see your thinking, I'd love for you to write something. There aren't many blogs these days where conversation in the comments is this lively. Rilog is still early, so users are leaving lots of comments with real interest. (Editor's note: the "dark comment squad" are other crew members at Woowa Tech Course, a Korean developer bootcamp, and passionate fans of Rilog.)
After the interview
Thinking of AI News Daily, which is made 99% through AI automation, I felt a little called out. So much of what Sunjae shared struck a chord with me. It also makes me think that slop has really cut down the number of people who actually read. I hope Rilog, at least, becomes a place where people write without AI's help, a gathering place for humans.
Try Rilog
Rilog.
Rilog. is a blog platform for in-depth writing and knowledge sharing.
rilog.kr ↗
