Depending on the way you phrase questions, ChatGPT will gleefully suggest you a wrong approach, just because it’s so intent on satisfying your whim instead of saying No when it would be appropriate.

And in addition to that, you don’t learn by figuring out a new concept. If you already have a feeling of the code you would write anyway, and only treat the model as a smart autocomplete, that doesn’t matter. But for an apprentice, or a layperson, that will keep code as scary and unpredictable as before. I don’t think that should be the answer.

This.

If LLMs were actually some magical thing that could write my code for me, I wouldn't use them for exactly this reason. Using them would prevent me from learning new skills and would actively encourage my existing skillset to degrade.

The thing that keeps me valuable in this industry is that I am always improving, always learning new skills. Anything that discourages that smells like career (and personal) poison to me.

I treat LLMs as junior programmers. They can make my life easier and occasionally make it harder. With that mindset, you start out knowing that they're going to make stupid mistakes, and that builds your skill of detecting mistakes in other people's code. Also, like with biological junior programmers, nonbiological junior programmers quickly show how bad you are giving direction and force you to improve that skill.

I don't write code by hand because my hands are broken, and I can't use the keyboard long enough to write any significant amount of code. I've developed a relationship with nonbiological junior programmers such that I now tell them, via speech recognition, what to write and what information they need to create code that looks like code I used to create by hand.

Does this keep me from learning new skills? No. I'm always making new mistakes and how to correct them. One of those corrections was knowing that you don't learn something significant from writing code. Career-sustaining knowledge comes at a much higher level.

I try hard to avoid the scenario where junior programmers write things they don’t understand. That’s actually my biggest frustration and the difference between juniors I enjoy vs loathe working with. There are only so many ways to remain supportive and gently say “no, for real, learn what you’re working on instead of hacking something brittle and incomplete together.”

For me, both Copilot and ChatGPT are reasonably skilled junior programmers. They understand about 70% of what I'm looking for. I can correct them with one revised prompt and get them to the 80 to 90% range. At three prompts, I assume GPT/Co-Pilot is an idiot.

In both cases of non-bio and bio junior programmers, I always ask myself the question, how am I explaining it wrong? More often with bio junior programmers, I am explaining it wrong. With nonbio junior programs, it's still giving the wrong explanation, but in a different way.

The closest analogy to this experience is learning how to use speech recognition. You get to about the 95% recognition level by the system learning how you speak. You get to the 98, 99% recognition level by speaking the way the system hears

It's a great question. My answer generally is yes, I would (and do), but I'm willing to sacrifice a bit in order to ensure that the junior developer gets enough practical experience that they can succeed in their career. I'm not willing to make such a sacrifice for a machine.

Can you please write a blog post on what tools you use for that?

My hands are fine, still, I'd love to just verbally explain what I want and have someone else type the code for me.

It's fair for the type of code you want to write for your own growth. But even with that, there's more than enough bullshit boilerplate and trivial cross-language differences that contribute zero (or negatively) to your growth, and is worth having someone else, or something else, write it for you. LLMs are affordable for this, where people usually are not.

A better language reduces boilerplate. A better compiler helps you reason about errors. Better language features help you be more expressive. If I need to spool up a jet turbine feeding H100's just to decipher my error messages, the solution is a better compiler, not a larger jet engine.

I myself have noticed this: a wild heterogeneity in the types of tasks for which LLM are helpful. Its appearance as a silver bullet withers the closer you get to essential complexity.

For example, nobody would ever have developed RAII if manual memory management didn’t peeve them. Nobody would have come up with C if they didn’t feel the pain of assembly, or Rust without C, or Typescript without JavaScript, etc. Nobody would have come up with dozens of the genius tools that allow us to understand and reason about our software and enable us to debug it or write it better, had they not personally and acutely felt the pain.

At my job, the people most enthusiastic about LLMs for coding are the mobile and web devs. They say it saves them a lot of time spent writing silly boilerplate code. Shouldn’t the presence of that boilerplate code be the impetus that drives someone to create a better system? The entire firmware team has no interest in the technology, because there isn’t much boilerplate in C. Every line means something.

I worry LLMs will lead to terrible or nonexistent abstractions in code, making it opaque, or inefficient, or incorrect, or all of the above.

You don't need a jet turbine and H100s for that, you need it once for the whole world to get that ability; exercising it costs comparatively little in GPU time. Like, can't say how much GPT-4o takes in inference, but Llama-3 8B works perfectly fine and very fast on my RTX 4070 Ti, and it has a significant enough fraction of the same capabilities.

Speaking of:

> A better compiler helps you reason about errors.

There's only so much it can do. And yes, I've actually set up an "agent" (predefined system prompt) so I can just paste the output of build tooling verbatim, and get it to explain error messages in it, which GPT-4 does with 90%+ accuracy. Yes, I can read and understand them on my own. But also no, at this point, parsing multiple screens of C++ template errors or GCC linker failures is not a good use of my life.

