fhd2

Good example. Transitioning from an outdated framework to a modern (or sometimes "slightly less outdated") one is probably one of the few situations where you do not want to change semantics at all.

And in my experience, these are _dangerous_. People go into "while we're at it..." mode, and it quickly turns into a big 2.0 kind of thing that takes forever.

I would argue that LLMs can speed this kind of thing up, but not by an order of magnitude or anything, just a bit. Unless there's high risk appetite.

Depends on how much you're asked to burn I guess. Until one point, it's actually helpful. Then there's a point where you can do stuff that's semi helpful but doesn't get in the way. But then I would imagine you reach a point where you have to come up with a token burn strategy and some kind of narrative for your manager that's in line with it. I bet at that last point, it gets taxing.

Probably like eating. Having to eat less to loose weight isn't great. Eating anything you want without worries is great. Having to eat more than you want to gain weight, not great.

AGENTS.md is fun too, solid AI bro stuff:

Code like Anthony Fu and Evan You

default to the highest quality modern code the legends would ship

What a time to be alive.

If it's profitable, they would. Companies aren't moral, with very rare exceptions. Legal risks and costs are just part of the overall equation.

But that's not in defense of what Karp said, or that slop tweet summarising it. That's... wild. I regret reading it.

I think it's primarily a filter. Candidate filters are pretty much always silly, even common ones based on degree/grades etc. But with a lot of candidates on the market, using some filters reduces the list to a manageable amount.

Personally, as someone with a German company and a good chunk of German clients, I'd argue it _does_ help a little. Occasionally. But by and large I'm far more interested in the candidate's English proficiency.

I'd argue it's pretty much like monitoring, which certainly benefits from multiple people seeing the same stats and alerts. I agree it's at odds with CI/CD and should probably not block anything, like deterministic checks commonly do.

One fascinating thing about LLMs is the degree of evangelism it inspires in some. You can explain some of that with paid micro influencers, people invested in the success of AI, consultants looking for workshop opportunities and all that, but I know enough people with no skin in the game at all, that turned into very vocal advocates.

I think to some degree, that effect is also at play here. CEOs, product managers etc are simply amazed, and want to spread the good news. I doubt they can even _comprehend_ that others might not be as excited as them.

SEO is definitely a relevant component still, AI mode does a traditional search under the hood. Gaming the system to rank high on the index is still going to matter. But it'll be less about tricking people into clicking and more about tricking LLMs into considering the information relevant and authoritative. For someone using traditional search, I'd wager that would actually improve the results a bit over time.

Then again, SEO gaming got a whole lot cheaper with LLMs, spammers spam even if there's not a great return, as long as it's cheap for them.

Yeah, plus it's a bit... single minded. A static single page site is _quite_ "agent ready". Scores 0 here. It's not like it'll need an MCP or whatever.

So AI generated code doesn't benefit from stable foundations maintained by third parties? Fascinating take I don't currently agree with. Whether it's AI or hand written, using solid pre-existing components and having as little custom code as possible is my personal approach to keep things maintainable.

Agreed, it is different in terms of there being no guarantee that a specific piece of software even has an exploit. If you don't want to break into a specific piece of software, or even a specific system, I would argue that the law of averages applies: If you just invest enough, you'll likely find _something_ worth exploiting.

In other terms, I feel the argument from TFA generally checks out, just on a different level than "more GPU wins". It's one up: "More money wins". That's based on the premise that more capable models will be more expensive, and using more of it will increase the likelihood of finding an exploit, as well as the total cost. What these model providers pay for GPUs vs R&D, or what their profit margin is, I'd consider less central.

But then again, AI didn't change this, if you have more money you can find more exploits: Whether a model looks for them or a human.

They are, wow. I had this age old Yen conversion wired into my brain: 100 Yen is one Euro. Boy did that change in the last decade or so, it's only half that now.

I typically install both systems on the same disk, different partitions. Then work with additional SSDs strictly for game storage. Only annoying bit is that some games _need_ to be on C, but very few in my experience. If you have enough space to shrink your Windows partition, that could work without waiting for an SSD. Though I guess the one OS per disk setup is ultimately cleaner.

