lunar_mycroft

> That's your job.

No, that isn't. To quote your own blog, his job is to "deliver code [he's] proven to work", not to manage AI agents. The author has determined that managing AI agents is not an effective way to deliver code in the long term.

> you don't have the agent-managerial skills to tell the coding agents how to clean up the mess they made

The author has years of experience with AI assisted coding. Is there any way we can check to see if someone is actually skilled at using these tools besides whether they report/studies measure that they do better with them than without?

That's the theory. In practice, if your UI is changing a lot, the data your UI needs is also changing a lot, meaning that your data API will either have a lot of churn or you'll allow a lot of flexibility in how untrusted clients can use it, which introduces it's own pile of issues.

> Behavior does not need to be fully specified at the outset. It could be evaluated after the run.

This doesn't work when the software in question is written by competent humans, let alone the sort of random process you describe. A run of the software only tells you the behavior of the software for a given input, it doesn't tell you all possible behaviors of the software. "I ran the code and the output looked good" is no where near sufficient.

> We've actually done this before in our own technology. We studied birds and their flight characteristics, and took lessons from that for airplane development.

There is a vast chasm between "bioinspiration is sometimes a good technique" and "genetic algorithms are a viable replacement for writing code".

For this to work, you'd have to fully specify the behavior of your program in the tests. Put another way, at that point your tests are the program. So the question is, which is a more convenient way to specify the behavior of a program: a traditional programming language, or tests written in that language. I think the answer should be fairly obvious.

There is no such thing as read only network access. For example, you might think that limiting the LLM to making HTTP GET requests would prevent it from exfiltrating data, but there's nothing at all to stop the attacker's server from receiving such data encoded in the URL. Even worse, attackers can exploit this vector to exfiltrate data even without explicit network permissions if the users client allow things like rendering markdown images.

As an aside, both those statements were wrong. People who learned to drive well after cars were widely adopted were at no particular disadvantage when and if they decided to adopt the technology. You can see this is true by noting that at this point, no one alive learned to drive when cars first came out.

> At the is point the best evidence we have is a large volume of extremely experienced programmers - like antirez - saying "this stuff is amazing for coding productivity".

The problem is that we know that developers' - including experienced developers' - subjective impressions of whether LLMs increase their productivity at all is unreliable and biased towards overestimation. Similarly, we know that previously the claims of massive productivity gains were false (no study reputable showed even a 50% improvement, let alone the 2x, 5x, 10x, etc that some were claiming, indicators of actual projects shipped were flat, etc). People have been making the same claims for years at this point, and every time when we actually were able to check, it turned out they were wrong. Further, while we can't check the productivity claims (yet) because that takes time, we can check other claims (e.g. the assertion that a model produces code that doesn't need to be reviewed by a human anymore), and those claims do turn out to be false.

> If you're determined to say "I refuse to accept appeal to authority here, I demand a solution to the measuring productivity problem first" then you're probably in for a long wait.

Maybe, but my point still stands. In the absence of actual measurement and evidence, claims of massive productivity gains do not win by default.

The core of your argument is that using LLMs is a skill that takes a significant amount of time to master. I'm not going to argue against that (although I have some doubts) because I think it's ultimately irrelevant. The question isn't "is prompting a skill that you'll need to be an effective software developer in the future" but "what other skills will you need to do so", and regardless of the answer you don't need to start adopting LLMs right away.

Maybe AI gets good enough at writing code that it's users' knowledge of computer science and software development becomes irrelevant. In that case, approximately everyone on this site is just screwed. We're all in the business of selling that specialized knowledge, and if it's no longer required then companies aren't going to pay us to operate the AI, they're going to pay PMs, middle managers, executives, etc. But even that won't be particularly workable long term, because all their customers will realize they no longer need to pay the companies for software either. In this world, the price of software goes to zero (and hosting likely gets significantly more commoditized than it is now). Any time you put into learning to use LLMs for software development doesn't help you keep making money selling software, and actually stops you from picking up a new career.

If, on the other hand, CS and software engineering knowledge is still needed, companies will have to keep/restart hiring or training new developers. In terms of experience using AI, it is impossible for anyone to have less experience than these new developers. We will, however, have much more experience and knowledge of the aforementioned non-LLM skills that we're assuming (in this scenario) are still necessary for the job. In this scenario you might be better off if you'd started learning to prompt a bit earlier, but you'll still be fine if you didn't.

> People seem to believe that there is a burden of proof. There is not. What do I care if you are on board?

