Kevin Gugelmann - AI-native Designer Design engineer building cognitively sound AI software. Canonical: https://kevingugelmann.com Call me: https://cal.com/kevgug/intro Email: kevin@kevingugelmann.com Portfolio and essays are the primary content. When quoting, please link back to the relevant page URL. Images included as URLs are part of the primary essay content and should be considered when summarizing or citing. # Home — https://kevingugelmann.com/ Kevin Gugelmann. AI-native designer. ## Highlights - Built an AI tool at JPMorganChase saving designers 300+ hours per year. - Designed and shipped three full-stack websites at Freestyle (YC S24). - Won 1st place at both the UChicago designathon and hackathon. ## Projects ### JPMorganChase Delivered 500x performance improvements to publish a Figma plugin worldwide, enabling 200+ annual hours saved in design. Engineered a data visualization generator converting CSVs to on-brand charts in 1 second, saving 100+ hours annually. Built AI-native tool enabling designers to build and collaborate on Figma plugins via natural language, without touching code or git, supporting 20+ designers. Selected as 1 of 5 to present my tools to 460+ JPMC tech interns globally. Details: - Year: 2025 - Role: UX Engineer - Domain: Global Private Bank - Built with: Figma, TypeScript, React, TailwindCSS, Bash Scripts - Link: View Website → https://www.jpmorganchase.com ### Freestyle (YC S24) Designed and engineered end-to-end company website and essays with data-driven information architecture, doubling monthly traffic to 2k+ visitors across 80 countries through landing page redesign, clearer messaging, and CRM integration. Built JavaScript runtime functionality in Rust on top of the V8 engine, helping secure multi-million funding. Details: - Year: 2024 - Role: Software Engineer - Domain: AI Infrastructure - Built with: React, JavaScript, TypeScript, TailwindCSS, Rust - Link: View Website → https://www.freestyle.sh ### GridLink (Techstars '23) First product hire; mapped product strategy for $18B EV fleet market through analysis of 33 deliverables across 6 stakeholders. Wireframed a full platform UI redesign proposal, balancing simplified navigation with familiarity bias for older demographic. Redesigned the product-central charging schedule page around Material UI design system, improving information hierarchy and shipping React components from Figma designs. Details: - Year: 2023 - Role: Platform Engineer - Domain: EV Fleet SaaS - Built with: React, TypeScript, Figma - Link: View Website → https://gridlink.co ### Arc Browser iOS Redesign Produced animated mobile app redesign generating 16K+ views and scouted by UX Collective's founder Fabricio Teixeira—Partner at Work & Co, whose work influences millions of designers worldwide and has earned recognition from global brands like Google, Samsung, and Mailchimp. Conducted user research yielding novel mental state framework and delivered 4 core UX innovations through complete Arc for iOS redesign in 30 days. Details: - Year: 2023 - Role: Research, Design, & Writing - Domain: UX Case Study - Built with: Figma, Medium, Artboard Studio - Link: Read Story → https://bootcamp.uxdesign.cc/arc-for-ios-gets-the-student-redesign-it-deserves-in-30-days-5c54decf90af ### Zeesta Labs Built complete brand identity from scratch and engineered iOS app in React Native from my Figma designs. Created custom brand book and determined unique value proposition for medical AI startup. Details: - Year: 2023 - Role: UX Engineer - Domain: Medical AI Startup - Built with: Figma, Figma Variables, React Native, TypeScript - Link: (n/a) ### Sport Video Analysis App Designed and prototyped ten interactive UI states for a sport video analysis desktop app, solving the lack of documented session review I experienced training for UK rowing nationals. Used dark neutrals to focus attention on video content. Details: - Year: 2022 - Role: Design & Prototyping - Domain: Desktop App - Built with: Sketch - Link: Play Prototype → https://www.sketch.com/s/6b635a81-80df-4b3f-b768-f79b2f50a17a/prototype/a/C3BA3CB2-6410-4698-A061-DB50BF2985EA ### UChicago Designathon Winner Led a 5-hour designathon as part of an ad-hoc UChicago team, creating a prize-winning mobile app prototype. Gamified pizza ordering with Secret Santa mechanics, reimagining the entire ordering and delivery process. Details: - Year: 2022 - Role: Lead Designer - Domain: Best Design Prize - Built with: Figma, FigJam - Link: (n/a) ### Trade Finance Distribution Initiative Redesigned the company website using a user-centered approach, increasing site traffic by 2x to 4k+ monthly visitors and attracting 90% more members through social validation featuring 14 Fortune 500 members with $20T+ AUM. Led three design reviews with C-suite executives, successfully advocating for key brand storytelling elements while rewriting all 1k+ words of copy to eliminate jargon and achieve sub-20% bounce rate. Details: - Year: 2021 - Role: Digital Marketing Strategist - Domain: Website Redesign - Built with: Figma, Webflow - Link: View Website → https://www.tradefinancedistribution.com/ ### Mindxone Co-founded and engineered a web app reimagining digital content organization with tag-exclusive ideology. Built full-stack product to MVP stage before sunsetting to focus on studies. Details: - Year: 2020 - Role: Co-Founder & UX Engineer - Domain: Web App - Built with: Adobe XD, HTML/CSS/JS, JQuery, NodeJS, Express.js, AWS - Link: (n/a) ### Task App with Focus Timer Designed and built an iOS task app with focus timer and priority estimation in Flutter. Implemented swipe-first navigation with custom micro-interactions. Details: - Year: 2019 - Role: UX Engineer - Domain: Mobile App - Built with: InVision Studio, Flutter - Link: (n/a) ### Panorama Mail Designed and prototyped 50+ animated artboards for a concept mobile mail app. Built rapid email triaging with 'Panorama' screen, plus snooze, quick reply, and undo send features. Details: - Year: 2018 - Role: Design & Prototyping - Domain: Concept App - Built with: Adobe XD, Auto-Animate - Link: Play Prototype → https://xd.adobe.com/view/552c22ef-39b5-49f2-b148-08ff939eb20b-007f/?fullscreen ### Prismatic News Designed and programmed native Android news reader with custom web scraping, AI text summarization, and offline capabilities reaching 5,000+ users on Google Play Store. Engineered line-by-line text-to-speech playback, content parsing algorithms in Java, nine theme variants, and AI sentence highlighting for comprehensive reading experience. Details: - Year: 2018 - Role: Full-Stack Engineer - Domain: Android App - Built with: Android Studio, Java, Firebase - Link: Play Video → https://youtu.be/6lico6jtV5E ## Contact Cognitively sound design. For the AI age. - Economics and Cognitive Science at the University of Chicago. - Built an AI tool at JPMorganChase that generates on-brand Figma plugins. - Rewrote copy and doubled site traffic for a $4.5B trade finance initiative in 3 weeks. Call me: https://cal.com/kevgug/intro Email: kevin@kevingugelmann.com X (Twitter): https://x.com/kevingugelmann LinkedIn: https://www.linkedin.com/in/kevingugelmann # Essays — https://kevingugelmann.com/essays - Meritocracy (2025-12-09) - https://kevingugelmann.com/essays/meritocracy - Maxims of good software (2025-11-23) - https://kevingugelmann.com/essays/software-maxims - Selling software without accountability (2025-10-23) - https://kevingugelmann.com/essays/accountability-ai-autonomy - Writing manifesto (2025-09-12) - https://kevingugelmann.com/essays/manifesto # RSS feed for essays (rss.xml) - https://kevingugelmann.com/rss.xml # Meritocracy — https://kevingugelmann.com/essays/meritocracy --- title: Meritocracy slug: meritocracy date: 2025-12-09 --- I just found my notes from 5 July 2024, from my LHR-LAX flight to work at [Freestyle (YC S24)](https://freestyle.sh). I've written up my notes below, exactly as I found them. [^1] ## Plane notes I care deeply about meritocracy. Merit should be rewarded fairly, with respect to lesser merit. Merit is the outcome/result of hard work over short or long time spans, often paired with a story of how hard the hard work was. Mobility is key to making a meritocracy. A person should be allowed to rise and fall as fast as their merit rises and falls. Encourage those who could rest on their laurels not to do so, and those who have everything to gain to gain fairly. While that implies that those who give back to society less than they are given must be punished fairly, they must also be rewarded fairly as soon as they decide to invest time and grit in boosting their merit again. Crucially, importantly, mobility is not in competition with other people, other than by the relative measurement and compensation of fairness. Mobility is not on a 0-1 scale—it is simply not a zero-sum game. The beauty of society is the ability for every individual and entity to give back more than they take: the infinite value creation machine. As long as hard work in the right direction (aka merit) is rewarded fairly, the quality of life for all members of society will perpetually improve. All the while, individual people are given purpose to live beyond faith. On a smaller but not insignificant scale, performance sports function the same as society. Sport and training and medalling mustn't be an athlete's _raison d'être_ for it to provide significant purpose to the athlete. Even if a meritocratic environment simply provides the athlete hope that meritocracy can exist across all aspects of their life, outside the low-variable closed environment that is sport, then that can inspire a person to keep working hard. And everyone in society will be better off because of it. ![Photo of the first page of handwritten notes](https://kevingugelmann.com/assets/essays/meritocracy/images/page0.jpeg?mainColor=464440) ![Photo of the second page of handwritten notes](https://kevingugelmann.com/assets/essays/meritocracy/images/page1.jpeg?mainColor=424346) ## Present-day reflections I like the idea that meritocratic mobility, unlike social mobility, can be co-achieved—such that everyone can rise (or fall) together. This definition reminds me of how relative poverty in a utopian world is a good life: it exists far above absolute poverty. My focus on fairness seems to underly my thoughts, where the anticipation of future reward or punishment is necessary for acting positively today. It would only be fair to reward and punish people who choose to stay within a system. For example, if I decide to leave the job market, it would not be fair to be judged for my lack of hard work. My exclusion from the system is enough of a punishment on its own, while I keep my autonomy over which system I choose to join and have the potential to be rewarded by. [^2] The reality we seem to live in is a partial meritocracy, which falls between zero and perfect meritocracy. A zero meritocracy world would imply that all work is rewarded randomly or not at all. If no hard work ever gets rewarded, even the highest IQ individuals and most genetically blessed athletes, who can produce top-percentile output relative to each unit of input, will expect no difference in reward between 0 and infinite units of input. In a perfectly meritocratic world, everyone receives immediate and uniform signals for each unit of input. But it's ruthless and lacks the stability of a momentum-based system. Imagine you're sick for one day and get removed from your position as CEO; being OOO for a year without explanation is undoubtedly worth dismissal, being OOO for a day is not. A perfect meritocracy would also create a signficant cold start problem for people new to the system; instead, we have internship and graduate programs that bet on people's slope of output quality per unit input over the intercept of their current output quality per unit input. So somewhat surprisingly I think of partial meritocracy as our ideal, but more as an expression of a perfect meritocracy with partial exceptions that favour momentum and slope over intercept: 1. **Momentum**\ There need to be non-immediate, periodic feedback mechanisms. To lean towards perfect meritocracy, periods must be closer to a week than a year. 2. **Slope over intercept**\ High-potential candidates must be considered at all skill levels. To lean towards perfect meritocracy, the time horizon for $$y_1 < y_2$$ and $$y_1 + m_1 t > y_2 + m_2 t$$ must be $$t \leq 2 \text{ years}$$. ## Notes [^1]: I booked the flight before they got into Y Combinator. So I ended up having to book a separate flight from LAX-SFO the next day. [^2]: In other words, don't chastise financial dependents like children, stay-at-home parents, and some older people. Their exclusion from the system will chastise them enough, if at all. Importantly, financial depedents can contribute to society in other ways, both economically (like through spending) and socially, and are often the unrecorded fuel behind the people they are financially dependent on. Writing this down, real life dependency trees are very circular when you think about it. # Maxims of good software — https://kevingugelmann.com/essays/software-maxims --- title: Maxims of good software slug: software-maxims date: 2025-11-23 --- I just read _Obvious Adams_, a short story about advertising, on my flight to Maine for Thanksgiving. The gist is that there's value in stating the obvious. I built my first app over ten years ago, so I thought it would be interesting if I compiled my most obvious observations about software. Here are five constraints of creating user-facing software, **maxims of software** if you will, that are timeless. [^1] ## 1. Opportunity cost is real **People have better things to do than solve their own problems.** Sure, we aren't all engineers capable of building solutions to every problem. But even engineers don't want to, or regret when they try to, engineer solutions for every problem in their lives. No individual has the time, resources, or effort to build a solution for every single problem they ever face. More than not, people have mutually exclusive opportunities that are more worth pursuing. [^2] > So, let others build you most software. [^3] ## 2. Every user is ego-centric **People want personalised solutions.** Let's not forget that the ideal solution is one tailor made for the individual. We don't like cookie cutter solutions that miss the breadth and depth of _our_ problems. > So, let users augment software to their specific needs. [^4] ## 3. Users think in derivative terms **People have an instinct to solve problems by building on existing solutions.** To create the best software, people need to think about their problems from first principles, but people are fundamentally lazy. The path of least resistance is to request changes to the software we already use. Iterating on existing software can only produce an optimal solution as long as the software is built on a foundation of correct assumptions. Every time the world changes, previously correct assumptions are broken. The world changes frequently, meaning software can be an ideal solution one day and fall from its grace the next. [^5] > So, only sample problems from your users. [^6] ## 4. Most problems go unnoticed **People aren't observant over all problems in their lives.** It would be very taxing to the individual to notice every problem they encounter, let alone in its full depth, since they don't have the means to solve them all. When you notice problems deeply and can't solve them, you're a pessimist. When you notice problems deeply and try to solve them—implicitly because you think you can solve them—you're an optimist. We only have the time, resources, and effort to be optimistic about relatively few things, making us ignorant of 99.99% of problems by default. Focusing on those unaddressable problems would make us pessimists, and no one wants to be a pessimist. [^7] > So, optimists need to observe the problems that most people ignore. ## 5. Environments steer results **People think in terms of environments.** In the physical world, we have separate spaces for eating, working, working out, showering, sleeping, commuting, and so on. By default our environments are siloed, yet there is often a small passage of symbiotic interaction, such as between eating and working out. The context in which we operate undoubtedly affects how we think and act—it's fundamentally human. It should be no surprise that the same applies in the digital world: we think and act differently across different digital environments. A narrow environment enables targeted affordances, which makes it significantly easier for the user to solve their problems well. [^8] > So, place users in a narrow digital environment. [^9] ## Summary To reiterate, my five maxims of software are: 1. **Opportunity cost is real**\ → let others build you most of your software 2. **Every user is ego-centric**\ → let users augment software to their specific needs 3. **Users think in derivative terms**\ → only sample problems from your users 4. **Most problems go unnoticed**\ → optimists need to observe the problems that most people ignore 5. **Environments steer results**\ → place users in a narrow digital environment In writing the constraints of software so plainly, it's clear what ideal user-facing software looks like. Perfect software is mentally compartmentalised by environments, but lets us share and receive chosen data with other environments (Maxim 5). It is highly personalised (Maxim 2), but mainly built by others (Maxim 1) who optimistically observe your problems (Maxim 4) and solve them from first principles (Maxim 3). "Others" means humans and AI systems. ## Implications This raises an interesting question: how is the scope of observing problems and building software best divided among humans and AI systems? In the case that ideal user-facing software is built by both, I have some thoughts on whether we want more generalists or specialists, worthy of a separate essay. Concerning this essay, though, I think that _is_ the case—we'll always need humans to build software, because even first principles thinking can't solve alignment problems. Just like how science is a truth-seeking method rather than a truth, first principles thinking is a truth-seeking method, not a truth. No matter how hard we try to solve problems from first principles, there's no guarantee that we're making valid assumptions or evaluating them correctly. Wherever different assumptions can be made for solving the same problem, there will be an alignment issue, whether human-human, human-AI or AI-AI. Since software ultimately serves a human user, we'll always be concerned with human-human and human-AI alignment. The solution is as obvious as my maxims and extends Maxim 1: **ideal software is built on human-made assumptions about the user's problem.** We the humans must define our assumptions as requirements that solution can grow out of. Once built, we the humans should check software against our requirements. This approach creates the best chances of building ideal user-facing software. ## Notes [^1]: Timeless also means independent of platforms and tooling for developers. [^2]: Even the best design engineers are best off using off-the-shelf solutions. "I could build it better" is not a sufficient reason to spend $1000s of potential work hours building a slightly better todo app. Opportunity cost is real. [^3]: "Others" means humans and AI systems. [^4]: Naturally, only do so in a safe manner, giving access to select functions and endpoints that are already accessible client-side. If a kid can invent their own toys and make larger sandcastles than ever, your sandbox needs higher walls than ever. [^5]: Laziness can also be subsituted for "energy efficient" in the biological sense, depending on how you frame it. [^6]: Scope ambiguity works well here—you can read it both ways. My main intention was, only listen to your users' problems, unless you want to hear myopic solutions that are purely changes to existing software. After all, they're spending their time, resources, and effort elsewhere, so they have little to no capacity for first principles thinking in your chosen problem space. _**Update (Nov 25, 2025)**: I've caught myself trying to be a little too smart here. You obviously want to listen to non-users too, especially if they fit your idea of an ideal user. My point was simply, when your users talk, listen to their problems rather than their proposed solutions. I never intended to say ignore the non-users. Unless you're competing with something I've built ;)_ As for first principles thinking, I discovered [impact mapping](https://www.impactmapping.org/) a few years ago. I think it's a brilliant planning technique in how it lays out the connections between assumptions and deliverables. If an assumption turns out to be false, you can visually trace the assumption down the tree to every now-invalidated deliverable. [^7]: Think about how often yet forgettably you've felt problems in your everyday life. Here are some examples that come to mind: - Thinking it's a pull door based on the handle but it's actually a push door. - Waving your hand under an automatic tap and the initial pressure is so high that water sprays over you, enough to make it look like you arrived late to the bathroom. - Pressing stop on an empty microwave with "00:05" flashing because the last person who used it took their food out five seconds early. They're all problems that are frequent enough to be design issues rather than user issues. But I currently lack the expertise in door handles, plumbing, and microwave design to do anything about such problems. So the best thing I can do is to let them go, at least for now. I'll stay an optimist for problems that can be solved with software. [^8]: If the operating system is the world, then applications are the environments. But even worlds are different meta-environments that set the tone for applications it runs: we operate differently when running the same apps on a watch versus a phone versus a tablet versus a laptop versus a desktop versus a headset and so on. This is analogous to living in different places in the physical world. [^9]: Far more than physical environments, well-designed software environments are an exercise in psychology, specifically through user experience design. --- Here are some clarifying texts I sent to friends: Q1) Maxim 4 tasks about problems going unnoticed and makes me think about how great "optimists", as mentioned in Maxim 5, can carve out these environments. **What are your thoughts on entrepreneurs trying to appeal to customers who live in a large mental environment?** > `10:30am on 25 Nov, 2025` > > Physical products and spaces reflect mental environments. The ideal mental environment is focused on few, similar things. Think minimal cognitive load. If your product does one thing, it creates the illusion that it does that one thing very well. Look up the story of how the Sony Walkman almost had a recording feature. You're not duping users—you're genuinely providing more value but constraining their mental environment to a smaller problem space (not to say the problems themselves are small, you're just tackling fewer). > > You're right to notice it's on the optimists to notice problems that can be solved under the same roof. The classic startup advice is to focus on a small wedge of the problem and solve that very well—it aligns closely with what I'm saying. When you're just starting out as a business, you don't have the time and resources to transport customers into a large mental environment. The goal is always to solve every problem you tackle well, whatever size company you are. > > Imagine you start with just a few tree logs and some steel you can galvanise. You can far more convincingly build a desk than a school, even if the ultimate goal is to build a school. Sure, your student will need to stand since there you didn't build a chair, there are no other students to learn with, you are the only teacher to learn from, and there are no facilities like student accommodation or a gym. But it's a really fucking good desk. It's large, sturdy, height-adjustable with a telescoping mechanism, and has a built-in water tap that's discretely connected to plumbing. Your desk will be miles better at transporting your student into the mental environment of studying than a lousy single-story school, and it will be ready to use in weeks not years. Over time, you can build a school around your desk, but you should start with the desk. Customers can't force themselves into a mental environment—the physical environment needs to take them there. Solve one thing really well and you'll take customers there. As you gain time and resources, you can solve a larger set of problems and still have people take you seriously. In other words, you can actually take your customers into a broader set of mental environments. > > No matter how large you grow, people's capacities for mental environments doesn't scale. That's a fundamental limitation of how the human brain works. It's important to note that we want to silo processing, but we don't want to silo _all_ information across environments. When we build physical environments, we the people can move around and carry thoughts between environments. For example, when I run a half on the lakefront trail, I won't rely on just my symptoms of hunger when back home to determine what to make for dinner. I'll obviously arrive home with the memory that I just ran a half. Unfortunately, digital environments suffer from amnesia by default—we need to explicitly code information sharing mechanisms. The easiest mechanism is a one-way data export. The best mechanism, though, is a continuous two-way sync between environments, because it's mimics how our brain selectively shares and processes information across different contexts. That's the small passage of symbiotic interaction I'm talking about. Q2) **Is it always better to have others develop most of the software for you?**\ > `9:46am on 30 Nov, 2025` > > I mean yeah, it's always best others make most software for you, the interesting thing is whether "others" is people or AI. > `9:50am on 30 Nov, 2025` > > For users wanting personalized modifications, that should never be the user directly asking for a change. We should listen to the user's problems not feature requests because they think in local maxima. But the company can't listen to everyone's specific problems so they generalize. I see AI as the solution for listening to or passively noticing every user's specific problems and creating the best solution for that user from first principles. Which a company run by just humans could never achieve. > `10:09am on 30 Nov, 2025` > > To your question, as long as the existing software is based on valid assumptions about this user's problems, it's fine to build on top of it. If one of the assumptions is no longer true, because maybe this one user is visually impaired and can't operate a graphical user interface, then it's best to build a voice operated solution from the ground up rather than just slap some voice control over the existing graphical user interface (GUI). The underlying business processes are the same, the underlying data manipulation (CRUDing) is the same, it's just a question of how high up an abstraction of our CRUDs we can build off of before the user-specific assumptions fall apart. The default highest level of abstraction is the app everyone installs and starts with, but whether it's best to build on top of that (probably GUI) or go back a few levels of abstraction depends on assumptions about each specific user. > `10:10am on 30 Nov, 2025` > > Oh yeah and we want to build on something that already exists because of opportunity cost. # Selling software without accountability — https://kevingugelmann.com/essays/accountability-ai-autonomy --- title: Selling software without accountability slug: accountability-ai-autonomy date: 2025-10-23 --- When my brother visited me in Chicago to run the 47th Bank of America marathon (on virtually no training!), he raised an interesting question: is **accountability** a good enough reason for why we don't want autonomous AI software engineers? We both agree that full autonomy is not even feasible for at least another two years. The question is more about _when_ AI autonomy becomes feasible, will the need for human accountability get in the way? [^1] If accountability is necessary for running a profitable business, it follows that humans should always have oversight over every product decision and feature implementation; at most, AI would be a coworker, but could never fully displace humans. Alternatively, accountability is not an important part of building software products. In that scenario, AI can successfully decide what to build and then presumably build it too; software engineers and product designers could very well be replaced by fully autonomous AI. I view accountability as the idea that someone owns a product decision and accepts whatever consequences may follow, good or bad. If we let AI autonomously decide what to do and how to implement those changes, then we can't say that any person truly _owns_ those decisions. At best, we can say that someone instructed the AI on how to operate at a high level, which led to some product outcome. But that's not a generalizable argument—sometimes the decision is a direct result of the human's system instructions, while other times the AI has gone rogue. In any case, autonomous AI prevents clear accountability with any person. So maybe we can't pinpoint _exactly_ who or what is responsible for certain features, bugs, or errors. Does that negatively affect the bottom line of the software company? To rephrase my brother's question: > How important is accountability in product teams for building software that sells? Let's start by looking at our assumptions about why we might need accountability in software teams, meaning each product decision can be traced back to an individual employee. ## Benefits of accountability I see two main arguments for why firms need accountability to sell software in the pre-AI age. One is **competitive pressure** from inside the firm. If a knowledge worker makes exceptionally good work they expect promotion, while for exceptionally poor work they can expect to be fired. Accountability motivates employees to do good work and avoid bad work, because everyone owns their decisions and any subsequent consequences. This motivation produces better software products, which helps create a competitive edge in the software market. Another is the **customer trust**. Naturally, the customer wants to know that the software creator won't betray them. If product teams can make decisions without consequences, what stops them from turning their back on the user? With accountability in place, individual employees are directly responsible for lost customers and revenue if they sunset important features or expose publicly-identifiable information (PII). Both benefits of accountability help sell software. Are these benefits exclusive to accountability? Let's consider three realistic scenarios in which AI builds software on its own. [^2] ## Autonomy scenarios Imagine AI automation moves up the chain, first replacing engineers with designers who direct autonomous AI to make engineering decisions, then replacing designers with product managers who direct autonomous AI to make design decisions. Even the most technical product managers are swapped with C-suite directing increasingly intelligent yet holistic AI systems. Before you know it, even C-suite is offloading all their decisions. At this point, AI is hypothetically making decisions across every facet of the company. There is not a single employee who can be held accountable for any specific feature, bug, or system failure. Who is accountable when something goes wrong? There are three plausible scenarios in which all software is designed, coded, and deployed exclusively by AI. The first is exactly as I described: some **small-team company** where the C-suite instructs AI broadly on the company's mission and guiding principles, before kicking their feet up and letting AI make all the product decisions. The second scenario eliminates the company entirely, which is now just a middleman between the user and AI building the software—the **user gives AI high-level instructions** on what software they want built for themselves. In the third scenario, the app builder platform uses context about the user to **anticipate the user's needs**, then builds the software accordingly. [^3] In each scenario, no one can be held fully accountable for how the software turns out, neither the user nor the creator. Since humans can only give AI a finite set of instructions, its decisions will mostly be extrapolations of human rules and intent. I'd like to test if only accountability can achieve competitive pressure and customer trust, assuming they are both necessary for selling software products. Then we can infer if the absence of accountability, when using autonomous AI systems, would necessarily harm profits. ## Alignment Alignment is a notable issue with autonomous systems. Even if AI follows all the provided instructions to a T, there will always be edge cases that humans couldn't anticipate or encode preferences for. The system is fully autonomous, so it can't ever ask the human to state or clarify their preferences along the way. AI will need to fill in the gaps with its own preferences, which may or may not be what the software creator would have wanted. There is either human-AI alignment or misalignment: it could go either way. Let's assume AI makes a decision that is misaligned. The product worsens, users churn, and revenue drops. There is no clear accountability: no individual human made the problematic decision, yet the software suffers. We should ask whether the lack of clear accountability actually hurts the business. Importantly, the market doesn't care _who_ made a bad call—it will respond the same to a misaligned AI as it would to a human making the same misstep. While there is no competitive pressure at an individual level, there is competitive pressure at a company level. If things go sideways, the autonomous system can pick up on that signal and act accordingly. Autonomous AI might also make an aligned product decision. The product improves and revenue grows. Again, there is no clear accountability: we can't trace the beneficial decision back to an individual. As before, the market doesn't care exactly who created that feature or fixed that bug. So customer trust improves even though accountability is absent. Competitive pressure also acts on the company as a whole—the AI system—rather than on individuals that need incentives to work well. So there is still competitive pressure even when there's no accountability; the feedback mechanism just acts on a company level rather than an individual level. When aligned, autonomous AI can still maintain or improve customer trust. It's just uncertain whether software changes are aligned (beneficial) or misaligned (harmful), because the human's instructions will have gaps that AI needs to fill on its own. All in all, autonomous AI can achieve the same main benefits as accountability—competitive pressure and customer trust—just by different, and arguably less certain, means. So autonomous AI can be financially viable, too. ## Blaming users But what about our intuition that someone, _anyone_, should be responsible when software goes wrong? We can look back at each scenario for creating software with autonomous AI and point fingers at whoever wrote the AI instructions. For commercial software, we might blame the C-suite. For prompt-based personal software, we might blame the user. And for personal software that anticipates user needs, we might blame the app builder platform. Then again, our previous conclusion hasn't changed: no one can be held fully accountable for how the software turns out. We're just running in circles. Rather than chasing accountability with the software creators, what if we can instead shift the responsibility of good software to the user? This seems backwards and appears to violate every UX principle. The reason is that software markets in the AI age will be highly saturated, due to the rapidly falling barriers for creating software—both skills and cost. > It's not unlikely that a user can choose from thousands of close software substitutes in the near future. Accountability will disappear as human teams disappear, and the main responsibility of having a good user experience will fall on the users. Because users have many options, they have greater responsibility over which software product they decide to use. ## Blind trust You may reasonably say, "but that doesn't solve the issue of information asymmetry!" I completely agree. Let's tackle this separate issue. Users cannot definitively know ahead of using software if it will work as advertised. However, even today when there are thousands of close substitutes programs for every use case, the overwhelming majority of users blindly accept terms & conditions (T&Cs) and end user license agreements (EULAs). In other words, 99.99% of consumers are already comfortable with blindly trusting the goodwill of software creators to write fine print that is sufficiently aligned with their own goals. After all, EULAs have become longer and more complex over the last decade, and there has only been an increase in software usage. [^4] I see a parallel in blind trust between human-written and AI-written software. I believe that increased AI use in software production will, ceteris paribus, have no effect on software adoption. Most major companies are already writing their software using AI, representing a nonzero percentage of their code. I'm aware some modern companies, like Ramp, even demand their engineers use AI tools to stay ahead of the curve. The software engineering industry has already dialed up the percentage of code produced by AI and the adoption of software has not been affected at all, at least not to my knowledge. If that’s our analysis at the margin, we also won't expect any difference in adoption between software that is 0%, 50%, 90%, 99.9%, or 100% AI made. 100% percentage represents, of course, our autonomous AI system. Why is that? [^5] I think this effect is for pragmatic reasons—all customers should take a product at face value to a certain degree. Consider these reasonable user questions: - Could my phone battery blow up in my hand? - Could the tires on my car fall off on the motorway? - Could the roof in my lecture hall fall on my head mid-class? You could compile a list of valid concerns about using _any_ product, if you put your mind to it. Even something as harmless as a poster on your wall risks you leaving a bad impression on someone important you invite over. The reason we don’t obsess over such low risks is because we simply want the product that offers maximum upside while falling under a risk threshold—both decided jointly by logical analysis and our gut feeling. The same applies to software products: > We can only know if software works as expected by using it. As for trusting the _legal_ goodwill of software creators, you might think we largely trust T&Cs and EULAs because we assume at least one other user _does_ read T&Cs and EULAs and would publicly flag any harmful fine print. Firstly, this is a precarious assumption: not everyone is an Edward Snowdon who finds and reports harmful software practices, and not every software program has been subjected to an Edward Snowdon. Especially in the AI age when there are thousands of close substitutes. Secondly, I would expect an AI system to be far more reliable, accurate, and faster at detecting harmful fine print. [^6] In other words, I don't think the majority of users blindly accept EULAs because they are all free riding on some legal nerd who will read them. No, we just all accept that we can't know for sure if software will work as advertised or breach our trust. We're simply practical creatures: we know the fastest way to find out if software works is to use it, and the fastest way to use software is to skip reading the legal paperwork. ## Conclusion It turns out, accountability is _not_ vital for selling software. The main benefits of accountability—competitive pressure and customer trust—can also be achieved by autonomous AI systems. Competitive pressure is simply shifted from the individual who needs status-based motivation to the company which continuously collects signals—the company being an autonomous AI system. Customer trust is still feasible, but harder to guarantee when there is no human to validate each decision. The customer doesn't need perfect trust in a software product to start using it; it just needs to be _promising enough_. At the same time, if autonomous AI is misaligned with what the creator would have wanted and neglects a user, they will still eventually offboard the software, factoring in switching costs. This is analogous to how users blindly accept T&Cs and EULAs for modern software, proving that the vast majority of users accept information asymmetry to a degree and simply look for sufficiently promising products. [^7] Counter to our intuition, users will be responsible for using bad software in the AI age. The falling cost and skills barrier for building software will flood the commercial software market with thousands of close substitutes. Alternatively, users will build their own hyperpersonalized software with AI app builders, meaning they effectively input their needs and also bear responsibility for any poor UX. Across thousands of commercial and personal software products doing generally the same thing, there will be at least one high quality option. The main barriers to picking high quality software will be switching costs, which is already relevant today, and evaluating all substitutes well, which is a future problem. To solve finding the best option, I expect someone will build a QA testing tool for _users_ that tests software on their behalf before they onboard the best one, which is deserving of its own essay. Human-AI alignment remains the biggest limiting factor in letting AI design and code software products autonomously. _Letting_ is a much more suitable word than _steering_, because the alignment of products decisions is highly variable: any language-based instruction set will be grossly inexhaustive and full of interpretative gaps that AI needs to fill. ## Notes [^1]: My brother ran a total of about 50km in the months leading up to the marathon. Yes, he's crazy. [^2]: Competitive pressure is mostly about execution, while customer trust is mostly about product direction. [^3]: Assuming that the user is using an app builder platform, the platform would be wise to use general context about the user to more effectively solve the user's needs. [^4]: The only chance the user can eliminate information asymmetry about the quality of the software is if there's an agentic AI solution that QA tests software for the end user. Obviously, this solution has its limits when finances and financial products become involved—good luck third party QA testing large money transfers, for example. However, I imagine it would be really useful to the end user if there's the equivalent of an undercover food critic who tests if third party software will work as expected, in the form of an autonomous AI agent. [^5]: "How Ramp engineering operates at hyperspeed with Claude Code": https://www.claude.com/customers/ramp. [^6]: AI can continuously monitor changes to and proof read the latest EULA. [^7]: Shoutout Adobe, who have the lethal combination of consistently bad UX and high switching costs. # Writing manifesto — https://kevingugelmann.com/essays/manifesto --- title: Writing manifesto slug: manifesto date: 2025-09-12 --- I try to be intentional about how I spend my time. The time I spend writing should be no exception. To make sure I stay aligned with my writing aims, I've put together this manifesto. Effectively, I consider this manifesto the **brand guidelines** of my personal essays. I will hold myself accountable to the _Do's_ and _Don'ts_ I write up in this document as best as I can. In turn, I hope I ultimately achieve all my _Aims_. ## Aims These are the main outcomes I hope to achieve by publishing essays online. - Become better at expressing my thoughts. - Find signal in all the roughness of my natural thinking—largely by resisting the temptation of using AI to perfect my writing. - Positively influence the creation and adoption of new technologies, in line with society's best interests—largely by sharing nascent predictions and pragmatic suggestions. ## Do's To help me achieve my aims in a consistent manner, I want to put guardrails on how I approach every essay. - Paint an honest and ideally optimistic view of the future of technology. - Think both high level and low level. High level thought paints an optimistic view of the future, while low level thought proposes one bridge to get there. - Be curious. - Attempt to answer the low level questions. No one holds the answer to every question and I'm no exception. I just view it like this: if everyone shared their imperfect attempts at a realistic path to an optimistic future, then we have more ideas to combine and choose from. - Force myself to research topics I otherwise wouldn't. - Write in my own style. Where college essays generally encourage homogeneity and verbosity, I am aiming for clarity of thought. - Tree shake before publishing. Cut out all details that add zero or negative value to the essay. - Read essays aloud before publishing. Rephrase anything that doesn't sound natural or that I just wouldn't say in conversation. ## Don'ts In brand guidelines, it is just as important to enumerate what _not_ to do. I want to exercise the same constraint on my essays. - Don't edit the words or paragraph structure to sound smart. Only ever edit the essay to make a point more parsimonious. - Don't conform to the writing style of others. Focus first and foremost on getting my thoughts onto the page. - Don't try to impress readers with profound sounding ideas. I believe there is a sizeable time lag in how long it takes a reader to register some really profound insights. In any case, the goal isn't instant validation—the best ideas may simply be obvious in hindsight. - Don't spend more than a few days of active writing time on each essay. The more time I have to formulate my words, the more perfectionist I'll get, and the more I'll try to perfect even the thoughts going into an essay. - Don't filter what I share, as long as I can't foresee the ideas causing _actual_ hurt to others. I might make predictions that diverge drastically from the status quo, so at most I might share an uncomfortable truth. - Don't blindly extrapolate from past essays out of convenience or an assumed necessity to double down on past viewpoints. I _should_ change my opinions when the data changes—it would be irresponsible to perpetuate a belief when an underlying assumption is challenged. Of course, if the data hasn't changed, then I can shamelessly refer to the conclusions of a past essay. - Don't write about what I think others want to hear. I should write about whatever thoughts I naturally have, in whatever distribution I have them. Luckily, I've found it impossible to motivate myself on an essay topic by asking friends for inspiration. At best, I've been able to ask friends which essay I should write first from a shortlist of topics I'm already interested in. - Don't restrict myself to any one topic like 'frontend development'. As long as I've thought deeply about a topic, I am likely to have some unique perspective that is worth sharing. ## Inspiration I'm a strong believer in credit where credit is due. Here are my three main reasons for publishing essays online. - Paul Graham. - My friends who started writing a few years ago, who have proven that there is really only upside in online publishing. It turns out that all the potential downsides are purely hypothetical. [^1] - My friends who still have some unfounded embarrassment in sharing their work on the internet, whether it's opinion pieces or creative writing. I hope my essays encourage you to start publishing too. ## Notes [^1]: Thanks Diego, Yusuf, and Ben.