Someone Behind the Software: Karri Saarinen on Product Soul in the Age of AI Coding Agents

Karri Saarinen's essay "Someone behind the software," published on karrisaarinen.com and discussed on Hacker News (486 points, 175 comments), argues that good software carries the perspective of the people who make it — and that agent-driven development risks replacing that perspective with an average of many independent, uncoordinated changes. The essay's closing line states the thesis directly: "I want to feel the creator behind the software, not the factories."

The core claim: products carry the perspective of their makers

Saarinen's central argument is that software quality is not only a function of process and requirements, but of the judgment of the people building it. He writes: "I think good products carry something of the people who make them. Their experience, what they care about, and how they think things should work. You might not know who those people are, but you can feel their perspective in the product."

He contrasts this with the industry's factory metaphor — collect requirements, build features, measure whether they work — and points out that the metaphor cannot explain observed differences in output: "two teams can talk to similar customers, have access to the same technology, and make very different things. The difference comes from how they understand what they see and the style they go about building it."

Hacker News commenter @nagalluri made the same point more generally: "Give two different people the same problem, and you'll likely get two different solutions shaped by differing experiences and ways of thinking. I think software is an example of this manifested."

@abroszka33 offered a direct comparison: "look at modern AAA games vs. small indie games." @conqrr extended the idea beyond software: "This is everything not just software... Handcrafted things easily have more value." @ceuk noted the same argument has been made about food for years.

Why "intuition over process" does not mean "no evidence"

Saarinen clarifies what Linear means when it says it values intuition over process or data. He acknowledges the common misreading — "making decisions based on personal preference, without much thought or evidence" — and rejects it: "What we mean by it is that your intuition develops through experience and understanding. You work on something, talk to customers, make mistakes, and learn what to pay attention to."

He describes intuition as a point of view that forces judgment rather than hiding behind metrics: "The intuition is your point of view on something, and forcing to use your judgment, not hide behind faceless data." He also notes that the perspective improved through customer conversations before launch: "We had our own frustrations with this type software, but those conversations helped us understand what mattered beyond our own experience."

Not every commenter accepted the framing. @nickm12 argued that intuition and data are not opposites: "'Intuition' and data are both ways of learning about the world and they complement each other. Sometimes the insights only come when you dig into why intuition and data disagree." He added that process is also a tool: "Processes embody our best practices. But sometimes we should deviate and sometimes we should discard or rebuild them. These are all tools in the toolbox."

@sp1nningaway took the opposite side of the data question, claiming that organizations preaching data-driven decision making often use data badly: they are "either using data to make unintuitive wrong decisions or chasing down stats that reinforce their priors."

The additive-feature problem: why products become Frankenstein's monsters

Saarinen's most-quoted passage concerns how products degrade through addition rather than rethinking. He observes that "many products are starting to feel messy to me, including products from very successful companies," with more thought going into "what the technology can do and what can be added than the form it should take."

His explanation: "it's lot easier to add new capabilities, than rethink existing capabilities. So each product becomes a collection of abilities, without actually having unified point of view."

@jakub_g called this "a very good and succinct summarization" and added an observation of his own: "pretty much every product tries to expand to do things that completely different products used to do, and become a mega-product-for-everything. It's like a Zawinski's Law on steroids."

@iamcalledrob noted the commercial disconnect: "the best things aren't always the most commercially successful... JIRA might be objectively awful, but it still manages to print money!" @alexpotato gave a concrete illustration of that failure mode: use JIRA, find a bug or feature request, check Atlassian's board, "see someone opens exact same issue 10 years earlier, 3000 upvotes, still 'under review.'"

@ah1508 made a product-counterpoint using cars: Porsche recently showed the Mission-S concept with "not even a screen in the car," and in France the low-cost Dacia Sandero with only basic features is the country's best-selling car. The implication is that feature restraint can be a competitive position rather than a weakness.

The agentic "software factory" concern

Saarinen links the additive drift to how work is now organized. He writes: "Individuals work with agents to produce changes independently, each operating a small software factory. Each change might make sense on its own, but together they start to resemble Frankenstein's monster rather than a carefully shaped sculpture."