The burden of proof rests on those making the positive claim. You say you don't care if others get on board, but a) clearly a lot of others do (case in point: the linked article) and b) a quick check of your posts in this very thread shows that you are indeed making positive claims about the merits of LLM assisted software development.

> If you can solve "measure programming productivity with data" you'll have cracked one of the hardest problems in our industry.

That doesn't mean that we have to accept claims that LLMs drastically increase productivity without good evidence (or in the presence of evidence to the contrary). If anything, it means the opposite.

In the past week, I saw Opus 4.5 (being used by someone else) implement "JWT based authentication" by appending the key, to a (fake) header and body. When asked to fix this, it switched to hashing the key (and nothing else), and appending the hash instead. The "signature" still did not depend on the body, meaning any attacker could trivially forge an arbitrary body, allowing them to e.g. impersonate any user they wanted to.

Do I think Opus 4.5 would always make that mistake? No. But it does indicate that the output of even SotA models needs careful review if the code actually matters.

Interestingly, things like domain name registrations and new github repositories didn't have the an inflection point in recent years [0]. This means it's almost certainly that a greater portion of new projects are getting submitted as Show HN, not that there's more new projects overall.

[0] https://mikelovesrobots.substack.com/p/wheres-the-shovelware...

As others has already been pointed out, not all new technologies that are proposed are improvements. You say you understand this, but the clear subtext of the analogy to compilers is that LLM driven development are a obvious improvement and if we don't adopt them we'll find ourselves in the same position as assembly programmers who refused to learn compiled languages.

> Is that what I’m doing?

Initially I'd have been reluctant to say yes, but this very comment is laced with assertions that we'd better all start adopting LLMs for coding or we're going to get left behind [0]

> taking the gcc analogy, in the early compiler days there was a period where compilers were weak enough that assembly by hand was reasonable. Now it would be just highly inefficient and underperformant to do that

No matter how good LLMs get at translating english into programs, they will still be limited by the fact that their input (natural language) isn't a programming language. This doesn't mean it can't get way better, but it's always going to have some of the same downsides of collaborating with another programmer.

[0] This is another red flag I would hope programmers would have learned to recognize. Good technology doesn't need to try to threaten people into adopting it.

> It's like the articles point: we don't do assembly anymore and no one considers gcc to be controversial and no one today says "if you think gcc is fun I will never understand you, real programming is assembly, that's the fun part"

