General-purpose tools try to serve everyone and end up with features that kinda work for most cases. Someone deep in a niche builds for the edge cases they actually encounter, and it turns out those edge cases are universal within that niche - they just weren't visible to outsiders.

What actually happens is tiered understanding. I might vibe-code a utility function (don't care about implementation, just that it works), but I need to deeply understand data flow and business logic boundaries.

The 20k LOC weekend SaaS stories are real but missing context. Either the person has deep domain knowledge (knows WHAT to build, AI helps with HOW), or it's mostly boilerplate with thin business logic.

For complex systems, the testing point is key. AI generates code faster than you can verify behaviour. The bottleneck shifts from "writing code" to "specifying behaviour precisely enough that you know when it's right". That part isn't going away.

The people I see struggling aren't the ones who don't understand their code - it's the ones who don't understand their requirements.

I work with banking data day to day and the internal systems are often just as rough. CSV exports with inconsistent date formats between the same bank's own products. Transaction descriptions that are random truncated strings with no standardisation. Every bank formats their statements differently and some of them can't even stay consistent between their own account types.

You'd think with the regulatory pressure around data accuracy this stuff would be sorted by now. But the reality is most banks treat their digital infrastructure like legacy plumbing - it works well enough that nobody wants to risk touching it.

To be fair, people actively choose to do this every day

For example, millions of people actively choose to do this for HTTP-01 ACME challenges

https://www.ietf.org/rfc/rfc8555.txt

https://letsencrypt.org/docs/challenge-types/

Certificate authorities also actively choose to do this for

1. TLS Certificates

For example, http://www.ssl.com/repository/SSLcom-RootCA-ECC-384-R1.crt

2. TLS Certifcate Revocation Lists (CRLs)

For example, http://crls.ssl.com/ssl.com-ecc-RootCA.crl

3. Online TLS Certificate Status Protocol (OCSP) responses

For example, http://ocsps.ssl.com

NB. If the statement was more specific, something like, "HSBC chose to use HTTP for return receipts in 2026" then I would have no reason to comment. Instead the statement suggests HTTP is no longer a useful nor appropriate choice for _anyone_. That of course is false, as shown above

Adding in an optional HTTPS there would not greatly increase the amount of intermediaries, though I by no means argue that it matters.

(a) it forcefully "delegates" trust to third parties, i.e., commercial CAs

(b) these CAs, for a fee, are happy to trust sites that the user would not trust if given the choice of which sites to trust, e.g., ad servers, tracking servers, etc.

(c) popular browsers pre-install (trust) third party commercial CA certificates^1

(d) popular browsers distrust the user's freely-generated CA certificates

The efforts of the user who wants to sign a small number of certificates from sites that he trusts are deliberately hindered by (d). For example, browser warnings, interstitials, TLS failures. The user is effectively discouraged perhaps even prevented from trusting himself, i.e., his own CA, while being forced to trust pre-installed third party commercial CAs

One might reason this problem could be avoided by not using popular browsers. However, website owners, and today, "Content Delivery Networks" (CDNs), attempt to coerce or force users accessing websites to use popular browsers. The CDNs terminate TLS connections and substitute their own server certificates . These certificates are signed by CAs approved by the browser vendor. This produces no browser warnings, interstitials, or TLS failures

However if the user terminates TLS connections and substitutes her own free certificate signed by her own free CA,^2 then this will trigger browser warnings, insterstitials and/or TLS failures. The practice of the user trusting herself more than third parties is deliberately hindered

From this state of affairs, one might conclude that TLS termination is acceptable under this "WebPKI" so long as the CA is approved by the browser vendor and the user is not the one doing the termination

1.

These pre-installed certificates in (c) are also distributed by a popular browser vendor as a "bundle" for installation in operating systems, non-browser software, etc.

In other words, users get these CA certificates not from the CA but from another third party, i.e., a browser vendor

But it's also possible to get the CA certificates directly from the CAs

This can be done over HTTP (cf. HTTPS)

2.

I do this using a loopback bound TLS forward proxy. I use TLS failures as an additional way to block undesired connections, e.g., to Google servers (another form of so-called "de-Googling")

The proxy performs _many_ different functions for me, allowing far more control and versatility than a popular browser. Plus I can modify and compile the proxy myself even on underpowered computers; it's only several MB. Whereas compilation of a popular browser is impractical by comparison. Compiling a so-called "modern" browser consumes too much time, CPU, RAM and storage space

One function is sending all HTTP requests over TLS, so, e.g., an http:// URL as in this story about HSBC would be sent as HTTPS^3

This applies to all software sending HTTP requests on the computer, not only browsers

I have a file that lists sites for which I do not want to go over HTTPS. This file is loaded into the proxy's memory and these sites will be forwarded by the proxy without using HTTPS. This is a short list but an important one

I use rinetd and DNS to send TCP and HTTP traffic to the proxy as opposed using the firewall. As such it's still possible to reach non-HTTPS sites via IP address, even in popular browsers

3.

If HSBC used IP addresses rather than a domain name, then this could bypass the proxy

They don't seem to have nearly the same concern for their online banking web UIs, though. Or even the UIs presented on screen at ATMs.

In my experience with bank data, on the downstream side, banking data is available in the OFX specification, which is a consistent transaction data format. Unfortunately, memo’s do get truncated to different char lengths by different banks, even though the specification allows 255 characters. AMEX, amazingly, switches NAME and MEMO properties. It's a dog breakfast of compliance, but there is a standard.

https://en.wikipedia.org/wiki/Open_Financial_Exchange

https://www.financialdataexchange.org/FDX/FDX/About/About-FD...

    OFXHEADER:100
    DATA:OFXSGML
    VERSION:102

HTTPS still typically exchanges the Server Name Identification. So you know somebody is talking to HSBC. And the rest of the URL is just an anonymized tracking ID. So I'm having a hard time seeing what the threat is this particular instance.

"Not the real HSBC", and "Also not real HSBC" respectively.

HTTPS doesn't encrypt query parameters. Content of the image itself is irrelevant, as its only purpose is to get request URL into the server logs.

The only thing outside is the hostname, if the connection is not using the latest versions

Trying to MITM an existing tracker pixel when they're connected to public WiFi sounds like practically the hardest way to do it.

In this case, sending your malicious image through a fake email might get flagged, or even not opened by someone whos been trained in infosec enough to be suspicious of these things. But a tracking pixel in an email that is verifiably from a trusted entity will be opened no problem. Type of thing that will look pretty slick if you read about it being used

Like I said, even with HTTPS everyone in the cafeteria theoretically knows you're connecting to HBSC as well.

So I don't see the difference.

It's trivial to encode each tracking pixel with a personalized hash of some sort linking it to the intended recipient of that particular email.

This is...just how tracking pixels work.

HTTPS the attackers know a conversation is happening, but no idea what

But, I personally think the threat is being overblown (I am happy to be corrected though)

The main problem seems to be tracking pixel itself to deduce involvement. The suggested approach to send email to confirm email seem better, unless it contains link to login page (as it can be phished). So, the best seems to be that one should send email that explains user how to confirm e-mail by logging manually to the app.

The flaky test problem usually comes from either race conditions (waiting for wrong things) or environmental differences. Adding AI vision on top often adds another layer of flakiness - now you're debugging "why did the model misread this button" on top of "why did the test timeout."

For mocking external services specifically - tools like MailHog (email) or mock OAuth providers tend to be more reliable than screenshot-based approaches. The determinism matters.

That said, if you genuinely need to test against production-like visual state - Playwright's screenshot comparison (toHaveScreenshot) combined with proper wait strategies has gotten pretty solid. The visual regression approach catches layout bugs that functional tests miss.

What surprised me was how much the ugly first version taught me that planning never could. You learn what users actually care about (often not what you expected), which edge cases matter in practice, and what "good enough" looks like in context.

The hardest part is giving yourself permission to ship something you know is flawed. But the feedback loop from real usage is worth more than weeks of hypothetical architecture debates.

Commenter's history is full of 'red flags': - "The real cost of this complexity isn't the code itself - it's onboarding" - "This resonates." - "What actually worked" - "This hits close to home" - "Where it really shines is the tedious stuff - writing tests for edge cases, refactoring patterns across multiple files, generating boilerplate that follows existing conventions."

> Commenter's history is full of 'red flags': - "The real cost of this complexity isn't the code itself - it's onboarding" - "This resonates."

Wow it's obvious in the full comment history. What is the purpose for this stuff? Do social marketing services maintain armies of bot accounts that just build up credibility by doing normal-ish comments, so they can called on later like sleeper cells for marketing? On Twitter I already have scroll down to find the one human reply on many posts.

And when the bots get a bit better (or people get less lazy prompting them, I'm pretty sure I could prompt to avoid this classic prose style) we'll have no chance of knowing what's a bot. How long until the majority of the Internet be essentially a really convincing version of r/SubredditSimulator? When I stop being able to recognize the bots, I wonder how I'll feel. They would probably be writing genuinely helpful/funny posts, or telling a touching personal story I upvote, but it's pure bot creative writing.

Russia and Israel are known to run full time operations doing this for well over a decade. Twitter by their own account, 25% of users are/were bots back in 2015 (their peak user year). Even here on HN if you go look at the most trafficked Israel/Palestine threads, there are lots of people complaining about getting modded into oblivion, turning the conversation into neutral/pro israel, and silencing negative comments via a ghost army of modders.

This particular piece is LinkedIn “copy pasta” with many verbatim or mildly variant copies.

Example: https://www.linkedin.com/posts/chriswillx_preparing-to-do-th...

And in turn, see: https://strangestloop.io/essays/things-that-arent-doing-the-...

Relatedly, LLMs clearly picked the "LinkedIn influencer" style up.

My guess is some cross-over between those who write this way on LinkedIn and those who engage with chatbot A/B testing or sign up for the human reinforcement learning / fine tuning / tagging jobs, training in a preference for it.

I understand that it's not the main point in your comment (you're trying to determine if the parent comment was written using an LLM), but yes, we do exist: I've spent years planning personal projects that remain unimplemented. Don't underestimate the power of procrastination and perfectionism. Oliver Burkeman ("Four Thousand Weeks", etc.) could probably explain that dynamic better than me.

My struggle is having enough patience to do any planning before I start building. As soon as there's even the remote hint of a half-baked idea in my head, it's incredibly tempting to just start building and figure out stuff as I go along.

I resist working like that because I am mega ignorant and I know I will encounter problems that I won't recognize until I get to them.

But, I also HATE having to rework my projects because of something I overlooked.

My (attempted) solution is to slog through a chat with an AI to build a Project Requirements Document and to answer every question it asks about my blindspots. It mostly helps build stuff. And sometimes the friction prevents me from overloading myself with more unfinished projects!

We currently live in the very thin sliver of time where the internet is already full of LLM writing, but where it's not quite invisible yet. It's just a matter of time before those Dead Internet Theory guys score another point and these comments are indistinguishable from novel human thought.

I don't think it will become significantly less visible⁰ in the near future. The models are going to hit the problem of being trained on LLM generated content which will cause the growth in their effectiveness quite a bit. It is already a concern that people are trying to develop mitigations for, and I expect it to hit hard soon unless some new revolutionary technique pops up¹².

> those Dead Internet Theory guys score another point

I'm betting that us Habsburg Internet predictors will have our little we-told-you-so moment first!

--------

[0] Though it is already hard to tell when you don't have your thinking head properly on sometimes. I bet it is much harder for non-native speakers, even relatively fluent ones, of the target language. I'm attempting to learn Spanish and there is no way I'd see the difference at my level in the language (A1, low A2 on a good day) given it often isn't immediately obvious in my native language. It might be interesting to study how LLM generated content affects people at different levels (primary language, fluent second, fluent but in a localised creole, etc.).

[1] and that revolution will likely be in detecting generated content, which will make generated content easier to flag for other purposes too, starting an arms race rather than solving the problem overall

[2] such a revolution will pop up, it is inevitable, but I think (hope?) the chance of it happening soon is low

Remember back in the early 2000's when people would photoshop one animals head onto another and trick people into thinking "science has created a new animal". That obviously doesn't work anymore because we know thats possible, even relatively trivial, with photoshop. I imagine the same will happen here, as AI writing gets more common we'll begin a subconscious process of determining if the writer is human. That's probably a bit unfairly taxing on our brains, but we survived photoshop I suppose

The obviously fake ones were easy to detect, and the less obvious ones took some some sleuthing to detect. But the good fakes totally fly under the radar. You literally have no idea how much of the images you see are doctored well because you can't tell.

Same for LLMs in the near future (or perhaps already). What will we do when we'll realize we have no way of distinguishing man from bot on the internet?

> What will we do when we'll realize we have no way of distinguishing man from bot on the internet?

The idea is this is a completely different scenario if we're aware of this being a potential problem versus not being at all aware of it. Maybe we won't be able to tell 100% of the time, but its something which we'll consider.

Not sure about this user specifically, but interesting that a lot of their comments follow a pattern of '<x> nailed it'

Psy-ops, astroturfing, now LLM slop.

Ironically, I see this very often with AI/vibe coding, and whilst it does happen with traditional coding too, it happens with AI to an extreme degree. Spend 5 minutes on twitter and you'll see a load of people talking about their insane new vibe coding setup and next to nothing of what they're actually building

Probably. I've been known to spend weeks planning something that I then forget and leave completely unstarted because other things took my attention!

> Commenter's history is full of 'red flags'

I wonder how much these red flags are starting to change how people write without LLMs, to avoid being accused of being a bot. A number of text checking tools suggested replacing ASCII hyphens with m-dashes in the pre-LLM-boom days¹ and I started listening to them, though I no longer do. That doesn't affect the overall sentence structure, but a lot of people jump on m-/n- dashes anywhere in text as a sign, not just in “it isn't <x> - it is <y>” like patterns.

It is certainly changing what people write about, with many threads like this one being diverted into discussing LLM output and how to spot it!

--------

[1] This is probably why there are many of them in the training data, so they are seen as significant by tokenisation steps, so they come out of the resulting models often.

> "A typo or two also helps to show it’s not AI (one of the biggest issues right now)."

The best marketing is usually brief.

There is so much to be learned about a problem - and programming in general - by implementing stuff and then refactoring it into the ground. Most of the time the abstractions I think up at first are totally wrong. Like, I imagine my program will model categories A, B and C. But when I program it up, the code for B and C is kinda similar. So I combine them, and realise C is just a subset of B. And sometimes then I realise A is a distinct subset of B as well, and I rewrite everything. Or sometimes I realise B and C differ in one dimension, and A and B in another. And that implies there's a fourth kind of thing with both properties.

Do this enough and your code ends up in an entirely unrecognisable place from where you started. But very, very beautiful.

Fred Brooks, author of “The Mythical Man Month” wrote an essay called “Plan to Throw One Away” in 1975.

He argues much what you’ve described.

Of course, in reality we seldom do actually throw away the first version. We’ve got the tools and skills and processes now to iterate, iterate, iterate.

https://wiki.c2.com/?PlanToThrowOneAway

Of course you’ll also maintain the satisfaction of doing something well.

Nice statement.

I think there is another equally pervasive problem: balancing between shipping something and strategizing a complete "operating system" but in the eyes of OTHER stakeholders.

I'm in this muck now. Working with an insurance co that's building internal tools. On one had we have a COO that wants an operating model for everything and what feels like strategy/process diagrams as proof of work.

Meanwhile I am encouraging not overplanning and instead building stuff, shipping, seeing what works, iterating, etc.

But that latter version causes anxiety as people "don't know what you're doing" when, in fact, you're doing plenty but it's just not the slide-deck-material things and instead the tangible work.

There is a communication component too, of course. Almost an entirely separate discipline.

I've never arrived at acceptable comfort on either side of this debate but lean towards "perfect is the enemy of good enough"

The most important aspect of software design, at least with respect to software that you intend not to completely throw away and will be used by at least one other person, is that it is easy to change, and remains easy to change.

Whether it works properly or not, whether it's ugly and hacky or not, or whether it's slow... none of that matters. If it's easy to change you can fix it later.

Put a well thought out but minimal API around your code. Make it a magic black box. Maintain that API forever. Test only the APIs you ship.

The plumbing also needs iteration and prototyping, but sound, forward looking decisions at the right time pay dividends later on. That includes putting extra effort and thinking into data structures, error handling, logging, naming etc. rather earlier than later. All of that stuff makes iterating on the higher levels much easier very quickly.

One of my friends calls it "development-driven development".

There is a difference between shipping something that works but is not perfect, and shipping something knowingly flawed. I’m appalled at this viewpoint. Let’s hope no life, reputation or livelihood depends on your software.

"I spent weeks planning" -- using the terminology from that book: No, you didn't spend weeks planning, you spent weeks building something that you _thought_ was a plan. An actual plan would give you the information you got from actually shipping the thing, and in software in particular "a model" and "the thing" look very similar, but for buildings and bridges they are very different.

Do a thing. Write rubbish code. Build broken systems. Now scale scale. Then learn how to deal with the pattern changing as domains specific patterns emerge.

I watched this at play with a friend's startup. He couldn't get response times within the time period needed for his third party integration. After some hacking, we opted to cripple his webserver. Turns out that you can slice out mass amounts of the http protocol (and in that time server overhead) and still meett all of your needs. Sure it needs a recompile - but it worked and scaled, far more then anything else they did. Their exit proved that point.

The "ask for contrasting perspectives" prompt is annoying specifically because it makes you process more information. The devil's advocate approach forces a second round of evaluation. Even just opening a fresh session adds friction that makes you reconsider the question.

When I'm working in domains I know well, I catch the model drifting way faster than in areas where I'm learning. Which suggests the real problem isn't the model - it's that we're outsourcing judgment to it in areas where we shouldn't be.

The uncomfortable answer might be: if you're worried the model is reinforcing your biases, you probably don't know the domain well enough to evaluate its answers anyway.

If a function does actual computation or has branching logic that could go wrong in subtle ways, unit test it. If it's mostly wiring things together (fetch data, transform, save), an integration test catches more real bugs.

The "unit test everything" era came from a time when spinning up test databases was painful. Now with Docker and in-memory DBs, integration tests are often faster to write AND more useful.

Where unit tests still win: algorithmic code, parsing, anything with lots of edge cases. Writing unit tests forces you to think about boundaries. Integration tests just tell you "it worked this time."

The worst outcome is having tests that make refactoring painful but don't catch real bugs. I've seen codebases where every internal method signature change breaks 50 unit tests that were essentially testing implementation details.

What I find interesting is how these physical displays handle the inevitable "ghost trains" in the feed - cancelled services that still show as running, or trains that briefly appear in the wrong location. The software problem is messier than the hardware.

The trap is when correctness is subjective. Tone, phrasing, whether something 'sounds right' - no automated check helps there, so you're back to reviewing everything.

For structured data like invoices, I've found pattern-matching against known values beats LLMs anyway. Less hallucination risk, faster, and when it fails at least it fails obviously rather than confidently wrong.

Started with "configure your coding rules" - let users set up how transactions should be categorised. Made sense architecturally. Nobody used it. They'd stare at the config screen and give up.

What actually worked: learn from their existing data. Pull their historical GL, reverse-engineer how they already code things, then just do it that way. No configuration, no "agent" concept. Upload bank statement, get coded transactions back.

The insight that killed our complexity was realising bookkeepers don't think in rules. They think in outcomes. "This should be coded like the last time we saw a payment from Stripe" not "if merchant contains 'stripe' and amount > 100 then category = payment processing fees".

Curious about your MCP orchestration layer - how do you handle cases where the described workflow is ambiguous? In accounting there's often multiple valid ways to code something.

Would love to swap notes on the accounting side. Similar problems, different domain constraints.

The domain-specific wrinkle for accounting: every firm has their own coding style. What one bookkeeper calls 'Office Supplies' another calls 'General Admin'. So we had to build pattern learning at the individual level - watch how each person codes, learn their preferences, then apply that to new transactions.

The tax rules (VAT in the UK) add another layer - sometimes the same merchant gets different VAT treatment depending on what you bought. Gets messy fast.

Would be happy to swap notes - feel free to reach out. Always interested in how other domains handle the 'close enough to be useful, flexible enough for edge cases' problem.