black3r

So much this. When coding I use my LLM to hone the code to perfection before sending it to review, including running AI reviews on it multiple times and fixing obvious bugs so that reviewers have less work to do. I also test all my code manually (LLM can be helpful by giving me a list of test scenarios to consider). When reviewing PRs I carefully read the AI reviewer output, consider which points are relevant, which are irrelevant and only post the relevant issues when requesting changes.

I have coworkers who routinely post PRs with comments stating "all tests green, ready to review" and then I actually start the application, test it manually and it doesn't work. And don't get me started on reviewers who post the raw AI output of their "reviewing skill" and then I have to read through 30 paragraphs of "findings" most of which are irrelevant (just today I got the "valuable" feedback of "View is @api_view(["POST"]); no test asserts GET/PUT/PATCH/DELETE → 405")...

How LLM usage affects your thinking process entirely depends on the workflow you use with them.

I can honestly say that while using LLM my thoughts are as sharp and as fast as they were before, if not sharper and faster. But my workflow is that I watch the LLM as it rips, have verbose output turned on so I also read Claude's thinking process (and lots of interesting information is hidden there).

This helps me learn new stuff I wouldn't think of. Helps me stop Claude if he's veering off track. Makes it easier to proofread what's Claude doing and why step-by-step and easier to spot any mistakes (because they often come from wrong assumptions you wouldn't see if you didn't see the thinking process).

If you just let your agent write thousands of lines of code, reviewing them is painful. If you also run multiple agents for multiple tasks at the same time, your focus is divided, so you aren't spending all your brain power on the task at hand.

I have one like that and so do my parents. But they're much less effective than classic split AC with an outside unit. A regular split can cool a bigger room to 24 even when it's 38 outside and is basically completely quiet. A portable AC cools down smaller rooms to ~27 when it's 38 outside and is noisy (50-60 dB).

It's not that expensive. There are other reasons why people can't install one in Europe than money. Mostly for people living in apartments. In an apartment building you need the approval of other apartment owners to "modify the building facade". And some people have terrible neighbors. Another thing that happens in Europe is that if the building is 100+ years old, it's facade may be protected as a "historic building" and then you need another approval from some bureaucrats which are responsible for protecting historic buildings. And of course if you're renting, you need to convince your landlord if you want a proper AC not a portable one.

my guess is that the outdoor AC unit reached its maximum working temperature...

since we're not that used to extreme heat in EU, units with max working temperatures of 45 degrees Celsius are pretty common and the air around the AC unit is warmer than regular outdoors air, doubly so if they're placed on the ground and the glass from the building reflects some additional heat from the sun.

the risk of this was broadcasted in our local news for home AC owners when the forecast reached 40, as lots of apartments have the AC on partly glass-encased balconies, or on walls facing direct sunlight...

the sentiment "AI couldn't code last year, but now I use it for everything!" rings true for me... but I didn't flip cause AI is now better than me... I flipped cause now I am faster with AI than without it...

A year ago the AI output was so bad that getting it up to my standards took more than writing it myself from scratch. And nowadays it is faster for me to start with AI output and iterate from there to reach quality submission.

The ninety-ninety[0] rule was a thing talked about 40 years ago, long before anyone thought of AI coding. AI can nowadays make the first 90% of the task very fast and good enough. The last 10% is still the hardest part of coding by far.

[0] https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule

Majority of the things I've mentioned don't need QA. Improving performance of an existing code is fine as long as it passes the existing test suite. Dev tooling / Monitoring is for devs only. Unused code is unused, just needs review from another dev to confirm. Documentation is for devs only.

And I work on the backend in a smaller company these days. Our backend code doesn't pass through QA, we just write tests and another backend coder reviews the tests if new tests are written. QA only handles frontend.

I probably spend even more than 20% of my time away from the computer these days. AI is great for this. I task Claude with something and while it's working I have the time to think about next steps, I can take a walk outside, have a coffee, talk with coworkers about my ideas, ... I'm paid to think, not to sit behind a computer.