Been dual booting for >20 years now. It's nice that some games work on Linux pretty well these days, and of course I had fun messing with Wine manually to get some stuff to work decades ago. But it really doesn't bother me too much to reboot when switching between gaming and literally anything else.

Isolated QA should not exist because anything a QA engineer can do manually can be automated.

Well, sort of maybe, but it's not always economical. For a normal web app - yeah I guess. Depends on the complexity of the software and the environment / inputs it deals with.

And then there's explorative testing, where I always found a good QA invaluable. Sure, you can also automate that to some degree. But someone who knows the software well and tries to find ways to get it to behave in unexpected ways, also valuable.

I would agree that solid development practices can handle 80% of the overall QA though, mainly regression testing. But those last 20%, well I think about those differently.

I think there's also a pretty good chance that if a robot that could mine the same cobalt with no human intervention appeared tomorrow, many folks would complain about "hard working cobalt miners in Africa losing their livelihood to automation".

Well, yeah? Just because the current work safety situation is bad, doesn't mean being out of a job couldn't be worse. I'd love a world where more automation meant less, safer, higher paying work for everyone. Our world never worked like that, to my knowledge, and I'm not sure it ever will.

Well, I'd say there's two dimensions:

1. Check frequency (between every single time and spot checks).

2. Check thoroughness (between antagonistic in-depth vs high level).

I'd agree that, if you're towards the end of both dimensions, the system is not generating any value.

A lot of folks are taking calculated (or I guess in some cases, reckless) risks right now, by moving one or both of those dimensions. I'd argue that in many situations, the risk is small and worth it. In many others, not so much.

We'll see how it goes, I suppose.

Especially if they are earning 5k per year as the title suggests.

Not sure that's how the math goes. TFA mentions every employed worker has a team behind them, and is often successful in their job as a result.

Kinda fascinating. Here we are, usually dreaming about how one person could do multiple jobs. There they are, having multiple people do one job in the best (looking) way.

If the spec covers 100% of the code paths, then yes, you're right. But now spec and code are entirely redundant. Changing the spec or changing the code takes the same effort.

If the spec doesn't specify all the details, then there are gaps for the code to fill. For example, code for a UI is highly specific, down to the last pixel. A spec might say "a dialog with two buttons, labelled OK and cancel". That dialog would look different every time the spec is reimplemented.

Unless of course, there was also a spec for the dialog, that we could refer to in the other spec? That's really just code and reuse.

Businesses naturally see their "suppliers" and "resources" as exchangeable. And to a degree, they really are, at the end of the day.

But it's still a non-trivial activity with long feedback loops, that requires a level of expertise.

Making workers easily exchangeable requires processes that ultimately underutilise their abilities, finding the lowest common denominator. Some businesses clearly can and want to afford that. Pretty much by definition, that leads to mediocre work.

From what I gather, a good chunk, if not the majority of agency work serves that particular need. But there's plenty of clients out there that want something else. Like all of mine.

Who's "we"?

I'd consider shipping LLM generated code without review risky. Far riskier than shipping human-generated code without review.

But it's arguably faster in the short run. Also cheaper.

So we have a risk vs speed to market / near term cost situation. Or in other words, a risk vs gain situation.

If you want higher gains, you typically accept more risk. Technically it's a weird decision to ship something that might break, that you don't understand. But depending on the business making that decision, their situation and strategy, it can absolutely make sense.

How to balance revenue, costs and risks is pretty much what companies do. So that's how I think about this kind of stuff. Is it a stupid risk to take for questionable gains in most situations? I'd say so. But it's not my call, and I don't have all the information. I can imagine it making sense for some.

That's why I find any effort to create specifications... cute. In brownfield software, more often than not, the code _is_ the specification.

A lot of this rings true for a development agency, in 2026:

You cannot succeed in design services unless you really believe in your clients and your client’s products. Just as it’s essential to enjoy working with the people you form a company with, working with clients that you like is essential too.

Yup. Otherwise you're just "implementing specifications", which I'd argue is generally not the best form of collaboration.

