stitched2gethr

I'll keep using markdown.

This take rings true for me after admittedly only a couple of hours of use of gpt-5. I had an issue I had been working with Claude on but it was difficult to give it real-time feedback so it floundered. gpt-5 struggled in the same areas but after about $2 of tokens it did fix the issue. It was far from a 1 shot like I might have expected from the hype, but it did get the job in about an hour done where Claude could not in 3.

For reference my Claude usage was mostly Sonnet, but with consulting from Opus.

Well me plus a $1200 / year subscription is still much cheaper than 2 of me.

Well it's about time.

Maybe it's not.

I made an OSS tool to help you cheat on your taxes, screw your business partner, or ensure your ex wife cannot see the children. Someone stole the source and is backed by a major VC firm. Is the thought different at all or exactly the same? Just raising the question.

Yes, although when I'm wrong I rarely say "Oh, now I see. This is definitely it!"

Why would you review agent generated code any differently than human generated code?

It will very soon be the only way.

I'll admit, hearing a robot swear is pretty damn entertaining.

I feel you, but cost is a real thing.

Been building proxymock (proxymock.io) a free CLI tool to make local apps feel connected to prod, or any other environment. Good for fast integration testing, mocking, driving load, etc. Critical feedback appreciated.

I've been building proxymock, a CLI tool which automatically builds mocks and load tests from captured traffic.

Feedback appreciated - https://proxymock.io/

And yet some of the accepted changes still haven't taken affect.

> @overload is a decorator from Python’s typing module that lets you define multiple signatures for the same function.

I'll be honest, I've never understood this language feature (it exists in several languages). Can someone honestly help me understand? When is a function with many potential signatures more clear than just having separate function names?

> It can do anything a human can do within a terminal.

This.. isn't true.

> subtle AI-written bugs slipped through unnoticed, and we (humans) increasingly found ourselves rubber-stamping PRs without deeply understanding the changes.

I'm not even going to add to this.

If your CI/CD process was able to fully verify a fix then it would have stopped the bug from making it to production the first time around and the Jira ticket which was handed to multiple LLMs never would have existed.

Probably because it has read the facts but has no idea how numbers actually work.

Meh. I've been using 2.5 with Cline extensively and while it is better it's still an incremental improvement, not something revolutionary. The thing has a 1 million token context window but I can only get a few outputs before I have to tell it AGAIN to stop writing comments.

Are they getting better, definitely. Are we getting close to them performing unsupervised tasks, I don't think so.

I very much agree. I've been using Gemini 2.5 pro for coding and I've always given it a simple instruction. Never write comments. It will stop writing them for a time but it's nowhere near the 1M context window.

Now maybe this is more a lack of instruction following than context length but the fact that it works at first and then starts going downhill quickly makes me wary about how much it will pay attention to other details further back in the context.

Remote work did a number on middle management. When many of them realized that if they aren't the strategic brain at the top, and they aren't individual contributers, and they can supervise butts in chais, then they aren't actually providing that much value.

I think this misses the point. It seems like the author is saying we should move from imperative instructions to a declarative document that describes what the software should do.

Imperative: - write a HTTP server that serves jokes - add a healthcheck endpoint - add TLS and change the serving port to 443

Declarative: - a HTTP server that serves jokes - contains a healthcheck endpoint - supports TLS on port 443

The differences here seem minimal because you can see all of it at once, but in the current chat paradigm you'd have to search through everything you've said to the bot to get the full context, including the side roads that never materialized.

In the document approach you're constantly refining the document. It's better than reviewing the code because (in theory) you're looking at "support TLS on port 443" instead of a lot of code, which means it can be used by a wider audience. And ideally I can give the same high level spec to multiple LLMs and see which makes the best application.

I guess this is an unpopular opinion given the existing comments, but I don't get it. They spent time and energy on this instead of writing features or fixing bugs and I don't think it matters at all. The only interaction I have with my API keys is copying them from one place to another. If I need to manually identify a key then putting the first or last few chars, whatever they are, in my working memory is more than sufficient.

This seems more on the trivial side to me.

Yes, if the callee has reason to believe the caller isn't who they say they are. But this will never enter the mind of someone who's retirement age.

I'm just happy to see the tl;dr at the TOP of the document.

I work with Kubernetes enough that I would answer to the title "kubernetes developer" and I would recommend you don't use kubernetes. In the same way I would recommend you don't use a car when you can walk.

Your friend lives 1/8 miles away. You go to see them every day so why wouldn't you drive? Well, cars are expensive and you should avoid them if you don't need them. There are a TON of downsides to driving a car 1/4 of a mile every day. And there are a TON of benefits to using a car to drive 25 miles every day.

I hate to quash a good debate but this all falls under the predictable but often forgotten "it depends". Usually do you need kubernetes == do you have a lot of shit to run.

I have a perfect solution for this, that works for me at least.

Adding a `..` to the end of a variable triggers a macro that changes `val` into something like `print("val:", val) // FIXME: REMOVE`. Then a pre-commit hook makes sure I am unable to commit lines matching this pattern.

I don't see it that way. He wanted to work there. They paid him for his time and from his account all of the passion was his own. I'm not speaking against those who just want to do what's required, but is it really wrong to hire someone who is passionate about the work?