> And moreover, what differentiates software now will no longer be the care put into it but marketing and trends. The highly commercialized nature of software means that there's not much point now in doing anything except getting there first and exiting with a decent nest egg.

That happened at least 20 years ago. How many recent "this product did so great because of the care of software engineering, and now the creator is comfortable for the rest of their life without risk of it being copied" success stories are there compared to "this product chased some trends VCs were nuts about with a slapdash MVP and the founders took out 8 figures from their later fundraising rounds, but then the business sputtered out"?

I think there's an angle with AI tools where business-minded people will have a better chance of doing interesting things now than in the recent past, because you could potentially tailor much more deeply to individual customers with reasonable economics than in the past. There are fields where there's room for a garden of solutions from different small-team vendors appropriate for different use cases instead of a one-size-fits-all SaaS winner-take-all type market in the past. We could kill the old line about SAP around needing to change your business to accommodate SAP instead of customize SAP to accommodate your existing workflow.

But if you aren't business-minded at all there are likely less places that will need to hire as many careful maintainers or novel-software-writers, which obviously is a huge kick in the teeth to a lot of people.

It seems to me that you are comparing two kinds of business-minded people. Some want to sell tailored products to individual customers, while others want to sell one-size-fits-all products to many customers.

You could also focus on problems. What are the actual problems you want to solve? Can you use software to solve them? Do you still need to buy that software from other companies, or is it now feasible to have sufficient in-house expertise to develop it yourself?

> Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so.

Claude in its current Opus 5.5 form has made some wild reaches in response to reasonable-seeming prompts. For instance: "this error is getting swallowed, make sure the real termination message exposes the root cause" -> discovering that the issue is actually in a third party library that isn't exposing the original error except so through logs, so doing some hackery to inject a log-capturer that gets the stdout, buffers it, and looks for the message in order to re-throw based on that...

And it can demonstrate that working, but it's added some fragile and/or unintended consequences like (a) string matching on a particular WARN log message of a particular version of the lib, and (b) buffering those logs such that there were now cases where they would never make it to the actual output stream before the program terminating.

It's certainly capable of being used smarter than that, but it's also really easy to end up with messy fragile stuff if you get lazy about reviewing the output.

> "this error is getting swallowed, make sure the real termination message exposes the root cause"

Without judgement, I think this illustrates a fundamental objection the anti-AI crowd raises.

The example prompt requires no understanding of what's happening, before suggesting action. Where I work, process requires that a PR review for a solution, has to have a corresponding explanation of why, or it's marked needs work

I don't disagree.

I think there's some nuance here though between "fully anti-AI" and "be careful with that power saw."

That example I mentioned didn't make it to production. It got noticed and fixed more properly by the person who submitted the first prompt before it even went to PR.

But a lot of times things in that same vein can be solved sufficiently with a "dumb" prompt like that, so a one-line prompt to get a PR drafted in the background for the dumb stuff can be a pretty good time saver.

The art is not skimping on your attention to the bigger or more important stuff so much that all the time you save on first getting code written is lost by cleaning up stuff like that...

As a very amateur woodworker in addition to my day job, I have always thought the power tool analogy is a good one for LLMs. The tools don’t remove the need for skill and being very very careful with how you use them. You can work faster but do a lot more damage also.

I think you're misunderstanding where in the process that prompt got made.

> but it's added some fragile and/or unintended consequences

In python, in a co-worker's code, it seems to significantly prefer "some_dict.get('key')" over "some_dict['key']". For the non-python-users, the first one will return None (equivalent to null) when the key is missing, while the second raises a KeyError. It was being used in a whole bunch of places that would cause problems (bad data instead of errors) if it did receive None. Some of these keys were actually optional and it does makes sense for those, but it looks like whichever model he was using just repeated the pattern everywhere instead of just where it was appropriate.

I don't get it... What's the problem? I too prefer getting None as opposed to a key Error which would prolly necessitate a try..catch as opposed just checking for None. I'm having trouble reasoning up a situation where raising a keyError would make any sense over a None for data structures like dicts that could return a value or no value! Help?

KeyError localizes the issue to the lookup (ie “right here this key should be present and it’s not) vs later in the code where it can be hard to trace where the None value came from or how to handle it.

Well... yeah but at the cost of halting your entire program? As opposed to logging?

Think of it like an assert.

Sometimes you do want some flow to terminate if a schema / data contract is breached, and not have this broken data contract propagate elsewhere / outwards.

And/or, it is a perfectly valid pattern to indeed add try..catch, and contain (hence "localize") the issue there and then. If there is a way to handle this breach - you will need some kind of if check anyway. Catching by matching against the particular KeyError exception is in fact robust - and if you forgot to add an intended catch, then the exception will propagate upstack, yes - which is what you want - and this way you do not need to worry about forgetting an "if None" check.

This sort of approach makes it structurally impossible to "forget" - if exception is not caught, it will abort the cannot-be-null breach continuing with program flow, possibly (e.g.) ending up persisted in some place it shouldn't be, causing problems later.

Python uses `except`, not `catch`.

