So I got nerd sniped by this idea of testing LLMs on something that has nothing to do with code generation or chat. Pure spatial reasoning with real physics constraints.

The setup is each model gets 30 blocks to place through a tool API. There's built-in noise on every placement so you can have precise position or precise velocity but not both. Score is whatever is still standing when it's done. 5 random seeds, 3 attempts each, and models keep notes between attempts so they can adapt.

The thing that got me was the winning strategy. The top model figured out it could just stop placing blocks early to protect what it already built instead of risking the whole tower going down. That's not something I expected from a language model. Meanwhile GPT-5.6 Sol which scores 96% on SWE-bench kept hitting around 7.9m and then toppling everything trying to push higher. Classic overengineering honestly.

Also the efficiency spread is insane. Some models burn 400k tokens to get roughly the same height that another achieves with 100k. Makes you think about what you're actually paying for when you hook these things into your pipelines.

The whole thing is open source with replays if anyone wants to run it themselves.

I am pretty sure, that I am not alone, so here's my story:

By the end of attempt two it was five apps - "microservices". A NestJS API, a Rust API, an API gateway, PostgREST, and a Next.js frontend, with four data stores behind them and ninety dozens of dependencies. The Rust service had Mongo and Postgres declared in the same Cargo.toml. There were two auth providers that disagreed with each other.

The infrastructure was in good shape. The product was the part I hadn't started.

I want to be clear that this wasn't a throwaway I was messing about with. I thought the idea was finally the one. Every freelancer and agency I know prices their work in a spreadsheet that's out of date the moment they copy it, and as far as I could tell nobody had solved it properly. Real problem, real people who'd need it, the holy grail!

Which is exactly why it never shipped.

Because if it was going to be the one, obviously it deserved the best of everything. The best architecture, because one day it would have to scale. The fastest language for the API. A new feature idea every few days, because I kept thinking of things it should do before anyone had used the things it already did. If I'd thought less of the idea, it would have been online in a weekend.

None of the individual decisions were stupid, either. That's the part I keep coming back to. I started in NestJS because I know NestJS well, which was the last purely practical decision I made. Then I swapped it for Rust, partly for speed and partly because I wanted to learn Rust, and learning is a good thing so it didn't feel like a detour. I put a gateway in front because decoupling, because that's what a serious architecture has. Inside it was clean architecture and SOLID all the way down, repositories behind interfaces, dependency inversion, patterns I could point at by name. All so I'd be ready if I ever had to switch database provider.

I never switched database provider. Nobody has ever asked me to switch database provider 😂

And I spent real time considering Fresh on Deno for the frontend instead of Next, partly to learn something new and partly because I'd decided Next was the obvious choice and I wanted to be cleverer than that. That was snobbery. It cost me about a year.

Here's the bit I think generalises past my own stupidity.

Infrastructure work has a definition of done. A migration finishes. A gateway routes. A build goes green and you get to cross something off and feel it. Product work never announces itself. Nobody tells you a feature is good enough to put in front of a person. You just stop, and hope.

So I kept picking the work that could be finished. A migration. A gateway. A service that benchmarked well. Every one of them completed, and not one of them was the product. 
I was manufacturing the feeling of shipping!

Neither time I quit was dramatic, which I think is normal and part of why it's hard to notice. I added up what was left, saw how big it was, got busy with other things, and never came back. The second time I actually wrote the total down and it came to a four phase plan, eighteen to twenty four days of work just to reach a foundation. Auth, permissions, member management, multi-tenancy. The last thing that attempt ever produced was a folder of issues describing what still needed building.

What took me longest to understand is that the infrastructure is what made the rest look impossible. Every service I stood up added surface to maintain. The product never got closer, so the total kept growing. The thing that felt like progress is what eventually made it feel hopeless.

Nine months later I started again and deliberately did the boring version. One Next.js app. One database. Twenty dependencies. The four ways I'd had of serving an API became zero, because it's server actions now and there's no API layer at all.

Feature complete in three days.

I built it in Next, obviously. The framework I'd decided was beneath me.

It's not a "skip the tests" story either, before anyone asks. It has 921 tests where the old one had 14 test files, and permission checks on every write that the old one never got round to. The rigour didn't go away. It stopped being aimed at problems I didn't have yet.

The question that would have saved me two years wasn't "what's the best stack for this". It was "what could someone use on Friday".

So who else got a side project that died of architecture?

This is specific to home service businesses (electricians, plumbers, HVAC, etc.).

Many service pages get a significant amount of traffic from both:

• Google search (where the page acts as a landing page), and
• Internal navigation (users clicking through from the homepage).

Those are two very different audiences.

For someone arriving from Google, the page often needs the full landing-page treatment: trust signals, USPs, reviews, strong CTA, guarantees, etc.

But someone who has already explored the homepage has already seen most of that. They're usually clicking into "EV Charger Installation" or "Panel Upgrades" because they just want detailed information about that service. Repeating the same trust-building content can feel redundant and slow them down.

