Comic strip for 2025/11/27

Furnituremakers among you undoubtedly remember your most difficult glue-up: A countertop, bench or tabletop of unwieldy dimensions. Well, you probably won't complain again, after seeing what these folks are doing. Swiss timber company Huesser Holzleimbau, which specializes in creating glue-lam beams, recently won a contract to manufacture two burly beams for a bridge.

Twenty-eight employees (including people from the office called onto the shop floor to pitch in) worked together on the most massive glue-up I've ever seen:

Once all of the separate glue-ups were put together, the resultant part was 27.3 m (90 ft) long, with a width and height of 1320 x 1360 mm (52 x 54 in). Counting the steel brackets embedded into the beam, it weighs 24.1 tonnes (53,130 lbs)! And they made two of them.

Located in Obersaxen, Switzerland, the Lochlitobel Bridge was erected last month to span a gorge.

As for why they made it out of wood and not steel, it was actually faster and required less logistics to make it out of wood. Glue-lam beams have 1.5 to 3 times the strength-to-weight ratio of steel, and could thus be fabricated offsite, trucked to the site and hoisted into place with less equipment than would have been required with heavy steel.

"During the entire construction period, no auxiliary bridges would have been possible, and there would have been virtually no convenient detour options," writes the Canton of Graubunden, where the bridge is located. "To minimize traffic restrictions, the two wooden load-bearing girders, each weighing 25 tons and over 27 meters long, were prefabricated and then installed on site with millimeter precision. This process ensured high quality and, from the dismantling of the old bridge to the commissioning of the new one, a road closure of only eight weeks."

Claude Code Can Debug Low-level Cryptography

Go cryptography author Filippo Valsorda reports on some very positive results applying Claude Code to the challenge of implementing novel cryptography algorithms. After Claude was able to resolve a "fairly complex low-level bug" in fresh code he tried it against two other examples and got positive results both time.

Filippo isn't directly using Claude's solutions to the bugs, but is finding it useful for tracking down the cause and saving him a solid amount of debugging work:

Three out of three one-shot debugging hits with no help is extremely impressive. Importantly, there is no need to trust the LLM or review its output when its job is just saving me an hour or two by telling me where the bug is, for me to reason about it and fix it.

Using coding agents in this way may represent a useful entrypoint for LLM-skeptics who wouldn't dream of letting an autocomplete-machine writing code on their behalf.

Via Hacker News

Tags: cryptography, go, security, ai, generative-ai, llms, ai-assisted-programming, filippo-valsorda, coding-agents, claude-code

Comic strip for 2025/10/31

Amazon is reportedly leaning into automation plans that will enable the company to avoid hiring more than half a million US workers. Citing interviews and internal strategy documents, The New York Times reports that Amazon is hoping its robots can replace more than 600,000 jobs it would otherwise have to hire in the United States by 2033, despite estimating it’ll sell about twice as many products over the period.

Documents reportedly show that Amazon’s robotics team is working towards automating 75 percent of the company’s entire operations, and expects to ditch 160,000 US roles that would otherwise be needed by 2027. This would save about 30 cents on every item that Amazon warehouses and delivers to customers, with automation efforts expected to save the company $12.6 billion from 2025 to 2027.

Amazon has considered steps to improve its image as a “good corporate citizen” in preparation for the anticipated backlash around job losses, according to The NYT, reporting that the company considered participating in community projects and avoiding terms like “automation” and “AI.” More vague terms like “advanced technology” were explored instead, and using the term “cobot” for robots that work alongside humans.

In a statement to The NYT, Amazon said the leaked documents were incomplete and did not represent the company’s overall hiring strategy, and that executives are not being instructed to avoid using certain terms when referring to robotics. We have also reached out to Amazon for comment. 

“Nobody else has the same incentive as Amazon to find the way to automate. Once they work out how to do this profitably, it will spread to others, too,” Daron Acemoglu, winner of the Nobel Prize in economic science last year, told The NYT. Adding that if Amazon achieves its automation goal, “one of the biggest employers in the United States will become a net job destroyer, not a net job creator.”

Honeypots are fields that developers use to prevent spam submissions.

They still work in 2025.

So you don’t need reCAPTCHA or other annoying mechanisms.

But you got to set a couple of tricks in place so spambots can’t detect your honeypot field.

Use This

I’ve created a Honeypot component that does everything I mention below. So you can simply import and use them like this:

<script>
  import { Honeypot } from '@splendidlabz/svelte'
</script>

<Honeypot name="honeypot-name" />

Or, if you use Astro, you can do this:

---
import { Honeypot } from '@splendidlabz/svelte'
---

<Honeypot name="honeypot-name" />

But since you’re reading this, I’m sure you kinda want to know what’s the necessary steps.

Preventing Bots From Detecting Honeypots