...sure, that's true :) but you get the point. p.s. and the software design pattern applies in general, imho.

yes, that makes sense. Thank yu so much!

Or you know, test if the key exists before using it. The key could exist and be None, representing a legitimate None at that key. Or the key might not exist and asking for it is a bug.

Use a defaultdict if you must have all keys optional. Using get() everywhere is buggy because it masks illegal key use.

> test if the key exists

Double lookup.

Cheaper than fixing bugs due to illegal key access.

Cheaper than get() masking bugs in your code or dict generation.

But yes let's prematurely optimise for speed in a slow-by-default language by writing bug prone non-idiomatic code. OK.

There are times where you want to check for existence before fetching a key-value pair, and there are times where you want to automatically throw an error if the value doesn't exist.

Both have valid use cases. It's weird to be sarcastic about it.

Oh man, you're giving me flashbacks to a vibe coded utter mess. Gets were a big offender. It seemed to have no discipline to commit to a data format, added all kinds of optional parameters everywhere, was also doing truly insane things like having contingency fallbacks in case some library it wanted to import wasn't where it expected, sometimes even importing things in the middle of a function.

This to me feels more like a developer skills issue than a problem with the LLM. At my day job, we banned using untyped data structures like this entirely well before LLMs because no one could read code that passed them around.

You could use a data structure that better articulates an optional field, like a dataclass with type hints or a pydantic model. Then you, your coworker, and the agent alike, aren’t guessing at whether the key’s value is optional.

Another example in this vein is having many optional parameters on a function or api route, that drive behavior deeply nested in the application logic. Or maybe they were there for testing and never deleted. No one comes across this code next and understands it easily. How could you expect a LLM to understand it, either?

I find it funny when people blame the LLM for dog shit code, but at the same time have a pollock painting of code they load into its context, and are like “put a person in the horse and carriage!” And the LLM is like “bro I just see dots and squiggles but you asked so boom!”

The square bracket version tells the reader it's required, the .get version tells the reader it's optional. Kind of the reason both exist in the language (the .get version has an optional second argument to return instead of None when the key is missing).

The point is that the implementer shouldn’t have to investigate to know whether the key’s value is nullable.

I used Opus 5.5 to figure out that a language model we were serving at work for internal use (we don't really serve models, we only use this internally because it processes sensitive data that we can't send to external endpoints) was being bottlenecked by CPU contention on tokenization, by having Opus run in an autoresearch style loop.

Opus's first proposal for a fix was to spawn multiple Python processes and build a load balancer between them in Python. At first I asked it why it wasn't using haproxy and it said that haproxy would be an added dependency and that the overhead for this kind of thing in Python would be negligible. I knew this was idiotic but wanted to test this out, so had Opus run two experiments in parallel. Sure enough an haproxy load balancer was much, much better on HTTP load balancing than Python code was.

This is the kind of thing that if you're unfamiliar with how networking code works, the models can autopilot into bad decisions that are verifiably correct (higher throughput than the original CPU-bottlenecked implementation) but much short of best practice.

Are you doing CPU inferencing? For small models you could check qxotic.ai which is a whole inferencing stack for many popular open models in Java, which can beat llama.cpp in speed in some cases. Its tokenizer toknroll is faster than tiktoken, which is what made me think of it for your use case.

The advantage is that you don't have issues like the GIL or whatever, so there's no need for all the complexity of load balancing between multiple pythons.

Thanks for the pointers, I'm gonna look into them.

I'm not doing CPU inferencing but I'm doing some tokenization in Python which is CPU-bound. In all honesty I started on this project to scale the model and did not build it myself so have been trying to read code and walk back the approach. I've been thinking about rewriting the Python glue in Go to avoid issues with the GIL.

I disagree with their criteria that they couple with it, but I could come up with some of my own that I'd like better.

"This has 900 lines but 850 of them are in codegen boilerplate that changed", for instance.

"This has 900 lines but they're mostly updating a bunch of test fixtures along common patterns."

"This is 800 lines because we bumped ten version dependencies and that bumped a lot of other things + they changed the package naming for some so we had to rewrite a bunch of imports."

"I added two panels to a Grafana dashboard." (ok slight exaggeration)

>How do you know Apple has not interviewed a broad and representative sample of real users and found that their #1 desire in a laptop is thinner and lighter than what is currently available?

>I would bet that is what real users have been asking for, for decades now. They aren't asking for swappable batteries or headphone jacks.

Well isn't it telling that Apple hasn't focused on thinner and lighter than what is currently available for 5 years now?

Their actions seem to indicate that they heard this desire loud and clear, and that this caused a single-minded focus that lost the plot on the overall functionality part of the role of design. And then they heard lound and clear from users that "thinner than what came before" was not the end-all-and-be-all. They also rolled back other victims of the "as thin and liught as possible" chase, such as SD cards and HDMI ports.

The claim here is that they could have anticipated that if they weren't driven overly by the aesthetic bragging-rights side of the design team vs the functional side. It's not hard to anticipate everyday reliability causing more blowback than relatively-rare battery-replacement capabilities. They probably had a very good idea of how many replacement batteries were sold, after all. (And for the record: headphone jacks are still there.)

