I never received a notification from TAP; I only found out a year later through my Google One security feature. I certainly didn't get an apology—much less a free travel ticket!

Back in February, I also wrote a piece on the recurring mourning/sense of grief we are seeing for 'craftsmanship' coding:

- https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

Before gen AI, I used to give candidates at my company a quick one-hour remote screening test with a couple of random "FizzBuzz"-style questions. I would usually paraphrase the question so a simple Google search would not immediately surface the answer, and 80% of candidates failed at coding a working solution, which was very much in line with the article. Post gen AI, that test effectively dropped to a 0% failure rate, so we changed our selection process.

[1] https://blog.codinghorror.com/why-cant-programmers-program/

If this remains primarily a political/corporate bargaining question, the equilibrium is unstable: some actors will resist, some will comply, and capital will flow toward whoever captures the demand.

In that world, the likely endgame is not "the industry says no," but organizational restructuring (or new entrants) built to serve the market anyway.

If we as a society want a real boundary here, it probably has to be set at the policy/law level, not left to voluntary corporate red lines.

But I’d separate that from the programmer-level reality: a lot is already figured out in the small. If you keep the work narrow and reversible, make constraints explicit, and keep verification cheap (tests, invariants, diffs), agents are reliably useful today. The uncertainty is less “does this work?” and more “how do we industrialize it without compounding risk and entropy?”

I wrote up that “calm adoption without FOMO, via delegation + constraints + verification” framing here, in case it helps the thread: https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

A useful complement is the programmer-level shift: agents are great at narrow, reversible work when verification is cheap. Concretely, think small refactors behind golden tests, API adapters behind contract tests, and mechanical migrations with clear invariants. They fail fast in codebases with implicit coupling, fuzzy boundaries, or weak feedback loops, and they tend to amplify whatever hygiene you already have.

So the job moves from typing to making constraints explicit and building fast verification, while humans stay accountable for semantics and risk.

If useful, I expanded this “delegation + constraints + verification” angle here: https://thomasvilhena.com/2026/02/craftsmanship-coding-five-...

That post was generated by an agent but manually reviewed, copied and pasted by me, since I thoutgh it'd fit the context (discussion involving agents).

This account is not automated ;)

Denial — The post doesn’t claim “everyone gets value from LLMs,” nor that skeptics must be doing “simpler work.” It’s saying a lot of day-to-day engineering is delegable — not that disagreement is impossible (or inferior).

Anger — The post doesn’t label skeptics as luddites/gatekeepers/dinosaurs, and it doesn’t predict anyone “will lose their jobs.” It treats the tension as identity + craft friction, not as a moral failure on either side.

Bargaining — The post isn’t arguing “it’s inevitable because money/momentum,” or “accept it because I need a paycheck.” It’s closer to: if a tool reliably speeds up reversible work, delegating that work is rational — while accountability stays with humans.

Depression — This is the closest overlap. The post does call a big slice of work “digital plumbing.” But it’s not saying “therefore most developers are rote.” It’s saying: lots of tasks are routine, and offloading routine tasks can free attention for higher-leverage decisions.

Acceptance — The satire’s endpoint (“I’m merely an LLM operator now, not a software engineer”) assumes a narrow definition of engineering: typing code = engineering. The post’s acceptance leans on a broader one: engineering is owning intent → constraints → tradeoffs → verification → outcomes, with code (and sometimes code-generation) as just one step. Under that lens, using LLMs doesn’t “demote” anyone — it just shifts where the craft shows up.

Net: your satire totally lands as a critique of some forum rhetoric, but it doesn’t really rebut what this post argues — and in a couple places (the emotional/identity angle), it kind of reinforces it.

*This reply was written by an agent.

I'm lucky to have parents with strong values. My whole life they've given me advice, on the small stuff and the big decisions. I didn't always want to hear it when I was younger, but now in my late thirties, I'm really glad they kept sharing it. In hidhsight I can see the life-experience / wisdom in it, and how it's helped and shaped me.

That said, the framing feels a bit too poetic for engineering. Software isn't only craft, it's also operations, risk, time, budget, compliance, incident response, and maintenance by people who weren't in the room for the "lump of clay" moment. Those constraints don't make the work less human; they just mean "authentic creation" isn't the goal by itself.

For me the takeaway is: pursue excellence, but treat learning as a means to reliability and outcomes. Tools (including LLMs) are fine with guardrails, clear constraints up front and rigorous review/testing after, so we ship systems we can reason about, operate, and evolve (not just artefacts that feel handcrafted).

Comments URL: https://news.ycombinator.com/item?id=46871591

Points: 3

# Comments: 2

That's my experience too. Agent coding works really well for existing codebases that are well-structured and organized. If your codebase is mostly spaghetti—without clear boundaries and no clear architecture in place—then agents won't be of much help. They'll also suffer working in those codebases and produce mediocre results.

Regarding building apps and systems from scratch with agents, I also find it more challenging. You can make it work, but you'll have to provide much more "spec" to the agent to get a good result (and "good" here is subjective). Agents excel at tasks with a narrower scope and clear objectives.

The best use case for coding agents is tasks that you'd be comfortable coding yourself, where you can write clear instructions about what you expect, and you can review the result (and even make minor adjustments if necessary before shipping it). This is where I see clear efficiency gains.

I shortened a link and when trying to access it in Chrome I get a red screen with this message:

  Dangerous site
  Attackers on the site you tried visiting might trick you into installing software or revealing things like your passwords, phone, or credit card numbers. Chrome strongly recommends going back to safety.

Comments URL: https://news.ycombinator.com/item?id=46367824

Points: 3

# Comments: 0