I’ve known lots of people who got into services thinking that they can use the income from clients to bankroll their own product ideas. That is not an impossible scenario — it’s been done before more than a few times, and it’s a beautiful thing when it happens. But it’s very, very difficult to pull off. To do services, you need to wake up in the morning with a different approach to life from the way you wake up in the morning to do products, and only a few people have the skill — and stamina — to juggle both at once.

Yup, I don't think anyone I know (and not myself either) pulled this off. I bet many did, just from anecdotal evidence I'd consider it rare, and subjectively, I agree that it's hard.

Most clients, when they hire a design studio, take the attitude that the studio is lucky to work with them, that they selected them from a plentiful pool of design companies bidding on their business. To many clients, design studios are, in a sense, interchangeable. [...] This is a deadly position for a design studio because it essentially commoditizes the studio’s value.

Yup. If clients start comparing hourly rates, they are a) making a rather meaningless comparison, looking only at a single factor in a larger equation and b) going to try and haggle you down, which is unpleasant for both sides.

I usually give a rough estimate of what I think it's gonna cost, and then we talk about what _not_ to do and where to cut corners to get it down to the ballpark of the budget, if needed.

That's not even all, but I have a feeling my comment shouldn't end up exceeding TFA in length.

Sure, depends on the field. Some fields can't realistically WFH to begin with. Some easily can though. If you have a doctor and a programmer, the doctor can work at a hospital that provides the best career opportunity for them, while the programmer can work at the place that provides the best opportunity for them, given WFH.

If both can WFH, they can even choose the place they want to live in regardless of where their optimal employment options are based.

Sort of. I was arguing that I see WFH as the superior model for people in relationships, because it eliminates the need for sacrifice and compromise on one dimension: Career beneficial location.

Not on all dimensions, of course. People with kids e.g. will have to find a solution for who gets to work how much, it's a similar conflict WFH addresses partly at best.

What baffles me most about RTO is what it does to romantic partnerships. If both can find career advancing jobs in the same city, that's cool.

But what if they can't? The options aren't great:

1. One of them takes a hit on their career for the benefit of the other.

2. Both move to an area with OK-ish jobs for both, sharing the sacrifice.

3. Both take optimal jobs wherever they are and move into a long distance relationship.

With kids in the mix, it becomes even harder, you might want to be around family to have a support network etc.

RTO mandates generally seem pretty tone deaf about this aspect.

This was McKinsey & Company — a firm with world-class technology teams [...]

Not exactly the word on the street in my experience. Is McKinsey more respected for software than I thought? Otherwise I'm curious why TFA didn't just politely leave this bit out.

Absolutely. I'm pro emotions :) Just also good to realise what battles are lost.

I do sometimes rebelliously use words in their original connotation along with an unnecessarily lengthy explanation. Never anything that's now an insult, of course, those I just stay away from and am not mad about either.

My thinking is a bit different here: Seniors, even mediocre ones, already learned a lot of hard lessons by doing things pre-LLMs, even pre-SO. Those skills are valuable and I don't know how to train them into juniors.

I find it easier to get a reasonably smart senior to use AI in a good way, than to train a junior in what thinking to do, and what to outsource, learning basics about good design, robustness and risk analysis. The tools aren't the problem per se, it's more about how people use them. Bit of a slippery slope.

That's just my anecdotal experience from not a whole lot of data though. I think the industry will figure it out once things calm down a bit. Right now, I usually make the bet to get one senior rather than two juniors. Quite different to my strategy from a few years ago.

That's the right move. If a word changes its colloquial meaning, better drop it and find a new one. Happens all the time. From stuff like "agile" in a software development context (pretty meaningless at this point, can mean anything from the original definition to the systematic micro management it got to be commonly associated with), to previously neutral words that became offensive (because they were commonly used as such).

No individual holds power over connotations. Language just evolves.

I guess the chain of reasoning would be: AI for art is bad -> Writing is art -> Translation is writing.

Personally, I do appreciate good localisation, Nintendo usually does a pretty impressive job there. I play games in their original language as long as I actually speak that language, so I don't have too many touch points with translations though.