His conclusion about the aggregate effect: "Without the shared perspective, soul, or thought, the product becomes an average of all those outputs. The choices that once gave it character are being diluted by day. More things work, but it becomes harder to feel someone or even something behind them."

@ttul agreed about where the real bottleneck sits: "Agentic coding lets you build more things in less time... But the bottleneck isn't coding execution, it's choosing what to build and verifying that what got built doesn't suck." He predicted this will change: "How long before they get trained up on product management? It won't be long. Sorry."

@unsungNovelty framed the trend as an ideological continuation rather than a new one: "People just added LLMs to the 'move fast and break things' ideology of software factory's toolchain. The focus is on making money and ONLY making money."

@kristianc drew the sharpest line between the two meanings of "done": "This age will be brilliant for sorting between those who care about 'done' as in 'technically complete' vs 'done' as 'creates enduring value for the person on the other end of it'. AI largely only does the former."

Taste and values are not automatable

@allenu argued that AI lacks the human inputs that give products intent: "ultimately AI does not have values, intent, and taste... When you use good software, you can sense the intent in what was made. The person (or team) combined their particular point of view with that of the goals of the user." He added that agentic coding "might get most of the shared values and common things right as a result of its training data, but a human still needs to edit the output or steer it on a good path that only they can see."

@jwr, a SaaS author, described where he sees his own value now: "the value is not in the code (AI can code better than me at this point), nor even in the software architecture... It's in deciding what to build and what not to build, defining the overall character and vision of the product, looking at each screen and thinking 'how does this help my customer do their job'." He noted the cost: this "takes time, as one has to restart many times because of ideas that turned out not to be as great as one had initially thought. And it results in software that is called 'opinionated'."

@piro0919 gave a practical example: "Even with Claude Code writing the code, I still decide which features go in, and how the screens look and what they say. Building with a specific user in mind is something I can't leave to AI yet."

@simonbarker87 summarized the principle as "Great software is opinionated," adding: "The opinions are those of the creators and that isn't changing with AI."

@blauditore made the structural version of the argument: "the implementors also act as representatives of the human users of software to be built. That's something which can't be automated away pretty much by definition."

Solo developers may have an advantage

@mik3y raised a question that follows directly from Saarinen's software-factory passage: "Do solo developers consequently have a bit of an advantage today when it comes to producing tasteful, opinionated software?"

@absoluteunit1 reported that solo work does not automatically solve the problem: "I recently left my job and have been working on building a product. And even though I'm solo, I notice it's still very easy to fall into this way of operating. (Even before AI) Having a clear product vision and sticking in to it; whether its features, design, copywriting, etc is really hard to do consistently over the lifetime of building the product."

@tamersalama offered a related observation about who builds the best software: "What if the consumers of software are those writing it? Isn't that what usually made software great?"

The "mind of the maker" tradition behind the essay

@ajrouvoet connected the essay to an older lineage, noting that Fred Brooks cites Dorothy Sayers' The Mind of the Maker in The Mythical Man-Month. The quoted passage divides creative activity into "the idea, the implementation, and the interaction," and Brooks writes that "The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker."

@swiftcoder pointed out that the factory model was never how respected software houses actually operated: "Steve Jobs and Johnny Ive yelling at their minions about user experience. Even Bezos sending the dreaded question mark. Great software was the work of a team translating an auteur's personal vision into software... while the blue chips like IBM churned out useful but soulless software by the corporate method above." He added: "Somehow most people don't seem to believe this anymore, despite the repeated failure of corporate environments to produce better software."

@impoppy applied the idea to a specific tool: FFmpeg. "What kind of a mind created FFmpeg?" The answer, in this commenter's telling, is the same person behind QEMU and tcc — "an exceptional brilliant mind" whose interface choices "chose accuracy over convenience," producing a CLI that is "so obtuse it's unreal." The point is that a product's character can be felt even when that character is difficult.

A/B testing replaces "someone" with optimization

@lightandlight drew a direct line from the essay's argument to a common product practice: "this is why I dislike A/B testing for product development. It replaces the 'someone' with vague broad appeal or rogue optimisation forces."

@convenwis extended the concern to conversational interfaces: "This is why I really hope that we don't end up in the world that a lot of AI pilled people believe is the future: one in which chatting with the AI drives everything and interface basically goes away... Well thought out and built software is so satisfying to use that I would be very sad to see it go."

