"The specification language gets more precise over time, because natural language is ambiguous and different models interpret the same prompt differently. You add more structure. You define exact function signatures. You specify return types. You nail down error handling behavior with enough precision that two different models should produce interchangeable output. The specification starts looking less like English prose and more like a programming language."

https://nesbitt.io/2026/01/30/will-ai-make-package-managers-redundant.html

Will AI Make Package Managers Redundant?

Following the prompt registry idea to its logical conclusion.

Andrew Nesbitt
This is obviously a thought experiment but I can genuinely see a lot of these spec driven projects going this way, at some point you're trying to do something that would have been easier just using an existing high level programming language.
Which might be an indictment of how badly we've taught these programming languages tbh lol.
Honestly I think there is a lot to this, when I see some of the guides to using LLMs for folk without coding skills I think I could more easily just teach them to code. The mystification of coding is also a huge part of the appeal of this stuff for lots of people.
Part of what makes me think this is that teaching folk to build using LLMs means they'd get inconsistent results to their inputs, which would be a disastrous situation when learning to code, you can't build a foundation skillset without seeing consistent results for the same actions.
@sue indeed. It gets even more 'fun' when one uses a cloud based model and a self-updating coding harness - I had one update to a major new model while preparing a demo. I could turn back the model version, but not (easily) the coding harness.
I'm discussing with @emilybache and others about this. One exercise could be to build a small coding agent, using a local model. This removes some of the mystery.
I'm playing with a small bit of messy code, and a tiny agent. find smells, do refactoring.
@mostalive @emilybache This sounds really interesting!
@sue This was on the samman discord (I am a guest there, I've been on it for a while). Since you and someone on LinkedIn responded, I might develop this in the open and make a mini-series of blogposts about it . It is easier to be coherent on my own with code than in writing though ;-) might take a while.
@emilybache
@mostalive @sue I think building your own coding agent seems like a great project to understand what they do. To also gain control of a coding environment for exercises - that's a good idea too.
@emilybache @mostalive Myself, @anthrocypher and Ray Myers (who I don't think is on masto) used an agent making exercise recently to test Ana's theory that introducing human pair programming into learning / building with LLMs shifts the dynamic in a healthier direction

@sue it reminds of when when I learned to code for the web - tools like Frontpage and Dreamweaver made it "easy", but I never for a moment thought what was produced was ready for anything serious.

I love to see the excitement for what it's like to create a working application. But I don't know where the confidence to publish it publicly is coming from.

@sue partially this is due to our tools being atrocious at being learnable.

Like, I am sorry, but how the heck did we need decades to come up with the idea of a multiline error message... Or simply, searching for people not understanding error message and then trying to fix it. And yet, it took Rust to make it something we *start* to do at large. (It existed in niches, but I mean that even GCC got *one* multiline error message now).

We simply have not considered the UX of our tools before. Partially due to lack of funding but also because well... Toxic masculinist culture of software I think

@Di4na Absolutely, there has been a ton of intentional gatekeeping at work, and now it's colliding with these tools promising to make those problems go away.

@sue yeah and they are... "smooth" about it. I keep pointing out that the main reason LLM suddenly work is that we stopped trying to train them to meet a banchmark or abstract construct goal. They all started training them only to be... "appreciated" and make the humans feel good.

They basically are the only tool in our suite that make you feel like you matter and are respected. Emphasize on "feel"

@sue @Di4na
I still recall going into my 1st code review after being transferred to a new group (at least I didn't get laid off 🙄) many, many years ago. The PRs were bug fixes and 90% of time spent was to reverse engineer the code to figure out what it was supposed to do. I got chided for "too many comments" that were also "too verbose". But no, delete those before we allow merge. Make the next sucker suffer like you did.
@sue +100 to this, except I think that learning to code has become more daunting than ever thanks to package managers, CI/CD, linting tools, etc. - I've been doing this a while, and I find lists like https://willigottstein.medium.com/from-good-code-to-reliable-software-a-practical-guide-to-production-ready-python-packages-aa881c2c31e9 intimidating. (Type hints in Python? Whatever happened to the friendly, approachable little language I once knew?)
From Good Code to Reliable Software: A Practical Guide to Production-Ready Python Packages

Most of us have written Python that worked beautifully — right up until someone else tried to install it, run it on a different machine or…

Medium
@gvwilson It definitely has, you can't even make a simple website without a "build" process etc, we've overcomplicated the fuck out of everything and now those patterns are baked into LLM output.
@gvwilson @sue That "friendly, approachable little language" is long gone. Nobody's going to get a promotion for solving a problem with a simple function and a dict.
@gvwilson @sue I can download Thonny IDE and start interactively learning Python right away. The tasks in that post have always been required to produce production ready code for distribution, but none of them are required to learn to code.

@gvwilson @sue It's still there. Nobody's forcing you to type-hint your throwaway Python scripts.

That said, I now add them in my throwaway scripts, even when I'll never use them for static analysis, because they are a higher bitrate communication channel to my future self than docstrings for the specific information they convey.

@dwf @gvwilson @sue it feels wrong to not use type hints. Definitely better readability and more useful error messages.
@Frantasaur @dwf @sue better readability _for who_, and do you have evidence to back that up? the studies I've seen about the impact of strong typing on code comprehension weren't particularly compelling - if something stronger has been published since 2019, I'd be grateful for a pointer.
@gvwilson @dwf @sue better readability for me, of course. A method signature is a contract. If someone writes a function without type hints, it’s considerably less information on how the author expected others to use that function. Perhaps that author was just my past self, and I don’t remember exactly what I was thinking back then. This has personally saved me a lot of time, so I consider it basic common sense.

@gvwilson @Frantasaur If you assume

1. That parameters to a function ought to be documented,
2. That the natural language documentation of that parameter should contain information as to its expected/allowed type(s), at least if not available as a formal annotation,
3. That any study comparing comprehension (for experienced users) would start from a null hypothesis of "no difference",

then I'd think that the ability to use one and not the other as input to static analysis tools would already break the tie.

@dwf @gvwilson wait, do you not know what type hints are? We aren’t talking about natural language comments.
Type Hints in Python - GeeksforGeeks

Your All-in-One Learning Portal: GeeksforGeeks is a comprehensive educational platform that empowers learners across domains-spanning computer science and programming, school education, upskilling, commerce, software tools, competitive exams, and more.

GeeksforGeeks
@Frantasaur @gvwilson (not sure who you're addressing but I do and I'm sure Greg does, my comment was about the relative merits of using type hints/annotations as an additional form of documentation, versus presumably communicating that same information in the docstring instead)
@dwf @gvwilson ah, yeh I see. The reference to natural language threw me, should have reread the whole thread again before responding 😅

@sue There is a similar issue to this on the output side, where we are now seeing guidance on how to “tidy up” substandard GenAI output, which – if done well and applied consistently – takes significantly longer than creating the output yourself, once you have learned the necessary research and writing skills.

One of the things I’m telling my students to try to dissuade them from using GenAI for their assignments, is that “the math just isn’t mathing” and likely never will.

@sue interesting thought experiment, and thank you for sharing @andrewnez ' writing. I wish we could teach programming languages and their environments better, and at the same time I am not sure how much can be taught and what requires osmosis.
@sf105 called smalltalk an 'apprenticeship language'. I learnt smalltalk and miranda, a precursor of haskell, at uni, but for both production smalltalk and haskell I benefited from pairing with people who had been there before.
@sue or maybe *which* languages we taught? Because if the main teaching language was something like C++ I can imagine people thinking all languages were similarly complex and difficult and wanting nothing to do with programming.
@sue (forking the thread) indeed. I like the specific examples in that post. Models and their harnesses get better, more precise, but there are some things they can't do and my guess is that some of these things are fundamental (e.g. 2D graphics at the moment, but one of my researcher friends believes that will be solved, even thorugh theorem provers also struggle with that apparently). And thus easier, for some definition of easier, to express in a programming language.

@sue in the programmimg classes I took at the uni we were given techniques to derive a program from a description of the post state to a pre state. Most of the time describing the post condition (a description of the final state), or any rewrite needed to start using one or another derivation technique, was as much, if not even harder, than writing the code the usual way. At least you had a proof that the algo worked.

We currently simplify this in terms of unit tests.