(Environment-wise, I'm still net ahead of a typical dev anyway, by staying away from Electron-powered tooling and ridiculously wasteful modern webdev stacks.)

> A better language reduces boilerplate.

Yes, that's why everyone is writing Lisp, and not C++ or Java or Rust or JS.

Oh wait, wrong reality.

> Better language features help you be more expressive.

That's another can of worms. I'm not holding much hopes here, because as long as we insist on working directly on plaintext codebase treated as single source of truth, we're already at Pareto frontier in terms of language expressiveness. Cross-cutting concerns are actually cross-cutting; you can't express them all simultaneously in a readable way, so all the modern language design advances are doing is shifting focus and complexity around.

LLMs don't really help or hurt this either, though they could paper over some of the problem by raising the abstraction level at which programmers edit their code, in lieu of the tooling actually being designed to support such operations. I don't think this would be good - I'd rather we stopped with the plaintext single-source-of-truth addiction in the first place.

> Its appearance as a silver bullet withers the closer you get to essential complexity.

100% agreed on that. My point is, dealing with essential complexity is usually a small fraction of our work. LLMs are helpful in dealing with incidental complexity, which leaves us more time to focus on the essential parts.

> Oh wait, wrong reality.

You are a bit too cynical. The tools (compilers and interpreters and linters etc) that people are actually using have gotten a lot better. Both by moving to better languages, like more Rust and less C; or TypeScript instead of Javascript. But also from compilers for existing languages getting better, see especially the arms race between C compilers kicked off by Clang throwing down the gauntlet in front of GCC. They both got a lot better in the process.

(Common) Lisp was a good language for its time. But I wouldn't hold it up as a pinnacle of language evolution. (I like Lisps, and especially Racket. And I've programmed about half of my career in Haskell and OCaml. So you can rest assured about my obscure and elitist language cred. I even did a year of Erlang professionally.)

---

Btw, just to be clear: I actually agree with most of what you are writing! LLMs are already great for some tasks, and are still rapidly getting better.

You are also right that despite better languages being available, there are many reasons why people still have to use eg C++ here or there, and some people are even stuck on ancient versions of or compilers for C++, with even worse error messages. LLMs can help.

You cannot ask it to build a complex system and then use the output as-is. It's not enough to replace developer knowledge, but it also inhibits acquiring developer knowledge.

You could learn the skill of running yourself over with a car, but it's either a skill you'll never use or the last skill you'll use. Either way, you're probably just as well off not bothering to learn that one.

In that context I think the analogy holds. Using an LLM halts your learning, as does running yourself over with a car. It's an exaggerated point for sure, but I think it points to the fact that you don't have to learn to use LLMs simply because it's a skill you could learn, especially if you think it will harm you long term.

When an algorithm tries to fix it for you you only learn how to send the code to the algorithm to fix it for you. It's convenient in the moment for sure, but you haven't learned how to fix your own code and won't know how to fix it when the algorithm is the cause of the error.

That also ignores secondary risks, like giving your codebase to a nonprofit / very much for profit company. That isn't always possible depending on the codebase, and in general why bother giving them access to it when you instead learn how to find your own missing semicolons? Why spin up a pipe of GPUs and burn all that power rather than learning to do it yourself?

I'm just trying to be clear-eyed about the risks. As an example, code completion tools in IDEs will cause me to get rusty in important baseline skills. LLMs present a similar sort of risk.

Using an LLM _is_ a skill, too.

A feedback loop with an LLM is useful for refinement of ideas and speeding up common tasks. I really even think it can be a massive productivity boost for one of the most common professional dev tasks with the right tooling. I work a lot of mercenary gigs and need to learn new languages all the time, and something like phind.com is great for giving me basic stuff that works in a language whose idioms I don't know, and the fact that it cites its sources and gives me links means I can deal with it being wrong sometimes, and also drill down and learn more when appropriate more easily

However, LLMs are super not like compilers. They simply do not create reliable simplifications in the same way. A higher level language creates a permanent, reliable, and transferable reduction in complexity for the programmer, and this only works because of that reliability. If I write a function in scala, it probably has a more complicated equivalent in JVM bytecode, but it works the same every time and the higher-order abstraction is semantically equivalent and I can compose it with other functions and decompose it into its constituent parts reliably without changing the meaning. Programming languages can be direct translations of each other in a way that adding the fuzziness of natural language makes it basically impossible to. An abstraction in a language can be used in place of the complex underlying reality, and even modified to fit new situations predictably and reliably without drastic risk of not working the same way. This reliability also means that the simplification has compounding returns, as it's easier to reason about and expand on for some future maintainer or even my future self.

LLMs for code generation, at least in their current form, lack all these important properties. The code they generate is a fuzzy guess rather than a one-to-one translation. Often it's a good guess! But even when it is, it's generating code that's no more abstract than needed to be written before, so putting it into your codebase still gives you just as much additional complexity to take into account when expanding on it as before. Maybe the LLM can help with that, maybe not. Asking an LLM to solve a problem in one case can fail to transfer to another one in unpredictable ways.