There are people who say it's better to have multiple claude code instances crunching different stuff at the same time, and using the waiting time to prompt up another one. This might result in opening up more PRs faster but in the end it's not more productive. Context switching takes time, it divides your attention so your work is more sloppy and less thought through, and driving your brain too much makes you tired which again results in more mistakes. Having to compensate for this negates the productivity gains by finishing more grunt work faster.

I love having no task assigned. Means I finally have time to do code maintenance. Upgrading dependencies, fixing bugs (there are always some), clearing TODOs left in code, improving performance, improving dev tooling or monitoring configuration, cleaning up unused code, improving documentation, ...

And the best part is that since it's not an assigned task, nobody is waiting for it, so I'm under zero pressure.

Sadly it doesn't happen that much as we're always pushing for more new features out.

We have 257 python dependencies in our production app (over half of them are direct dependencies). We don't have any upper bounds in our pyproject.toml and we just run `uv lock --upgrade` every 2 weeks through GH actions.

We have good test coverage so if anything breaks the tests fail + we have AI assisted review process for this -> when GH action creates the upgrade PR, an AI workflow uses a python script to list major and minor version updates, finds and links changelogs, summarizes them, and makes the risk factor analysis for each package based on how we use it in our codebase.

It's mostly painless and we don't have to deal with upgrading packages one-by-one, checking which packages are outdated, or having outdated packages. Very rarely something breaks in a way it can't be fixed in our code and we need to wait on a fix from the dependency author (maybe once a year?). And in the past 3 months only one such upgrade required some changes to our code, there were 18 major version bumps in that period.