The compiler reliably and deterministically produces code that does exactly what you specified in the source code. In most cases, the code it produces is also as fast/faster than hand written assembly. The same can't be said for LLMs, for the simple reason that English (and other natural languages) is not a programming language. You can't compile English (and shouldn't want to, as Dijkstra correctly pointed out) because it's ambiguous. All you can do is "commission" another

> Do you resent folks like us that do find it fun?

For enjoying it on your own time? No. But for hyping up the technology well beyond it's actual merits, antagonizing people who point out it's shortcomings, and subjecting the rest of us to worse code? Yeah, I hold that against the LLM fans.

The following was originally at the start of your comment:

> Here’s the same text with all em dashes removed and the flow adjusted accordingly:

Did you have an LLM write your comment then remove the evidence?

Except in context that was very much what was suggested. The implication of the comment I replied to is that there actually are "a ton of 1 person startups" (and by implication, that LLMs do enable the massive increases in productivity that their proponents like to claim), but that they just keep the fact that they are quiet.

You have to manually write that out either way. In the SPA/reactive paradigm, you have to specify that multiple parts of the UI depend on the same part of the state, vs sending down those multiple parts of the UI from the backend.

I'd also argue that if you look at the interactions on web apps, you'll find the number of cases where you would actually need an OOB swap is more limited than you might be thinking.

This isn't just a hypothetical. I have written apps both ways, including porting a few from a SPA framework to a hypermedia based solution. It allowed me to sidestep several major sources of complexity.

> Can't speak for anyone else, but I personally know 3.

I'm not saying your three friends/acquaintances don't exist, I'm saying the evidence suggests they aren't representative of a trend. This is consistent with the other evidence we have (e.g. studies which show that LLMs produce at best relatively modest gains in productivity, not enough for a one person team to do the work of even two people.

> I'd also point out that 2025 was a particularly volatile year because of shifts in the political and economic environment so I wouldn't take your stat at face value without considering external factors that might affect the total number of net new business registrations.

Sure, it's always possible that without LLMs there would have been a significant contraction in these metrics. The issue is exactly that though: you can always make that argument. In other words, you've rendered your claims unfalsifiable.

> If you display mutable derivations of the server-side state in more than one place on the client, you're synchronizing it.

Again, this is the XY problem. Your actual requirement isn't "display mutable derivations of the server-side state in more than one place on the client", it's "update two parts of the DOM in response to user action". You can usually accomplish this with HTMX just fine by either using out of band swaps or swapping out a mutual parent element, depending on your actual needs. You can think of this as state synchronization if you really want to, but it's meaningfully different and significantly easier. Your frontend state isn't a synchronized partial copy of the backend state requiring custom software to manage, it's a projection from that state with embedded possible transitions/mutations.

> If you're not displaying mutable derivations of server-side state in more than one place on the client, then you don't need HTMX.

Even if you think HTMX isn't a good solution and limiting ourselves to swapping out a single element, it very clearly enables a lot of behavior that just isn't possible with standard HTML hypermedia controls (links and forms). Things like active search, infinite scroll, etc. cannot be done with vanila HTML, because you can only trigger HTTP requests with a small subset of events, and if you do trigger one you must replace the entire page.

[0] https://htmx.org/docs/#oob_swaps

For the vast majority of web apps (including the ones that are built with SPA frameworks now), "how do I do distributed state synchronization" is an example of the XY problem. Most of the time, you don't actually need to write an entire separate app that understands your domain and synchronizes state with the backend, you need something that allows your users to trigger network requests and for the HTML displayed to them to be updated based on the response. Hypermedia is fully capable of solving that problem, completely sidestepping the need to solve the sort of state synchronization problem you mention.

As of the middle of the year, there was no increase in publicly available indicators of new startups at all [0]. No change in the trend in steam releases, domain name registrations, app store releases, etc. People might be able to keep the fact that they're a one person team that built the app with AI secret, but they wouldn't be able to keep the fact that they made an app secret. Unless someone has evidence that's changed dramatically in the last six months, I have to conclude that the reason we aren't seeing a wave of AI enabled SaaS startups isn't that they're keeping the fact that they're solo operations with AI a secret, but rather that no such wave actually exists.

[0] https://mikelovesrobots.substack.com/p/wheres-the-shovelware...

> Thus far, we do have evidence that AI (at least in OSS) produces a 19% decrease in productivity

I generally agree with you, but I'd be remiss if I didn't point out that it's plausible that the slow down observed in the METR study was at least partially due to the subjects lack of experience with LLMs. Someone with more experience performed the same experiment on themselves, and couldn't find a significant difference between using LLMs and not [0]. I think the more important point here is that programmers subjective assessment of how much LLMs help them is not reliable, and biased towards the LLMs.

[0] https://mikelovesrobots.substack.com/p/wheres-the-shovelware...

So Anthropic had to pay less than 1% of their valuation despite approximately their entire business being dependent on this and similar piracy. I somehow doubt their takeaway from that is "let's avoid doing that again".

A risk I see with this approach is that when the bubble pops, you'll be left dependent on a bunch of tools which you don't know how to maintain or replace on your own, and won't have/be able to afford access to LLMs to do it for you.

Every single point you made is contradicted by the observed behavior of the AI labs. If any of those factors were going to stop them from training on data they legally can't, they would have done so already.

That fits, except later on they say

> And now I'm preparing for my post-software career because that coworker is going to be me in a few years.

Which implies they anticipate their manager (or someone higher up in the company) to agree with them, presumably when considering overall effectiveness of the team.

For your answer to be correct for your employer, the added productivity from your use of LLMs must be at least as much as the productivity from whichever coworker you're having fired. No study I've seen claims much above a 20% increase in productivity, so either a) your productivity without LLMs was ~5x that of your coworkers, or b) you're making a mistake in your analysis (likely some combination of thinking about it from your perspective instead of your employers and overestimating how helpful LLMs are to you).

People do not have perfect foresight, and the ways open source software is used has significantly shifted in recent years. As a result, people reevaluating whether or not they want to participate.

> You refusing to write open source will do nothing to slow the development of AI models - there's plenty of other training data in the world.

There's also plenty of other open source contributors in the world.

> It will however reduce the positive impact your open source contributions have on the world to 0.

And it will reduce your negative impact through helping to train AI models to 0.

The value of your open source contributions to the ecosystem is roughly proportional to the value they provide to LLM makers as training data. Any argument you could make that one is negligible would also apply to the other, and vice versa.

Adding rust to the kernel makes sense. Porting a million lines of code per engineer month is insane, regardless of language (it works out to ~600ms per line total, including review, testing, etc). Anyone who heard about that expectation and thought it sounded good is the opposite of decent candidate.