You also aren't able to use it to make permanent architectural simplifications recursively. We can't for example save a series of simple english instructions instead of the code that's generated, then treat that as a moving piece we can recombine by piping that into another instruction to write a program, etc. This would also increase the cost of computing your program significantly obviously, but that's actually a place where, well, not a compiler but an interpreter is a decent analogy. My main concern with LLMs being deployed by developers en masse is kind of already happening, but it predates LLMs. I notice that codebases where people have used certain IDEs or other code generation tools proliferate a bunch of unnecessary and hard to maintain complexity in codebases, because the programmer using the tools got used to just "autogenerating a bunch of boilerplate" which is fine in a vacuum but accumulates a ton of technical and maintainability debt really fast if you're not actively mindful of it and taking steps in your workflow to prevent it, like having a refinement and refactoring phase in your feedback loop

I think LLMs are useful tools and can help programmers a lot, and even may lead to "barefoot programmers" embedded in local community needs, which I love. I hear the analogy to compilers a lot and I think it's a bad one, managing to miss most of what's good about compilers while also misunderstanding the benefits and pitfalls of generative models

Btw, currently I wouldn't even dare to compare LLMs to compilers. For me the relevant comparison would be to 'Googling StackOverflow': really important tools for a programmer, but nothing you can rely on to give you good code. Nevertheless they are tools whose mastery is an important skill.

Remember how in yesteryears we complained about people copy-and-pasting from StackOverflow? Just like today we complain about people committing the output of their LLM directly.

---

I do hope that mechanical assistance in programming keeps improving over time. I have quite a few tricky technical problems that I would like to see solved in my lifetimes.

Is that not an unlikely thing to happen at least for developers working as company employees? The company I am working for has a contract with several LLM providers and there is no option to ban individual employees, as far as I am aware.

For freelancing developers the risks might be greater, but then you are usually not starting as a freelancer as a junior.

But I don't think this is a now problem, in the age of AI, but has been a growing problem for decades as software has matured.

LLMs are different because devs declare with pride that they “saved so much time” by just letting chatGPT do it for them.

Biggest failure mode I experience with LLMs is a very human-like pattern, what looks like corresponding with an interlocutor who absolutely does not understand a core point you raised 5 messages earlier and have re-emphasised on each incorrect response:

--

>>> x

>> y

> not y, x

oh, right, I see… y

--

etc.

chatgpt will make something that looks much more like it should work than your copy-pasted code from stackoverflow. It looks like it does exactly what you want. It's just riddled with bugs. Major (invented an api out of whole cloth; it would sure be convenient if that api did exist tho!) or subtle (oh, this bash script will bedshit and even overwrite data if your paths have spaces.) Or it will happily combine code across major api revisions of eg bootstrap.

I still use it all the time; I just think it makes already-expert users faster while being of much more limited use to people who are not yet experts. In the above case, after being told to make the paths space safe it did so correctly. You just had to know to do that...

Meta commentary on this, I honestly don’t mind if this is the hell that the business/management world wants to build for themselves. I’ll make a fortune cleaning it up.

I tried one to help me get the syntax right for the config file for a program. It started by generating a config file for the latest version and not the old one I was using, but once I told it that, it fixed that convincingly and spit out a config file that looked like it was for my version.

However, the reason I asked for help was that the feature was very badly documented, and yet ChatGPT happily invented syntax for the thing I was having problems with. And every time I told it that it didn't look quite right, it confidently invented new syntax for the feature. Everything it made up looked pretty damn convincing, if I had designed the config file format I could have gone with either of those suggestions, but they were all wrong, as evidenced by the config file validator in the program.

At least Stack Overflow had comments and votes that helped you gauge the usefulness of the answer. These glorified toasters have neither.

In this case we took our colleague to a whiteboard, and helped him do an actual design and helped him ask the right questions. LLMs won't question what you're doing, they will happily answer all your questions and help you pile on line after line of broken logic.

This is the only way I like to use it. Also in some cases for refactoring instead of sitting there for an hour hand crafting a subtle re-write, it can show me a diff (JetBrains AI is fantastic for my personal projects).

Therein lies the mistake. Too many people assume ChatGPT (and similar LLMs) are capable of reasoning. It's not. It is simply just giving you what is likely the 'correct' answer based on some sort of pattern.

It doesn't know what's wrong, so it's not aware it's giving you an inappropriate answer.

Sure it is, just like a child or someone not very good at reasoning. You can test ChatGPT yourself on some totally novel ad hoc reasoning task you invent for the task, with a single correct conclusion that takes reasoning to arrive at and it will probably get it if it's really easy, even if you take great pains to make it something totally new that you invented. Try it yourself (preferably with ChatGPT 4o) if you don't believe me. Please share your results.

LLMs are simply making probabilistic inferences about what "words" (tokenized particles of language, not necessarily individual words from our perspetive) are most likely to appear in relation to other words, based on the training data fed into them.

Their output often resembles reasoning simply because the training data contains large amounts of explicit reasoning in it. But there is no actual reasoning process going on in response to your prompt, just probabilistic inference about what words are most closely correlated with the words in your prompt.

