I think for now the probability is limited by their requirement for high resource clouds. They have a limited number of targets. They tend to be targets with comparatively high security monitoring and people will notice if their resource usage suddenly jumps.
...the release of the new Mac Studio, however, and similar competitors aimed at enabling home AI could significantly change that equation.
This is the counter example to "protocols and interop solve enshittification". No, they don't. Email is the model protocol: perfectly interoperable, perfectly decentralizable. And yet it is centralizing in the hands of a few organizations who then wield enough market power to bend everyone else to their will. It's still enshittifying. If email hasn't resisted enshittification, then interoperable protocols are not the solution for it. And yet, pretty much all of the pro-social, anti-enshittification effort in tech is being directed into protocols and interop.
I think most of this is correct, in spite of potentially being built on a bad assumption.
The assumption is that LLMs should be writing the code and human engineers reviewing and verifying the LLM output. And that this pushes the cost of producing down. And I fundamentally disagree with that.
Every time I ask LLMs to write code, even with Opus 4.8 (haven't tried it with Opus 5 yet), what I get ends up being totally rewritten. LLMs still aren't good at writing maintainable code. Can they write plausibly functional code? Yes. But it won't survive the long term. People using LLMs to write all their code are gambling on them eventually getting to a point where the LLMs can fix their own code. It's possible, but I wouldn't necessarily bet on it.
Where I have found immense value from LLMs is in code review. Repeated review by LLMs catches an amazing amount of potential issues. They really shine on security review, but are very effective with any kind of review.
The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck. Understanding was. And understanding the code is still the bottleneck. But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing.
Most of the time previously spent writing was actually spent updating and deepening our understanding of the system under development. There's no replacement for that understanding in a world where LLMs are doing the writing.
But if you flip it: humans write, LLMs review, then you still get a major gain -- not in speed, but in quality. And you keep the understanding loop intact. I would propose that this might be the best way to deploy LLMs.
How do you handle the fact that an LLM can't seem to help itself from disgorging page after page of words no matter what it's asked to do? I've never seen an LLM say "this looks good as-is; I would not spend any more time on it; what's next?" it will always seem to suggest using another pattern or additional abstractions or other yak shaving.
But to be fair human code reviews have the same problem. It's like reviewers feel they have not done their job if they don't find something wrong.
I personally rely on this behavior of LLMs. For example, for reviewing prose, I might ask the LLM to find five issues. If there are obvious issues I missed, then it'll find them. But if all the issues it lists are minor or hallucinated, then I can have some confidence there weren't any glaring issues.
I do the same for LLM code review comments: some changes are out of scope or could be moved to a separate PR; some edge cases don't happen in practice and should just fail noisily instead of writing more code to maintain. When these are the only issues it's raising, then I know it's done.
I've totally had latest models just say "here are minor nits but this is good to ship" when reviewing code. Claude is a bit more verbose usually but Codex by default is pretty terse. My experience anyways. They also take pushback on suggestions (this isn't actually a problem because X) and they'll agree and say ship it (hopefully only when you're right and it's not a problem ;) ).
It is surprisingly hard to do in a single prompt. I’ve had good luck though with being very explicit about asking for review, then to think deeply about what actually matters, and then reduce to a very short extremely concise reply. —- the model NEEDS to output those pages of text as part of its thinking process. It’s used to doing it in the assistant reply but can be cajoled into doing it in the thinking tokens.
I've tried and tried to get an LLM to delete code, it couldn't do it. I knew a file was 40% bad so what I ended up doing was deleting the file, then asking AI to create the missing file. That's how I got AI to delete code :)
Yeah, that's just a problem with review. I tend to keep it going until the stuff its finding is stuff that I look at and think "I can live with that". Usually by that point it's found the worthwhile stuff and what remains is minor or, like you said, yak shaving.
There used to be a bit of "wisdom" passed around that said "when you submit something to the client (or management, etc) for approval, leave an obvious mistake somewhere." Then they will find it and point it out, you can easily correct it, and everyone is happy. Otherwise they will find something to critique, just to demonstrate that they contributed something to the review.
The verbosity itself seems to be a problem with post-4.6 Claude rather than a general issue with all LLMs. and IME the yak shaving is due to an overly generic prompt. We have a generic automated review bot but it’s prompted to only look for errors and never suggests refactoring; that was a conscious trade off to avoid what you’re talking about. If you’re reviewing interactively then you can give additional guidance about any code smells etc. that jump out
My guess would be that this is a matter of fine-tuning the model to the problem. You would need to run the review experiment N times, observe the distribution of answers, and then fine tune with model operational parameters.
Perhaps someone more knowledgable could jump in here to clarify?
What tools are you using? I've found that Codex will happily tell me there's nothing more to do after a few rounds of /review and fix (or sometimes, it picks up on low value points that are technically correct but not worth changing).
I’ve found stating “only call out critical issues, report but ignore everything else” will basically get what you want. Put that in a review skill and you’re good to go.
To be clear I mostly only use Opus and Gemini Flash but this might work for others too.
I think this is outdated. If you follow spec-driven development, get the model to do all the planning work upfront, review and iterate the plan, write clear markdown file documentation on the abstractions and patterns you want to follow, then you have every opportunity to tell the model how you want it to write the code. If you use Opus or Fable 5 it will then write the code better and faster than you will.
you're a lot more skilled than I am if you're able to know the abstractions and patterns you want while only have a weak grasp on the actual code. For me the abstractions emerge as I understand what I'm actually working with
> while only have a weak grasp on the actual code.
How much of a grasp does one need on the UEFI code operating their computer? The drivers that operate a hard drive? The communication protocols for their monitor?
This seems to me to be the fallacy — that all code must always be understood to operate properly or to be useful. If the AI is sufficiently intelligent enough to understand the code, at some point (most) people won’t need to. Not saying that’s now, but that is likely to be where things are headed in the long horizon. That said, I don’t have a crystal ball, nor do the people claiming that won’t be the outcome, so right now it seems more like people arguing about which forks should be used while the cake is still in the oven.
I think you can have some system design in mind upfront, but agree the bulk emerges as you code. Clean Code practices worked exactly this way in which you write and then rewrite the clean code.
I agree, but this works too because AI makes prototyping more rapid. It's common to be stuck with suboptimal solutions because of time constraints. Maybe the feature isn't really what the customer wants, or maybe the code isn't actually very good. But it reaches prod anyway.
But, with AI, the cost of code has gone down more than it already has. Well, cheap things are easy to throw away. So you prototype, prototype, prototype, and close the loop as much as possible with the customer. True agile development, not big A Agile.
The problem is this requires alignment from management, and we're just not seeing it at many company. They can't grasp that things have changed, and that throwing away code is free. They don't trust engineers to close that gap, so customers and stakeholders are still waaaaaay over there and we're delivering features they don't want.
IMO "get the model to do all the planning work upfront, review and iterate the plan" is backwards. It works better if you do an initial plan yourself and then have the AI review it (and iterate as necessary). Makes you think about the design for a bit so you can have a semblance of a mental model.
I have never seen a plan written by LLM that wasn’t vague and light on details, every time I need to ask for more details and every time I ask to implement it trips over some dead end in the plan, discards the plan and continues as if there was no plan to begin with. Planning feels often just narrating the request and a wish list then what a human would do - methodically build enough understanding so that you’re confident of the direction you choose.
LLM plans are overhyped and overrated.
This just doesn't match my experience writing idiomatic C code for embedded real-time systems with ChatGPT-5.5 and -5.6. Are Opus and Fable really that different? I general I find that a fully correct implementation for some function may take an hour and be nearly one-shot, but going from there to code I'd be willing to actually commit is at least 4x the time commitment with regular back-and-forth -- so four hours of deep engagement for every one hour of one-shot. ChatGPT-5.6 Sol seems to be better that -5.5 at the one hour do-it portion, but worse at the four hour do-it-well portion.
True, but I think people are also missing the trick behind markdowns that reference each other and are used for context window management. They go in your source control, they are reusable, extendable, and composable in the same way code is. So planning is not a one-off effort. It compounds over time. If you're doing it right your plan is referencing automation techniques - testing, CI/CD, etc. This further compounds so that the agents verify their own work against the standards that you set.
To be honest, the models are getting so good that they do most of this unprompted now.
Agreed, all of the staff/principal engineers I work with are ~99%+ AI generated code, and increasing business value delivered as a result. This is on planet scale infra not CRUD apps. (And yes, you do need to carefully review the output and give steers/corrections. It’s still faster.)
At this point if you can’t get the agent to write good code then either I) you are in a very specific niche (like Karpathy trying to write NanoGPT) that is extremely out-of-distribution, or II) skill issue, you need to learn how to prompt better.
It’s fine to have a skill gap! Just don’t delude yourself that the tools are bad and everyone claiming they are good is wrong.
> Agreed, all of the staff/principal engineers I work with are ~99%+ AI generated code, and increasing business value delivered as a result. This is on planet scale infra not CRUD apps.
This has been the pro-"write with LLMs" argument the whole time. "If you're not getting good results, you're not prompting well. FAANG are doing x% of their development with AI."
Yet all of the companies that I can think of that build on planet scale infra and have gone all in on LLM development have seen a marked drop in quality and stability since adopting LLM driven development.
So yeah, I don't buy it. When I hear that engineers are writing their with LLMs and I see quality improve or stabilize, then maybe I will start to question whether its a prompting issue.
How is a GPT implementation “extremely out of distribution” but “planet scale infra” isn’t? That’s got me totally confused about your point that I was taking seriously.
Go read Karpathy on this, his telling will be more nuanced than mine for the specific example. But the whole point of NanoGPT is that it’s distilling all of his wisdom and taste into a very dense and maximally educational version that fits on a single screen. It’s simply not something that has been done before in the corpus.
Planet scale infra often requires some novel ideas at the architectural layer (the engineers can input those) and then it’s mostly in-distribution C++ / Rust / Go; most of the hyperscalers open-source their stacks, for one. But for two, a ring buffer, look-aside cache, deterministic hash, b-tree, lsm-tree, etc. are all well-known patterns.
Hyperscaling is also often a very clear objective function; i need this code path to run in this many microseconds/nanoseconds, so i can hit the scale numbers I need. Claude/Sol can extract prod logs and build a representative micro-benchmark, and then hill-climb on it autonomously. Thats straight up the fairway for the training set, even if it often has a high bar for finishing and requires sophisticated Workflows or lots of tokens to explore the search space.
E2A: sorry sorry, typo, I meant microGPT. I can see why this would be confusing.
A lot of stuff that underpins planet-scale infra is open source and has been for a long time. The general approaches and architectures for it have also been widely discussed and litigated in the commons so it's not just the code - the specific why is also very well documented.
So despite its importance much of it is actually pretty in-distribution.
it's really cool how in the past measuring developer productivity was incredibly difficult, but now its become easy if someone's making a point about LLMs
LLm generation of code is an absurdly high dimensional process, and incredibly sensitive to the starting conditions and any other interactions so in some sense it's expected that there will be wildly different outcomes.
Personally, I'm more on the LLM code is pretty bad from a design point of view, particularly when much of the code is already LLM generated.
I write code in Go in an established codebase. 90% of the time the LLM gets a basic api/feature right and fully e2e tested as long as I give it enough business context in the prompt. The other 10% of the time I have to do some follow up prompts to either change the behaviour or change the approach of a given step in the flow or just to point out that the wrong pattern was used and please rather use our codebase standard. I haven’t actually hand-written code in well over a year. Is this way faster? Absolutely. Does it lead to better code? Yes, because I have time to write all the regression tests that keep the behaviour as I wanted it when others come bungling around.
I do think the comment is right about understanding. I'm still feeling out what I think is the right level of understanding to invest in now. I think it is probably not the deep line by line understanding I used to have of the systems I worked on. But I also think it's easy to remain too aloof from how the system is being built, and that this is very bad. I think the right answer is somewhere in between, but I'm still working through my own process and forcing functions to strike that balance properly.
> writing was never the bottleneck. Understanding was.
Well put. This insight is worth repeating in every discussion on the subject, from software engineering to mathematics.
The problem is that understanding is not the product being sold. The business model is for everyone to become consumers of what the magical genie generates, where the "understanding" is kept on the side of the model providers. This ensures a future generation of consumers dependent on someone else to provide the understanding.
Otherwise, you can create your own answers based on actually understanding the code, theorem, proofs, etc. Smart consumers of LLMs will use them to increase their own knowledge and understanding, so that the service is augmenting their intelligence, not replacing it.
I’ve found that doing the full requirements capture, planning, writing, reviewing, gardening loop with frontier models has worked quite well since last October, and phenomenally since Fable 5.
The key I’ve found is human peer review. The reviewer jumps on a live call with the developer, pulls up the PR with transcription on, and asks questions. At the end of the call, the transcript passes back into the coding agent and the PR is polished up, becoming more self-documenting, and the humans are left with some degree of common understanding of what’s going on.
I’ve been operating my team of ~15 this way for 9mo to great effect… there is simply no going back to the stone ages.
I have not experienced this "llms dont write maintainable code narrative" I just tell it the shape of the entities and apis I want vaguely and the mental model and the output is excellent.
A lot of people should try being more specific in their prompts, but then again at a certain point you're basically just writing all the code in sentence form!
I could do this in the beginning of 2025. Unfortunately, given the over-proactiveness of model these days, I find that they end up inferring what my original request was and implementing it anyway, and then writing unit tests, etc. even when all I asked for was to wire up a few components, as an example.
I actually find the converse, that I try to scope things down into chunks small enough for the model to work on, but it will start trying to hack off pieces that don't belong because it thinks the restricted scope is the whole world and I have to stop it and explain the bigger picture so it stops trying to remove things that serve the full scope.
For me, at least, the overall design needs to come from using the code.
I think for refactoring, you're definitely right as if you give them a good high level sketch you can get them to do all of the more tedious implementation.
> The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck. Understanding was. And understanding the code is still the bottleneck. But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing.
This was my stance a couple of years ago, but now I've given it up.
It turns out writing actually was the bottleneck. You can understand perfectly well what you want, but writing it is long and tedious to the point where you find excuses not to do it. Particularly with version 2, the step where you have an OK system and you want to improve it. Quite a lot of changing the code is just useless busywork: re-wiring old functions, moving imports around, searching for locations that benefit from extracting a common piece of code. And each time you do one of those, there's a decent chance you did something even more trivial like forgetting a semicolon or calling the wrong function.
Now that I have an LLM helping me, I can see why. The critical decision is a terse declarative like "we need to have several TCP connections instead of one, and just use the sequence number to arbitrate". A human junior programmer could perfectly well understand what this meant, but he would have to go through all of the above to get to the final product. Now, I can just tell the LLM and I will get what I want, even with the things I didn't explicitly state, without spending attention.
This means I can use my attention on the things that matter. So instead of spending today thinking about how to arbitrate between the TCP connections and tomorrow thinking about pre-calculating my outgoing orders, I can just do both today. I don't waste the good waking hours chasing minor bugs, I just think about the large structure.
I get the feeling the best programmers of years past were actually masters of the little things, which led them to be able to look at the big things. Essentially it was cheaper for them to get to the top of the mountain, where you can see the landscape. Kinda like how the kid who was good at mental arithmetic in primary school was also good at calculus at the end of high school: if you don't have to concentrate on the little things, you have time for the big things.
> And each time you do one of those, there's a decent chance you did something even more trivial like forgetting a semicolon or calling the wrong function.
how did you decide to pick the most trivial kind regression for this example? do you compile your code before checking it in?
> A human junior programmer could perfectly well understand what this meant, but he would have to go through all of the above to get to the final product. Now, I can just tell the LLM and I will get what I want, even with the things I didn't explicitly state, without spending attention.
the main efficiency you have described here is offloading the verification of a change onto the LLM. that is the bottleneck. readers can decide whether a non-deterministic statistical model is a good tool for this job
> I get the feeling the best programmers of years past were actually masters of the little things, which led them to be able to look at the big things
the best programmers understand that their job is to automate workflows, and that includes their own. if you're worried about missing a semicolon, I'm sorry to say that's a skill issue
> how did you decide to pick the most trivial kind regression for this example?
Why would this be a regression? You might just be writing a new line of code.
> do you compile your code before checking it in?
Well obviously. That is generally how you discover that a semicolon is missing.
> the main efficiency you have described here is offloading the verification of a change onto the LLM. that is the bottleneck. readers can decide whether a non-deterministic statistical model is a good tool for this job
No, it's the time between you deciding something needs to be done, and it being done, that is the bottleneck. You cannot avoid trying to compile the code and testing it. Now you can get to that test without paying attention, which is time you can use productively.
> readers can decide whether a non-deterministic statistical model is a good tool for this job
Somehow, the non-deterministic model has built me the deterministic code that I want, very fast, pretty much all the time. A year ago it would get stuck. Now it doesn't, for me at least, and for competent programmers that I know.
> the best programmers understand that their job is to automate workflows, and that includes their own. if you're worried about missing a semicolon, I'm sorry to say that's a skill issue
Well yeah, and I've automated my workflows completely. I don't have the problems I used to have. If you haven't caught on to the new way of working, well, that's a skill issue...
> Somehow, the non-deterministic model has built me the deterministic code that I want, very fast, pretty much all the time. A year ago it would get stuck. Now it doesn't, for me at least, and for competent programmers that I know.
I still find the models get stuck or go on _massive_ side quests. Just today, I asked claude to write a hello world C++ program using import std; I interrupted it when It decided I needed a new toolchain installed, and started checking for docker installations. This is super basic stuff, it hadn't even generated a plan, it just started searching for LLVM versions rather than running clang --version.
> If you haven't caught on to the new way of working, well, that's a skill issue...
Honestly, it feels like the emperor has no clothes on this topic, and the crowd defending LLMs to death are way too quick to call it a skill issue.
> Honestly, it feels like the emperor has no clothes on this topic, and the crowd defending LLMs to death are way too quick to call it a skill issue.
I feel it's the other way around. The LLM skeptics are unwilling to admit that these things can get you there faster than you would on your own, in the face of clear evidence.
> Well yeah, and I've automated my workflows completely. I don't have the problems I used to have. If you haven't caught on to the new way of working, well, that's a skill issue...
I use LLMs, but they're just a tool in the workflow, and I make sure to review the output. they might remember semicolons but they make much more pernicious mistakes that are harder to detect
But are those pernicious issues more common than what you would write yourself? Keeping in mind that you will get your LLM code back a lot sooner and have more time left over to check for them?
>It turns out writing actually was the bottleneck. You can understand perfectly well what you want, but writing it is long and tedious to the point where you find excuses not to do it.
Speak for yourself. Writing code has never been a bottleneck for some of us. I can't speak for everyone, and neither should you.
>Now, I can just tell the LLM and I will get what I want, even with the things I didn't explicitly state, without spending attention.
This should worry you. All too often the LLM invents things I didn't ask for and implements things I didn't need. YMMV, I guess. If slop gets the job done, and nobody notices, then who should care?
> Quite a lot of changing the code is just useless busywork: re-wiring old functions, moving imports around, searching for locations that benefit from extracting a common piece of code.
If other people are dissatisfied with LLM output quality while it seems to work fine for you, you might want to consider that the quality of code you produce is closer to the quality of code the LLM produces than what those other people are producing.
What you posted there, for example, about most of changing code being busy work is a pretty big red flag for a codebase. One of those "large structure" things that you're supposed to be paying attention to is the architecture of the code. There's always the chance that some change you need to do goes against the grain of the solution you architected, and you need to make changes all across your codebase to fit it in, but in general the point of modularity and good architecture is that when you make a change you just have to make that one change, ideally just changing the logic of the one responsible function with only minor changes required anywhere else in the codebase. If you're consistently having to hunt throughout the code for related functions that you need to rewire that's a sign that your architecture does not fit with the direction your codebase is evolving, or alternatively that you don't have much of an architecture to begin with and your code is highly interconnected.
Actually one habit you mention at the end of that quote can worsen this issue: "searching for locations that benefit from extracting a common piece of code". Tautologically this is a good thing as you define it as only working on locations that will benefit, but given the frequent need for rewiring of functions I would hazard to guess that you've "deduplicated" code a bit overzealously. Just because two functions share some common code does not necessarily mean it is appropriate to pull that out into a function. Deduplicating is good if conceptually the code is a single thing that you would always want to keep in sync, as it means that when you need to make a change to it you don't have to hunt down all the places it's used. On the other hand, if you find yourself frequently needing to delve in to these functions to rework them because you need to make a change to how it's used by just one caller, your "deduplication" has added to your workload, and probably created some overcomplicated code in the function that is in reality handling multiple distinct needs.
I hope this doesn't come across as too condescending, and if I've just wasted your time explaining principles you already understand I apologize. I don't know you or the code you're working on so I can't exactly confidently judge your work solely on a few paragraphs. It's just that your mention of how your experience of coding has been different from what others have described, and specifically that, for you, writing has been the bottleneck rather than understanding, combined with the specific issues you describe facing, imply to me that you may not realize that the approach you are taking to producing code yourself may be significantly different from how other Software Engineers are producing code, and that may account for some of the differences you note in your personal experiences programming.
I understand what you mean. Those are just some small examples. But I had this conversation with a friend today, and it goes something like this:
1) It was good for me to spend years learning the little stuff. Loops, variables, if conditions, how to import stuff, git, debugging things, reasoning about the flow of control. Classic coding.
2) I had a false dawn at about 10 years in. I thought I understood a lot.
3) I learned I had a lot to learn. Very wide areas of programming I'd never touched, ways of thinking that started to click.
4) I spent another ten years covering holes, building a different type of experience. My guesses about how to do a project are much better now. My guesses about what really matters have changed.
5) Now the small stuff is actually just bothering me. I'm not going to learn much more from staring at little things. There are larger architectural things to think about, and the little things are just friction.
So that's where I'm coming from. I get that a lot of pushback is going to be from 10-year-me, who thought he'd gotten to a high level of understanding by slogging through the little stuff.
" But understanding is truly gained during the writing loop. The understanding you gain from pure reading or code review is marginal compared to the understanding you gain while writing."
Debugging code step by step is how I understand complicated code.
This is where I've landed too, I imagine based off all the responses that it depends on domain and also the rigor you care about in your implementation. For me, what I do, and the quality required, there's just not much time (if any) saved on handing off the implementation to an LLM.
But that doesn't mean they're useless either. I use them all the time for review as you mentioned or to knock out one-off scripts that don't go anywhere near source control. There's just no world where I don't need to understand every line of code that I'm responsible for getting into our project.
In my domain since circa Opus 4.5 LLMs write code as good as most engineers given well defined small enough chunk of work. They refactor. They write tests. These days LLM also debug/troubleshoot better than most engineers.
Are they as good as handcrafted code by 0.1% of top software engineers. Generally no. But neither is 99.9% of real code.
LLMs also are good at code reviews. What they'll miss is often the big picture but they can still catch plenty of issues. I still want to see a human in the loop in my domain.
Totally agree that writing the code was never the bottleneck. We're not seeing massive productivity gains even if some code is written faster. It's not just about understanding but also various other activities that happen in large companies and teams.
Also agree LLMs can be used to gain quality but realistically most orgs are going to aim for "fixed or decreasing" quality at lower costs.
There is the flip side of where the code is no longer read by humans and is becoming the prevailing way software is shipped in tiny businesses. You don't need to code to be maintainable since you will never maintain it, the AI will and the quality will naturally improve as models improve. For example 5.6 sol and fable are showing signs where you can feed garbage in and it will spit out something pretty decent, definitely not the quality you'd expect from a senior developer with millenia of experience, but that of your average grunt worker turning words in an issue board into code.
However, sometimes then I tell it to write an app with detailed instructions and it spits out garbage so your mileage might vary.
I find this to work for a V1 or product with only a few users but not sure this will scale. At least you still need software engineers reviewing the functionality and giving the AI hints at what to do.
> They really shine on security review, but are very effective with any kind of review.
They are getting more and more hostile for making any security assesments. I wonder will they even write secure code in the future if they can’t point vulnerabilities from existing code.
> The other thing that the "LLMs write code camp" misunderstands is that writing was never the bottleneck.
Anyone who's seen tech debt where each item is well known and understood but just big in scope knows that this isn't true universally - depending on your team size and composition, any damn thing can be the bottleneck, often at different times too. I'll take everything that helps me resolve them with reasonable trade-offs, even if I need to come up with ways to mitigate the issues created by those trade-offs (like enforcing >90% test coverage as a starting point).
> LLMs still aren't good at writing maintainable code.
I find that depends on the target language. They can be good at writing maintainable code, but not consistently across every language.
The languages beginners usually gravitate towards are especially hard for LLMs to produce quality output for. Presumably this is due to the training data including all the unmaintainable codebases written by beginners in those languages, which hasn't allowed the LLM to converge on recognizing what a maintainable codebase looks like in those languages.
You're right about understanding. Where we might disagree is the conclusion. I think it's possible to build the understanding without having to type out syntax by hand (debugging, writing tests, etc). Maybe we're missing much better verification tools? LLMs will likely play a big part in those too (explain the codebase, walk me through A, B, C etc)
To be honest, it feels like you are contradicting yourself.
If LLMs are, as you stated, really good at catching potential issues, then they are, almost by definition, really good at producing code without potential issues, if guided correctly: all they need to do is inspect and iterate, until they do not find any more potential issue in the code they produced.
That isn’t necessarily true. LLMs could be good at finding issues that human miss when coding, while being bad at catching issues that they themselves miss while generating code.
I've come to realize that the smarter LLMs get, the less they understand the point of abstractions.
I've been using it for a unity game for the past few years. Nowadays it will go sleuthing into packages and assembly and make decisions based upon what it sees there.
It will make comments about why it's doing something based upon a function call 3 methods deep.
God forbid any of these details change in a minor version update.
Try reducing thinking and use lighter models. For example I observed that using Sonnet works much better (compared to Opus) for tasks I want to be in control of architecture and just need a faster code input.
“Not in speed, but in quality” — unfortunately though, not a single CEO, executive, company, VC, investor or anyone with the power to make decisions cares about quality instead of speed.
I agree. Also, what does "code quality" even mean in the age of agentic dev? If the code works, and is secure, what else matters?
I do know what good code looks like, but does that even matter anymore? All I know is that now, I get to focus on endless UX polish, which is the only thing the matters.
I feel like we are living through something like the Protestant Reformation, where priests once spoke Latin, and then started to speak in plain local language. The old guard did not like this.
Also, what does "code quality" even mean in the age of agentic dev? If the code works, and is secure, what else matters?
AI pricing is mostly based on tokens consumed right now. Shouldn't that mean being able to quickly and reliably analyse existing code and to make only small local changes to implement new functionality is as valuable as ever - if not more so - if you're relying on agentic LLMs to do the grunt work?
A lot of things about writing clear specs and developing systematically and employing lots of different kinds of checks and controls to ensure quality and performance have always been true but used to get brushed under the carpet by a lot of cheap/lazy development teams. If LLMs really do accelerate everything about development - including negative behaviours like acting undesirably based on flawed or ambiguous information and doubling down on mistaken assumptions - then the pattern across all of these areas is that doing things the right way is more important than ever if you want to get good results from AI assistance.
Except AT Protocol can't do the very thing that made Facebook the commons: privacy.
There's a proposal to add privacy to the protocol (private posts, private groups), but I don't think anyone has solved the real root problem with trying to implement privacy in a federated system (as opposed to P2P), which is the bad administrator problem. The proposal I saw still relied on trustworthy app administrators to respect a post's privacy settings. And that's a huge flaw.
Friendica and Diaspora both have the same problem, and to my knowledge don't have a good solution for it. They both just sort of hand wave it away.
I'm waiting to see if someone comes up with a good solution for the unsafe admin problem, but so far I haven't seen one.
Privacy works fine in Fediverse. The admins of both servers can read your messages, but you should expect that. Fediverse is email with gratuitous JSON and HTTP.
ATProto is trying to implement privacy on top of global public pub/sub which just obviously doesn't work.
I think the issue is that those stories are rooted very much in the failures of human systems that we see every day. They are us imagining what could go wrong based on what has gone wrong and is going wrong.
It would be a lot easier to set those warnings aside if we didn't have so many examples of the very things they warn about happening in real life.
We currently have a system where private individuals can fund private science and then deploy the results globally to their own profit with very few mechanisms for enforcing restraint and caution. And we've seen this backfire with horrific consequences over and over again.
Lead in the gasoline. Microplastics in the water. Pesticides widely applied to the biosphere. In my area PCBs are a massive risk due to past soil contamination. In other areas fracking biproducts make the water undrinkable.
Hell the AI rush in the face of climate change. We literally have heatwaves killing massive numbers of people while a tiny handful of investors and the companies they control are drastically increasing our carbon emissions in the race for AI.
It's easy to imagine all the ways in which synthetic life could go horribly wrong, even with out those sci-fi stories, especially since all but the youngest of us have been through a brutal pandemic in living memory.
It's very, very hard to imagine our current system showing proper restraint with this technology.
Ever since the industrial revolution, humanity has stumbled from one environmental disaster to the other.
Heavy metals, CFCs, acid rain, radioactive elements that don't occur naturally, microplastics, PFAS, large scale oil spills, greenhouse gasses, deforestation, over-fishing, species extinction, the list goes on & on.
And in each case, early warnings are ignored & the harmful activity is only curbed many decades after deployment at scale, when environmental harm becomes too serious to ignore.
Imho AI is no exception to this rule. Its energy usage alone adds to CO2 emissions at a time those should be reduced. Higher efficiency says anyone? No! Higher productivity. Read: same # of humans can consume even bigger amount of resources per time unit.
Yeah I can envision the wonders AGI/ASI could bring to humanity. But as deployed right now, it mostly helps to worsen a number of problems in human society (CO2 emissions, wealth inequality, concentration of economic/political power, to name a few).
Synthetic life? Absolutely, would be a fantastic scientific milestone. But could also turn into yet another eco disaster.
It's important to emphasize that cars are the leading source of carbon emissions. Anyone fighting against AI on the basis of climate change should be fighting for safe and reliable alternatives to driving everywhere.
This is "whatabboutism" which is a logical fallacy.
Someone doesn't have to talk about the climate impacts of cars every time they talk about the climate impacts of AI. Both have climate impacts, independently of each other, and we should be dealing with the climate impacts of both simultaneously.
Regardless, don't assume the person you are talking to isn't consistent. Peruse my personal blog and you will see that I, in fact, ran a whole city council campaign on a platform of "to fight climate change we should not be driving".
> This is "whatabboutism" which is a logical fallacy.
No it isn't. You don't optimize a piece of software by profiling it and rendering a flame graph, and then ignoring the sections of code that the most time is being spent in. You work on optimizing the paths where the most time is being spent, because that is where your effort has the most room for impact. If we are trying to optimize carbon emissions instead of time, we look at the biggest sources of emissions first, because that's where our effort has the most room for impact.
> Someone doesn't have to talk about the climate impacts of cars every time they talk about the climate impacts of AI.
I never said they did. I said they should be fighting both if they actually care about the issue.
> Peruse my personal blog and you will see that I, in fact, ran a whole city council campaign on a platform of "to fight climate change we should not be driving".
Excellent, you are fighting both because you care about the issue. Thank you for your service.
Someone doesn't have to talk about the climate impacts of cars every time they talk about the climate impacts of AI.
Actually they do, because the best way to get cars off the road is to replace many if not most of their occupants with AI.
Private ownership of cars is not the problem. The assumption that people have to drive all over the place to get stuff done is the problem. Let's work on that.
> the best way to get cars off the road is to replace many if not most of their occupants with AI.
I'm so confused by this. Instead of one person driving a car to the store and parking, now the car is driving itself to the store with one person in it, dropping them off, and then either parking, or driving itself around more, back to the house or to a distant parking facility. In crowded cities, the car is just going to drive around the block empty for an hour instead of paying $12 for parking. Single-occupancy vehicles are a big problem now; I don't understand how introducing a bunch of zero-occupancy vehicles are an improvement on that? It seems very obvious to me self-driving cars are going to significantly increase the total number of miles driven every day in the world.
I didn't say anything about self-driving cars. You still need to go to the store, if you don't get your stuff delivered by someone who is (hopefully) delivering to more than one house.
You don't need to go to the office. Neither does your car.
And the most promising of those alternatives is, ironically enough, AI itself. Fighting data centers is literally like fighting nuclear power. If you just want more carbon emissions, then by all means, proceed.
Of course most people who commute to work don't need to be doing that now, but that's the other big elephant in the room with AI. We don't use the intelligence we already have, so what makes us think the emergence of ASI/AGI will change anything?
The most promising alternative is making it legal to build housing near where people want to be (commercial districts) and make it legal to build places people want to be near where they live (build cafes, shops, etc in suburbia). Any help that AI could have on the situation would just as easily be applied to working from home without AI.
That’s just wrong. Transportation is 24% of carbon emissions with 18% road transportation and about 10% of that from cars. Electricity and heat production is the largest source of carbon emissions.
> cars are the leading source of carbon emissions.
WTF? cars are less than 7% and even including trucks we are barely around 11%. when you look at greenhouse effect instead of "just carbon", the percentages are even tinier.
If you are looking for leading sources of climate change look at electricity/heat, industry and agriculture.
just because (bad) politicians are always talking about cars when talking about climate it doesn't mean the are actually a meaningful component. it is smoke and mirros…
No. That sentiment didn't "move toward the center".
What happened is that the far-right -- and, lets not use euphemisms like "the far right" here, we're talking about fascists and literal Nazis (ethno-fascism is Nazism) -- have successfully taken control of much of our mass media. They've also more or less captured the government of one of the world's super powers. Those two things put together have allowed them to make their views appear mainstream.
This is exactly what happened during the 1920s and 1930s prior to World War II. And similarly, you were finding Nazi views expressed openly and proudly and being given a veneer of respectability. (See https://en.wikipedia.org/wiki/1939_Nazi_rally_at_Madison_Squ...)
But they are no less extreme now than they were then. They are still fascist and Nazi views. And they still ought to be abhorrent to anyone who considers themselves a decent human being.
It's beyond incredible that anyone thinks that the far right has taken control of the mass media. It's clearly the left that has control of most of the media, which makes sense. People in cities tend to be on the left. Journalism majors tend to be on the left.
The days of a scrappy newspaper or local market newscast are over. Reframe your statement from "People in cities tend to be on the left. Journalism majors tend to be on the left" to "People who own media firms tend to be on the right. People who set journalistic standards for their outlet tend to be on the right."
NPR. NBC. ABC. CBS has decided to try being moderate, so we'll see how that goes. MS NOW or whatever they call themselves now. The New York Times. The Washington Post. Politico. USA Today. Vox. Slate. The New Yorker. Huffpost. The Atlantic. Much of the gaming media, weirdly. Reddit. Twitter was. Bluesky is. Wikipedia, if that counts as media.
Allsides even lists the AP as left leaning, though I don't ingest enough direct AP stuff to verify. I'd disagree with them listing the BBC as neutral on quite a few topics, nowadays, and put them towards left - but that's just me.
Sure, there are right-leaning places like The National Review, but apart from the opinion section of the WSJ and Fox News as a whole they're pretty small.
Washington Post is owned by Bezos, so at best center-right. CBS (and its associated properties like Paramount) are owned by a family of far-right oligarchs, who will also soon own Warner Bros Discovery. Said oligarchs appointed a far-right political commentator as a political officer to control editorial content at CBS.
A lot of the rest you list are not left leaning, but centrist (derogatory).
You could make an argument that some of them are "classical liberal" or "neoliberal", but that was the center in the US and everywhere else it is center-right.
Definitions are helpful here.
"Classical liberal" is what the US was founded as. It was a liberal Republic. Classical liberals value political freedoms, civil rights, and free markets. They are anti-monarchy and anti-authoritarian. Most of the revolutions of the 1700s and 1800s were driven by Classical Liberals seeking political freedom
In the origination of "left" and "right", Classical Liberals were "center left". "Center right" were the moderate constitutional monarchists. In the US where we have zero interest in constitutional monarchy, Classical Liberalism was always the center.
Since World War II, that center became a settled question in much of the western world. The answers are "Yes, constitutions", "Yes, political freedoms", and "Yes, civil rights". Though in many places, civil rights were incompletely extended and so much of the argument has been about extending them fully.
The other side of the argument is "the social question" which got rebranded as "economics". It boils down to how much do we allow power and wealth to concentrate. This became more and more of an element of the revolutions starting in the 1850s -- the revolutions of 1848 were the first to really feature a true left as it is understood today: socialist, communist, and anarchist. (At the time, it was just socialist. Communism as a theory didn't exist yet and anarchism was nascent.). And just to be clear, the "left" refers to Classical Liberals as "Bourgeoisie liberals" -- capitalists and capitalist defenders -- and does not consider them to be part of the left.
The center in the US since the 70s has been a neoliberal consensus which argues for allowing the Capitalist markets to do their thing with minimal intervention. And most of the debate has been about how much that minimal invention should be -- with the two sides mostly arguing between "almost none" and "minimal".
Neoliberalism is more or less a form of libertarianism (US Libertarianism edges into Anarcho-capitalism).
For all of the 80s, 90s, and early 2000s, Neoliberalism was the center and was the entirety of both the Democratic and Republican parties. The "left" vs "right" argument was focused on things like foreign policy and whether we complete the extension of civil rights to everyone.
For most of those decades, all of those sources you just named arranged themselves squarely around that center. They were all Neoliberal. They all took rotating positions on foreign policy, aligning with each party based on the political winds of the moment. Many of them did include arguments in favor of the continued extension of civil rights, but many of them also included arguments against it. Few of them whole-heartedly endorsed that extension until after the fact.
We've never had much of a truly left mass media to speak of.
In the last decade and a half, authoritarianism, fascism, and neo-Nazism have seen a resurgence world wide. And in the US an explicitly fascist movement with Nazi elements captured the Republican party and then the government. Anyone with a political science background taking an honest, empirical look at the MAGA movement will identify it thus. That movement directly pulled from the Nazi playbook in their rise to power. Trump has often cribbed directly from Hitler's speeches, barely even paraphrasing them.
During that movements rise to power, we have seen large elements of the wealthy elite that controls much of the media align with that movement.
At this point, most social media sites are controlled by actors who either have explicitly aligned with the US fascist movement or have effectively acquiesced to it.
Meta has added fascist aligned members to its board and put fascist aligned people in executive positions through the company. They've also voluntarily acquiesced to the regime's requests to silence anti-regime activists.
Twitter is explicitly fascist. Elon Musk is a core member of that movement.
TikTok has been captured by that movement through an orchestrated buyout.
Most of our media is social media, and right there you now have the biggest source of news and information for the vast majority of people fully captured by the fascist movement.
As for traditional media, CBS has been captured. Bari Weiss is a part of the fascist movement and her elevation was part of their pressure campaign.
The Washington Post is owned by Bezos who has aligned with that movement and is explicitly exerting editorial control.
News Corp (Fox News and the WSJ) is aligned with the fascist movement and is arguably one of its originators. Sinclair group, which owns most local TV stations, is also aligned with that movement.
And to be clear, I watched this happen. I've long made a habit of subscribing to sources from across the spectrum and made a hobby study of political science and trying to identify source's biases by political taxonomy vs the frustratingly simplistic left / right spectrum. I used to subscribe to The National Review, Reason, The American Conservative, the Weekly Standard, and others. I've largely tried to avoid those that are blatant, ingenuine propaganda (which Fox News has always been) in favor of those making earnest well founded arguments. And one by one, I've watched them fall to the fascist movement over the last decade. Reason is the last hold out, truly committed to civil liberties and libertarianism -- though it hasn't yet recognized the fascist movement for what it is (or hadn't last I checked in on them -- I haven't had the time to read as much lately).
It's pretty clear that you're in the fascist propaganda bubble, based on your posts and where you put things, and that is badly skewing your perception of where the center is.
I would strongly encourage you to get out of that bubble.
I'm not the one in the bubble. You are so far left that think that MS NOW, Huff Post, Vox, etc. aren't on the left in a No True Scotsman type manner, and in your comment you used the word 'fascist/fascism' over 10 times in reference to people that are simply right leaning or even very centrist.
I personally have individual beliefs that align with both of our two major political parties, which is something very few people can actually say, for what it's worth.
No, I'm basing my analysis in history and political science and you are basing yours on your own gut biases. I'm referring to people who are part of an explicitly fascist movement (as identified by political scientists, historians, and experts in fascism) as fascist.
Another point of the Rwandan genocide that's important to remember, is the party who eventually committed the genocide spent months talking about how the other side was about to use extreme violence and they were really the victim. This allowed them to preemptively use violence "in self defense."
The National Lawyers Guild released a pretty incredible statement about this trial. They basically were not allowed to mount a defense, in blatant violation of their constitutional rights.
> Alarmingly, this mistrial order is just the latest example of attacks on the Prairieland Defendants’ constitutional rights to access to counsel, a fair and impartial jury, an adequate defense, a public trial, and more. Judge Pittman has made highly unusual moves that suppress defense teams and which federal lawyers have not seen during their entire careers:
[...]
> NLG remains extremely concerned about these cases. Defendants’ First Amendment rights to free expression, assembly, and association; their Sixth Amendment rights to counsel; their Fifth Amendment rights to a public trial; and their Second Amendment rights to bear arms are under attack in North Texas. If unchecked and ignored, this case and the judicial decisions coming from it will set a very dark precedent for the rest of the country.
"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
And I honestly think this is one of the fundamental problems with the push back towards protocols and decentralization. We're overestimating the bandwidth and capabilities of the average user and we haven't fixed the problems that pushed everyone towards centralization in the first place.
Take me, for instance. I am not only capable of running my own Mastodon or Atproto data server+relay -- I'm technically capable of writing my own ActivityPub or Atproto app.
But I'm currently sitting with accounts on bsky.app and mastodon.social -- the biggest most centralized "instances" (yes, I know, but it reasonably describes the problem). This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
And this is doubly and triply true for the average person who doesn't have the technical abilities I have.
As a result, both Mastodon and Bluesky are still practically centralized to a large degree. An overwhelming majority (more than 90% last I found data) of Bluesky users are hosted by bsky.app. Similarly on Mastodon, a large plurality of users (~20%) are on Mastodon.social. Mastodon's obviously doing better than Bluesky in this regard, but it also has about a quarter of the overall traction, and I'd honestly put that down to Bluesky's apparent centralization which makes it a lot easier for people to join and wrap their heads around it.
This isn't about "average user". Relays have nothing to do with using atproto as a user. They're about developers making new apps.
By "most people" it's implied we're talking about most people who want to run a web app in their spare time. Do you mean a different definition? If you want to run a web app (which is the only reason you'd want a relay) and you're able to pool with ten other developers who want to do the same, you can make the cost to $3/mo. Is that feasible? What do you normally pay for web app hosting?
And again, if you're a hobbyist developer, you'd just use a community relay that already exists and is free. I assume that, if you want to run your own, you have a specific reason to do so.
You're getting hung up on the relay distinction (which is fair). But I'm not talking about relay's here.
And to be clear, I'm talking about the push back towards protocols and decentralization as the solution to enshittification and lock in. I fully believe decentralized protocols and the ability for us to run federated instances for our communities is valuable in and of itself. What I'm arguing against here is the degree to which the pro-social tech community has coalesced around this push as the one and only solution to the problems of enshittification.
And in that context, the average user is everything. And the push fundamentally misunderstands both how enshittification works (email is fully decentralized but still enshittified to a large degree) and the capabilities of the average user (not just their technical capabilities but their cognitive load capacity).
If you want, s/relay/pds/ and my point may become clearer. Or, even, s/relay+pds/app/. The point is pds+relay+app functions as instance for the average user. And the average user doesn't have the time, energy, or cognitive capacity to pick an instance that would be the right fit for them. Which means these decentralized networks are still heavily centralized. And if they remain heavily centralized, those central players still exercise an enormous amount of power over the network.
Including the power to enshittify it.
We can't solve enshittification if we're not cognizant of what the average user is capable of. And that capability extends to more than just "technical understanding". So far, I don't think the protocols push, in so far as it is being pushed as the solution to enshittification, is grappling with that adequately.
I view Bluesky as being decentralized-optional. It's cool because you actually can join first and wrap your head around it later. You can continue using your account you created on the fully 1st-party stack, and you still have the option to switch to self-hosting the parts you care about, without losing your posts or followers.
- If you just want to use your domain name as a username, you set a DNS record.
- If what you care about is the client, you can build your own website or native app. You don't really even need to host a server other than for your own static assets, since the app can request Bluesky network data directly via the logged-in user's PDS (they even have CORS headers!)
- If what you care about is data sovereignty, you can self host your PDS (personal data server) on a low-end VPS. It's cheap because it pretty much just holds your data, passes events to Relays, and proxies data requests to your preferred AppView.
- If what you care about is not needing to trust Bluesky to reliably gather and collate events from each PDS, then you'd need to host a Relay ($30/month) and an AppView (even more expensive) so you'd be best off pooling resources with other people you trust. But that's kind of the nuclear option.
- With a narrower scope though: if you noticed that Bluesky was censoring a handful of legitimate accounts and you still wanted to follow them, I think you could probably have a personal Relay+AppView that only listens to the censored accounts' PDS's, and proxies other requests to the 1st party AppView. (I'm not 100% sure if that would be allowed.)
>"Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
I don't think that was a recommendation for people to do, but to demonstrate that it doesn't require much in the way of resources. That VM could probably host hundreds of people, since relays scale and de-dupe shared content.
If someone said that email or a personal website was inexpensive and could be hosted on a cheap VM, I don't think you'd make a comment like the above dismissing it as impractical: the idea is that if it's that cheap, then there are people that can host cheap/free (maybe ad supported) relays, similar to how cheap/free webmail exists today.
> "Most people" cannot afford $30 /month. And of those who can, most of those cannot afford the time and effort required to run a relay.
??? that's not the point. the goal isn't that some non-technical 40 year old will run their own relay. the goal is that relays will be cheap enough to run that there can be hundreds of relays for developers of apps to choose from.
relays are DEVELOPER facing only, meaning the developer of the app chooses which to use, and can even use none at all and build the functionality of the relay into their app itself.
no matter where your account is hosted, it will be crawled by every relay (unless it's banned from some of them) so users or people who "don't have the bandwidth to think about this" don't have to worry about relays at all. anyone who will ACTUALLY BENEFIT from an independently hosted relay (app dev) will perceive them as an incredibly marginal cost.
> This is because I do not have the time or mental bandwidth to even pick an "instance" that would be better suited to me and migrate, let alone run my own.
Idk what to say to that. So I'll just say that you can run `npm create pds` and have a single-user PDS hosted for free on Cloudflare in minutes.
But I think what you meant to say (stop me if I'm wrong) isn't that you don't have the "mental bandwidth", it's more that you (and the average user) don't actually _want_ to migrate because there's no tangible benefit.
To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil. The real way to get people to spread out across different PDSes is to make it so there are more "entry points" to the atmosphere, so more people are onboarded to the atmosphere in more places other than Bluesky, where they can sign up and automatically be on another instance. If more independent atproto apps are created with their own PDSes for onboarding, that's what will solve the problem imo, not encouraging users to migrate (although that can also be done at smaller scales, as Blacksky and Eurosky have proven)
>To this I would say: migration is not the path to spreading users out across instances at a large scale. Migration to me is more of an insurance against a service going down or turning evil.
I think people aren't paying enough attention this part right here: I think the architecture of atproto creates a different set of incentives. People running communities are more likely to face community pressure to ban users, or de-federate with other communities they don't like, and your open/decentralized network fractures apart, creating little silos.
People running infrastructure connecting them to a global network/resource are less likely to feel those pressures. No one asks an email provider to ban another webmail host. The architecture colors the perception.
The biggest problem Bluesky has had is that by virtue of being the only effective relay at launch, people viewed it more like the former and less like the latter. But I think if we start to see more places like Blacksky and Eurosky get mindshare, we can shift it back.
An average user does not need to run their own node for decentralization to work. It just needs to be cheap and easy enough for enough of technical users to run
If the goal is to actually calculate how many words we know, then you should include an "I don't know" option. Sure, some people will choose to guess to inflate their score, but some of us will be honest because we legitimately want to know our scores.
If you force me to guess, then I'm going to guess. Not only does that give me a 25% chance of getting it right at random, but as others have pointed out, it is very hard to make a multiple choice question that isn't guessable by an astute enough test taker. I think I knew 80 - 85 of those words, but I scored 97, because those questions were very guessable.
Also, reiterating everyone else's comments with respect to the UX needing fewer clicks, and also the definitions not being exact or precise in many cases.
That was fun, but the AI and the balance need some work.
It's too easy to win as the small boat. You just stay ahead of your opponent and then turn back and strafe periodically.
It would be much more challenging if you added wind and realistic sailing dynamics. If wind direction vs sail orientation mattered to your speed and boat characteristics weren't as simple as smaller = faster then I think it would be much better balanced and way more fun/challenging!
On further play, really the only match up where I had any trouble was large vs large. (As a side request, it would be nice to be able to choose your opponent!)
With both small and medium, you can just strafe back and forth in front of your opponent if you're faster than them. With medium and large, you can just circle them and absorb more punishment than them when you're larger than them.
Multi-player would solve the AI problem -- especially if it was more than 1v1 -- and then it would be more challenging.
But I would still request realistic wind and sailing dynamics. That strafing maneuver isn't really possible with real wind dynamics, because you slow down as you swing around and that allows the opponent to catch up to you and return fire. You could have a little arrow in a corner of the screen that shows the wind direction. You don't even have to make the sails movable, you could just have your speed be proportional to how orthongal your sails are to the wind direction in the simplest implementation.
It would add a whole new element to it that would make it much more challenging! :)
Thanks for playing and the feedback. I plan on adding wind dynamics very soon. Letting you choose opponent instead of random should be easy. Multiplayer with more than 1 would be interesting, I like that idea!
Highlighting that game mechanics are hard - I struggled with your strategy but found it too easy to be the tank. Turn in a circle and shoot and rely on the higher HP + cannon loading.
That's interesting, because I found it trivial to win with the largest boat. Tank one hit, lead your target, blast away. I remain undefeated with the largest boat.
By contrast I found winning with the medium boat required the most skill, and lost the first few times I tried.
The cannonballs should have randomized elevation as well so that "raking" the bow and stern is more likely to get hits than hitting the side. Hits on the bow and stern should also do more damage. Cross the T!
Yeah so the other factor missing is gun calibre and ship hull reinforcement/design. The reason sloops didn’t dominate against ships of the line came down to these factors, as well as sheer number of guns.
A sloop’s guns were generally so light the balls would bounce off the hull of a ship of the line. The sheer weight of firepower in return would shred a sloop to pieces. Add on to that the fact that heavier guns can achieve longer range when trained at the right angle, and a sloop can’t really get anywhere near a ship of the line and live to tell the tale.
I plan on adding wind dynamics. The largest ship has 1 more cannon, do you think I should add more? or perhaps longer range on the larger ship cannons?
Longer range would help! I should also note that ships had forward- and aft-firing guns in addition to the main batteries on the gun decks firing to the sides. A smaller ship merely trying to run away could be fired upon until it got out of range.
...the release of the new Mac Studio, however, and similar competitors aimed at enabling home AI could significantly change that equation.
reply