Here are two things that you must not do:

1. Do not use <input type=hidden>.
2. Do not hide the honeypot with inline CSS.

Bots today are already smart enough to know that these are traps — and they will skip them.

Here’s what you need to do instead:

1. Use a text field.
2. Hide the field with CSS that is not inline.

A simple example that would work is this:

<input class="honeypot" type="text" name="honeypot" />

<style>
  .honeypot {
    display: none;
  }
</style>

For now, placing the <style> tag near the honeypot seems to work. But you might not want to do that in the future (more below).

Unnecessary Enhancements

You may have seen these other enhancements being used in various honeypot articles out there:

• aria-hidden to prevent screen readers from using the field
• autocomplete=off and tabindex="-1" to prevent the field from being selected

<input ... aria-hidden autocomplete="off" tabindex="-1" />

These aren’t necessary because display: none itself already does the things these properties are supposed to do.

Future-Proof Enhancements

Bots get smarter everyday, so I won’t discount the possibility that they can catch what we’ve created above. So, here are a few things we can do today to future-proof a honeypot:

1. Use a legit-sounding name attribute values like website or mobile instead of obvious honeypot names like spam or honeypot.
2. Use legit-sounding CSS class names like .form-helper instead of obvious ones like .honeypot.
3. Put the CSS in another file so they’re further away and harder to link between the CSS and honeypot field.

The basic idea is to trick spam bot to enter into this “legit” field.

<input class="form-helper" ... name="occupation" />

<!-- Put this into your CSS file, not directly in the HTML -->
<style>
  .form-helper {
    display: none;
  }
</style>

There’s a very high chance that bots won’t be able to differentiate the honeypot field from other legit fields.

Even More Enhancements

The following enhancements need to happen on the <form> instead of a honeypot field.

The basic idea is to detect if the entry is potentially made by a human. There are many ways of doing that — and all of them require JavaScript:

1. Detect a mousemove event somewhere.
2. Detect a keyboard event somewhere.
3. Ensure the the form doesn’t get filled up super duper quickly (‘cuz people don’t work that fast).

Now, the simplest way of using these (I always advocate for the simplest way I know), is to use the Form component I’ve created in Splendid Labz:

<script>
  import { Form, Honeypot } from '@splendidlabz/svelte'
</script>

<Form>
  <Honeypot name="honeypot" />
</Form>

If you use Astro, you need to enable JavaScript with a client directive:

---
import { Form, Honeypot } from '@splendidlabz/svelte'
---

<Form client:idle>
  <Honeypot name="honeypot" />
</Form>

If you use vanilla JavaScript or other frameworks, you can use the preventSpam utility that does the triple checks for you:

import { preventSpam } from '@splendidlabz/utils/dom'

let form = document.querySelector('form')
form = preventSpam(form, { honeypotField: 'honeypot' })

form.addEventListener('submit', event => {
  event.preventDefault()
  if (form.containsSpam) return
  else form.submit()
})

And, if you don’t wanna use any of the above, the idea is to use JavaScript to detect if the user performed any sort of interaction on the page:

export function preventSpam(
  form,
  { honeypotField = 'honeypot', honeypotDuration = 2000 } = {}
) {
  const startTime = Date.now()
  let hasInteraction = false

  // Check for user interaction
  function checkForInteraction() {
    hasInteraction = true
  }

  // Listen for a couple of events to check interaction
  const events = ['keydown', 'mousemove', 'touchstart', 'click']
  events.forEach(event => {
    form.addEventListener(event, checkForInteraction, { once: true })
  })

  // Check for spam via all the available methods
  form.containsSpam = function () {
    const fillTime = Date.now() - startTime
    const isTooFast = fillTime < honeypotDuration
    const honeypotInput = form.querySelector(`[name="${honeypotField}"]`)
    const hasHoneypotValue = honeypotInput?.value?.trim()
    const noInteraction = !hasInteraction

    // Clean up event listeners after use
    events.forEach(event =>
      form.removeEventListener(event, checkForInteraction)
    )

    return isTooFast || !!hasHoneypotValue || noInteraction
  }
}

Better Forms

I’m putting together a solution that will make HTML form elements much easier to use. It includes the standard elements you know, but with easy-to-use syntax and are highly accessible.

Stuff like:

• Form
• Honeypot
• Text input
• Textarea
• Radios
• Checkboxes
• Switches
• Button groups
• etc.

Here’s a landing page if you’re interested in this. I’d be happy to share something with you as soon as I can.

Wrapping Up

There are a couple of tricks that make honeypots work today. The best way, likely, is to trick spam bots into thinking your honeypot is a real field. If you don’t want to trick bots, you can use other bot-detection mechanisms that we’ve defined above.

Hope you have learned a lot and manage to get something useful from this!

---

Building a Honeypot Field That Works originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.