If you're getting what appear to be reasoned responses to "novel" prompts, then one of two things is likely happening: either (a) your prompt isn't as novel or unique as you thought it was, and the model's probabilistic inference was sufficient to generate a valid response without reasoning, or (b) the response isn't as well-reasoned as it appears, and you are failing to notice its errors.

If you want to genuinely test an LLM's ability to engage in reasoning, try throwing a complex math problem at it, or a logic puzzle that trips most people up.

That's a good way to think about it. Treat GPT-4 as having mentality of a 4 year old kid. A kid this age will take any question you ask at face value, because it hasn't learned yet that adults often don't ask questions precisely enough, don't realize the assumptions they make in their requests, don't know what they don't know, and are full of shit. A four year old won't think of evaluating whether or not the question itself makes sense, they'll just do their best to answer it, which may involve plain guessing what the answer could be if one isn't apparent.

Remember that saying "I don't know" isn't an innate skill in humans either - it's an ability we drill into kids for the first decade or two of their lives.

It's not just "I don't know", really. It feels like OpenAI ingrained the essence of North American culture into the model (Sorry North Americans, I really don't mean this in a demeaning way!), as in, the primary task of ChatGPT is supposed to be to make its users happy and feel good about themselves, taking priority over providing accurate answers and facts.

So a young child might answer your question with a response that he heard other people say to a similar question, without actually understanding what he's saying. LLMs are basically this at a grand scale.

I really enjoyed the notion of barefoot developers, local first solutions, and the desire to wrest control over our our digital lives from the financialists.

I find these ideas compelling, even though I'm politically anti-communist.

The presentation was also quite lovely.

This really, really, really needs to be fixed. It's probably the most irritating (and potentially risky) part of the whole ecosystem. Nothing more infuriating than being give code that not only doesn't work, but upon the most casual inspection, couldn't possibly work -- especially when it's done it four or five times in a row, each time assuring you that this time the code is gonna work. Pinky swear!

Which is easily solved by using another agent that is told to be critical and find all flaws in the suggested approach.

Have you seen AI code review tools? They are just as bad as any other AI products - it has a similar chance of fixing a defect or introducing a new one.

We've known how to make reliable components out of unreliable ones for a century now. LLMs aren't magic boxes which make all previous engineering obsolete.

... and real defects that you never noticed or would've thought of.

> This is not going to help junior developers figure out good from bad.

Neither is them inventing fake defects which do not actually need fixing on their own. What helps juniors is the feedback from more senior people, as well as reality itself. They'll get that either way (or else your whole process is broken, and that has zero to do with AI).

The majority of people are content with learning the bare minimum needed to get by and never having to learn anything new. Don't believe, the proof is self evident the moment you try to update a UI that requires users to do things differently than before.

And this is all fine, I've accepted it by now. It's the way it's always been and always will be. Still, these new tools will empower a relatively small percentage of the population to create amazing open source apps that will be used by a lot of people. The tools also very much empower pro-developers to build a lot more apps with less efforts than before, which I'm looking forward to.