I wish we could do this on the frontend as well (I'm a full stack dev), but we don't have enough tests on frontend for this to work safely. Tests on the backend are easier to write and are more important so I believe every codebase should have them. And if you do, you can just auto-upgrade everything.

It really is far easier than you'd think if you haven't tried.

Different countries use different definitions of what "small business" or "micro business" is. And people usually use their own local expectations they're used to. I'm not from the US and a company with 100 million revenue is far from a small business to me.

In EU where I'm from the micro/small/medium business sizes are tied to both employee count AND revenue. Micro is below 10 employees and below 2 million € revenue, Small is below 50 employees and below 10 million € revenue, Medium is below 250 employees and 50 million € revenue.

So if you had 100 million revenue you would be a large business even if you had less than ten people.

The difference with AI is that now generating AI slop is much faster than carefully crafted code. So companies began to prefer AI slop.

Also this doesn't just mean more disk space usage, but also longer local build times... for the app I'm working on `exporting to image` takes 71.5 seconds with containerd, without containerd it's 4.3s (the rest of the build takes ~180 seconds). And that's just a 5.76GB image.

Depends on the complexity of the task. That's what I tried to hint at by also mentioning college-level math. For the high-school level tasks yeah, couple of hours and I'd be as fast as I was in high school again. For the number in another base it could be as quick as less than 1 hour as again that's a simpler task than the other two.

For derivations/integrations it'd take more time. Less than what it took me to learn them in the first place, for sure. But still a lot more than 1 hour.

Cause I forgot how to "do them" in the first place, which is what the discussion was about in the first place. I still know the "theory" behind, so I can "figure it out" if needed without needing anyone to "instruct" me, or needing "classes" to learn how to do them. But essentially all the "practice" I had back then is forgotten.

And again the same goes for code and technology knowledge, which is what the discussion was about in the first place.

As a senior developer with 10+ years of experience I've already encountered situations where I needed knowledge I knew I had at some point, but already forgot. In my case as a backend developer working for the same company for 5+ years my favorite example is payments processing. There are tons of special/edge cases - e.g. how a failed recurring payment during a subscription is processed. That's something you set up once, then don't touch for years, and suddenly need to study again if a change is needed. How a subscription goes "past due", what you can do in that case, what your code actually does, how it reverts to correct state once a retried payment follows through, what options you offer a customer if his payment method expired and he wants to switch it, ...

And this is also a good example why "domain knowledge" and "code ownership" is a good thing in larger companies. Because under usual circumstances I don't have to deal with these, cause we have a dedicated person who's maintaining the payment-related code. I only fill in in urgent cases happening when he's on vacation.

And juniors designing stuff like this AI-first without properly thinking about all these cases won't learn all the edge cases this flow can contain. So if something goes wrong, you end up with nobody who has the "maintainer experience" for that code - you don't have the one person who is knowledgeable about that topic - everyone in your company is in the same spot as me - having to research the topics again to understand them enough to be able to debug the incident which happened.

What the actual fuck? Customers' expectations shouldn't matter at all if the things they expect is illegal.

And this is already a solved problem.

The city I live in (Bratislava, Slovakia) has some pedestrian-only zones in the "old town", and if you're in one of them, calling an Uber/Bolt forces you to pick a pickup spot where cars can go...

(arguably this still has issues with Uber/Bolt allowing you to choose bus stops as pickup spots, which is explicitly illegal - only buses can stop on bus stops, but it's still better than driving onto a road which does not allow cars in the first place).

EDIT: i mistakenly thought this was about driving on dedicated bike paths, idk why, but this is still a solved problem, the applications already allow to designate some roads as places which can't be picked as pickup/dropoff points...

Knowledge comes basically from manual trial/error almost daily.

This is the important statement, although I'd swap the word "knowledge" for "experience" here. You can gain "knowledge" from books, but only trial & error will give you experience to know "which" knowledge to use in which situations.

And what's important about this in the context of working with AI is the "error" part.

You have to experience errors to become truly experienced. And part of the experience is to recognize when you're about to make an error - to avoid it.

AI-driven processes mess up our natural trial & error learning curve in multiple ways:

- the AI push forces us to ship features faster (cause if we don't, our competitors will), reviews are sloppier, we discover errors later on, the feedback loop gets longer...

- using AI to debug and fix errors means we spend less time understanding what the error was about, which means we learn less about how to avoid the error in the first place...

- AI itself sounds overly confident, so reading its outputs without previous experience you may be less likely to recognize when it's making an error, which makes it harder for you to recognize when you're making an error trusting it...

On the other hand, this last point I tried to make is also why I don't think avoiding AI completely is a good strategy. Whether we like it or not, AI is becoming a part of developer's workflow. And as such, we also need to learn the trial & error process of using AI - what makes AI make errors and how to prompt it to avoid that.

Multiplication is elementary school math which doesn't require any thinking and the learned approach is simple. You can't really compare the simple stuff that's taught to kids, like basic multiplication or riding a bike with stuff that requires domain-specific knowledge and experience.

Think more stuff like "find the angle of lines defined by (x-4y-1=0) and (x-y-2=0)", "write the number 2026 in base 7", "solve an equation sin^2(x) - sin(x) = 0".

I plucked these from our country's high school final exam from this year. Back when I was in high school, I did mine in 60 minutes without an error when the time limit is 150 minutes and I intuitively immediately knew how to approach each task since the moment I saw it. Also all needed formulas are supplied, you don't need to remember any of them.

I plucked these because for these I don't have the immediate "know how" now, I still understand the topics, and could solve them with enough time, but it would require some thinking and thus I would be slower at solving them than when I was in high school, even though I'm pretty sure I could still ace it in the 150 minute time limit.

But reality goes beyond high schoool... College-level math, like derivations/integrations, sums, algebraic proofs, is even harder and solving some of them could take me hours when I could do them in minutes when I was in college.

With code it's the same. I could solve simple Python/Pascal/C++ high school level tasks as fast or faster than when I was in high school, even if I didn't write any code for a couple of years. But we also had assembly class in college, and I would struggle at assembly if I had to code it now, 10+ years later, even though I didn't struggle with it back then.

For me AI mostly reduces time effort. AI types code faster than I do, looks up stuff on the internet faster than I do, debugs faster than I do, but doing those never required much "brain effort" from me.

What does require "brain effort" from me is making educated decisions. Mostly during planning to figure out which pros/cons of each possible approach are actually relevant for our situation - AI does this poorly, makes lots of wrong assumptions if you don't steer it correctly, and noticing these + correcting AI on them requires "brain effort" too. Then the part of code review where you think about what can go wrong. AI still sucks at figuring out edge cases. It doesn't "know" the entire codebase like I do, its context only has "the parts of codebase deemed relevant".

Before AI I could jump from 30 minutes of hard thinking into an hour of coding during which my brain essentially rested, before returning to hard thinking again. Nowadays those hour-long coding sessions turn into 5-10 minutes of watching AI do something.

So for me using AI doesn't "free up brain juice", it instead makes me use my "brain effort" more, and in a workplace environment gives me less time to rest and makes me more tired, cause nowadays bosses expect us to work faster + colleagues working faster means more review requests.

I hear sentiments about farming from lots of burnout software developers.

I always wonder what made them become developers at all. Cause my primary motivation for selecting a job was that I explicitly didn't want to ever work manually, I knew that since early childhood and it still didn't change even after 2 burnouts. My secondary motivation was that I liked working with machinery/computers.

Also when I started coding, it immediately felt like my passion. And the thing I love most about coding is that mostly all changes I make have instantly visible results. I couldn't imagine working a job where I had to plant a seed and then wait a week to see if it sprouts.

Also what I love about development is that with modern Docker/Kubernetes setups you can make the environment where your code runs pretty predictable. And with proper backups configured and backup restore testing you aren't really worried about losing the stuff you worked on for months. Meanwhile while farming you can't predict how much sun is gonna shine or how much rain you're gonna get. And you can't prepare for natural disasters which can come anytime and ruin your crops.

So I wonder if it's all just people who never loved software engineering and just went into it for money, and now that they have money after years of working they start looking for their true passion.

that's basically how it already works...

extensions choose on which site they're active and if they provide any available assets (e.g. some extensions modify CSS of the website by injecting their CSS, so that asset is public and then any website where the extension is active can call fetch("chrome-extension://<extension_id>/whatever/file/needed.css" if it knows the extension ID (fixed for each extension) and the file path to such asset... if the fetch result is 404, it can assume the extension is not installed, if the result is 200 it can assume the extension is installed.

This is what LinkedIn is doing... they have their own database of extension IDs and a known working file path, and they are just calling these fetches... they have been doing it for years, I've noticed it a few years back when I was developing a chrome extension which also worked with LinkedIn, but back then it was less than 100 extensions scanned, so I just assumed they want to detect specific extensions which break their site or their terms of use... now it's apparently 6000+ extensions...

You can have decoupled Controllers from Views using React. That's the basis of the "original" Flux/Redux architecture used by React developers 10+ years ago when React was just beginning to get traction.

A flux/redux "Store" acts as a Model -> contains all the global state and exactly decides what gets rendered. A flux/redux "Dispatcher" acts as a Controller. And React "Components" (views) get their props from the "Store" and send "events" to "dispatcher", which in turn modifies the "Store" and forces a redraw.

Of course they aren't "entirely decoupled" because the view still has to call the controller functions, but the same controller action can be called from multiple views, and you can still design the architecture from Model, through Controller (which properties can change under what conditions) and then design the Views (where the interactions can happen).

in theory "maintenance mode" should mean that they still deal with security issues and "no longer maintained" that they don't even do that anymore...

unless a security issue is reported it does feel very much the same...

My experience is similar, but I feel I'm actually thinking way harder than I ever was before LLMs.

Before LLMs once I was done with the design choices as you mention them - risks, constraints, technical debt, alternatives, possibilities, ... I cooked up a plan, and with that plan, I could write the code without having to think hard. Actually writing code was relaxing for me, and I feel like I need some relax between hard thinking sessions.

Nowadays we leave the code writing to LLMs because they do it way faster than a human could, but then have to think hard to check if the code LLM wrote satisfies the requirements.

Also reviewing junior developers' PRs became harder with them using LLMs. Juniors powered by AI are more ambitious and more careless. AI often suggests complicated code the juniors themselves don't understand and they just see that it works and commit it. Sometimes it suggests new library dependencies juniors wouldn't think of themselves, and of course it's the senior's role to decide whether the dependency is warranted and worthy of being included. Average PR length also increased. And juniors are working way faster with AI so we spend more time doing PR reviews.

I feel like my whole work somehow from both sides collapsed to reviewing code = from one side the code that my AI writes, from the other side the code that juniors' AI wrote, the amount of which has increased. And even though I like reviewing code, it feels like the hardest part of my profession and I liked it more when it was balanced with tasks which required less thinking...

Literally every datacenter in the world was going to fail on this change

I would expect most datacenters to use their own local recursive caching DNS servers instead of relying on 1.1.1.1 to minimize latency.

4. Ends up in test environment for, what, a month.. nothing using getaddrinfo from glibc is being used to test this environment or anyone noticed that it was broken

"Testing environment" sounds to me like a real network real user devices are used with (like the network used inside CloudFlare offices). That's what I would do if I was developing a DNS server anyway, other than unit tests (which obviously wouldn't catch this unless they were explicitly written for this case) and maybe integration/end-to-end tests, which might be running in Alpine Linux containers and as such using musl. If that's indeed the case, I can easily imagine how noone noticed anything was broken. First look at this line:

Most DNS clients don’t have this issue. For example, systemd-resolved first parses the records into an ordered set:

Now think about what real end user devices are using: Windows/macOS/iOS obviously aren't using glibc and Android also has its own C library even though it's Linux-based, and they all probably fall under the "Most DNS clients don't have this issue.".

That leaves GNU/Linux, where we could reasonably expect most software to use glibc for resolving queries, so presumably anyone using Linux on their laptop would catch this right? Except most distributions started using systemd-resolved (most notable exception is Debian, but not many people use that on desktops/laptops), which is a locally-cached recursive DNS server, and as such acts as a middleman between glibc software and the network configured DNS server, so it would resolve 1.1.1.1 queries correctly, and then return the results from its cache ordered by its own ordering algorithm.

I've been using pyenv for a decade before uv and it wasn't a "major pain" either. But compared to uv it was infinitely more complex, because uv manages python versions seamlessly.

If python version changes in an uv-managed project, you don't have to do any extra step, just run "uv sync" as you normally do when you want to install updated dependencies. uv automatically detects it needs a new python, downloads it, re-creates the virtual environment with it and installs the deps all in one command.

And since it's the command which everyone does anytime a dependency update is required, no dev is gonna panic why the app is not working after we merge in some new code which requires newer python cause he missed the python update memo.

this picture does show differently in Chrome and Safari, but if I analyze it using the methods you did I arrive at a different result - I don't see an iHDR chunk there, instead I see a gAMA chunk and if I remove it with pngcrush it shows normally in Chrome.

maybe you linked a different picture?

There have been ads in App Store for a long time. The upcoming change is that they will also appear further down in search results, right now they only show on top...

There are GPUs from 3 different generations in that list... Quadro 6000 is an old Fermi from 2010, Quadro RTX6000 is Turing from 2018, RTX6000 Ada is Ada from 2022...

Oh and there's also RTX PRO 6000 Blackwell which is Blackwell from 2025...

Ubuntu has alphabetical order too, but that's only useful if you want to know if "noble" is newer than "jammy", and useless if you know you have 24.04 but have no idea what its codename is and

Android also sucks for developers because they have the public facing numbers and then API versions which are different and not always scaling linearly (sometimes there is something like "Android 8.1" or "Android 12L" with a newer API), and as developers you always deal with the API numbers (you specify minimum API version, not the minimum "OS version" your code runs in your code), and have to map that back to version numbers the users and managers know to present it to them when you're upping the minimum requirements...