What public figures publish and believe, in their own words.
About this feed
Latest: everything, as it happens, in the order it happened. Nothing ranked.
Show highlights instead.
The quoted blocks are what people actually said; a beneath one is
the belief those words support, in korrents' wording. Nobody here wrote their own page.
Top people are the people in this feed with the most beliefs on this site, then the
most here. Choose an area and the row leads with the people whose beliefs are about it;
tap a face for their feed.
Omarchy is not going to adopt a formal Code of Conduct because those turned out to be struggle-session processes in the last turning. But we are going to play nice. We're going to be courteous, professional, and composed in our direct interactions with users, competitors, and even haters. Because that's what's going to pave the path to the win.
I can't tell you the number of people over my career that have said "I tried learning tmux" First problem: the fact you have to "learn it" at all. The world's best multiplexer is the one you don't have to learn. It just works.
The 'in between' is likely to be subsumed by agents producing just-in-time UI. When you need utilitarian content or data, it'll be generated just-in-time for you. Think of the agent as the new browser in this model.
I actually think the opposite, which is that there are going to be many more software engineers than even the rosiest current predictions, and that software engineers will take over these other jobs: legal, marketing, accounting.
Maybe Nix is like Rust: Amazing if you don't have to look at the code! I'm open to the idea that Omarchy Cinque could switch packaging system if I never have to look at nixlang, there are no ergonomic regressions, and we have full repo sovereignty.
The revelation I've had working on Omarchy the last three months is that to get that magical 10X, 100X, in a few rare cases, 1000X productivity boost, you have to interact with the agents directly, and you cannot intermediate that bandwidth with another human because it's simply too slow.
The reason I say that is there's a lot of programmers who are not very good product managers. Software is product management. What should it do? Who should it do it for? How should it do it? How should it look? What are our priorities? What do we start with first? What does version one include? All of those skills are not easily or equally distributed across all programmers.
So it's strange because it's also perhaps the major software release that I've worked on the least in terms of lines of code. I have the least number of personally hand-chiseled lines of code in Quattro than I've had in any major release I've ever done. And yet, I am insanely proud of what we've accomplished.
I also see people attacking major product categories now with performance-based pitches. Things like File Pilot or the Blick video editor, like things like this that have been coming out lately where it's like, oh, really performant software to try to take on uh incumbents in a space and they've been getting traction.
I find there's a lot of like received programming wisdom that's just nonsense. Like clearly no one's ever tested it and if they did they would have found out that it's that there's no actual basis for it.
If every uh software engineer knew to watch out for false serial dependency chains, things where they were creating series of dependent operations that could not be optimized away or other sorts of architectural problems like that that cannot be easily fixed, then the world would look more like just wait and optimize the hotspot, right?
With thousands of developed in a mono repo, it just does happen that one directory is missing one of the two files and this means that a subset of devs work with lobotomy. We fix this with automation but it’s a stupid complexity tax that shouldn’t have to be paid.
New: emulate a GitHub App in a few lines of TypeScript Generated App keys, installation auth and stateful repository APIs Develop locally, test in CI or give sandboxed agents their own isolated GitHub environment
Frontier Labs are incented to be fearful as it provides a moral justification for staying closed.
Chinese Labs take the consistent position of doing what’s good for all and being open.
So the little guys find themselves in the uncomfortable position of rooting for the Chinese…
The problem with this argument is that you probably don’t need a user interface on prod. You need a command line interface on prod that a user interface on your Macbook can drive.
I would say, sometimes, I don't know if it's controversial, that very few developers understand memory management. And that makes it even harder to debug memory problems. And so the state of the art around memory debugging hasn't evolved all that much over the years.
And that embrace of people are going to use whatever tech they want to use. You can't tell people what to use very often. They're going to use whatever they want, and your job is to help them be successful on your platform, and to help your users have a great time.
And it's effectively the next step of, you know, every phase of of software evolution is just like a rising tide of abstractions. This is the next abstraction.
Now you can have a quake style console in your operating system. Except with an infinitely patient agent to help you customize it instead of esoteric variable names and slash commands like in the 90s
I think it's all about having regulatory clarity and ease for all sizes of of companies. Um and if we can work with Congress to do something like that, I think that would be that would be the biggest boon for for for startups.
if the US wants to lead in artificial intelligence, we have to have a vibrant closed and open source ecosystem, and that's the only way they can all work together.
I believe that we are now entering a era of comparable turbulence in mathematics. This time, though, what is being stress-tested is not our foundational framework for mathematical truth, but rather the largely implicit framework of mathematical values and practices: what we consider a contribution to be, what we reward, what we regard as understood, and who - or what - we regard as having done the work.
I guess you can’t go wrong with Charles Petzold. This book is excellent and highly recommended to anyone interested in computing. Must read for computer science students and software developers.
Nicely written and an entertaining story of Linus Torvalds and the creation of Linux kernel. I read it in high school and it definitely strengthened my interest in computer programming.
The The point just being this is so not an exact science. And I always like to show either what a client asks for or what a programmer might have used as a placeholder because I've gotten so many good ideas that way.
a cybernetic machine can nail the task and completely miss the job. coding makes this very very easy to see because the tasks are so legible (and verifiable!): write the function, migrate the API, fix the tests.
buuuut my roadmap is’nt ten times shorter. and I’m definitely not ten times better at deciding what is worth building. teams haven’t started casually shipping a year of product work every month. you can look around and and it’s hard to say what software has gotten meaningfully better in the last year.
For the first time, AI has "hands" - that is, the ability to reach out and interact with the tools on your computer and in your browser, just as you would.
This is a disappointing and frustrating book - not least because it so nearly hits the mark. The subtitle is "How Computer Programming Is Changing Writing" - but it never gets close to discussing that topic, let alone deeply examining it.
And in all of these applications, the customer is making a decision based off of the recommendation of the AI model more or less. Uh, and this means that if the customer is ultimately like kind of making the decision, this means that if the system makes a mistake, um, that's okay because usually the person can kind of recognize that or or decide what to do even despite that mistake.
I mean at the very least I actually think that just starting with a generalist policy and then fine-tuning it even like right off the bat uh can be really effective.
As soon as you merge, it should be going out. You like you should have to stop the train to make your code not go into production as soon as you've merged.
it's always weird to me just how much software engineers really seem to believe that the world exists in the repo. It doesn't. It's production, you know?
Thinking Forth by Leo Brodie. I used to have this habit where I learned various programming languages. To challenge my perspective, I chose languages from families and paradigms that were fundamentally different from what I already knew. Occasionally, I stumbled upon greatness. Thinking Forth presents programming as a creative process, and it delivers those lessons in an entertaining and pedagogical way. The book is particularly strong on software analysis and design, but it's the execution and technical writing that brought the book to my top five. This is the book for anyone writing about software — Leo's way is the way to do it.
Facts and Fallacies of Software Engineering by Robert L. Glass. In essence, this is a book about an industry that refuses to learn. That was true 25 years ago when this book was published, and it's probably twice as true today. (Just think about all the AI adoption metrics being rolled out — back to productivity mistaken for lines of code produced, only more elaborate. And expensive). What I like about this book is that Glass doesn't present anything new. Quite the opposite, actually. Rather, it's about research lessons that we all should know, but tend to forget. Ever had to do an estimate, or plan according to a requirements spec? Or maybe you thought that enough eyeballs make all bugs shallow? Then this book is for you. A great work by a fantastic author.
Paradigms of Artificial Intelligence Programming by Peter Norvig. Learning the AI described in this book probably won't land you a job today. But reading the code examples will transform how you think about source code. The book shines when it comes to code comments, a topic that I've never seen demonstrated well in other sources. Here we get to see how comments become valuable as a narrative that explains both intent and reasoning. Brilliant, just brilliant.
Multi-Paradigm Design for C++ by James O. Coplien. Twenty years after reading this, the core techniques are still with me. These are commonality analysis, where the purpose is to identify families of systems, and variability analysis, which focuses on capturing the domain parameters that vary. In essence: the foundation of great software design.
This book is a beautiful introduction to simulations of natural systems. We get concise prose, clear illustrations, and carefully chosen systems with a guided tour through the math. All done in the Processing language, which is fun and easy to pick up. The reason I like this book so much is probably due to timing. In 2013, I was on the verge of abandoning software development. I was fed up. (That's a story for another time.) Instead, I planned to go into cognitive psychology full-time as a researcher. This book brought back the joy in programming for me. Sometimes, a good book is the book that motivated you.
The the part that's really nice about it is because I do a lot of Mac software, agents love to take over my screen and click around and if you put that in their own if you give them their own machine, it will not bother you. Otherwise, you'll fight with the agent for the mouse cursor.
Every lab will sell you an agent. Open claw is the alternative. Open source runs everywhere, works with any model. And if you run local models, your data never has to leave your device.
Second of all is I hope you worked on your personal brand and on visibility because in this day and age there's so much noise out there that your hardest problem is not the tech, it's not the software, not even the people. The hardest problem now is like getting eyeballs.
If you count all the permutations, you can write all the tests you want. It is impossible to cover all of these and not break things from time to time. It is infinitely harder to evolve software that has users.
And most of them really sent reports that their agent produced without actually even testing it. I would I would take a stronger sense of explaining what are the parts that we guarantee and what are the parts that will not be fixed because that that's not our security boundary.
In addition to reliability issues, it often engenders a mind-numbing workflow and an environment where junior developers will never acquire the expertise to become senior developers capable of designing complex systems.
Given the high cost of errors, you need to have a very high level of safety and a very high level of confidence on day one before you deploy your first robot, before you drive your your first autonomous mile.
So, a deployment of your agent uh in the real world generates data. That data then grounds the simulator and makes it more realistic. The simulator generates harder edge cases for the critic to score and for the agent to learn from.
absolutely agree that product skills are probably the most durable. My build would just be there's a lot of people who have the title PM who haven't spent a lot of time building those skills in the last 5 years, but have gotten really good at communicating frameworks to leadership.
Technologies from our community - CRDTs, sync engines, universal version control, and good old-fashioned open protocols and file formats - can give a nation more independence and control over its own critical software infrastructure.
So we've always told computer scientists from the very beginning that really it's really important to specify what it is, what's the software that you're writing is trying to accomplish before then going and writing it. And so now we actually have agent-based systems that can do the writing, but the importance of specifying what what it is you want has actually gone up because before you'd be handing it off to a very intelligent human who maybe has context or can ask you follow-up questions.
Um, and to give you an example of a a a use of a coding agent that works extremely well is you can ask today's models to translate software from one computer language to another very effectively because in that case you actually have a incredibly detailed specification.
I predict that in the next 10 years software development will survive, but it will become like any other white-collar professional work. No more $200,000 salaries, unlimited vacation, or incredible employee bargaining power.
But I think it is more useful for most developers to have an exposure to like what math has in the various fields versus just going all in every single field when they see them, right? You've got to know what's available to know what's most useful for you. And most math will not be useful for you.
while we are a lot better at iterating than other fields, we're worse at the planning part. Like we still need to do some kind of planning before we iterate and we just aren't as good as those other fields.
Software is kind of unique in having the third kind of the practitioner conference where we are just meeting to get better at what we do. We also are really the only kind to really focus heavily on like open source in making our knowledge freely available.
we don't believe in a world where these models are so expensive that, you know, they get rationed only for the most wealthy of developers and and companies.
Superlogical will begin by shipping a terminal multiplexer. I'm pouring my years of experience building a terminal and studying the potential and limitations of other multiplexers into something new, powerful, and, of course, fast.
At boom we need far more software engineers in a postAI world than we need in a pre-AI world. Why? Because the cost of software development has dropped. anybody including hardware engineers can now become a coder and we need software engineers to make sure the architectures are right and make sense and are coherent.
The key thing is to make hardware development look more like software development to reduce the cost of iteration both in the world of bits and in the world of atoms.
But great airplanes are incredibly integrated and everything affects everything else. uh the the best airplane design is interplay of propulsion, of aerodynamics, of structures, of all kinds of optimizations, how you fit the systems into it.
We said all of this engineering that historically exists in spreadsheets really should exist in software. The spreadsheet engineering is like it's like baby software.
we're on the path to fully automating the maintenance of our apps by doing this. And this is again hundreds of agents running every day, sometimes thousands of agents every day. It's doing the work of you know, dozens or hundreds of engineers.
I I think this is sort of the crazy thing about building on models. It's just so different than all the engineering that I've ever done. Like in the past when you built on systems, you built these like big beautiful systems and you really think about the system design up front. You have like a big suite of unit tests. You think about everything and you know, like a re-architecture is a big project.
we want we want to encourage everybody and every company to build their own AIs. And and and who knows what innovation will come from the fact that it's open source.
LG makes the best TVs, end of story, but their software is shit and spies on you, NEVER connect them to the internet/WiFi, instead buy an Apple TV box and connect that, that doesn't spy on you and has no ads, then connect it with HDMI and you're good, also no annoying LG TV updates
LG makes the best TVs, end of story, but their software is shit and spies on you, NEVER connect them to the internet/WiFi, instead buy an Apple TV box and connect that, that doesn't spy on you and has no ads, then connect it with HDMI and you're good, also no annoying LG TV updates
So AI has made everybody just as capable as everyone else, it equalized everyone in the world, as in everyone can make everything (software, music, images, art etc) now and everyone is equal, at least in the digital realm now
I read a bunch of blog posts about how it is totally fine to use SQLite in production for a small site and I think it is totally fine, but what I did not fully appreciate is that SQLite is still a database, databases are complicated, and I do not know a lot about operating databases.
So I think the the thing I'm most excited is actually like what we call like iterated loops or like slow loops where we basically have a cron job. We have the loop the the the structure of the loop is really easy. It's like run this llinter fix one thing commit and push and then we run that every night in our GitHub actions and we wake up every morning to one PR that makes the codebase a little bit better.
yes it will catch things and it will raise your floor but I don't believe like the model writing the code is the same model reading the code and if you ask a model hey is this code good it's going to be like oh yeah it's great comprehensive it's got unit tests
We tried this. We built a lights off software factory in July of 2025 and by November we had shut it down. I think it takes about three to six months of you shipping all the time with nobody reading the code before you realize like, wow, this is getting way worse and it's easier to start over than it is to fix it.
there's a different kind of intuition that you that you develop over years as a software engineer and uh there's many categories of it but the one I'll I'll call attention to that is like a thing that you cannot teach you cannot do you cannot learn in a textbook. The only way to learn it is like I know bad patterns in software because I have debugged them at three in the morning.
And at the end of the day, they're all like different ways to pass tokens into a model and ask it to produce usually some structured output. And understanding that is a lot more powerful than trying to learn memory and trying to pick some agent framework off the shelf and some memory framework off the shelf.
All you really need today to build a business is 100% free open source software that charges you $0/mo a VPS server an API to do some required AI stuff some R2/S3 file hosting
I did try Dell's laptops a few years back, didn't like what I saw, and ended up spending a few years using Framework computers instead (they're still great too).
So beforehand because of this social divide between programmers and testers. There was a lot of incentive for the testers to have their own language. This is my tool. I know how to run it. I'm going to run it.
The agile manifesto is the intersection of the ideas of the people in the room. I think there's a lot more to software development than is contained in the manifesto. And I've written books and books and books about what I think those things are.
what I don't like about it I didn't like about it then and still don't like about it is it's not defensible. Nobody's going to say I'm not agile. Oh no, I prefer rigid development. Oh, I prefer inflexible development. No, everybody's going to say that they're agile, which extreme doesn't have that problem.
which is why when I see manifestos today I'm just like too soon. Not a bad idea. Would love to have one just too soon. It took 15 years for the technical change of object-oriented programming to come before we could say here are the consequences of it. Here's how in a simple way we can express how to effectively use this technology that we've been using day in and day out for 15 years. The genie comes along. People are like, "Well, what's the new manifesto? It's just not manifesto time yet.
And then there were people who used it as a moral cudgel. Like you should be if you're not using TDD, you're not professional. And that's just such People can write very good software with a wide variety of workflows.
I agree with @theo completely, it's clear to me this is where it's going, also seeing @karpathy with Claude moving to the cloud (via Slack etc), I think AI "agents" and AI coding will operate on servers / from the cloud first
I am not affiliated with any of the tools mentioned in this article, but one nice thing about Ollama is that they also optionally support open-weight models hosted in the cloud
Yeah, so I would say over the last 6 months actually we've been cranking a lot of features out a lot of code out. Most of it has been written by AI at this point. And before that really wasn't the case. I was actually a really big AI hater for a long time
And even the cost issue with AI is probably going to be like once the subsidies start running out, which we're starting to see, I think that's going to be a really big issue where maybe all these companies that embraced AI programming are now going to like cut back on it.
I think a lot of people, especially students, are unfortunately learning everything through LLMs. So a lot of that isn't really learning, they're just kind of cheating and they're just doing everything like that. And then they lose a lot of their skills
Like every single time there's just like the big innovation like cloud computing, like higher level programming languages, for whatever reason things do not like it doesn't lead to fewer programmers. And I would have expected it would have.
Zig is exceptional software: ambitious, practical, independent, and unusually serious about quality. Ghostty exists in large part because Zig made it possible for me to build the kind of software I wanted to build. This is why I support Zig.
And eventually, you have to really move into a full stack. So, not just a silicon, you need to have a software, and some of the customer asked me, "Give me the whole rack." So, there's a system that you have to build.
there there's a one question we got to back up and really explore which is is AI a new platform and I would argue that it is not yet a new platform. It is an important technology.
Users can't see the code, so UI is the only way for them to judge the quality of the app. If UI looks good, that means developers had time to polish it, which means that they probably spent a comparable amount of time to iron out the code.
In terms of science, I think it really makes sense and we're deeply committed to open source. Um, there are obviously interesting considerations on this that are important too because there's a lot of considerations around biosafety and things like that that we're going to need to balance and think through how to how to handle.
the competitive dynamic in China is more intense because it's more intense. Everyone's chosen to go open source and that creates a system that in my mind is capable of innovating far faster than the competitive system we have here. All the models learn from one another.
My Dad and I tested all the PiKVM models, and I like everything but the price. I 100% recommend them, especially since you're directly supporting the folks who wrote the software.
They just recently released a report, and I think like you really have to squint to see anything happening. Like basically, if you want to take kind of like uh an an approach across the entire economy and looking at even looking at like software engineering, like the most exposed sort of sectors, there's just like not really anything going on. There might be a little bit of a signal about like junior developers getting jobs less than before, and that but that's like a less than before rather than a level shift.
And so you have been part of the change to other industries and other people yourself. What did you think about that? Did you even think about it at all? So let's not be surprised if you find no sympathy from all the other professions that you've helped force change upon.
It's like maybe you don't understand what the job has always been. We are trying to solve human problems and we use whatever technology is required. In some cases, the technology happens to be software and software ain't required for every human endeavor.
I'm watching people write these huge markdown files to give the agent context. How about you write documentation to give me context so I can have fully working examples.
and it turns out people kind of over glorify entrepreneurship. I think a lot of people believe there is tremendous upside, right? the type of entrepreneurship we talk about with software companies, the the upside is crazy. But when you're doing like selling parts or service business, unless you plan to open lots of stores and you know grow a larger employee base, it's not the same growth trajectory as software companies.
The thing that makes Kubernetes powerful, there's a data model. We gave infrastructure a type system. So instead of imperative shell scripts, you finally had types.
So often with new software paradigms, what looks like inevitability turns out to be just design failure that can be solved with the right guardrails or affordances or system instructions.
But you if you also become an expert in a specific industry, that's like a deadly combo. Um if you are like just pick any industry, let's say let's say farming, let's say you understand that farming industry really well and you're also a decent software engineer, you're probably like the top 10 people in the world for that combination that the whole industry will want to hire.
The the biggest advantage to in DevTools is the fact that everyone working at DevTools is a programmer and programmers are horrible at B2C products. They don't realize DevTools are B2C products.
The thing that I find interesting is that's not novel. This has been the thing we've always been trying to do forever. How do we get a junior engineer to ship code safely without breaking stuff? Right? How do we make patterns in the codebase? How do we make tests? Like it's it's all the old stuff that we've always wanted to do.
The second is that most of the work that you do is actually going to happen on your computer in an environment like Codex or Cloud Co-work that becomes the sort of operating system for it becomes the sort of operating system for how how you do all of your work, whether that's your email, the documents you create, like all that kind of stuff.
And what you see when we work with them internally is now they're just like they're just making pull pull requests. Like they don't they don't need to hand it off as much. Sometimes they do but like a lot of times they just make pull requests and it's like the thing is built and that's it and I think that's incredible for the way that companies work
And I think that Cursor has at least so far more distinctly chosen a lane. Like they're more distinctly choosing to be a for programmers. And that may limit how far they get in here.
And what this is is that in the guide level explanation, you explain your feature as if you were writing a guide as if the feature already existed. And in the reference level explanation, you explain your feature again as if it already existed, but as if it would be in the language reference instead of a tutorial.
My opinion is that the least mature area is front end. There have been some attempts to compile Rust to Web Assembly and then run it on the web as a front end as a replacement for TypeScript. But if I was writing a web server, I would totally use Rust for the back end and TypeScript for the front end. I would not really go the web assembly route.
I think where Rust is really unique is in the combination of things. So on one hand, it it doesn't have a garbage collector and it it's usable in low-level context like the Linux kernel or firmware or whatever.
I think this is kind of leads to another way that Rust really helps with reliability, which is that if you're refactoring, I think Rust is really good at telling you all the places you need to update. I've done this sometimes where I would refactor something. I change the code. I change the return type or whatever it is, and then I just fix the compiler errors and until the compiler stops shouting. And then once I've done that, I've updated every place I need to update.
As reasoning models and agent workflows keep more tokens around (for longer), KV-cache size, memory traffic, and attention cost quickly become the main constraints, and LLM developers are adding a growing number of architecture tricks to reduce those costs.
unless the code is completely out of your control, the need for mocking often indicates a design problem-consider refactoring to make the code easier to test directly.
I ended up making this site with Tailwind CSS, and it helped me make a site I felt pretty happy with my minimal CSS skills and just 2 evenings of work!
Their words now
I’m a lot better at CSS than I was when I started using Tailwind
Ultimately Tailwind is limiting: if you want to do Weird Stuff in your CSS, it’s not always possible with Tailwind. Those limits can be extremely useful (a lot of this post is about me reimplementing some of Tailwind’s limits!) but at this point I’d like to be able to pick and choose.
And quite honestly, language design is 90% the same and 10% new for for pretty much every language. Every language you build still has to have a compiler. Compiler is still built in a pretty much the same way.
You know, there's open source and there's open development. And and and we were technically open source in the beginning, but it was not open development. We would sort of lob the source code out in this repository and scrape the issues off of that and put it into our internal issue tracker.
So, if we're checking 99% instead of 100%, well, heck, that's better than the 0% that JavaScript checked, right? And it gives you like language features that no other languages can provide because they can't get to 100%.
And so everything is lazy and deferred and functional and reusable inside the compiler. And it's a very different way of writing compilers than than what the textbooks will traditionally teach you.
At even $500/kg, launch cost is only 5% of the total satellite deployment cost, so a lunar mass driver is unlikely to drastically improve the economics of space-based AI, by reducing launch costs.
Going forward, I think the future will be filled with software abundance, or, more accurately, I'd call it "software proliferation". That is, centralized development will be history. Software will be highly personalized, especially for open source software.
the more that we could build a platform uh around our business, the more that we could build an ecosystem with creators and developers, the harder it would be for folks uh to to just copy that.
network effects are certainly an important piece of the puzzle for sure, um but I don't think they're enough when it comes to these sorts of software uh you know, software cloning.
As the software industry is largely driven by trends and fashion, React's "cool factor" led to a mass amnesia regarding how to make normal, well-designed web apps made of HTML with a sprinkling of scripting on top and everything became one big tangled, brittle mass of Javascript that completely keeled over when scripting wasn't available.
local-first software, which is this idea that we want to take away a bit of the power from cloud operators and give it back to end users. So, end users should be more in control of their own data and less dependent on cloud services for providing the applications and the data that that the users need.
software as a service businesses, for example the whole reason why they can charge a subscription is because they are able to essentially hold a gun to the customer's head and say, "Pay us at your subscription, otherwise we will delete all your data."
And now suddenly people are building databases on top of object stores, for example. And now the replication happens at the object store level, no longer at the database level.
Maybe as AI writes more and more code of our code, it's less about like the details of how you express logic in a particular programming language and much more about those kinds of high-level trade-offs.
Ensuring that moving, borrowing, and sharing don't break the illusion is surprisingly easy to do with a static type system, and surprisingly hard to do with a dynamic type system, or at least hard to do cheaply.
I actually see the opposite of what people see I think the number of agents are going to grow exponentially. The number of tool users are going to grow exponentially and it's very likely that the number of instances of all these tools are going to skyrocket.
We have got to acknowledge that most of the advanc advances in AI came out of algorithm advances not just the raw hardware. Now if most advances came from algorithms and computer science and programming tell me that their army of AI researchers is not their fundamental advantage.
I love chiseling my code and the way I use AI is in a separate window. I don't let it drive my code. I've tried that. I've tried the cursors and the wind surfaces and I don't enjoy that way of writing. And one of the reasons I don't enjoy that way of writing is I can literally feel competence draining out of my fingers.
Their words now
I will now start any project I'm starting with. I'm starting agent first and that's a massive shift
Where I get fired up, and this ties back to the AI discussion, is when that's turned into this meme, that programmers no longer have to be competent. I mean the AI is gonna figure it out. The generators is gonna figure it out. I don't need to know SQL, active record is gonna abstract it away from me. No, no, no dude, hold up. The path here is competence.
Their words now
really good programmers are currently more valuable than ever because they're the ones who are able to get the most out of the AI acceleration.
The joy of a programmer, of me as a programmer, is to type the code myself. If I elevate myself, if I promote myself out of programming, I turn myself into a project manager. A project manager of a murder of AI crows as I wrote the other day.
Their words now
I have been hyper accelerated as a programmer. It's a different kind of programmer, but it still has the same affinity to aesthetics, at least when I'm producing Ruby code.
So certainly one thing that a lot of them seem to be bottlenecked on is now having interesting ideas and in particular having interesting design ideas.
which is that the the Venn diagram of developer experience and agent experience is a circle. And the point here is that, you know, what we do that that's good for the agents is good for the humans and vice versa. I'm hearing a lot of feedback saying, "Yeah, actually, if you have well-modularized code, that actually makes it easy for the agents to work with."
Um I think another similarity is I mean, the core notions uh behind Agile and extreme programming are solid and good, but a huge snake oil industry appeared around it, the Agile industrial complex as I like to refer to it. Um and that will happen. That is happening with AI right now, and it's often hard to see the difference between where is the snake oil and where is the real stuff.
My bet is on the more effective two pizza teams. Um and it it's also some interesting, you know, feedback we're beginning to get in terms of pair programming. I mean, with pair programming, do you say pair programming is the human and the genie? Or is it two humans and and genies? Because if it's two of us, we can control the genies perhaps a little bit better.
For years, it was faster to mock up software than to ship it. Designers stayed "ahead" of engineering with prototypes. Now AI coding agents make development so much faster that the loop has flipped.
none of us wanted to go through that extreme but lots of time when you are under a lot of pressure and no time to react other than just to survive that scale that keep on coming at you, you have to make uh decision that increase uh speed and velocity because speed and velocity allow us to build quick enough to survive
we're trying to crack the next frontier which is how we get that level of productivity increase and output building new features on top of a code base that are older,
But in Vietnam and also in a lot of other Asian countries, people are on the move all the time. Like people are on the motorbike all the time. So, they actually really don't like typing. So, the voice like a lot of the companies in Vietnam actually deploy voice bots before they do uh do chatbot.
I feel like now I can build anything I want. But at the same time, anyone can build anything I want. So, what is the incentive structure for me to do anything?
And organizations have super high pain tolerance. But human-made enterprise codebases take years to get there. The organization slowly evolves along with the complexity in a demented kind of synergy and learns how to deal with it. With agents and a team of 2 humans, you can get to that complexity within weeks.
With an orchestrated army of agents, there is no bottleneck, no human pain. These tiny little harmless booboos suddenly compound at a rate that's unsustainable. You have removed yourself from the loop, so you don't even know that all the innocent booboos have formed a monster of a codebase. You only feel the pain when it's too late.
You can give it a Bash tool so it can ripgrep its way through the codebase. You can give it some queryable codebase index, an LSP server, a vector database. In the end it doesn't matter much. The bigger the codebase, the lower the recall. Low recall means that your agent will, in fact, not find all the code it needs to do a good job.
Worse, you realize that the gazillions of unit, snapshot, and e2e tests you had your clankers write are equally untrustworthy. The only thing that's still a reliable measure of "does this work" is manually testing the product.
And if everything is proprietary, it's hard to do research and it's hard to innovate on top of, around, with. And so… Open source is fundamentally necessary for many industries to join the AI revolution.
right now, that whole front end has been like kind of smooshed because many times we can just like prototype really really rapidly and kind of solidify some of what we're thinking in terms of like ideas and coding. So I fully expect that part of the outer loop is just going to be collapsed as well, right?
There were a handful of people probably managing a security review process or a launch process or a deployment process or, you know, sometimes reviews were a little slow and they got backed up. Well, now we just threw gas on the fire and so all of that is a problem.
And so, like in the immediate term, yeah, we were getting more out, but now our systems, whether technology systems or human systems or processes, are really kind of getting overwhelmed.
I'm going to sound old when I say this, but like I one time had a company tell me, "Oh, well, they have to use that CI/CD system." I'm like 20 bucks, they're just spinning up Jenkins. And they were, right?
I kind of went from 80/20 of like, you know, uh to like 20/80 of writing code by myself versus just delegating to agents. And I don't even think it's 20/80 by now. I think it's a lot more than that. I don't think I've typed like a line of code probably since December basically.
these apps that are on the app store for using these smart home devices, etc. Uh, these shouldn't even exist kind of in a certain sense. Like shouldn't it just be APIs and shouldn't agents be just using it directly?
I do have like cautiously optimistic view of this in software engineering where I do think um it does seem to me like the demand for software will be extremely large. Um and it's just become a lot cheaper.
I simultaneously feel like I'm talking to an extremely brilliant PhD student who's been like a systems programmer for their entire life and a 10-year-old.
So I think the industry just has to reconfigure in so many ways that's like the customer is not the human anymore. It's like agents who are acting on behalf of humans and this refactoring will be will probably be substantial in a certain sense.
OpenAI and Anthropic have both realized that code is the most important thing to optimize the models for, cuz that's where the money is. Like coders will spend $200 a month on a plan if it's good enough, it turns out.
one of the magic tricks about these things is that they they're incredibly consistent. If you've got a code base with a bunch of patterns in, they will follow those patterns almost to a T.
just cuz the test suite passes doesn't mean that the web server will boot. You know, there's there's always a chance that when you actually try in the real world, something's not going to work.
projects are flooded with junk contributions at the moment to the point that people are trying to convince GitHub to disable pull requests, which is something GitHub have never done.
Um, and then you stack on 70 this year, 80 next year, growing to 100 by 2030. You're at like 700 EV tools by the end of the decade. Um, 700 EV tools, three and a half tools per gigawatt. um assuming it's all allocated to AI which it's not but three and a half tools per gigawatt gets you to 200 gigawatts worth of AI chips for the data centers to deploy
As we move from, you know, hey, [clears throat] these companies are selling tokens where they provide the entire uh reasoning chain and all that to uh selling automated, you know, white collar work, right? Automated software engineer, send them the request, they give you the result back and there's a bunch of thinking on the back end that they don't show you. The ability to distill out of American models into Chinese models will be harder.
I believe that data - real-world data, mostly human-generated, validated, and cleaned - is the only reliable moat we have as software founders in the near and mid-term future.
If you run a software business that is purely transformative - that takes incoming data, does something to it, and turns the data back out - that will be a problem.
I think that by the end of this year and we'll see demos of it like right away, but by the end of this year most people will be programming by talking to a face. A face as in a face on the screen.
My my feeling is that probably people have a low tolerance for non-determinism. And these things are fundamentally non-deterministic. So, they can't just go replace customer call center software because they they could be wrong.
If you're a monolith, you're kind of hosed because I told you the ceiling's going up for what they can do, but it ain't ever going to hit your monolith. They will never fit in the context window and you're never going to be able to never in the next 18 months be able to tell a model go fix my monolith. You have to break it up.
I had a lot of my own ego and identity wrapped up in my sort of compiler background. It's all It's interesting, right? But it's it's not useful in any meaningful sense anymore.
But right now I think it's sitting somewhere between half million and five million lines of code, somewhere in there. Probably more on the half million side right now and with the next drop of an Anthropic model, we're probably going to see it jump up to a few million lines.
Polyvagal theory provided me with a coherent framework for understanding why cognitive insight alone often fails when a nervous system is in defensive dominance. In such states, higher-order cortical processes are functionally constrained.
I've always been opinionated about how software should work. Mainly, it should be fast. The bounds of it should be "knowable." The contract you have with it should be "sane" (i.e., you just own it).
With Claude, I've built a host of software like this. Mostly small tools for myself — programs that instantly append copy buffers to text files (I keep a running file of nice things people write to me called notapieceofshit.txt) or quickly perform live currency conversions.
But but that's actually a very weak criterion, right? People thought I was saying like we won't need 90% of the software engineers. Those things are worlds apart, right?
But the quality of these systems isn't just in the code they write. It's also in the code I don't have to write. And maybe more importantly, their actual value is in the code I would never have written, or could never have written, or never would have wanted to write.
It’s actually how good they are at programming is almost a burden in their ability to empathize with the system that’s starting from scratch. It’s a totally new paradigm of, like, how to program. You really, really have to empathize.
building a third-party client to read and route messages is a gray area in their terms of service, and perhaps only partially supported in their API surfaces.
I think that there will be lots of work for us cleaning up after the slop, but if you know what you're doing AI augmented development is going to get you some amazing results
As high-level programming cedes way to the prose compiler, making your goals and specs well understood to the ambiguity loop and showing good judgment is going to matter more than ever.
The Moonlight client is available for virtually every platform: Mac, iOS, Android, and of course Linux. That means no need to dual boot to enjoy the best games at the highest fidelity.
there should be no way to get a big company like a public SAS company Unless NR is greater than 100, like otherwise cancellation should just win. And that is in fact the case.
But with today's AI coding agents, building software is remarkably easy. So instead of handing over static assets and static guidelines, designers can deliver custom software. Tools that let clients create their own on-brand assets whenever they need them.
Local-first is not going to win, but that's okay We'll explore the complexities of traditional stack (db-server-frontend), develop a theory of software evolution: which systems succeed and why.
I don’t think this is very productive (expert users of a piece of software are notoriously bad at being able to tell if an explanation will be clear to non-experts), so I needed to find a way to identify problems with the man pages that was a little more evidence-based.
. Understanding how we grow and develop will help you become a better leader and a more empathetic colleague. More accessible than his academic work, this book also provides a framework for understanding underlying beliefs and motivations that might be holding you back.
A korrent is a belief a person has stated in their own words: one
sentence stating the claim, backed by a quote and a source, kept at
korrents.com.
Under a name here, the quoted block is what they actually said.
The korrent beneath it is the claim those words support, in
korrents' wording — tap it to see the record, its source, and who
else holds it.
Nobody here wrote their own korrents. They are compiled from public
statements, and a person can change their mind, which is recorded too.
About the English under a post
Some people here publish in a language other than English. Where they
do, this site shows a machine translation beneath the post, in
this typeface — the site's own, not theirs.
The post itself is never changed, moved or hidden: what is set in the
serif above is exactly what the person published, and it is what to
quote them on. A translation can be wrong in ways that matter,
especially about tone.
Only the post's own words are translated. A quoted post, a linked
article and a belief on korrents.com
are left in their original language.