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")...

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.

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...

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

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.

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.

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 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.

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.

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.