This is probably true of SWEs as well (although in some places it's hard to get away without thinking at least a bit.)

Is this because they don't like learning something new, or because they've been burned so many times by badly done redesigns that make things harder to use for pretty much everyone? I'm sure half of Hacker News despises how Windows has been redesigned from Vista onwards, or at the very least since 11.

Perhaps many people don't like change as much because a lot of changes come less from user needs/insight into what would actually improve the program and more from the need to give designers something to do (or provide another way to add ads/track users/appeal to shareholders).

Having an interest in making your own job easier/more efficient is very different from being interested in accepting every redesign under the sun.

The belief system of humanity in itself needs nutrients, needs to seed and grow positively people. Open source is by far one of the strongest currents about for that.

Right now open source is a mess & bogglingly complicated. Technology in general has gotten vastly less accessible year after year, the on-ramps to understanding detoured into ever more appliance-ized experiences & neofuedal cloud empires happening in other people's computers. Far fewer are primed for the esoterics of software, know the basics, or have positive rewarding experiences tinkering and tweaking. Humanity has been shoved into superficial & coopted/dishonest experiences. Heck yes, a lot of things are against the possibility of the good.

But we unlike almost all other relationships with the material world, we can directly improve things, can keep enhancing things practically without material constraint, limited chiefly by imagination & will (ML excepted I guess). We can grow the pot, open up computing & it's softer side progressively, create better on ramps & more learnable, observable, experience able authentic experiences.

Over time I hope the barriers to being interested might be less severe. The other material conditions dragging people down & shutting them off from engagement might persist. But I think there can be a very tangible source of hope here, a demonstration that people, when they are doing their thing, creating as they might, when they are empowered, are cool. Are good. Are a role model. And that - with hope - will keep us iterating & improving, will hopefully lead to more efforts to keep redefining & expanding general purpose computing & soft systems in less deeply technical terms.

I have a really strong reaction against projecting the users of today & their sorry chained-to-the-cave-wall state to what people might be if there were some honest shakes out there. Open source is far from a perfect liberator today, 100%, but this is part of the journey, is part of why we need to be practicing & trying, so we can create & iterate towards alive interesting systems that welcome people in.

By extendable, I mean doing things like generating and sending emails, and using plugins to integrate with external services. By fun, I mean non-enterprisey, something that one would WANT to engage in as a hobby and that a total novice can pick up and gradually learn. Something you can engage in with friends.

I know that there are things that meet the extendable part of the equation, its the fun hobby part that I don't think has been cracked yet.

I think a big part of why I became a coder is because I enjoyed playing with Microsoft Access as a kid - but I'm a weird nerd, so I don't think that'll cut it for others.

I think the only point of disagreement we might have is that I don't necessarily think that the speadsheet, even an improved one, is the best graphical model/structure for articulating complex processes, but it seems to be the best we've discovered thus far.

I actually do agree with you on that, as you say its just the best we've discovered so far. But if there is a better model which is as versatile and easy to use, I'm totally open to it.

At my first job out of uni, a telco had a 25+ sheets spreadsheet each with 1000s of rows and accompanied by some normie VBA scripts , to basically power optical network allocations …

I was amazed and terrified when I first saw it. Absolutely no source control.

Speaking of spreadsheets, is there a spreadsheet with built in source control?

I've actually seen it happen using exactly that.

A (non-tech) person trying to write an inventory management software for their company (which is highly regulated and inspected) using Google AppSheets.

No amount of "don't" was enough to convince them... 6 months and much of their sanity later they gave up.

Now there's an expectation for things to be web-based and the entry point feels less obvious than it used to be.

Google docs has a pretty neat JavaScript api that can be used from inside the apps themselves too.

Call me a skeptic, but i remain very unconvinced that LLMs will be the enabling tool that lets non programmers program.

Maybe Lua[1] and Excel. Python's significant whitespace is unsuitable for doing the one-liners that spreadsheet experts do.

Writing code for the spreadsheet should not require putting that code in a separate file just so the significant whitespace can be maintained.

Whatever you write in a single cell should be the programming language. If you later want to move it to it's own file, module, package, CLI, etc, you should be able to.

[1] Visual Basic turned out to be very usable with spreadsheet experts.

While sql (or say microsoft access) could be seen as an intermediary, i don't really think it is. It is very specialized to specific applications, and arguably rdbms are more complex than basic python.

It is no wonder that the software that is used by a large number of people is talked about more than software that is only used by a handful. Home-Cooked Software already exists, it is just not as easy to see.

- Find any cool tool online, download it, use it locally. Your data is persisted to your own local machine and your own personal cloud.

- Visit any website, download it as your own, modify it. Host it as your own and continue to add to it online.

- Browser vendors implement user accounts & hosting into the browser, so anyone can make a working app locally with a little bit of HTML and serve it to the whole internet with the press of a button.

- If your app takes off and goes viral, part of the economic value provided flows back to you through micropayments.

Basically: portable HTML "objects" that can be treated as mutable apps instead of only static documents = like GitHub + Codepen + Vercel + NoCode in one neat little package.

The web ecosystem already provides the substrate necessary to realize these visions, it's a matter of building things with a particular perspective in mind; a rejection of centralized infrastructure which is in many cases simply not needed.

1) http://beyondloom.com/decker/

2) https://en.wikipedia.org/wiki/TiddlyWiki

Obviously this is much harder given how much more server side the modern internet is. But i think the more fundamental problem is that 99% of users dudn't want this in the past and still dont really want this.

Key quote:

> Much of the success of the computer industry depends on developing a class of users other than trained computer specialists

I believe COBOL had similar aspirations to be language for non-professional developers. One of the first high-level languages were called autocodes because they automated code generation. Sound familiar?

The difference between compiler and ML model is not that great from high level. Both take human-readable(/writable) input and produce machine-executable code in the end.

Huge amounts of SW engineering has been already automated and delegated. Consider how much effort setting up a CRUD application would be if you were writing machine code on bare metal system compared to writing high-level language and leveraging stuff like Linux and PostgreSQL.

Words can't describe how happy I would be if that wasn't the case, but it's better to walk than curse the road. Changing this would require pretty much everybody on the planet to re-evaluate how they interact with a computer, and I'm not holding out on that.

if someone is too lazy to find some python library to import, but driven enough to come up with an unambiguous way of telling a model to do something in natural language, that's a borderline non-existent demographic

really it's kind of baffling to me, some people just hear "code" and think we're talking about some undecipherable thing like the Voynich manuscript. makes me feel like the guy out of the Zen and Motorcycle maintenance book who was confused why his friend refused to figure out how to fix his own bike. some people just refuse to learn. if they wanted to, they would have already

I don't think this is true. No-code software development solutions have existed for a while now and we have not seen a rapid increase in software being built.

Technical people who are non-programmers are not interested in having power over computers at all. They want to get their work done. And if doing this work requires too much work, they'll give up on the task than learn the thing.

