Funny how windows updates are never postponed for lack of "scaling". I know, I know, completely different stuff here - but arent test vms and ci vms being updated constantly?
Im old enough to remember the hotmail migration to win2k (then 2k3) and the postmortem. I was also old enough to look at the rotor source code. Yah, that one, running managed code in freebsd.
Im still waiting for... Basically anyone that has used TFS (what microsoft had/pushed before acquiring github) to do a similar post, detailing how they miss the tool original concept. I'm sitting down, don't worry about me.
What are those strengths? I've worked with projects hosted on GitHub, GitLab, and Azure DevOps at my current job, and was generally not impressed with AzDO (mostly looking at CI stuff).
I haven't used azure devops but I used TFS in its heyday and still haven't ever seen a better integrated ticket workflow with fully customizable states and transitions - it's like a mutant hybrid of jira and github but all built into VS. There's definitely something to be said about keeping the primary admin UI in the dev tools.
We all understand that. We had some piece of software we still cling on to it (in my case is a copy of paint shop pro 5, corel draw 7 and Delphi 7), despite being completely obsoleted or assassinated by "big industry". I could add CoolEdit 2000 to it, but havent really opened it in a decade.
To be honest, I never understood the fascination with github. Its a hub, of git repos. Not to piss on your parade, because your complaints are valid, but maybe isnt github that as gone sour as much as you have grown out of it. This was your passion, now its over and you move on.
How is this different from "people that cant write sql should not use orms"? With code agents you can write raw sql better than most developers; and if you want, you can basically ask for the same implementation using whatever orm you want. Lastly, AI generated code is supposed to be reviewed by a human, just like code done by your colleague. Thing is, with AI, you can establish automatic review guidelines, and even ask for proper benchmarks and optimizations, at zero cost.
One of the simple "reasons" is to keep context clean; if you're doing planning, you're not loading source code, its just the plan. Also, it may happen that if you're running parallel manual sessions, cache expires after 1h, so a prompt on an idle session will re-trigger re-evaluating the whole context (something quite heavy on a 1M context window). This burns a lot of credit.
> It is NOT the way to work with humans basically because most software engineers I worked with in my career were incredibly smart and were damn good at identifying edge cases and weird scenarios even when they were not told and the domain wasn't theirs to begin with.
I have no clue what AI you're using, but both Claude and Codex, you just explain the outcome, and they are pretty smart figuring out stuff on complex codebases.You don't even need a paragraph, just say "doing this I got an error".
> NO guarantee either because these models are NOT deterministic in their output. Same prompt different output each time.
So, exactly like humans. But a bit more predictable and way more reliable.
> That's why every chat box has that "Regenerate" button.
If you're using the chat box to write code, that's a human error, not an LLM one. Don't blame "AI" for your ignorance.
> no matter how smart and expensive the model is, the underlying working principles are the same as GPT-2.
Sure. Every machine is a smoke machine if operated wrong enough. This tells me you should not get your insight from random YT videos. As a bit of nugget, some of the underlying working principles of the chat system also powered search engines; and their engineers also drank water, like hitler.
Have you created a plan where the requisite is not to bother you with x and y, and to use some predetermined approach? What you describe sometimes happens to me, but it happens less when its part of the spec.
It boils down to scope. I use CC in both very specific one-language systems and broad backend-frontend-db-cache systems. You can guess where the difficulty lies. (Hint: its the stuff with at least 3 distinct languages)
> Is it more important to be right, or to be happy?
Im going out on a limb here, but I'd say intelligent people will tell you - without a doubt - being right. Because being happy is a perception and always a transitive state. There's nothing holding you from being both right and happy.
> Nobody likes to be told they're wrong
Thats actually a southern european way of looking at things; Its a cultural trace that varies a lot by region. Pointing flaws in plans is actually something I saw as worthy of an appraisal in Germany.
Also, I always tell people when I think they are wrong. I no longer insist or argue, just point out what lead me to the conclusion; you don't want to be in the blast radius of a deaf manager, an incompetent colleague or a delusional partner. Win-win.
Im old enough to remember the hotmail migration to win2k (then 2k3) and the postmortem. I was also old enough to look at the rotor source code. Yah, that one, running managed code in freebsd.
reply