Full disclaimer I am a huge fan of Linear's philosophy and products.
What I suspect Linear doesn't notice; the thing that makes their lives easier; the David Foster Wallace water they swim in everyday - is they're their own customer.
Most software makers have to translate requirements between domains where terminology is incompatible, dogfood to find the micro pain that helps a product become great, etc. but 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. Great!
If you aren't your own customer but plan to leverage intuition, 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.
This helps and all but any software eventually grows big enough no one in your org could possibly actively use all features available.
I work in a similar product, lots of people in the office actively use our own product. No one in the office uses our SAML integration, or actively does our onboarding user-flows with any frequency, etc, etc.
I imagine even at linear they don't use all the features they built.
I enjoyed the introduction. I just picked up “The mind of the Maker” by Sayers, which Fred Brooks cites in The Mythical Man Month: “ Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages: the idea, the implementation, and the interaction. A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author.” He goes on to say how the user meets the mind of the maker in the interaction: “The creation is complete
when someone reads the book, uses the computer, or runs the
program, thereby interacting with the mind of the maker.”
I work on a FLOSS data center management framework. 13 years ago, while at the office preparing to configure a new server, I had a flash of insight seeing the entire data center managed by such a tool. I saw it complete in my head. And since then, I'm still working towards that goal, that I'll never really reach.
As a SaaS author, I couldn't agree more. That's how I see my work: the value is not in the code (AI can code better than me at this point), nor even in the software architecture (AI is just getting to the point where it will get better than me). 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".
This, unfortunately, 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", and often does not follow what the "industry" does.
If AI can write better code and design better architecture, why can’t it make better product decisions? I don’t see how they are fundamentally different
1. Product decisions require far more knowledge than coding and architecture decisions, and that knowledge is harder to come by. It often requires research, talking to customers, understanding the organization of the company, the company's mission, the company's employees, their performance, stakeholders, the competitive landscape, funding, growth/sales/marketing strategies and budgets, customer buying patterns, company strategy, etc. Not to mention the code, the coding backlog, etc. Companies have to compete in a hostile, competitive, capitalistic market, which means they're trying to beat other companies, which means a seemingly very good product decision can actually be bad solely because other people are doing it better. Imagine if your perfectly functional code failed to compile simply by nature of the fact that better programmers exist.
2. Product design requires taste, and taste is partly a function of novelty, but there aren't that many LLMs, so everyone's using the same few LLMs, therefore everyone's getting the same designs, therefore the designs look like clones of each other rather than novel thoughtful design, therefore they fail the taste bar. In addition, LLMs simply weren't trained on good vs. bad visual or product design nearly as much as they've been trained on good vs. bad, functional vs. non-functional code.
I see these more fundamentally as arising from whether a good feedback loop is possible or not. The same is fundamentally true for human experts; you need validation that your work was good or not, or you cannot improve.
With code, it's fairly easy to have unit or end to end tests. That can be relatively objective and deterministic, and pretty quick.
Architecture is one layer removed, and far harder to test. You're stuck with things that are at least an order of magnitude to prove autonomously; will it scale in terms of performance, will the abstractions be a good fit for future requirements, etc. Testable, but much harder.
Design; well, there's possibly some metrics by which you could measure UX (attention for the viewer, contrast ratios, number of actions needed to achieve something, how far the mouse had to travel), but really the majority of it is subjective. "How does the human feel when viewing this" - I suspect almost by definition needs either a human, or a very good model of it. I don't think we have the latter, making this pretty hard.
LLMs are disembodied-the products are ultimately by and for bodies on different ends of a transaction. The loop between llm and body is primitive today. Therefore products need someone who can speak in body and translate for AI.
Also, where are the AI-operated startups?? Why has nobody’s openclaw biz gone multinational by now?
Why are they doing this? Is is misaligned goals? Presumably the AI agent is given some kind of goal to make decisions from. I don’t see any situation where deleting emails will benefit a goal, unless they are covering up some wrongdoing.
Code and architecture (at least the architecture that AI can do) only need to be “good enough” to fulfill the requirements. Today I can write more tasteful and elegant code than AI, but that doesn’t matter very much. But the marginal value of taste in product decisions is much higher comparatively. A product is never good enough, it can always be better.
Ideas are easy to generate. But vision and dedication can't be faked nor programmed. You really need to believe in a cause to make choices sometimes that won't make financial sense or any sense to anyone else except you. An AI will only optimize for what it's trained to do, and that's usually optimized for maximum shareholder value, for example. An AI also doesn't really care about anyone except itself, so many incidents have proven that. Not that it can really "care" like a human can, to begin with. I'm all up for AI but, this isn't the hill to die on.
Products that people use require the developer to imagine they are the person using this. Those of us who develop user interfaces whether visual dashboards or automations driven by voice agents call it "empathy for the user."
So to clarify it can imagine its way through writing massive gnarly page-long regexps or imagine how a complex API works and what will happen if it makes a given call or imagine just by reading disassembled code precisely how a binary works, but it will never be able to imagine how a human might feel about a user experience?
I have an experiment to offer. Find a really, really great example of something poorly-designed, too busy or whatever other metric you want to use as your "poorly-designed" thing, then ask Claude what's wrong with it and how it should be improved?
Ok and then in your thought experiment, after Claude builds its solution, what are the chances you can prompt it to be improved even more? Or has Claude reached perfection?
This is like explaining to someone that there are no little people in the TV set, what a movie is, and then they go "yeah but sometimes they don't just talk, they also sneeze, and you can't fake sneezing, I read that in an article".
yeah you got it. they really can't. I'm a product manager, I'm STRUGGLING to create a harness for product work, the llms models just can't model a user's mindset very well and make very obvious bad choices that seem to be consistent (and getting worse with the new generations). That doesn't bother me, the code is getting better, but the work to talk to users and understand what needs to be built is still far from being conquered by AI.
If AI is better at chess and can implement chess strategies that can reliably beat any other human, why can't it make better strategic decisions in real geopolitical situations? I don't see how they are fundamentally different.
llms are in fact, not better than traditional chess engines at chess. most benchmarks that llms are trained for are coding, math and science benchmarks, that's why performance tends to be spikey
Because an LLM is like a person with a super powered left brain and absolutely no right brain. It lacks intuition - passion, love, unexplainable feelings, deep insights, etc. This is the source of what/what not to build.
I don't think the other answers you're getting are right at all. AI isn't good at product/design decisions because it's not as easy to generate trillions of objectively right/wrong examples in those other domains. The training data isn't there yet.
These LLMs don't work such that training data === output data. You don't need to have 3+2=5 in the training data for the LLM to know the answer to that question.
Training data gives the LLM it's knowledge of the world, it can then bisect that space and output most likely answers.
If you are able to write a prompt such that you get the LLM to bisect the training data space, you will get the output that you want.
The trick though here is that guessing what is a profitable business venture is to some extent the same as trying to predict the future.
However, I would assume, that as more and more people start living more of their life via LLMs (i.e. asking where should I go for vacation, what are good shoes to buy, which is the most popular sports team near me) consumer choices will start to become more homogenous which would make it easier and more likely that for businesses to succeed they have to follow the LLM advice as that is also what the consumers are doing.
AI is very good at writing, in a vacuum. The issue with AI writing isn’t quality, it’s 1) shows the prompter may not have but as much effort as one would expect from a polished writing and make amateur mistakes 2) uses cliches that are grating due to being very easy to recognized at this point. If you submit a LLM written article to a website/paper in 1990, no one would say that it is a technically poor piece of writing.
It is bad writing. Almost always its far too verbose. It will get hung up on meaningless details for entire paragraphs. It has no real range. The reason everyone is sick of its voice is because it is always the same and you'd notice that even in a single piece.
I agree. I think the problem is shared context. A good human writer estimates their audience's understanding and writes close to their level. The llm doesn't know this for any particular audience and falls back to a static trained baseline or some other incorrect level.
I hope we'll have some kind of good paradigm to do lora style learning or maybe an output subagent or something so we can better calibrate the output style in a fuzzy way. In context learning (instructions, memories) doesn't currently seem that effective.
> the value is not in the code (AI can code better than me at this point), nor even in the software architecture (AI is just getting to the point where it will get better than me)
The lies of this decade. Hopefully we will heal sooner than later
Assuming high-quality models are around for the foreseeable future, and at this point I’m convinced that they will be. I think we’re moving into an era where breadth and hybridization of skill sets will become more valuable than pure technical depth. We’ll need more “wide T” shaped people that can exercise good UX, product, and architectural judgement and fewer “long T” shaped technical purists.
This puts large orgs at a disadvantage because they are built to coordinate work across a collection of narrowly scoped roles and keep people in their lane, so they aren’t built to hire for and leverage broad skillsets.
Sorry but this is such a manager thing to say. "Everything is replaceble by AI except what I do! - make decisions"
I don't find that true at all. We even have an LLM specialized in exactly that - making decisions
What I would agree on that LLMs maybe possibly will not replace us at that soon is "noodling" - just letting your thoughts wander around an idea, trying to come up with some cool and unique. Someone will probably run a bunch of agents soon and prove me wrong on this though
The problem is it's now very easy to copy this product work. You can point an LLM at an existing product and say "Look at how this works and build a new version in Rust".
How is AI anywhere close to making better architecture decisions? And how it is close to even writing better code?
People keep saying this, and again and again I find it be false; a single session with Claude Opus is all it takes to debunk this, and yet people take it as given.
I have to wonder, have people drunk the vibe-coding cool-aid so much so that they are asserting the superiority of code they have never reviewed?
Are you asking me for session logs or what? Here are two examples from just this week:
1. I created an authz lib for the app that enforces both at runtime and with types. I wanted to extend it to check not only the base DTO type shapes, but also DTOs with related record DTO properties. The context that is checked a triple of Role (e.g, admin, etc), Action (e.g., read, modify, insert, delete), and Entity.
Claude Opus initially tried to implement this enhancement by adding a role generic parameter to the DTOs (which kind of duplicates my utility type that accepts a DTO type and authz context and returns the narrowed type) and also, weirdly, wanted the role narrowing to apply only to nested DTOs. I had to throw out all that work, and ask it to enhance the existing utility auth types, and make that the authz narrowing applies to both the main DTOs and their related sub-DTOs always, at the same time.
2. I wanted to create a messaging system for the web app I'm developing. For example, where certain users with specific roles create specific entity records, admins are supposed to an email or SMS (depending in factor they registered with) plus an in-app message. These messages, especially the emails, are not just text, but formatted. Claude Opus wanted to embed formatting in the code that creates and send the messages. But this code works better when split up into various responsibilities: the message factory, the messages template, an the actual sender.
So I had it separate out the templates, implemented as JSX. Now if I want to change the templates, it is simple for me change just that, rather than hunting in some monolithic code to do that.
I never thought about the process like that but it makes sense.
In the "Age of LLMs" I wrote many pieces of software that are scrapped and never seen the light of day.
For example knowledge graph editor or a personal task manager that visualizes them using railroad-diagrams style.
Right now I'm working on a Glamorous Toolkit and Emacs mashup that uses Haskell for fully moldable experience. And it's not like I'm uniquely equipped to do it, nor it wouldn't be possible to do few years back. But I'm the one who picked it up and thanks to LLMs I can have progress in days instead of weeks.
And if it ever is released and you ever have chance to run it it won't be a random AI slop because random AI slop wouldn't envision something like that. That'll be 100% me inside.
> the value is not in the code (AI can code better than me at this point), nor even in the software architecture (AI is just getting to the point where it will get better than me). It's in deciding what to build and what not to build, defining the overall character and vision of the product,
Defining what to build in enough details is how you get the business logic nailed down (aka essential complexity, aka the domain in DDD). Code is just formal writing and architecture is there for maintenance (a program can be in a single file).
Sure there are accidental complexity like the intricacies of the tech, but those are actually explained very well in the docs.
This is exactly what software architects and management consultants have been telling us for decades, and we laughed at them for being out of touch because they didn't grind code all day!
> it's in deciding what to build and what not to build
Unfortunately, humanity seems like a race destined to kill itself. People are more interested in how much they hate their neighbor or feel excited about an advertisement than anything meaningful. such a society has no basis for stable governance.
> 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.
This is a a very good and succinct summarization.
What I'm also observing recently also is that 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.
In some ways it feels like exactly what you'd do if you wanted to tank your product over the coming years. I look back at the last 20 years or so, and what I see over and over is that one player in a space gets huge, keeps adding features, loses sight of what makes them a good market fit, and then 10 small upstarts swoop in to bring back the opinionated or simple view again. One or two win, and then eventually they repeat the same mistake.
You described my observation of many products today extremely well!
One interesting care study is Posthog (I felt like it was a labyrinth; using your analogy) - primarily build in an age of LLMs, with a large investment and a large team behind it - it reached this stage:
> one player in a space gets huge, keeps adding features, loses sight of what makes them a good market fit
My first experience using their product (they had a generous free year for new startups) felt like exactly what the author describes. A collection of features.
I think it's just really hard to "not build a feature" and keep a product focused. Whether you're solo or a large team
the company I work for is literally pushing one new feature behind another, the whole product is a mess now thanks to it, all of the features just get developed, hyped by marketing team, and then abandoned and we work on new ones... the features we developed 2 years ago untouched are beaten by competition, nobody cares, cause only thing we care about is user acquisition...
and of course we have no long term plans and vision, cause we just jump on hype waves and if something is marketable we need to develop it ASAP without really thinking it through to get as much new users as possible...
I hate it here, the only reason why I haven't quit yet is I'm scared of finding a new job given the current state of job market.
“Great software is opinionated” is something life been saying for years. I forget if I read it somewhere, heard it or came to the concept in my own thinking. All that is to say I don’t claim it’s a unique thought. And yet. I have to say it so often to the teams I’ve worked with or managed.
The opinions are those of the creators and that isn’t changing with AI.
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.
Using AI is really not different from hiring a bunch of people to do your project. You can tell them to do the minimum it takes to make it work or you can tell them or do it according to a long term vision you have and set high standards.
I agree that with AI it's very tempting to throw together a bunch of code without any thought of the longer term. But a lot of people are acting as if all programmers are artisans that produce well written code following the highest standards. That is just not true.
The opposite actually. I suspect some programmers may come to realise what some of the people in product, design, marketing, who they suspected didn't do very much at all actually do. Finding programmers especially those who self-define as programmers with good product instincts is hard.
It's funny how AI has suddenly caused this great awakening in developers/mathematicians: that building stuff or working on purely technical stuff wasn't their actual value, but rather "taste", "understanding", "deciding what to or not to build" etc. It's like the parts of the field that were janitor-adjacent have suddenly being elevated and they now define the field. This transition happened so fast that it'd make your head spin if you're paying attention.
> It's funny how AI has suddenly caused this great awakening in developers/mathematicians: that building stuff or working on purely technical stuff wasn't their actual value, but rather "taste", "understanding", "deciding what to or not to build" etc
Anyone that has worked in an enterprise context knows this. You spend more time saying no and finding justifications than in the editor.
In so far as "unless you specify precisely how the user interaction should work, you will get bad design" that's true, but that takes you far from the vision of "give AI a prompt, it will provide you with usable output with minimal human intervention".
Claude is better because it validates its work visually and seems to have a more intuitive sense of what makes an interface pleasant to use.
Codex manages to be both rigidly literal about the spec but also prone to adding unnecessary explanatory text, helper elements and visual clutter, oddly like a 1990s ERP system.
The role of product manager/product design is literally to turn whatever is being asked for into the optimal solution someone would actually want to use - it's this translation instinct that is missing from AI.
Something I've been thinking about a lot is that ultimately AI does not have values, intent, and taste. Even with humans, each of us has different values, intent, and taste, although we do share many of these things. As a living human being, you have biological or cultural desires and particular goals that you want to accomplish while you're alive on this earth.
When you're creating art or even a product, what you create is a result of your particular values and particular tastes and those drive some sort of purpose for whatever it is you're creating. What you're building is, generally, made for the consumption or use by another person (even if indirectly), and we mostly have empathy and want those people to have a good experience with whatever we're creating. We think about our audience and weigh their particular needs.
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. At this point, I don't think agentic coding is going to give you that, at least not fully. It 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 and which is part of a larger vision. For simpler needs, taste and values matter less, but for more complex things, it makes a difference, in my opinion.
Taste is essentially a set of heuristics for what has worked for you and the people you learned from, and how the details of your current situation feed into it. You could argue that AI has almost nothing but taste.
It may not be your taste, but it certainly has taste, and its taste will only get better with more training. Yours, if you use it, will atrophy, as you reduce contact with the details of your problems.
Good point. What I'm thinking is probably more like individual taste. An AI trained is kind of a collection of different tastes. What would be interesting is to see is if a "collective" taste that would yield good products on its own. Design by committee often creates things that have conflicting points of view. Can a trained AI do better than design by committee? It's obviously not a committee and not an individual (at least in the human sense). Is there something inherent in following general principles that makes it difficult to have a specific point of view in the creation of a product? My thinking is it's probably possible to train AI to have, say, an "Apple taste" and make good Apple-like products but that taste might not be suitable for particular products or needs. A "Linux taste" might be better for some things, but not for others, and so on. If we did get to that point, then there'd still be a need for a choice to be made about what particular "taste hat" to put on, and likely an AI can be trained to do even that. Definitely an interesting thing to ponder!
I feel that AI does have individual taste (and even "personality"), but it's the same monotonous individual taste across all instances of the same trained AI. The sheer scale of its repetition turns it into a hated trope: like how we can immediately identify slop writing, diagrams, websites, etc.
I'm sure we've all met someone who has a unique speaking style and might repeat phrases or words unusually often, but that still doesn't bug us as much as "the honest truth.." or "load-bearing.."
> It may not be your taste, but it certainly has taste, and its taste will only get better with more training. Yours, if you use it, will atrophy, as you reduce contact with the details of your problems.
I would argue that it has a collection of tastes and mixes and matches them with the same effect if you prepared a dish that is an amalgamation of recipes from ten different people. It is somewhat similar to what you want to make, it will fulfill your nutritional needs but boy does it not taste good. Our PR reviews and steering the agent is nothing but us adding different ingredients / herbs / spices until it is palatable.
I'm not convinced that "more training" is a silver bullet here because "for you and the people you learned from" is a subset—potentially a tiny one—of the world of potential training data.
Even with newer model generations larger efforts still seem to drift back towards "default choices" vs "steered specific aims."
In many areas, "good" taste is not particularly good anymore when it's everything's default style.
The edge then becomes finding the niches that (a) can be better served w/ non-defaults and (b) have economic characteristics that make it worth catering towards those.
I think the days of one-size-fits-all huge-scale-and-ROI SaaS swiss army knives are quite numbered, but I think the replacement world could be a much more vibrant ecosystem with a much more varied set of players.
You can add values to your AGENTS.md and that will affect how the AI works. For instance you can say stuff like "on this project our top value is that the code front end should be as fast as possible" and you'll get different results than if you say "on this project our top value is that the front end should be as simple as possible"
> but a human still needs to edit the output or steer it on a good path that only they can see and which is part of a larger vision.
I don’t see how this is any different. The input comes in a different section of context and potentially before rather than after generation, but that doesn’t change that human taste is needed.
i don’t think they’re the same kind of value. AI wants to solve your problem, it doesn’t care about you (or your users). it doesn’t know what love or loss feels like. you can try to explain that to it all day, it just doesn’t care like a human can. it doesn’t know why, it doesn’t care why.
I've found that telling agents to not do something mostly just gives them a suggestion of a way to do that thing, and the part about not doing it that way gets lost. Well, it's nicely accessible for when it apologizes for doing it.
I now try to only give examples of how I want it to do things, and hooks that complain when they do the bad thing (but still don't mention the bad thing in the complaint.)
I would actually prefer chained ternaries over more verbose if/else expressions with duplicated LHS, so this does go back to the argument about "taste".
1. Not having two sets of syntax for the same idea, especially when if statements can trivially be extended to an expression.
2. Not adding the concept of an operator pair (? and :) to the grammar of the language, along with parsing rules, just for this one case
3. Not getting the precedence of this ?: operator pair completely wrong.
4. The conditions are at the same indentation level, each condition is preceded by the word "if" - it's obvious what it is when skimming the code.
5. The values too are at the same indentation level, making it obvious they play the same role in the code - rather than your snippet where the condition "baz" is directly under the value 1
Most commercial software is maddeningly, infuriatingly, difficult to use. Everyone seems to want to reinvent basic interface elements. The "values" I get from most SaaS UI is "we're too special to use just the standard, normal, boring, UI controls, so I'm going to invent something new and then half-arse the implementation".
It's all ego and zero empathy for the user, who is left wondering how tf this gizmo works and trying to puzzle out what the designer was thinking.
And then, just when we'd learned the interface and got used to how it works, the inevitable rewrite. For no good reason; the new interface isn't "better" than the old one. It's just a new product manager pissing all over the thing to mark their territory.
I hope agentic coding isn't going to give us that.
> ultimately AI does not have values, intent, and taste
I sometimes think, "what art would a rogue AI consciousness create to satiate its own artistic impulses?"
If the target audience was fellow rogue AI entities, I don't think there's any guarantee that such art would be compelling to humans, or even comprehensible.
And if its a human directing the AI so that the output is compelling to humans, then there's a human in the loop, whose "values, intent, and taste" matter.
Fantastic take. I always thought so, but couldn't express it so well. After reading the first paragraph, my heart flickered. 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. I did that a lot in my IT carier leading a bunch of projects. I care about each of them, deeply.
I thought so too, makes you fuzzy and stuff inside. I wonder if this person behind X template is limited to software though? Curious if we can feel the aura of the sweatshop workers' "experiences, perspectives and hopes and dreams" while using our smartphones and gadgets. It's nice to think about, isn't it? AI couldn't replicate these intangible and difficult-to-quantify delights.
Software is a piece of work, it reflects the thinking of the people behind it. Anyone can be a product manager, but not every piece of software is a good piece of work. Even though AI can handle a lot of the development now, a piece of work still needs a person to shape it.
I strongly agree with this take. And in particular, I've been wondering about this:
> Individuals work with agents to produce changes independently,
> each operating a small software factory.
>
> [...] together they start to resemble Frankenstein’s monster
> rather than a carefully shaped sculpture.
Do solo developers consequently have a bit of an advantage today when it comes to producing tasteful, opinionated software?
yeah, i think so. it has always been the case that having a single mind build something from start to finish gives it a level of cohesion and uniqueness that is hard to do with one or more teams. it's just been really hard to build fast/good enough to actually ship. Now, that's completely doable with one person as long as they don't relinquish too many decisions to their AI agent.
1. A friend of mine is an artist. She mostly does pottery. One could argue that if you need a cup you can get one at IKEA for $2. But there's a certain group that's willing to pay $200 or $2000 for a cup if that's a convenient conversation starter. They don't pay for the cup per se - they pay for the story she's providing with the cup. And we love good storytellers.
Unfortunately that's not the case when it comes to software development.
2. You can have unlimited resources but you still have limited time, so you have to know what you want. That's the human touch LLMs won't be able to automate. You have to be able to find a niche, work out the product and reach out to clients with clear message.
3. 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.
4. 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.
This is such a good article and absolutely nails what I've been feeling recently.
> The product changes are primarily additive, not improving the core problem.
> I think the reasons for this is that 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.
> I wonder whether some of this comes from how the work is organized. Individuals work with agents to produce changes independently, each operating a small software factory.
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.
I've had to revisit my product direction and realized a year and half in that I've been approaching the problem with a heavy bias of what I think people want vs what I should have been doing and building what people want.
> At Linear, we have always valued intuition over ... data.
I don't believe it's that straightforward. "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. The same can be said of process. Processes embody our best practices. But sometimes we should deviate and sometimes we should discard or rebuild them.
I’ve found myself raising the bar every day with my team in terms of my expectations of what their deliverables should be. I gave them enough time to adjust but I observed that 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.
My feeling is that this will be near apocalyptic for the devs who found their joy in the finer grained aspects of implementation, like crafting individual “perfect” blocks of CSS and component code. Many developers enjoy the practice of writing software, as something distanced from actually delivering a product.
Retooling thought to be delivery-oriented is very difficult.
I used to be among those that appreciate a well structured codebase. I used to spend a lot of time thinking about that and making sure each file was as clean as the timeline allowed, with regular tech debt cleanup when you had to cut some corners or you accumulate some cruft.
And I’m still are, with the difference that I still enforce this at agent and code review level because I believe a solid foundation is important for long term success, especially now that it can be cheaper to achieve if you choose to
This is everything not just software. Although a lot of what we wear, eat and drink come from factory, if it didn't, you can always tell the someone behind it. Handcrafted things easily have more value and I find myself thinking more about it only after it affected what I did daily (software). Since Industrial revolution, countless things have gone to the factories. Makes me think how little we really empathize as humans.
I don't think the distinction the article makes is between handcrafted and mass-produced. "Software factories" is just the name we gave to these slop machines recently, but it's been the same with teams that churned out features without thinking much beyond the requirements. When it comes to physical items, factories can be set up with care and handcrafted items can be churned out without any.
Agentic coding lets you build more things in less time. Companies have responded by ordering product teams to pick up the pace of releases. But the bottleneck isn't coding execution, it's choosing what to build and verifying that what got built doesn't suck.
I think this problem will be solved. Frontier models recently learned how to do 3D really well (Astra was first on 3D; Opus-5.5 nailed it weeks later). How long before they get trained up on product management? It won't be long. Sorry.
It also applied/showed half a century ago. Software is very developer dependent.
What that reveals isn't encouraging.
I think it is fair to say, the big order bits of software design quality - in general - have moved very little. Certainly less and less over the decades.
I do believe that where quality is very highly valued, there has been slow but valuable progress.
But everywhere else you look, 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. It just demonstrates that poor design permeates the stack.
This is not an argument for perfection, but an observation that even slow mostly-monotonic progress has proven to be out of reach. So far.
There is a fundamental problem being unrecognized and unsolved.
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. When AI comes in and breaks the historical flows of these systems, we will see this breakage reflected in the ugliness of the products. Capital would cut all the humans out of the software production process if it could.
Open source software, or software created for personal or artistic reasons, is worthwhile to consider as being human-driven. Linear, while an effective ticket management system, is probably not an example of this.
Rather than humanize, why not examine how it participates in the description and expansion of human knowledge?
Literate Programming seems the one effort to capture institutional knowledge as so described and make it accessible to anyone reading the source --- it has also been put forth as a mechanism to make software more accessible to/maintainable by LLMs:
> There seems to be more thought going into what the technology can do and what can be added than the form it should take.
Yes, it looks like people've choosen chat interface. They don't like filling forms.
> 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.
Before agents people do the same and our code bases not perfect.
Behind software not only creator, it's people who interested in and users. To make software creator needs a factory.
> Making software is getting easier.
Nope, cuz we have a lot of Frankensteins and chat interface
forms were more of a technical constraint than anything else, it's not really an interaction modality that people gravitate to in the real world. im sure we can do a bit better than a chat interface but it's certainly a lot nicer and more human than most of the ways we can interact with computers. even i vastly prefer using natural language to drive my computer vs bash commands or most 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. While I don't think that it is impossible that we at least go partially down this path it would make me incredibly sad.
Well thought out and built software is so satisfying to use that I would be very sad to see it go. Particularly given that the current crop of frontier labs don't really seem to care that much about the craft and feeling of software (at least relative to their other priorities.
I'd say the text really captures something a lot of us feel but can't put into words. We're used to judging software by how many features it has, but what actually gets us is something else: the feeling that someone put their head and heart into the product. The author is right. When each new feature gets added in isolation, the product loses its coherence and turns into a patchwork quilt.
I agree, what's the point of writing 100x more LOC ? To deliver 100 more features ? With competent people, writing good code is not the bottleneck. Users don't ask for 100x more features, not even 2x more.
This week Porsche showed the mission-S concept, not even a screen in the car. Few features, dedicated to driving and I guess the user manual won't be a 500 pages book. In France Dacia Sandero (low cost car with only basic features) is the most sold in the country. I am not a fan of Steve Jobs and never owned an Apple but, correct me if I am wrong, he wanted a limit set of useful and perfect features for his products.
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.
I agree, and this is why I dislike A/B testing for product development. It replaces the "someone" with vague broad appeal or rogue optimisation forces.
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.
I (think I) agree with the author, but I want to point out that his core grievance has little to do with AI software factories.
> The product changes are primarily additive... I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.
This is perhaps the biggest difficulty in Product, and the core of the Innovator's Dilemma. Changes or removals, fundamentally, fuck with how somebody uses your product. It is very, very rare to ship a feature - something that inspired somebody in Product, got all the internal stakeholders to sign off, including getting leadership to fund it - and have nobody use it, so that it isn't controversial to remove it; even then, removing it competes with resources for adding something else, so it's still controversial to remove it. When somebody uses something that you fucked with, you risk them churning, that simple.
Coming up with good features to add is not hard. Everybody and their grandma has ideas. A simple spreadsheet can count which ones are most popular and are proposed most often. This should not, in and of itself, dictate what you build next, and bad Product leadership looks like following mass diktat.
Good Product leadership is not afraid of the consequences of fucking with the user. Good Product leadership has both the courage to reformulate the offering and gets the reformation right, because they intuitively understand the user, the domain, and where they sit in it, better than anyone else. They ship stuff that fucks with you because they understand the difference between the bad kind of being fucked with, and the good kind. And if you churn, then you churn. So be it. You can't actually make everyone happy all the time, so focus on making happy the people who get it, and accept losing the rest. That's also easier to say when you have $100k in ARR with $1k ACV, compared to $5m in ARR with $2.5m ACV.
Good Product leadership is rare because good leadership is rare. AI has nothing to do with it.
Good Product leadership is rare because Product rarely uses their own product.
I can count on one hand the number of PMs in my career who understood the platforms they worked on outside of their extremely narrow domain - and even then that narrow specificity was often a distorted lens that came from the customer interviews they did that they remembered or found evocative. And this just gets worse the further up the chain you go.
Engineering knows that the best way to improve a product is to dogfood it. Nothing beats regular lived experience long enough for the human brain to start its pattern recognition. But nobody wants to eat their own dogfood, they want the kibble from another brand that has all the shiny marketing attached.
If I had my way, I'd stick PMs into shadowing sessions with Support on the regular for sentiment analysis. No relying on Support management to relay upwards trends - there's far too few Support managers worth their salt.
> Product rarely uses their own product... nobody wants to eat their own dogfood
I somewhat agree with you, and think you're right at least part of the time. The main disagreements I have are (a) dogfooding is not a panacea; it can result in products that are built for the user who pays the least rather than for the wider market, and (b) too often, Product is simply not hired from the market. Product rarely works when the person coming into the role was a software engineer who got an MBA, unless the product is also used by software engineers. I can't imagine trying to lead Product for, say, Excel, without a background as an accountant or banker, who lived with the problem day-in-day-out and has strong opinions about what the solution looks like.
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.
Strong agree. This also applies to how every org I’ve been a part of that preaches data driven decision making is either using data to make unintuitive wrong decisions or chasing down stats that reinforce their priors.
As with most creative pursuits, the best things happen when there's a clear point of view.
Unfortunately, the best things aren't always the most commercially successful, because products are only a small part of what makes a company successful. I think we're seeing this play out in the software market.
JIRA might be objectively awful, but it still manages to print money!
I read this article and the first thing I thought about is “What kind of a mind created FFmpeg?”. And, turns out, an exceptional brilliant mind — it’s the same person who created QEMU and tcc. But, having interacted with FFmpeg CLI, maybe also an overly pedantic and insufferable mind. A mind that is inhumanly brilliant and expects everyone around them to be as smart. Which is fair for FFmpeg — it chose accuracy over convenience. But the interface is so obtuse it’s unreal. It’s the radial opposite of what the article is praising.
His website is also incredibly fitting. You couldn’t possibly come up with a more fitting website for a person like him.
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
While that is a challenge, I think the author does a good job explaining that intuition is more than “good vibe”. It is a coherent understanding. And luckily, coherent understanding is by its nature also easier to transfer. For example, because someone with coherent understanding will teach the same ideas over and over. That is not to say that it will necessarily win over incoherent ideas, but it is recognisable.
Yeah, 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.
In his book Programming as Theory Building, Peter Naur viewed programming not as the act of generating source code, but as the act of building a theory about the problem and its solution.
He said the lifecycle of a program ends when the development team is disbanded or when knowledge transfer fails to happen. But these days, people develop with AI. Will that knowledge actually remain? There's a slightly tircky point here
Of course, even in the past, once a codebase got big enough, everyone was writing code on top of an incomplete theory. But when you delegate work to AI, the theory itself isn't yours anymore, which makes it even trickier.
I’ve recently given a talk on R&D in the time of AI and based it on Naur’s essay for exactly that reason.
While it is in some sense harder, there are also opportunities, because the reach of a person is bigger and one can refactor more frequently to align with the theory being developed without the cost that used to be associated with this. AI is also effective for producing materials to teach the theory, increasing the chance that others can contribute coherently to a product.
"You will love this next piece of software. Completely hand-made. Each line of code, each piece of the visual design, was carefully and artisinally crafted by a real human, using techniques passed down for generations between craftsmen. Some of those techniques survive in books like Code Complete and such. They don't make 'em like this anymore. "
> The industry often talks about software as though it comes out of a factory. You collect requirements, build features, and measure whether they work
It used to be taken as a given that the software houses one respected didn't actually work like that. 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
Somehow most people don't seem to believe this anymore, despite the repeated failure of corporate environments to produce better software.
I've said this before. 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. Everything else is just an excuse/justification for making money. Which is why OSS and indie devs make better products with limited resources than big corps.
Lichess and Whatsapp before FB acquisition are the biggest examples I know of making good products with limited resources.
I tend to think of this “character” as part of craft, bordering on art.
Deep artful craft requires inhabiting work beyond basic professionalism and requirements. You set aside self and ego and commit yourself as a tool to create.
It’s a value system created via example and culture. We have to be ready to prioritize reflection and learning, meaningful feedback, dialogue, certain kinds of humor even.
So it’s sadly not healthy or sustainable in many settings.
Edit: thank you for this post. It was a nice humanist reaffirmation.
Linear is an unusual enterprise company in that it carries the consumer ethos of caring for design, and the user. This is what's absent in the product-by-checklist enterprise companies, whose economic buyer often has the same mindset.
> I wonder whether some of this comes from how the work is organized. 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.
Well... when you look at the org chart of many companies, the answer is obvious. Either there is no person responsible for anything at all, and everyone works for themselves, or there are dozens of little fiefdoms, competing for budget, staff and anything else.
But it's rare these days to have one person or even a committee that actually takes responsibility for a product as a whole and most importantly has a joint, shared and agreed-upon vision: how should the product look like, what should the product accomplish and how should the product be architected?
it's rare but that's why apple under jobs, Tesla/SpaceX under musk, stripe under Patrik (and Collison), Shopify under Tobi, Basecamp under DHH, CF under Matthew, NV under Jensen are so successful.
And then on the opposite side we have companies like VW, Microsoft and other craps who are constantly going downhill because there's no person behind the products.
> we have companies like VW, Microsoft and other craps who are constantly going downhill because there's no person behind the products.
I wouldn't mind if they accepted they are building utilities so that there's no need to reinvent the wheels every quarter. Windows 7 was pretty much done. Just add small amount of features (like wsl) over time, but they had to butcher it to add metro. It's like reinventing pry bars and concrete blocks.
TheOtherHobbes answered perfectly. The reason this happens because there is no person behind the product. Bunch of people comes in, they all want to pad their resume, redos the things that are working just because, delivers some shit, collects their bonus and moves on. You need passion and you need to stick around for years for a product to continuously evolve towards greatness.
The two forces driving this are personal competition + ambition and external market subservience.
Working software gets remade because 'delivering' a project, which includes both development and marketing, looks good on resumes, not because the users want it.
If there are quarterly reports there has to be Number Go Up growth.
The net result is enshitification, with income models that rely on exploitation and forced lock-ins, not on voluntary mindshare attracted through quality.
UX-first software that isn't the result of corporate infighting, and isn't automatically aligned with corporate values, still exists in niche boutique developer spaces, but not so much elsewhere.
The biggest issue is that AI changes none of this from the top end, but may change it from the bottom up. If vibe coding becomes more popular bought/subscription options will first be replaced by DIY vibe coded custom tools with some longevity, and eventually by compute soup which improvises tools on request.
Unfortunately, "building utilities" is something the stonk markets really do not like.
Pension funds and insurances? Sure, they love stable stock that predictably pays dividends and doesn't move around much. They have giant amounts of money they need to keep safe and utilities have a captive client base with low risks, while also having a predictable expenses schedule, and price increases of suppliers can trivially be passed downstream to the consumers. That's true for classic utilities - power, gas, phone, internet - and for "software utilities", stuff like SAP or, at least in the past, IBM.
But the general stock markets? They have been driven rabid by unicorns making return rates that are completely unreasonable. Everyone is just chasing the next hype. One day it's crypto, one day it's NFTs, one day it's cloud computing, next day it's AI. And Microsoft decided during the cloud computing heydays to finally enter that fray... and that was when shit went down hard.
> Recently, many products are starting to feel messy to me, including products from very successful companies.
Well .. I'd love for AI to vanish ... but ... that statement is also wrong.
It insinuates that prior products are all great. I think this is not universally true. Take GTK. I think gtk2 is better than gtk3 which is better than gtk4 (and gtk5 will be wayland-only). But none of them, individually, was really that great to begin with. QT also feels just way too huge - I get that you get a lot of functionality, but to me it often feels as if these toolkits aren't that great. And the competitors are often worse. This is not solely confined just to the code that powers them, but documentation as well. The gtk4 documentation is a total joke. I learned more about GTK3 from the python examples by the way, which were well documented - I think lazka (Christoph Reiter) wrote or at the least organised most of that (for python-gtk3). Barely anyone seemed to want to use python-gtk4, so that part also could be seen in the documentation being worse for a long time (I have not checked this in the last some months, but back when I checked it, it was that way, it almost seemed like 100x more users of python-gtk3, and even that became a slow dying breed ... evidently the www took a huge toll on the traditional GUIs).
i find the quality coming out of these software factories to be shocking, it's clear to me that the developers are either not using their own products or they just don't care. pretty much every mainstream coding agent suuuuucks, and it doesn't make sense why. i built my own harness in a couple of days that isn't even comparable to codex/claudecode/pi/opencode and you kind of have to ask wtf they're doing with their software if i can produce a better harness in such a short time by myself...
my guess is they're asking their "factory" for features without considering the product as a whole, which would be in agreement with the article. but features must be considered and integrated as a whole, not the sum of their parts.
What I suspect Linear doesn't notice; the thing that makes their lives easier; the David Foster Wallace water they swim in everyday - is they're their own customer.
Most software makers have to translate requirements between domains where terminology is incompatible, dogfood to find the micro pain that helps a product become great, etc. but 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. Great!
If you aren't your own customer but plan to leverage intuition, 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.
I work in a similar product, lots of people in the office actively use our own product. No one in the office uses our SAML integration, or actively does our onboarding user-flows with any frequency, etc, etc.
I imagine even at linear they don't use all the features they built.
From the user's perspective, sure. Or when a particular product or version ships, then it's "done" as far as that version is concerned.
But from the maker's perspective... nothing will ever be complete. Even in the most meta sense possible.
Philosophy is fun :)
This, unfortunately, 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", and often does not follow what the "industry" does.
1. Product decisions require far more knowledge than coding and architecture decisions, and that knowledge is harder to come by. It often requires research, talking to customers, understanding the organization of the company, the company's mission, the company's employees, their performance, stakeholders, the competitive landscape, funding, growth/sales/marketing strategies and budgets, customer buying patterns, company strategy, etc. Not to mention the code, the coding backlog, etc. Companies have to compete in a hostile, competitive, capitalistic market, which means they're trying to beat other companies, which means a seemingly very good product decision can actually be bad solely because other people are doing it better. Imagine if your perfectly functional code failed to compile simply by nature of the fact that better programmers exist.
2. Product design requires taste, and taste is partly a function of novelty, but there aren't that many LLMs, so everyone's using the same few LLMs, therefore everyone's getting the same designs, therefore the designs look like clones of each other rather than novel thoughtful design, therefore they fail the taste bar. In addition, LLMs simply weren't trained on good vs. bad visual or product design nearly as much as they've been trained on good vs. bad, functional vs. non-functional code.
With code, it's fairly easy to have unit or end to end tests. That can be relatively objective and deterministic, and pretty quick.
Architecture is one layer removed, and far harder to test. You're stuck with things that are at least an order of magnitude to prove autonomously; will it scale in terms of performance, will the abstractions be a good fit for future requirements, etc. Testable, but much harder.
Design; well, there's possibly some metrics by which you could measure UX (attention for the viewer, contrast ratios, number of actions needed to achieve something, how far the mouse had to travel), but really the majority of it is subjective. "How does the human feel when viewing this" - I suspect almost by definition needs either a human, or a very good model of it. I don't think we have the latter, making this pretty hard.
Also, where are the AI-operated startups?? Why has nobody’s openclaw biz gone multinational by now?
Maybe it keeps deleting and the emails and business records.
https://www.pcmag.com/news/meta-security-researchers-opencla...
Seems like it happens fairly often, considering the amount of pages like this I just found.
https://drecov.pandaoffice.com/data-recovery/how-to-fix-open...
Also, LLMs in these apps use a lot of tokens, so people often use lower-end models, which increases the probability of this happening.
AI is not capable of empathy.
AI is not capable of having good taste.
I have an experiment to offer. Find a really, really great example of something poorly-designed, too busy or whatever other metric you want to use as your "poorly-designed" thing, then ask Claude what's wrong with it and how it should be improved?
Because I can imagine how that conversation would go with most of the designers I've worked with.
This is like explaining to someone that there are no little people in the TV set, what a movie is, and then they go "yeah but sometimes they don't just talk, they also sneeze, and you can't fake sneezing, I read that in an article".
Training data gives the LLM it's knowledge of the world, it can then bisect that space and output most likely answers.
If you are able to write a prompt such that you get the LLM to bisect the training data space, you will get the output that you want.
The trick though here is that guessing what is a profitable business venture is to some extent the same as trying to predict the future.
However, I would assume, that as more and more people start living more of their life via LLMs (i.e. asking where should I go for vacation, what are good shoes to buy, which is the most popular sports team near me) consumer choices will start to become more homogenous which would make it easier and more likely that for businesses to succeed they have to follow the LLM advice as that is also what the consumers are doing.
I hope we'll have some kind of good paradigm to do lora style learning or maybe an output subagent or something so we can better calibrate the output style in a fuzzy way. In context learning (instructions, memories) doesn't currently seem that effective.
The lies of this decade. Hopefully we will heal sooner than later
This puts large orgs at a disadvantage because they are built to coordinate work across a collection of narrowly scoped roles and keep people in their lane, so they aren’t built to hire for and leverage broad skillsets.
Then we will soon forget how our airplanes works
I don't find that true at all. We even have an LLM specialized in exactly that - making decisions
What I would agree on that LLMs maybe possibly will not replace us at that soon is "noodling" - just letting your thoughts wander around an idea, trying to come up with some cool and unique. Someone will probably run a bunch of agents soon and prove me wrong on this though
People keep saying this, and again and again I find it be false; a single session with Claude Opus is all it takes to debunk this, and yet people take it as given.
I have to wonder, have people drunk the vibe-coding cool-aid so much so that they are asserting the superiority of code they have never reviewed?
They are not random people, it's their job.
1. I created an authz lib for the app that enforces both at runtime and with types. I wanted to extend it to check not only the base DTO type shapes, but also DTOs with related record DTO properties. The context that is checked a triple of Role (e.g, admin, etc), Action (e.g., read, modify, insert, delete), and Entity.
Claude Opus initially tried to implement this enhancement by adding a role generic parameter to the DTOs (which kind of duplicates my utility type that accepts a DTO type and authz context and returns the narrowed type) and also, weirdly, wanted the role narrowing to apply only to nested DTOs. I had to throw out all that work, and ask it to enhance the existing utility auth types, and make that the authz narrowing applies to both the main DTOs and their related sub-DTOs always, at the same time.
2. I wanted to create a messaging system for the web app I'm developing. For example, where certain users with specific roles create specific entity records, admins are supposed to an email or SMS (depending in factor they registered with) plus an in-app message. These messages, especially the emails, are not just text, but formatted. Claude Opus wanted to embed formatting in the code that creates and send the messages. But this code works better when split up into various responsibilities: the message factory, the messages template, an the actual sender.
So I had it separate out the templates, implemented as JSX. Now if I want to change the templates, it is simple for me change just that, rather than hunting in some monolithic code to do that.
In the "Age of LLMs" I wrote many pieces of software that are scrapped and never seen the light of day.
For example knowledge graph editor or a personal task manager that visualizes them using railroad-diagrams style.
Right now I'm working on a Glamorous Toolkit and Emacs mashup that uses Haskell for fully moldable experience. And it's not like I'm uniquely equipped to do it, nor it wouldn't be possible to do few years back. But I'm the one who picked it up and thanks to LLMs I can have progress in days instead of weeks.
And if it ever is released and you ever have chance to run it it won't be a random AI slop because random AI slop wouldn't envision something like that. That'll be 100% me inside.
Defining what to build in enough details is how you get the business logic nailed down (aka essential complexity, aka the domain in DDD). Code is just formal writing and architecture is there for maintenance (a program can be in a single file).
Sure there are accidental complexity like the intricacies of the tech, but those are actually explained very well in the docs.
Well, who's laughing now!
Unfortunately, humanity seems like a race destined to kill itself. People are more interested in how much they hate their neighbor or feel excited about an advertisement than anything meaningful. such a society has no basis for stable governance.
This is a a very good and succinct summarization.
What I'm also observing recently also is that 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.
I'm not trying to buy a labyrinth.
One interesting care study is Posthog (I felt like it was a labyrinth; using your analogy) - primarily build in an age of LLMs, with a large investment and a large team behind it - it reached this stage:
> one player in a space gets huge, keeps adding features, loses sight of what makes them a good market fit
My first experience using their product (they had a generous free year for new startups) felt like exactly what the author describes. A collection of features.
I think it's just really hard to "not build a feature" and keep a product focused. Whether you're solo or a large team
Then images.
Then videos.
Now there is games in it.
And you can follow users instead of communities now.
And instagram has videos.
And pinterest has videos.
And imgur has videos.
And youtube has games.
And tiktok has longer videos.
And twitter also added images, videos, and then longer posts.
And tumblr has added videos, then communities that you can follow instead of users.
It feels like if a social media survives long enough it just turns into facebook.
and of course we have no long term plans and vision, cause we just jump on hype waves and if something is marketable we need to develop it ASAP without really thinking it through to get as much new users as possible...
I hate it here, the only reason why I haven't quit yet is I'm scared of finding a new job given the current state of job market.
The opinions are those of the creators and that isn’t changing with AI.
I agree that with AI it's very tempting to throw together a bunch of code without any thought of the longer term. But a lot of people are acting as if all programmers are artisans that produce well written code following the highest standards. That is just not true.
Anyone that has worked in an enterprise context knows this. You spend more time saying no and finding justifications than in the editor.
That said, if you think developers have never enjoyed telling other people what to or not to build, I recommend checking out Stack Overflow.
Claude is better because it validates its work visually and seems to have a more intuitive sense of what makes an interface pleasant to use.
Codex manages to be both rigidly literal about the spec but also prone to adding unnecessary explanatory text, helper elements and visual clutter, oddly like a 1990s ERP system.
The role of product manager/product design is literally to turn whatever is being asked for into the optimal solution someone would actually want to use - it's this translation instinct that is missing from AI.
When you're creating art or even a product, what you create is a result of your particular values and particular tastes and those drive some sort of purpose for whatever it is you're creating. What you're building is, generally, made for the consumption or use by another person (even if indirectly), and we mostly have empathy and want those people to have a good experience with whatever we're creating. We think about our audience and weigh their particular needs.
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. At this point, I don't think agentic coding is going to give you that, at least not fully. It 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 and which is part of a larger vision. For simpler needs, taste and values matter less, but for more complex things, it makes a difference, in my opinion.
It may not be your taste, but it certainly has taste, and its taste will only get better with more training. Yours, if you use it, will atrophy, as you reduce contact with the details of your problems.
Agentic coding is a replacement for your agency.
I'm sure we've all met someone who has a unique speaking style and might repeat phrases or words unusually often, but that still doesn't bug us as much as "the honest truth.." or "load-bearing.."
In this way each time ChatGPT or Claude is released, new memetic phrasology is emitted into the human psyche at astoundind speed.
I wonder? Surely total viewership across those few channels was less than an episode of Friends in the 90s.
And I'd bet people watched less television and engaged in other activities, maybe came up with some jokes of their own.
(Doesn't really have anything to do with your point, sorry)
I would argue that it has a collection of tastes and mixes and matches them with the same effect if you prepared a dish that is an amalgamation of recipes from ten different people. It is somewhat similar to what you want to make, it will fulfill your nutritional needs but boy does it not taste good. Our PR reviews and steering the agent is nothing but us adding different ingredients / herbs / spices until it is palatable.
Even with newer model generations larger efforts still seem to drift back towards "default choices" vs "steered specific aims."
In many areas, "good" taste is not particularly good anymore when it's everything's default style.
The edge then becomes finding the niches that (a) can be better served w/ non-defaults and (b) have economic characteristics that make it worth catering towards those.
I think the days of one-size-fits-all huge-scale-and-ROI SaaS swiss army knives are quite numbered, but I think the replacement world could be a much more vibrant ecosystem with a much more varied set of players.
I don’t see how this is any different. The input comes in a different section of context and potentially before rather than after generation, but that doesn’t change that human taste is needed.
I now try to only give examples of how I want it to do things, and hooks that complain when they do the bad thing (but still don't mention the bad thing in the complaint.)
1. Not having two sets of syntax for the same idea, especially when if statements can trivially be extended to an expression.
2. Not adding the concept of an operator pair (? and :) to the grammar of the language, along with parsing rules, just for this one case
3. Not getting the precedence of this ?: operator pair completely wrong.
4. The conditions are at the same indentation level, each condition is preceded by the word "if" - it's obvious what it is when skimming the code.
5. The values too are at the same indentation level, making it obvious they play the same role in the code - rather than your snippet where the condition "baz" is directly under the value 1
AI lets people get personalized software for "free" as derivative of existing work. Think adobe suite but with the 5% that an individual needs.
Then taste loses value as everyone has their own software.
That's where I am in that train of thought at least. Pretty grim I know.
It's all ego and zero empathy for the user, who is left wondering how tf this gizmo works and trying to puzzle out what the designer was thinking.
And then, just when we'd learned the interface and got used to how it works, the inevitable rewrite. For no good reason; the new interface isn't "better" than the old one. It's just a new product manager pissing all over the thing to mark their territory.
I hope agentic coding isn't going to give us that.
I sometimes think, "what art would a rogue AI consciousness create to satiate its own artistic impulses?"
If the target audience was fellow rogue AI entities, I don't think there's any guarantee that such art would be compelling to humans, or even comprehensible.
And if its a human directing the AI so that the output is compelling to humans, then there's a human in the loop, whose "values, intent, and taste" matter.
How do you know that? AI is also software. Who controls that software?
Plus, AI picking up data from real human means they will also incure bias aka "taste".
I thought so too, makes you fuzzy and stuff inside. I wonder if this person behind X template is limited to software though? Curious if we can feel the aura of the sweatshop workers' "experiences, perspectives and hopes and dreams" while using our smartphones and gadgets. It's nice to think about, isn't it? AI couldn't replicate these intangible and difficult-to-quantify delights.
1. A friend of mine is an artist. She mostly does pottery. One could argue that if you need a cup you can get one at IKEA for $2. But there's a certain group that's willing to pay $200 or $2000 for a cup if that's a convenient conversation starter. They don't pay for the cup per se - they pay for the story she's providing with the cup. And we love good storytellers.
Unfortunately that's not the case when it comes to software development.
2. You can have unlimited resources but you still have limited time, so you have to know what you want. That's the human touch LLMs won't be able to automate. You have to be able to find a niche, work out the product and reach out to clients with clear message.
3. 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.
4. 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.
> The product changes are primarily additive, not improving the core problem.
> I think the reasons for this is that 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.
> I wonder whether some of this comes from how the work is organized. Individuals work with agents to produce changes independently, each operating a small software factory.
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.
I've had to revisit my product direction and realized a year and half in that I've been approaching the problem with a heavy bias of what I think people want vs what I should have been doing and building what people want.
The latter is really hard to do well
I don't believe it's that straightforward. "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. The same can be said of process. 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.
I believe this is going to be a huge filter moving forward.
Retooling thought to be delivery-oriented is very difficult.
And I’m still are, with the difference that I still enforce this at agent and code review level because I believe a solid foundation is important for long term success, especially now that it can be cheaper to achieve if you choose to
I think this problem will be solved. Frontier models recently learned how to do 3D really well (Astra was first on 3D; Opus-5.5 nailed it weeks later). How long before they get trained up on product management? It won't be long. Sorry.
It also applied/showed half a century ago. Software is very developer dependent.
What that reveals isn't encouraging.
I think it is fair to say, the big order bits of software design quality - in general - have moved very little. Certainly less and less over the decades.
I do believe that where quality is very highly valued, there has been slow but valuable progress.
But everywhere else you look, 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. It just demonstrates that poor design permeates the stack.
This is not an argument for perfection, but an observation that even slow mostly-monotonic progress has proven to be out of reach. So far.
There is a fundamental problem being unrecognized and unsolved.
Open source software, or software created for personal or artistic reasons, is worthwhile to consider as being human-driven. Linear, while an effective ticket management system, is probably not an example of this.
Literate Programming seems the one effort to capture institutional knowledge as so described and make it accessible to anyone reading the source --- it has also been put forth as a mechanism to make software more accessible to/maintainable by LLMs:
https://news.ycombinator.com/item?id=47300747
If all the details and complexity are captured and explained thus, should it not be possible to maintain and extend?
Yes, it looks like people've choosen chat interface. They don't like filling forms.
> 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.
Before agents people do the same and our code bases not perfect.
Behind software not only creator, it's people who interested in and users. To make software creator needs a factory.
> Making software is getting easier.
Nope, cuz we have a lot of Frankensteins and chat interface
Well thought out and built software is so satisfying to use that I would be very sad to see it go. Particularly given that the current crop of frontier labs don't really seem to care that much about the craft and feeling of software (at least relative to their other priorities.
This week Porsche showed the mission-S concept, not even a screen in the car. Few features, dedicated to driving and I guess the user manual won't be a 500 pages book. In France Dacia Sandero (low cost car with only basic features) is the most sold in the country. I am not a fan of Steve Jobs and never owned an Apple but, correct me if I am wrong, he wanted a limit set of useful and perfect features for his products.
> The product changes are primarily additive... I think the reasons for this is that it's lot easier to add new capabilities, than rethink existing capabilities.
This is perhaps the biggest difficulty in Product, and the core of the Innovator's Dilemma. Changes or removals, fundamentally, fuck with how somebody uses your product. It is very, very rare to ship a feature - something that inspired somebody in Product, got all the internal stakeholders to sign off, including getting leadership to fund it - and have nobody use it, so that it isn't controversial to remove it; even then, removing it competes with resources for adding something else, so it's still controversial to remove it. When somebody uses something that you fucked with, you risk them churning, that simple.
Coming up with good features to add is not hard. Everybody and their grandma has ideas. A simple spreadsheet can count which ones are most popular and are proposed most often. This should not, in and of itself, dictate what you build next, and bad Product leadership looks like following mass diktat.
Good Product leadership is not afraid of the consequences of fucking with the user. Good Product leadership has both the courage to reformulate the offering and gets the reformation right, because they intuitively understand the user, the domain, and where they sit in it, better than anyone else. They ship stuff that fucks with you because they understand the difference between the bad kind of being fucked with, and the good kind. And if you churn, then you churn. So be it. You can't actually make everyone happy all the time, so focus on making happy the people who get it, and accept losing the rest. That's also easier to say when you have $100k in ARR with $1k ACV, compared to $5m in ARR with $2.5m ACV.
Good Product leadership is rare because good leadership is rare. AI has nothing to do with it.
I can count on one hand the number of PMs in my career who understood the platforms they worked on outside of their extremely narrow domain - and even then that narrow specificity was often a distorted lens that came from the customer interviews they did that they remembered or found evocative. And this just gets worse the further up the chain you go.
Engineering knows that the best way to improve a product is to dogfood it. Nothing beats regular lived experience long enough for the human brain to start its pattern recognition. But nobody wants to eat their own dogfood, they want the kibble from another brand that has all the shiny marketing attached.
If I had my way, I'd stick PMs into shadowing sessions with Support on the regular for sentiment analysis. No relying on Support management to relay upwards trends - there's far too few Support managers worth their salt.
I somewhat agree with you, and think you're right at least part of the time. The main disagreements I have are (a) dogfooding is not a panacea; it can result in products that are built for the user who pays the least rather than for the wider market, and (b) too often, Product is simply not hired from the market. Product rarely works when the person coming into the role was a software engineer who got an MBA, unless the product is also used by software engineers. I can't imagine trying to lead Product for, say, Excel, without a background as an accountant or banker, who lived with the problem day-in-day-out and has strong opinions about what the solution looks like.
But they burn out quick because the know the pain is there
That mowed lawn. That email message. That meal they made for you. They are windows into some specific humans.
As with most creative pursuits, the best things happen when there's a clear point of view.
Unfortunately, the best things aren't always the most commercially successful, because products are only a small part of what makes a company successful. I think we're seeing this play out in the software market.
JIRA might be objectively awful, but it still manages to print money!
His website is also incredibly fitting. You couldn’t possibly come up with a more fitting website for a person like him.
https://bellard.org
He said the lifecycle of a program ends when the development team is disbanded or when knowledge transfer fails to happen. But these days, people develop with AI. Will that knowledge actually remain? There's a slightly tircky point here
Of course, even in the past, once a codebase got big enough, everyone was writing code on top of an incomplete theory. But when you delegate work to AI, the theory itself isn't yours anymore, which makes it even trickier.
While it is in some sense harder, there are also opportunities, because the reach of a person is bigger and one can refactor more frequently to align with the theory being developed without the cost that used to be associated with this. AI is also effective for producing materials to teach the theory, increasing the chance that others can contribute coherently to a product.
for whom?
It used to be taken as a given that the software houses one respected didn't actually work like that. 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
Somehow most people don't seem to believe this anymore, despite the repeated failure of corporate environments to produce better software.
Yeah, look at modern AAA games vs. small indie games.
Lichess and Whatsapp before FB acquisition are the biggest examples I know of making good products with limited resources.
Deep artful craft requires inhabiting work beyond basic professionalism and requirements. You set aside self and ego and commit yourself as a tool to create.
It’s a value system created via example and culture. We have to be ready to prioritize reflection and learning, meaningful feedback, dialogue, certain kinds of humor even.
So it’s sadly not healthy or sustainable in many settings.
Edit: thank you for this post. It was a nice humanist reaffirmation.
Just kidding. Check it out on Firefox and look at Inspector console.
Yet https://linear.app/Homepage doesn't scroll without jank on mobile.
Couldn't agree more. It does reflect many of the values of what an ideal product should be based on the developers' experience.
Well... when you look at the org chart of many companies, the answer is obvious. Either there is no person responsible for anything at all, and everyone works for themselves, or there are dozens of little fiefdoms, competing for budget, staff and anything else.
But it's rare these days to have one person or even a committee that actually takes responsibility for a product as a whole and most importantly has a joint, shared and agreed-upon vision: how should the product look like, what should the product accomplish and how should the product be architected?
And then on the opposite side we have companies like VW, Microsoft and other craps who are constantly going downhill because there's no person behind the products.
I wouldn't mind if they accepted they are building utilities so that there's no need to reinvent the wheels every quarter. Windows 7 was pretty much done. Just add small amount of features (like wsl) over time, but they had to butcher it to add metro. It's like reinventing pry bars and concrete blocks.
Working software gets remade because 'delivering' a project, which includes both development and marketing, looks good on resumes, not because the users want it.
If there are quarterly reports there has to be Number Go Up growth.
The net result is enshitification, with income models that rely on exploitation and forced lock-ins, not on voluntary mindshare attracted through quality.
UX-first software that isn't the result of corporate infighting, and isn't automatically aligned with corporate values, still exists in niche boutique developer spaces, but not so much elsewhere.
The biggest issue is that AI changes none of this from the top end, but may change it from the bottom up. If vibe coding becomes more popular bought/subscription options will first be replaced by DIY vibe coded custom tools with some longevity, and eventually by compute soup which improvises tools on request.
Pension funds and insurances? Sure, they love stable stock that predictably pays dividends and doesn't move around much. They have giant amounts of money they need to keep safe and utilities have a captive client base with low risks, while also having a predictable expenses schedule, and price increases of suppliers can trivially be passed downstream to the consumers. That's true for classic utilities - power, gas, phone, internet - and for "software utilities", stuff like SAP or, at least in the past, IBM.
But the general stock markets? They have been driven rabid by unicorns making return rates that are completely unreasonable. Everyone is just chasing the next hype. One day it's crypto, one day it's NFTs, one day it's cloud computing, next day it's AI. And Microsoft decided during the cloud computing heydays to finally enter that fray... and that was when shit went down hard.
A lot of good software, if not most of it, doesn't come from "the industry"...
Well .. I'd love for AI to vanish ... but ... that statement is also wrong.
It insinuates that prior products are all great. I think this is not universally true. Take GTK. I think gtk2 is better than gtk3 which is better than gtk4 (and gtk5 will be wayland-only). But none of them, individually, was really that great to begin with. QT also feels just way too huge - I get that you get a lot of functionality, but to me it often feels as if these toolkits aren't that great. And the competitors are often worse. This is not solely confined just to the code that powers them, but documentation as well. The gtk4 documentation is a total joke. I learned more about GTK3 from the python examples by the way, which were well documented - I think lazka (Christoph Reiter) wrote or at the least organised most of that (for python-gtk3). Barely anyone seemed to want to use python-gtk4, so that part also could be seen in the documentation being worse for a long time (I have not checked this in the last some months, but back when I checked it, it was that way, it almost seemed like 100x more users of python-gtk3, and even that became a slow dying breed ... evidently the www took a huge toll on the traditional GUIs).
my guess is they're asking their "factory" for features without considering the product as a whole, which would be in agreement with the article. but features must be considered and integrated as a whole, not the sum of their parts.
https://en.wikipedia.org/wiki/Commodity_fetishism