They claim that large companies can never support the long tail since it’s too expensive to produce those features.

But they also claim that cost of software production is going to fall dramatically such that people can build their own apps for small user-bases.

I don’t mean to sound negative, since I love the picture painted by Local First, but I don’t think it will work out that way.

Im that guy.

She is way off the mark on some trivial points in there and they are easy to overlook.

Right now the big players are pouring money into hardware. There is a lot of talent out on the street. If they aren't resting and vesting in those orgs what are they going to do?

It's possible for a small team to bootstrap with ZERO money.

How much do you need to earn enough to support 3 devs? Apple only takes 15% if you make less than a million a year. Is that a staff of 3? They only take 15 percent of subscriptions!!! That dosen't include android.

If you dont piss away money on on cloud (vps), on everything as a service (login, metrics) the economics are amazing.

There's room in the market for 1000 founders who do very well, you wont be google but you can live a more than comfortable life.

The app stores by their nature don't actually let people into computing. They are the sad old pre-connected paradigm, entrenching top down systems control.

What Maggie is tapping into is more than the 15/30% cut. It's about possibility & connection, about software we have power over & can shape & share. The software we have today is all dead software, delivered to us on a platter, and that dead modality is not befitting the greatness humanity can & should be tapping into.

Local First is inherently not bound, not fixed into interaction with the golems created by far off others. It allows more. It allows soul. That earnest engage-ability is something that's been missing from the consumerized world, has created enormous disbelief & disdain in a place where hope & possibility once sprung freely.

http://malleable.systems now!

----

Regarding whether users will or not? Local First has a set of first principles to keep us from being too bound by software. The particular tools we have at any given point are arbitrary, secondary.

Who knows what would happen if we did have the capabilities, because right now we don't have the capabilities. Yes, Local First is about bootstrapping something new. No it doesn't create the barefoot developers automatically, doesn't make that imminent. But it makes it possible. And some will convert in, some will start being barefoot developers as it becomes possible. If & only if we make it possible. The cynicism about those who won't or the state of our tools is not yet due.

This is where She's being way too optimistic.

What we have now is software that looks like macdonalds.

She thinks the tools we have are going to enable home cooking. Software is way harder than that.

The step between is "local" restaurants. You dont need to build software for 8 billion people, or 300 million Americans. You can build for a region, or a niche group.

> It allows more. It allows soul.

You might not be old enough to remember zine's but they were a thing. We're about to have the software equivalent.

What we have now is often software that looks like a food hall: it has to contain all the features that anyone interested in some general area of functionality might want.

She thinks that sometimes it's going to be good to just cook up a Thai meal because that's all you actually need/want right now.

The only note I have is that I don't think it's really accurate to say this approach wasn't possible in 2004. I was a working web dev in 2004, and from that perspective, what we did was pretty close to what the talk describes.

Intermediated by commerce, certainly; as I recall having put it one day in that same job after hanging up a call wherein had occasioned a request that $400 a month of backhaul be provided free of charge, it's nice there's folks out there trying to save the world, but some of us have to earn a living. ("You said you were a web dev. Why were you talking to anyone about backhaul?" I pulled cable too sometimes, in those days. The mid-00s were a different time.)

