fhd2

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.

That's my experience with agentic development so far, a lot of extra time goes into testing.

Problem is, the way I've been trained to test isn't exactly antagonistic. QA does that kind of thing. Programmers writing tests are generally rather doing spot checks that only make sense if the code is generally understood and trustworthy. Code LLMs produce is usually broken in subtle, hard to spot ways.

Agreed. Putting the burden on parents is quite something:

1. You end up being the bad guy, other parents don't restrict their kids internet usage etc. Some folks would argue to just not set up restrictions and trust them. But it's a slippery slope and puts kids in a weird position. They start out with innocent YouTube videos, but pretty quickly a web search or even a comment can lead them to strange places. They want to play games online, but then creeps abuse that all the time. Even if you trust them to not do anything "wrong", it's a lot to put on their shoulders.

2. If you want to put restrictions in place, even if you're an expert, the tools out there are pretty wonky. You can set up a child protection DNS, but most home routers don't make it easy (or even allow you) to set a different DNS server. And that's not particularly hard to circumvent. I suppose a proxy would be a more solid solution, but setting that up would be major yak shaving. Any "family safety" features (especially those from Microsoft) are ridiculously complicated and often quite buggy. Right now, I got the problem on my plate that I need to migrate one of my kid's accounts from a local Windows account to a Microsoft account (without them loosing all their stuff), because for local accounts, it seems the button to add the device is just missing? Naturally, the docs don't mention that, I had to do research to arrive at that hypothesis. The amount of yak shaving, setup and configuration you have to do for a reasonable setup is just nuts.

3. If you're not good with tech - I don't see how you have _any_ chance in hell to set up meaningful restrictions.

Some countries are banning social media - sure, that's one thing. But there's a _lot_ of weird places on the internet, kids will find something else. I for one would appreciate dedicated devices or modes for kids < 18. Would solve all this stuff in a heartbeat.

Which would be pretty much full circle at that point. When I started out, it was common for developers to do "product management", there wasn't a specialised role for it yet. You had developers and maybe project managers (generally also developers) and testers, and that was about it. Management would talk to developers about their strategy and problems, and they'd figure out what to build based on that.

I'm pretty weirded out by some "modern" teams where you have product managers spoon feed specifications to developers, and developers focusing on nothing but the code they need to write to do exactly as they've been told.

Product managers are in a weird place. They wear a ton of hats and do entirely different jobs based on where they work. They're often really valuable, but I have some trouble putting my finger on what makes a good one. If they're good at whatever it is they end up doing, that's good.

Even if somebody shows you what they've built with it, you're none the wiser. All you'll know is that it seemingly works well enough for a greenfield project.

The jury is still very far out on how agentic development affects mid/long term speed and quality. Those feedback cycles are measured in years, not weeks. If we bother to measure at all.

People in our field generally don't do what they know works, because by and large, nobody really knows, beyond personal experiences, and I guess a critical mass doesn't even really care. We do what we believe works. Programming is a pop culture.

I never could get used to different key bindings. vterm in Emacs, with a few workarounds, works beautifully for me.

I got curious as well, because the craziest party poor me can imagine would clock in at maybe half that, including travel. All I could find:

> The three-day festival in downtown Oakland featured performances by Jay-Z, Anderson .Paak, T-Pain, and Soulja Boy, and brought 8,000 employees from around the globe.

So that'd make it 8.5k per person. Building stages, paying permits, hiring acts like these, I bet that's where it mostly went.

Exactly, I find the math fairly simple:

1. Employee costs x;

2. Employee produces output worth y;

3. Your profit from this particular employee is z = y - x.

So far so good. Let's assume z > 0, though of course it's not an easy statement to make with many roles, that are more like investments. But let's assume they're good investments and you're confident z is positive.

Now, if the same employee produces 2y, but doesn't receive a raise, z just improved significantly, it more than doubled. So effectively, labour just became cheaper in relation to the value of its output.

If it was that simple, layoffs would hurt profitability significantly.

Now what if you can't translate improved productivity to additional value? Simple example would be an agency with a fixed contract volume. If increases in y can't be realised, e.g. by finding more business, then the only way for the company to realise the gains is to reduce x, i.e. layoffs. z goes up right away, no business development required.

I think it's a defensive stance companies are taking. The economy is not great, they're hitting the breaks on investments, increasing their runway, shrinking to force the organisation to become more efficient. Once they're ready to invest again, they can always hire again. But I read layoffs-because-AI as "we don't know what to invest in right now, so we'll buy some time to figure that out".

It likely has to do with changed investor preferences. In the boom years, it was OK to grow at all costs, make money whenever. Nowadays investors are looking to cash out earlier, from what I observe. Gotta find ways to make the stock move up in that environment, cost-cutting-because-AI seems to work right now.

I'm not 100% convinced it means they gave up and are trying to cash out. It could also be that they just struggled to integrate all the people in a meaningful way, even if they're all really good. Having grown a company from a hand full of people to 250, I more than once fantasized about going back down to ~100. Scaling companies well is hard. 10k, I can't even imagine.

If geographic location is a serious advantage, then yes, kind of. Competitors would have an uphill battle against the grandfathered incumbents.

I doubt it is though, in these cases. Was probably just to make the measures more popular, as in not destroying existing investments / jobs.