The scaling objection to intuition

@dozerly raised the most concrete operational objection to the essay's intuition-first stance: "A practical problem with the intuition approach is that you have no possible way to measure two people's intuitions against each other. In smaller organizations that's fine, but anytime you get larger you can't weigh the intuition of 50 people against each other."

@cadamsdotcom offered a partial answer, arguing that Linear's position is easier to hold because the company is its own customer: "Linear can just... track the build of Linear in Linear. When the someone behind the software is its customer they'll get loads of judgment calls right first time." He added a warning for companies that are not their own customer: "plan on being wrong lots- and keep your company and architecture and products compatible with frequent wrongness so once discovered you can pivot to the right thing. No ego."

The counterarguments: AI is not the cause

@solatic agreed with the essay's diagnosis but disputed its attribution to AI. The core grievance, this commenter argued, is the Innovator's Dilemma: "Changes or removals, fundamentally, fuck with how somebody uses your product... When somebody uses something that you fucked with, you risk them churning, that simple." The argument continues that good product leadership "is not afraid of the consequences of fucking with the user," and that "Good Product leadership is rare because good leadership is rare. AI has nothing to do with it."

@elliotto rejected the essay's framing at a more fundamental level: "It is probably a mistake to humanise the artistry of a commercial software endeavour. These systems exist because capital has deemed it worthy to exist, and they will reflect the desires of capital - to consume and expand." This commenter argued that "Capital would cut all the humans out of the software production process if it could," and that open source and personally motivated software are the better examples of human-driven work, while "Linear, while an effective ticket management system, is probably not an example of this."

@zeroq argued the essay conflates several distinct points. Among them: a potter can charge $200 or $2000 for a cup because buyers "pay for the story she's providing with the cup," but that dynamic does not transfer to software; time is the real constraint, not resources; and "If your product is 'Tinder but for horses' it doesn't matter if it was written by LLM or vegans. As long as it works." The same commenter added that "If you want to gradually develop your product vibe coding will get in your way very fast. It's great for prototyping and developing well defined products but in a long run you'll want to know how your system works."

@dmitrijbelikov pushed back on the essay's optimism about easier software: "Nope, cuz we have a lot of Frankensteins and chat interface." This commenter also noted that pre-agent codebases were never perfect either, and that "Behind software not only creator, it's people who interested in and users."

@notesinthefield questioned the whole register of the discussion: "Is anyone observing the AI software dev convo from a sans wax poetic perspective? I dont think 9/10 people are capable here."

@riazrizvi argued the essay's opening insight is only novel to a narrow audience: "Only an audience of software developers would find that first statement insightful. The rest of the world generally understands that expression is a product of the human performing the execution of that expression. That mowed lawn. That email message. That meal they made for you. They are windows into some specific humans."

@lifeisloving noted the idea has a name in another tradition, linking it to commodity fetishism: "Everyone agrees with this sentiment until I tell them its a marxist idea."

Why this matters now

Saarinen's essay ends on an optimistic note about what easier software production could enable: "Making software is getting easier. I hope that gives people more room to develop a perspective and follow it further. To understand a problem deeply and keep shaping an answer until the pieces belong together."

Several commenters framed the moment as a filter rather than a loss. @thinkindie described raising expectations for a team: "I've found myself raising the bar every day with my team in terms of my expectations of what their deliverables should be... the average engineer believe they can do the same with less effort while they should rather think about delivering more and of higher quality, and taking the extra time available to connect the dots. I believe this is going to be a huge filter moving forward."

@hirako2000 put it more bluntly: "We may not wait 70 years to demand craftsmanship this time."

@Nevermark offered the longest view, noting that the problem predates AI by half a century: "the big order bits of software design quality - in general - have moved very little. Certainly less and less over the decades... software systems pervasively demonstrate obviously poor design. That this may involve the unavoidable problems dealing with complex underlying systems, as much as it represents the application developer's lack of taste, isn't an excuse."

@majkinetor summarized the practical takeaway for builders: "This will be the only determining thing in the age of AI - someone who shapes the things based on its own intuition and taste, based on experience."