And of course there were no LLMs involved, that technology then still being much the stuff of science fiction and allied fields like futurism. Even so, though: none of us had any real idea what we were doing, but we knew how to figure out what worked and what didn't, and that was usually enough even if the level of trial and error, and the lack of rigor, were shocking by today's standards. (I wrote my first SPA, a triathlon registration system for an org that lots of folks in the DMV might recall if I mentioned a name, in 2011. Imagine my surprise when two years later, on leaving my local backwater of web dev for the mainstream, I discovered that was what I had done, when I thought I'd just been trying a wild idea I was sure would fail, because it was that or lose the contract that was keeping the business afloat...)

Honestly, the vision described in this talk is a lot more like the kind of life I thought I'd live, when I got into this line around the turn of the millennium. It'd be easy to take an overly rosy view, and maybe I am. But then too, it'd be good if not every quarter-square-mile neighborhoodlet in my city had an intimate dependency on Amazon in order to function, too.

I don't really like the term barefoot developers, but local craftsman should own and understand the tools they work with and the code they write. Their tools should be local first as well.

I also don't understand why you'd consider LLMs as a blocker to local-only. You can run a 7B model on a $600 refurbished M1 Mac mini today. It won't be the fastest or the cleverest, and you probably will need an hour or so from someone who knows how to set up Ollama and Open WebUI, but it is absolutely usable after that with no Internet connection at all - I have a Mac mini so configured on my desk right now, actually. Or for an order of magnitude more outlay, you can get a Studio capable of supporting multiple concurrent users with 70B models producing tokens faster than you can read them. Again, sure, it won't be GPT-4o, and it won't be up to the standard of the sorts of tools described in the talk - not this year, anyway. In 2026 or 2027, though? Again, this talk looks to a possible future, not just today. And with a setup based on open models running locally as I've described, there is the countervailing advantage that once you have it, you own it.

As for the term 'barefoot developer' itself - it's a cavil, I grant, but I still want to quibble, because as a child in rural Mississippi with an Apple IIc and a couple of books, I was a barefoot developer, writing my own programs to solve my own problems, and often enough going to play in the woods by the road cut when I got stuck. (It helped! These days I'm more likely to chase wasps with a camera, but it still helps, when I can force the time. For what it's worth, though, I do wear shoes these days.)

Now I'm what Amazon would call an L5, earning as highly as almost anyone in this generation of my family - and not for a lot of student debt, because I never went to college. Whatever I am as a professional, I am in large part because I've been discovering and developing my craft since my single-digit days - and was free to do so without my parents having to pay anyone a damned subscription, besides.

True, the technology has grown far away from the kind of locally and individually empowering model this talk describes, and that I recall from my own childhood and early career days - that proto-SPA I mentioned nearby, for example, was hosted on a machine that everyone who ever worked on it could physically touch without leaving the office we all shared. And this in 2011! It really has not been that long a time since a model very much like what this talk describes was actually present in reality.

I see no reason in principle why that can't be true again. Certainly I'm convinced that it should.

Anything LLM can do locally, you can do it better with another, less demanding tool. And what they help with, it would be faster to just learn how to do it.

Again, there's nothing new in this; in fact it's much the way things were when 8-bit micros and BASIC were about as fancy as most ever saw, yet anyone who ever saw a computer could hardly help but see them. Maybe you'd learn to use those tools and maybe you wouldn't, but you knew they were there for you and the assumption was that you could learn enough to use them. More did than I think a lot of folks in their 20s today easily imagine. I don't blame them; if all I'd ever seen was how things are now, I'm sure I'd be the same. But people made things the way they are now. People can make them otherwise.

There's also no assumption in the talk that everyone involved is a loner, an atomized individual, the way you seem to assume would be true. Indeed, quite the contrary: community, in word and in concept, suffuses the text in its entirety, to such an extent it seems surprising its constant immanence could be overlooked even on a brief skim.

Admittedly, that's a difficult concept for many to fathom in 2020s America. I'm certainly among that number. But I'm also old enough to remember when things were better, and young enough still to imagine a future where things are better again. I just hope I'm not too old to still make myself useful by the time they start to be.

Using the command line isn't more complex, it's differently complex. It's differently complex and writ large, schools make no effort to teach it.

Don’t believe me? Look at the “Linux porn” and “ricer” communities on Reddit, who go out of their way to make their systems look as “TUI cool” as possible, complete with customized tiling WMs. Most of the people doing this do it because they’re going for the “l33t h4x0r” vibes.

As well as being a professional developer, I also do these local first types of apps, so I expect once the AI tools become good enough, we will be the first to figure out how to use them.

A simple explanation is that the devil is in the details when it comes to implementation. Edge cases and granular behavior are hard to capture except in granular snippets of code. I'm not convinced that LLMs necessarily solve this problem. Even if you are working with a theoretically quite competent LLM, there are still going to be instances where describing what you want is actually challenging, to the point where it would be easier if you just did it yourself. You could argue that this doesn't matter in the case of simple software, but I think we underestimate what people really expect out of something that's "simple", and I think we underestimate people's tendency to grow bored of old toys, especially if they don't work as expected.

If anything, my belief is that LLMs by themselves aren't necessarily going to make this a reality. You need an accessible and empowering UX/UI to go along with it. Otherwise, asking an LLM to build software for you probably won't be much of a fun experience aside from those who are AI enthusiasts foremost.

Side note, I have painful feelings about so many UX researchers I used to admire jumping on board the AI hype train so uncritically. I kind of get it, their job is to speculate on new possibilities a tech offers without getting too hung up on external complications. Still, I feel disillusioned. It seems that prior to all of this these same people were questioning our implicit assumptions with how we interact with computers in really interesting ways (in the same vein as Bret Victor). Now, their takes are starting to converge with that of the usual anonymous midwit AI enthusiast on Twitter who pivoted from crypto.

Put more bluntly, the idea that LLMs will usher in a golden age of people making simple software is kind of a boring speculative future, a speculative future shared and talked about by the most uninspired and boring people on Twitter.

Any automation will introduce complexity. There's no free simplicity lying around. We all need to take low entropy energy sources and dissipate it to get work done. If you don't want to reap barley by hand, you need an entire supply chain for machinery. The complexity can be hidden, you can pay people off to deal with it. But someone will have to manage it.

People wanna buy machinery and have technical support. They don't want to build machinery and maintain it. People want working software, they don't want to design, build and maintain it. That complexity never goes away.

Yeah exactly. I've seen meetings between engineers get into a level of technical specificity where I've had the thought "we are just coding in english now."

Even if you're able to communicate your intent with natural language rather than a "programming language," you still arrive at a level of concrete detail that is difficult or impossible to describe without some sort of standard technical shorthand or jargon. This is true whether the "listener" is an LLM, some other sophisticated machine interpreter, or just another person.

It's made me realize that it's usually the rule that intent at least feels easier to convey through code rather than through natural language. This is especially true if I'm trying to perform some complex mathematical task that's geometric in nature. Put another way, it's probably easier to understand how poisson disc sampling works if you saw the code for it, vs if you read the actual paper, especially if the code had comments providing additional context for different blocks of code. Doesn't help that the paper uses complex mathematical terminology, whereas the code, at worst, might have very terse variable names

And yet, I think a better example might be found in markup languages like HTML. Trying to convey the layout of a webpage using ONLY natural language seems really hard compared to using a markup language.

But I think local-first will be of the biggest benefit to small teams of professional developers who can see local opportunities bigger corporations are missing. At least in the short term.

There are barefoot developers too, but it's not as simple as professional vs barefoot — there's a spectrum of app developers, each with their own economic rationale.

Where contributing is using OSS, commenting on it, sharing work done with OSS tools with others, filling in bug requests and maybe even paying something for it.

Working with tools and sharing work done with tools is important because everyone is using photoshop instead of Gimp, everyone is using Excel instead of libre office.

Right now AI is mostly controlled by mega corps abusing copyright laws because they can get away with it. I seriously doubt this is going to drastically change.

Basically, I don’t understand this authors cute, homely portrayal of AI.

The bigger limiter is the missing culture of deliberately small and individualized software to specific people, families, or small communities. That’s the mindset Maggie is trying to espouse. Then, you can carve that space into closed vs open source, free vs paid, etc.

But Excel and Notion aren’t open source and people have gotten really good at using them for these home cooked meals.

Sure, now a days there are lots of big professional projects, but the core of open source/Free software, is people making stuff for themselves and their neighbours.

Linux didn't start with the goal of taking over the world. It started as one guy's amateur project.

You know there is libre office, there are tons of other OSS apps - accounting, CAD, image manipulation.

Whole idea that people somehow need to be developers is crooked and making it worse. There are tons of already useful local first software rotting out there - only because „everyone uses Photoshop” „everyone uses Excel”.

I don’t agree with „barefoot developers” - it should be „OSS promoters” that promote open standards and open applications and not come build up each and every piece of software by reinventing the wheel.

I as a developer don’t need to make every app for myself - 99% of my needs for software in personal life is covered by excel and 1% is communication apps that cannot be local and someone has to run server anyway.

You can build something amazing like Immich, a shining example of open-source software that, after a lot of setup, "just works"....until the next release wants you to make well-informed decisions to your `docker-compose.yaml` file.

My wife, who likes Immich but has no interest in learning to code, is not going to do those things if I get hit by a bus, because she won't know how. She's gonna give up and just go with paying some service for photo storage, or else losing photos like everyone else.

But I much prefer to host something locally and give my family access than letting them suffer the whims of big tech.

I’m not an engineer, but I've written more code this year than ever. LLMs have helped me tackle a huge backlog of projects at home that I wouldn't have been able to justify starting before. And I know 3-5 others doing similarly (we have a group chat).

Off the top of my head, this year I’ve made:

- webscrapers

- notification agents

- websites

- data manipulation and charting

- IaC devops for my entire homelab

- an RPG (well, a roguelike)

- applets for OBS

- chrome extensions to glue together a bunch of stuff I do to study Japanese

I’ve written projects in languages I’ve never used like rust and elixir, and learned a ton. Am I gonna switch ladders to be a SWE? Nope, but for better or worse have stopped asking my SWE friends for help.

And lately, between RAG and large context models, it’s much easier to improve existing projects. Typing, refactoring, linting, documentation generation, and GitHub ops are now practically effortless.

We forwent this in favor of getting that consoomer dollar. We gave the user ever more elaborate premade applications, which is nice; meanwhile, programming environments went from the default mode of interaction with the machine to expensive add-ins (thinking of early Windows with Visual Basic and ToolBook). HyperCard was free on the Mac, but didn't keep pace with the machine's expanding capabilities. QBasic was perfect for the DOS environment, but it didn't really transition to Windows except as Visual Basic, which again was an expensive add-on. Speaking of, even the RAD tools of yesteryear are largely gone. We have open-source dev environments now, but they aren't approachable the way microcomputer BASIC was. Getting someone set up with Node or even Rails requires command-line jiggery-pokery and installing all sorts of dependencies, just to get started.

And now, we're somehow hoping that a somewhat cleverer Dissociated Press is going to bring back citizen programmers? Fuck no. If we want end users to program their own apps, we have to find our way out of the shit we created, not add new layers of shit to deal with the old layers. The pathway to citizen programmers is making programming accessible, with full capabilities available, with documentation, right from the jump. No toy languages (e.g. Small Basic). Kids should be able to write turtle-drawing programs with the same language/environment adults use to build real-world applications.

We forwent this in favor of empowering the huge number of people who didn't want to program, who just wanted to use the computer to be able to do (nonprogramming) things.