あざらし🦭 retweeted
As you invite more agents to our work, and create software factories to be more productive than ever, you’ll soon outsource everything to an agent, even the thinking.
The work you will do will feel frictionless, it will feel amazing on the surface, but once you go a bit deeper, it’ll feel extremely shallow. It won’t reflect the struggles you went through, your decisions, and ideas.
It will no longer remind you of you and the work you aspire to.
You will turn into just another extremely efficient producer of things, but not a creator like you were before.
Invite friction to your work.
あざらし🦭 retweeted
i love writing. i never let agents write for me. whether it's docs, or tweets, or shitposts, or even prompts (okay maybe that one's harder as agents manage other agents)
there's a simple reason for that: i still strongly believe that writing is thinking. it's a skill i hope to never give up. it's also important to me that whatever i say is always authentic, mistakes and all. my favorite posts are the ones that i just full send without any editing
i suspect it also helps with prompting. being able to clearly express what i want, and knowing the vocabulary i need to be able to direct my agents does seem to make for more effective usage of agents. in the same way that engineers have an advantage when we prompt agents to write code, because we are intimately familiar with the words that make up the discipline
knowing the right word incantations to get an agent to produce a desired goal almost feels like spellcasting. as models get more capable, and that input box looks more and more like a magic box that can output anything, words become the interface between you and the genie
there may come a time when we give up the keyboard in exchange for brain-computer interfaces. but until then, i'm writing every word.
あざらし🦭 retweeted
But how do we keep encouraging and incentivising third-party developers who want to make a useful and thoughtful change to an open source repo?
They might have used an AI agent, been assisted by AI, or handcoded the code update. This doesn't matter for this particular point. External developers and users still have something of value to provide, surely? Beyond the Issues tab, beyond DMs, beyond making suggestions on a roadmap.
To guarantee the long-term future of open source, we need to make this work. And for cybersecurity. To keep open source libraries secure — with rapid and thorough patching of vulnerabilities — we need third-party contributions. For as long as we have hallucinations and errors, AI agents won't find and fix everything, just like humans.
Third-party developers have expertise and real value beyond the subjective taste, quality standards and gatekeeping of core maintainers.
There is a real danger that open source and FOSS become merely source available.
あざらし🦭 retweeted
I see this less as GitHub failing and more as open source evolving.
The current workflow is increasingly absurd: someone uses AI to generate a PR, I use a better AI to review it, then their AI and my AI go back and forth until we converge. Add AI-generated spam on top, and the human is mostly just acting as a router between agents.
I’d rather skip that entire loop.
Imagine you use a project and want a feature. You go to the repo and describe what you want. The project’s AI already knows its conventions, preferences, history, rejected ideas, and boundaries. It can immediately tell you whether the idea is likely to fit and what shape it should take.
If it makes sense, you press a button and the project’s chosen AI implements it, validates it, and presents the maintainer with the request and the code as one thing.
No separate issue. No PR ping-pong. No two AIs talking through two humans.
What AI still canot replace is taste: deciding what a project should be, what belongs in it, and where its boundaries are.
markdownのTUIビューワーを作った
$ mdcat README.md docs/*.md
$ mdgit show d34db33f
$ mdgit diff branch/update-sugoi-skill..main
それぞれcatとgitコマンドのサブセットになっていて、特に仕様駆動開発とかでmdの差分を良い感じに描画する目的で使ってます。
github.com/shqld/mdcat
あざらし🦭 retweeted
手抜き作業は概念が変わったとShopifyのTobi Lütkeが語る。
昔はアウトプットを全然出さない人だったのが、AI時代ではアウトプットを出しすぎて周りの人に確認作業を増やすのが手抜き作業であると主張。
あざらし🦭 retweeted
New experiment: json-render + jev
The future Generative UI is instant
Your components, your actions, your design system
Rendered in milliseconds
あざらし🦭 retweeted
I recently helped someone with old React 16 codebase. I forgot how clean and simple React was back then when it took over web frontend.
Hooks were a huge mistake, even bigger than trying to get React to the servers. Insane complexity just to not use classes.
わかる。
人間用の閲覧・操作UIとしては一番最適な選択肢だと思う。
ただ願わくはNotionデータベースくらい汎用的でかつLinearくらいUIの出来の良いサービスがほしい気持ち。
TSのBranded型をnewtypeと呼べるのか考えてみたが、TSは部分型があるので例えばUserId <: stringのときにUserIdをnewtypeと呼んでいいんだっけ？となった🤔
> 代数的データ型のある言語では価値が目減りしています。Value Objectの規律はnewtypeと網羅的matchで代替可能
DDDやクリーンアーキテクチャについてFableが実際のところどう思っているか？
--
結論から言うと、どちらも「本物の洞察」と「儀式化した部分」の抱き合わせで、価値の分布が極端に偏っています。分けて評価します。
DDDで今も第一級の価値があるのは戦略的設計の側です。Bounded Context、ユビキタス言語、コンテキストマップ、core/supporting/genericのサブドメイン分類。「大規模ドメインの統一モデルは幻想で、モデルは言語とチームの境界に沿って割るべき」という洞察は20年経っても摩耗しておらず、マイクロサービスの境界設計やチームトポロジーの理論的基盤は実質的にここから来ています。特にサブドメイン分類は、設計投資をどこに集中させるかを決める道具として最もレバレッジが高いのに、最も使われていない。
一方、戦術的パターン(Entity / Value Object / Repository / Factory)の大半は2003年当時のJava/OOPの制約の産物で、代数的データ型のある言語では価値が目減りしています。Value Objectの規律はnewtypeと網羅的matchで代替可能で、しかもコンパイラが強制する。"Make illegal states unrepresentable"の方が、VOのセレモニーより少ないコードで同じ目的を達成します。Wlaschinが示した通り、DDDの本質はクラス階層より型で表現した方が忠実です。Evans自身が「みんな戦術パターンばかり見る」と繰り返しぼやいているのは示唆的で、Repositoryの下にORMを包み、貧血モデルにマッピング層を重ねるだけのいわゆるDDD-liteは、DDDの失敗というよりDDDの不在です。
例外はAggregateで、これは型システムで代替できない唯一の戦術概念だと考えています。本質は「どの不変条件に強整合が必要で、どれを結果整合に落とせるか」というトランザクション境界の設計判断であり、これは今でもドメイン設計の核心です。同時に最も誤用されやすい概念でもあり、大きすぎればロック競合、小さすぎれば不変条件が漏れる。
Clean Architectureは、率直に言えばHexagonal(Cockburn, 2005)とOnion(Palermo)の統合とリブランドで、中身よりブランディングの勝利です。核の主張——依存は内向き、ドメインはインフラを知らない——は依存性逆転のアーキテクチャ規模への適用で、これ自体は健全。ただし本の内容は影響力に比して薄く、核心は2012年のブログ記事一本に収まります。実害は同心円図が「4層ディレクトリ+全境界にinterface」という様式として機械的に複製されること。実装が永遠に1つしかないtrait、DTOマッピングの山、1フィールドをHTTPからDBまで追うのに5ファイル。これは投機的抽象化で、行使しないオプションにプレミアムを払い続ける行為です。
中でも「DBは詳細」は同書で最も疑わしい主張です。多くのシステムではデータモデルこそ重心で、Postgresを差し替える日は来ない。しかもRepositoryの裏にDBを隠すと、トランザクション設計やクエリ最適化といったDBの強みを捨てがちになる。sqlxのコンパイル時検証クエリのような道具の価値がtrait境界の裏で死ぬのは典型例です。守る価値があるのは「依存の向き」と「ドメインコアの隔離」だけで、リングの数や用語の正統性はどうでもいい。そしてRustならこの依存規律はcrate分割で静的に強制でき、違反がレビューコメントではなくコンパイルエラーになる。人間の自制心にレイヤー規律を頼る原典の姿より、こちらの方がよほど筋がいい。
エビデンスについても正直に言うと、どちらも効果を示す実証研究はほぼ存在しません。ソフトウェア方法論全般がそうですが、これらは経験豊富な実務家のもっともらしい逸話であって科学ではない。だから信奉やアイデンティティの対象にすべきではなく、経済性の問題として扱うべきです。間接層・儀式・学習コストというプレミアムを払って「特定の変更が安くなる権利」を買う取引であり、付随的に、共有語彙と予測可能な構造がオンボーディングコストを下げるという調整価値もある。不変条件が複雑で寿命の長いドメイン——金融、会計、規制対応——ではオプションがほぼ確実に行使されるので買う価値があり、ジェネリックなCRUDサブドメインで買うのはただの損です。
まとめると、戦略的DDDは本物、戦術的DDDはAggregateを除き型システムで大半代替可能、Clean Architectureは正しい原則1つ+過剰な処方箋。実務の最適解は「戦略的DDD+型駆動モデリング+依存規律のcrate構造による静的強制」あたりに収束する、というのが私の評価です。
これを実践するぞ……！
はてなブログに投稿しました
私が懇親会でぼっちになったらやること - 腹は減る blux.hatenablog.com/entry/20…
#はてなブログ
あざらし🦭 retweeted
消費者庁が公開してる「消費者騙すダークパターン例」の15個を全て網羅したドメイン取得サイト（デモ）を作ってみた！！
project.activetk.jp/dark-dom…