> Well isn't it telling that Apple hasn't focused on thinner and lighter than what is currently available for 5 years now?

Could it be that miniaturization has reached a local maximum of what current technology can support and we simply can't make devices that are thinner and lighter while preserving battery life and computing power?

Or maybe they got thin enough so other factors now outweigh thinness. Notice how laptop batteries used to last 2 hours and now they go 8h and more.

If you can make a device 1cm thinner and keep the same 2 hours of battery life, worth it. But if a 10mm device lasts 2 hours and a 12mm lasts 6 hours, obviously 12mm is the better choice.

Notice that phones continue to get thinner. Except around the camera because better photos outweigh smaller camera.

But phones still get bigger. Current phones are far larger than the phones from 2020 and those were larger than those from 2010.

> But phones still get bigger

Yep I'm sad about this too. Consumers want big screen. Especially when a phone is their primary, often only, computing device

I literally wanted to by Iphone 13 mini because of it's size, but the camera sucks so I had to reconsider.

i remember something similar with the ipod shuffle, that they cannot keep make it smaller only because the power button would be too small to operate, innfact the one that is like a piece of metal, the only way to easily slide the power button is with your nail

>Well isn't it telling that Apple hasn't focused on thinner and lighter than what is currently available for 5 years now?

Not really. Jony Ive, chief designer at Apple for most of the iphone era, left in 2019. He and Jobs were the primary pushers behind the "thinner, lighter" drive. Once the chief pushers for "form > function" left, it predictably stagnated, and begun to fall in line with industry standards from other companies.

That seems nonsensical. Consider a selection of even just 8 types of components or patterns that might be in a training set (or available to be found over Google and fed into a prompt by a harness, for that matter). There are 256 distinct ways to use 1-8 of them together.

And of course the number of libraries, known algorithms, etc, is much larger than 8. There's any number of ways to make something new by combining well-understood parts.

I don't think non-expert prompting is pushing the envelope on what can be built because I think the current generation of harnesses and models pushes to using well-understood patterns in well-understood ways but it's certainly moving the line for what has been built. And with more skilled prompting you can build pretty crazy stuff + extensive validation for it.

> A workaround is to always shoot everyone the same. If a journalist or interviewer grows a reputation, they can show everyone "on level ground" by keeping the pose, lighting, etc... constant.

I don't think this works.

And I think it might be actually easier to exploit. The fraudster knows what you're going to do in advance, and can target their own presentation to maximally take advantage.

If the way you show someone conveys X about them, especially when due to outside cultural cues - here's the millionaire framing, here's the convict one... - and you just use the same X for every subject, then you're just suggesting a particular framing over and over. You're avoiding a layer of "my active framing is telling a particular story" but only with a passive—but still deliberate—framing of "my framing is telling a particular story" that you hold constant across every story.

In some ways this is similar to what Holmes exploited originally! Lots of industry media was willing to uncritically frame and present her with their "visionary tech founder" styles, and she leaned even further in to that with the Jobs-isms.

Would not a truer "fair" framing would've been to dig into the claims and let the evidence determine the visual language, to avoid the visual language of "Steve Jobs!!" bias the reader/viewer into giving Holmes' claims more credence?

I'm not convinced that "more training" is a silver bullet here because "for you and the people you learned from" is a subset—potentially a tiny one—of the world of potential training data.

Even with newer model generations larger efforts still seem to drift back towards "default choices" vs "steered specific aims."

In many areas, "good" taste is not particularly good anymore when it's everything's default style.

The edge then becomes finding the niches that (a) can be better served w/ non-defaults and (b) have economic characteristics that make it worth catering towards those.

I think the days of one-size-fits-all huge-scale-and-ROI SaaS swiss army knives are quite numbered, but I think the replacement world could be a much more vibrant ecosystem with a much more varied set of players.

If you say "yeah go with your own recommendation" every time you'll get something that'll at least kinda work sooner or later. Not sure you need an "architect."

But is that workflow enough in a competitive world anyway, or will there be an edge for people who do more than "outline the end-user requirements" like it's the waterfall 70s?

>I think user just use their agents to code, and agents don't report bugs, they just work it around somehow.

Claude comes up with some truly delicious insane workarounds these days. Like launching something in a subprocess and capturing stdout/stderr and doing string parsing on info logs because of a desire for some hook not exposed by API (or at least that it didn't find on its quick scan).

There's probably no such thing as semver reliability for dependencies anymore in stuff that agents glue together, since they will poke at ANY sort of way of getting additional insight or control if they want it.

That's so fragile.

> I think the point of a lot of configuration formats is that they don't want their configuration to also be a full-fledged programming language.

That seems to be everyone's initial goal, but then it inevitably gets leaky.

I think the dominant split here that forces everything into a weird mismash is that nobody really wants to have to understand arbitrary programming language configs for third-party stuff, they want to read config and know what's going on. BUT for their own stuff, they find reasons to want more power and expressibility...