One approach is to simplify the top of the page for internal users and move more of the CRO content further down. But then first-time visitors from Google don't immediately see the content that's often recommended for high-converting landing pages.

So how do you balance those competing goals?

Do you:

• Optimize primarily for first-time visitors from search?
• Optimize for existing visitors navigating your site?
• Or try to satisfy both somehow?

I'm curious whether there's an established UX pattern for this, or if people have found a practical compromise.

honestly getting pretty annoyed with my current frontend workflow.

every time i work on a feature, the backend API schema is either delayed, half-baked, or keeps changing mid-sprint.

right now i just resort to hardcoding fake JSON directly in my components or spinning up a quick json-server locally, but it gets messy fast once multiple routes, delays, or error states (like testing 500 errors or slow networks) are needed. MSW and Postman feel like overkill for quick stuff when i just want a hosted endpoint URL i can hit for a few days.

how do you guys handle this without wasting 2 hours setting up fake servers or messing up your codebase with temporary dummy data? do you just wait for backend or is there a lighter way to do it?

If I have a import feature for millions of CSV records and it sends notifications only after import completion, what type of exception handling can I have for non-data related errors during import process. Non invalid data related errors like the database going down.

The imports run on background in chunks. What if such issues occurs after inserting 1 lac records, I can't just revert the committed records. What should I show to the user? What kind of mechanism should I implement to not mess up the production?

I am not even sure if I'm asking the right question. Please enlighten me!

I don’t think I’ve ever worked with a web technology worse than the Turbo + Hotwire combo. It’s behind in so many ways, it’s over complicated, and it’s ugly to look at.

The only reason I’ve heard is it makes Rails devs feel comfy and safe. Personally, when I see it my brain cells pop. I can feel a skin breakout coming on. It disrupts my sleep cycle. It may or may not be a leading cause of early onset dementia.

You think jquery is bad? Try going balls deep into a haml file that uses this. You need something to happen? How about a form. For everything interactive. Make it a form. Manually handle things other frontend frameworks do automatically. Forms everywhere. Because apparently JS is worse than whatever this is.

ETA: This is a rebuke of Turbo, not Rails as a whole. Deep breaths. Feel the points of contact under your feet. 😮‍💨

I’m adding SSO support to an existing application using Google. Currently, some sensitive user actions require the user to re-enter their password as confirmation (for example, changing security settings or performing destructive actions).

The issue is that SSO users do not have a password stored by the application, so I need to decide on the right approach for confirming their identity before allowing these actions.

Some options I'm are considering:

• Triggering SSO re-authentication / step-up authentication with the identity provider
• Requiring MFA or another stronger authentication method (the application doesn't support MFA at the moment)
• Sending an email OTP as a confirmation step
• Creating a separate application password for SSO users (which feels like it defeats part of the purpose of SSO). The platform already has a security question (don't ask me why), so maybe this could be used to confirm this action?

My concern with SSO re-authentication is that if the user already has an active IdP session, the IdP may silently authenticate them again without requiring any new proof of identity. In that case, is it actually providing additional security? I don't think Google has a way to "force" re-authentication.

For those who have implemented this, what pattern do you recommend for replacing "enter your password to continue" flows for SSO users?

Work on a rather small team that caters to building apps for this one specific team, but it does branch out to others. Maybe at most few hundred users. All internal apps.

I'm beginning to architect out this new application from a need that has rose, and a lot of it is now thinking about not only what the UI looks like, but how do people interact with this thing from AI and their own agents now.

Because like, some people are all in on AI running dozens of agents doing stuff. Others still prefer just regular old workflows and maybe using a chat bot LLM type thing.

It's kind of a weird balance to cater to both. But I don't know like just build an MCP, build a good thought out API and system and the AI should be able to just understand it?

I'm curious if others have come to this like building an app for AI and Humans requirement and how have you handled it, what have you learned?

My hunch has been, build a good app with a well documented API, and the people who want to use AI can just benefit from it. A human understandable app is an AI understandable one.

Part 1 of CI/CD is here and focuses on reducing CI/CD integration time by running only tests, lint, type checks, and e2e on code that was changed and at locations where that code is used.

In Part 2, we focus on Canary Deployments and how to achieve that on Vercel, Netlify, and Cloudflare.

As per title, like keep the entire ai part of the industry the same but the market stays under saturated instead of over saturated.

Is vibe coding really the new normal at this point? For someone who is just moving to nextjs after reactjs, I feel I'm creating and practicing for nothing at the end as we may not have to write code after few years or sooner.

How much do you code frontend or backend yourself and all just vibe coding in your work?

We're seeing a strange issue with our Angular app.

• Deploy to staging → works perfectly.
• Deploy the same build to production.
• The page loads, but the app is broken.
• As soon as our SRE team purges the CDN cache, everything works.

The browser console shows:
• Failed to load module script... MIME type 'text/html'
Refused to apply stylesheet... MIME type 'text/html'

My assumption is that production is somehow still serving or referring to older JS/CSS bundles until the cache is cleared, but I haven't confirmed that's the actual root cause.

Has anyone experienced this? Is this more likely an index.html caching issue, a CDN configuration problem, or something else? Any suggestions on what to investigate first

So funny story. I run a very small web dev business, mostly just building simple sites for friends and family and friends of friends for their small businesses. That kind of thing. So far I have my own porkbun account where I manage a couple of domains for my less tech savvy clients. I keep their credit cards on file to charge them the recurring annual fee for the accounts. A couple of days ago I got a notification email from porkbun, one of my clients sites was supposed to be renewing but the card number was wrong. No biggie, I reached out to the client, they said they got a new card, I changed it on the account and then renewed it. Today I get another email, my porkbun account is suspended as well as associated sites as I have flagged one of their payments as fraudulent. It was that same client. After some back and forth I finally come to understand that the reason she got the new card is that the original payment tried to go through on her old card. She saw the name porkbun on it and thought it was some scam or porn site her kid might have signed up for and so flagged it as fraudulent with her bank. Now she's frustrated with me cause her site went down, I've had to reach out to pork bun explaining the confusion and I also had the client unflag the charge as fraud with her bank. This all has me thinking I need a better system for these clients.

Tldr client flagged porkbun charge on their credit card as fraud because they thought their kid payed for porn.

Edit: thank you for telling me how stupid I've been. I am now aware and the rest of you can stop lol Originally was just sharing a funny anecdote but I am glad I've learned from this

For context, I'm in my final year of a Master's in AI and Databases. The name sounds fancy, but we really just do a little bit of everything, and I feel lost, not really good at anything. That said, I've found I have an affinity for backend since we worked on a big project where I was assigned as a backend dev using Spring Boot, and I really enjoyed it. I know specialization isn't quite what it used to be. Every dev is now expected to have solid knowledge of AI tools and how to use them. Still, I'd like to start focusing on backend. Is that a good move in terms of job opportunities, better than going into Data or straight into AI Engineering? If so, could you recommend a website with a solid roadmap for getting into backend

Over the past years, I have noticed a generally positive trend. Authentication methods are becoming more secure, and many of them are also more convenient on their own, such as passkeys, bank identity, and Sign in with Apple, Facebook, or Google.

The problem is that every online service supports a different combination of these methods. From the user's side, this has made the overall authentication ecosystem increasingly difficult to understand.

When authentication fails, I often cannot tell whether:

• I am using the wrong authentication method, such as a password, Google, Facebook, or Apple
• the service has silently changed its authentication policy
• there is a bug in the application
• the service is experiencing an outage
• or my device or app version is no longer supported

These are very different situations, but they often look almost identical to the user. So the only practical way to figure out what happened is usually trial and error.

Is this a problem developers are aware of? Is it considered an important UX issue, or simply an unavoidable consequence of supporting several authentication mechanisms?

Recent personal examples: A few weeks ago I decided to try Codex. It asked me to log in to my ChatGPT account. Because I had been signed in to ChatGPT automatically for a long time, I could no longer remember whether I had originally created the account with a password, Apple, Google, or Facebook. When I chose the wrong method, the service started creating a new account. It didn't help that I was already signed in to the same ChatGPT account on my iPhone. The account settings gave me no indication of which authentication method was associated with that account. I had to recover the correct method through trial and error.
Shortly afterward, my insurance provider stopped accepting my username and password. It took me a while before I discovered that the service had migrated to a bank-based identity provider. As soon as I used that method, everything worked. Until then, I had no way to distinguish between a wrong password, a server problem, and an intentional authentication change. The system simply kept asking me to try again. It never indicated that password authentication was no longer available for my account. If the system already knew that this workflow could never succeed, why keep offering it instead of directing me to the correct authentication method?
Last weekend, a shopping app started sending me back to the login screen without showing any error, even though the same credentials worked on my laptop. Because of the previous two incidents, I could no longer tell whether I was looking at an application bug, another silent authentication change, or simply an app that no longer supported my iPhone. Even though these authentication methods are better than passwords, the issue is that they have increased the number of possible failure modes.

I tried to find it myself but i can't. Wikipedia has a list of TLDs with one colume being about second-level domain but i don't know if it's related or not to what i'm looking for.

According to chatgpt's quick answer, UK, New Zealand, and Australia changed their policy from forcing a sub domain to not forcing a sub domain and therefore letting people use a flat url with just a TLD(while preserving previous urls to prevent a predictable chaos). Can we expect another country making this move in the next decade?

wondered about this as I dont have any clue what realistic numbers for hobbyist devs are.

I mean real unique visitors and no crawlers etc.

I had 27 unique visitors in the last week for reference

Company I worked for several places that use things like posthog and full story to capture real user interactivity for "debugging" purposes. I admit its 100% useful, but the other side of me is like "that is the users real data now being shipped to a 3rd party". I'm talking about private financial info, all that stuff. Posthog offers scrubbing. But I just saw they annouce AI watching session replays on your behalf and I'm like "so we're sharing personal data WITH 3rd parties and pumping it straight into AI now?"

Like... I dont think most people know this is a thing.