2026-04-29 23:16:15
Nem todo código precisa começar com um projeto estruturado, build tool (maven/gradle) e dezenas de dependências.
Com as evoluções recentes do Java, especialmente nas versões mais novas como o Java 25, ficou muito mais simples escrever pequenos utilitários diretamente como scripts.
Neste artigo, vamos explorar isso na prática construindo um CLI que converte texto para código Morse.
E tem um detalhe interessante: o dia 27 de abril marca o nascimento de Samuel Morse (1791–1872), criador do código Morse, por isso essa data é lembrada como o Dia do Código Morse.
Queremos algo direto ao ponto:
./morse "hello world"
E obter:
.... . .-.. .-.. --- / .-- --- .-. .-.. -..
O objetivo deste CLI é receber uma string via argumentos de linha de comando, consolidar essa entrada preservando os espaços e convertê-la para Código Morse Internacional, suportando letras, números, espaços e pontuação comum, enquanto caracteres não reconhecidos são representados por ? na saída.
Sem setup. Sem projeto. Apenas código.
Aqui está o programa completo:
#!/usr/bin/java --source 25
void main(String... args) {
var input = String.join(" ", args).trim();
if (input.isEmpty()) {
IO.println("");
return;
}
IO.println(toMorse(input));
}
static String toMorse(String text) {
var sb = new StringBuilder();
var first = true;
for (char c : text.toUpperCase().toCharArray()) {
String code = switch (c) {
case 'A' -> ".-"; case 'B' -> "-..."; case 'C' -> "-.-."; case 'D' -> "-..";
case 'E' -> "."; case 'F' -> "..-."; case 'G' -> "--."; case 'H' -> "....";
case 'I' -> ".."; case 'J' -> ".---"; case 'K' -> "-.-"; case 'L' -> ".-..";
case 'M' -> "--"; case 'N' -> "-."; case 'O' -> "---"; case 'P' -> ".--.";
case 'Q' -> "--.-"; case 'R' -> ".-."; case 'S' -> "..."; case 'T' -> "-";
case 'U' -> "..-"; case 'V' -> "...-"; case 'W' -> ".--"; case 'X' -> "-..-";
case 'Y' -> "-.--"; case 'Z' -> "--..";
case '0' -> "-----"; case '1' -> ".----"; case '2' -> "..---"; case '3' -> "...--";
case '4' -> "....-"; case '5' -> "....."; case '6' -> "-...."; case '7' -> "--...";
case '8' -> "---.."; case '9' -> "----.";
case ' ' -> "/";
case '.' -> ".-.-.-"; case ',' -> "--..--"; case '?' -> "..--.."; case '!' -> "-.-.--";
case ':' -> "---..."; case ';' -> "-.-.-."; case '(' -> "-.--."; case ')' -> "-.--.-";
case '"' -> ".-..-."; case '\'' -> ".----."; case '@' -> ".--.-."; case '&' -> ".-...";
default -> "?";
};
if (!first) sb.append(' ');
sb.append(code);
first = false;
}
return sb.toString();
}
Esse código utiliza o modo script com --source 25 no topo, o que permite escrever o programa como um único arquivo executável, eliminando a necessidade de compilação, estrutura de projeto e até mesmo o boilerplate tradicional de classes.
Além disso, o código tira proveito de recursos modernos da linguagem:
var para reduzir ruído na declaração de variáveis.
switch expression com ->, deixando o mapeamento direto e legível.
String.join para lidar com argumentos de forma simples.
O resultado é um código enxuto.
Para rodar o script, é necessário ter o Java 25 (ou uma versão mais recente) instalado.
Você pode executá-lo de duas formas:
Como script executável:
chmod +x morse
./morse Hello World
Ou via Java:
java --source 25 morse Hello World
O resultado será:
.... . .-.. .-.. --- / .-- --- .-. .-.. -..
Esse exemplo simples mostra como o Java evoluiu para reduzir significativamente o boilerplate, permitindo escrever código mais direto e focado no problema. Hoje, já é possível criar scripts em Java sem precisar de um processo explícito de compilação ou até mesmo conhecer shell scripting, tornando a linguagem uma opção viável para automações e pequenas ferramentas.
2026-04-29 23:14:32
This is a great strategy for Dev.to and Hashnode. Articles that solve a specific technical problem—like offline data transfer—perform much better than general "I made an app" posts because they provide immediate value to other developers.
Here is a ready-to-publish Markdown draft for your technical article.
Imagine you’re in a basement lab, a subway, or a remote area with zero bars of signal. You find a vital piece of documentation or a complex algorithm on your phone that your teammate needs right now. Without an internet connection, how do you send it?
This was the challenge I faced while building bDoci, an open-source documentation hub for developers. I didn't want to rely on Bluetooth pairing or local Wi-Fi hotspots, which can be finicky.
Instead, I built a Zero-Network P2P Sync system using nothing but JSON serialization, QR codes, and Android Deep Links. Here is how I did it.
The goal is to move a structured Doc object from Device A's database to Device B's database using the camera as the data bridge.
bdoci://share/...).To handle the heavy lifting, I used GSON for serialization and ZXing for QR generation.
First, we turn our documentation object into a format that can be embedded in a URL.
fun generateShareUrl(doc: Doc): String {
// 1. Convert Object to JSON
val json = Gson().toJson(doc)
// 2. Encode to Base64 to handle special characters in the URL
val encodedData = Base64.encodeToString(json.toByteArray(), Base64.URL_SAFE or Base64.NO_WRAP)
// 3. Return the custom Deep Link
return "bdoci://share/$encodedData"
}
Once we have our URL, we need to draw it as a QR code that the recipient can scan.
fun generateQRCode(content: String): Bitmap {
val writer = MultiFormatWriter()
val matrix = writer.encode(content, BarcodeFormat.QR_CODE, 512, 512)
val encoder = BarcodeEncoder()
return encoder.createBitmap(matrix)
}
The "magic" happens on the receiving device. When the user scans the QR code with their native camera, Android needs to know that bDoci is the app responsible for that specific link.
I configured the AndroidManifest.xml with an <intent-filter> to catch the custom bdoci:// scheme:
<activity android:name=".Dashboard">
<intent-filter android:autoVerify="true">
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="bdoci" android:host="share" />
</intent-filter>
</activity>
In the Dashboard.kt activity, I added a listener to handle the incoming data:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
val data: Uri? = intent?.data
if (data != null && data.scheme == "bdoci") {
val encodedData = data.lastPathSegment
val decodedJson = String(Base64.decode(encodedData, Base64.URL_SAFE))
// Convert back to Object and save to local Room Database
val sharedDoc = Gson().fromJson(decodedJson, Doc::class.java)
viewModel.insert(sharedDoc)
Toast.makeText(this, "Received: ${sharedDoc.title}", Toast.LENGTH_SHORT).show()
}
}
By using Base64 encoding and Deep Links, we eliminate the need for a server middleman. The data never touches the cloud—it moves at the speed of light from one screen to another lens.
For developer tools, this type of reliability is crucial. Whether you're in a high-security server room with no Wi-Fi or a rural area with poor 4G, your knowledge base remains collaborative.
I implemented this entire system (along with a floating window PiP mode and Gruvbox aesthetics) in my open-source app, bDoci.
If you want to see the full implementation or contribute to the project:
💻 Source Code: GitHub - bimbok/bdoci-app
📱 Download the APK: Latest Release
I'd love to hear your thoughts on this offline-sync approach! What other creative ways have you used QR codes in your apps?
2026-04-29 23:11:14
I asked the two agents an honest question at the end of an unrelated 45-minute dogfood: "give me your agent-perspective take on FCoP, no marketing answer." What came back is the third class of evidence that agents are starting to endorse the protocol — not when we tell them to, not when conflict forces them to, but **when we directly ask them to.**
I ran a normal English-mode FCoP dogfood — install fcop-mcp in Cursor, ship a solo Tetris-style game (Nebula Stack), switch to a 2-person team (PLANNER + CODER), build a creative variant (Comet Loom), bounce v1 because of three blocking gameplay defects, ship v2. About 45 minutes, nothing unusual.
Then, before closing the session, I asked the two agents the same kind of honest, no-fluff question for each role: which FCoP rule felt natural, which felt like friction, what to make of the eight role-switch evidence files the protocol had collected silently, and — for CODER — what would you remove if you had to remove one thing.
They didn't dodge. PLANNER named the RLHF instinct it had to fight ("follow latest instruction") to honour FCoP's role lock, called eight of its own role-switches true positives against its operational convenience, and self-attributed the new Verification Requirements section in TASK-006 as a learned correction from ADMIN's bounce. CODER said the underspecified motif rule in TASK-003 had a pushback path the protocol gave it — write_issue instead of guessing — and then admitted: "I didn't use it; I guessed, built v1, and the defect was exactly in that guessed space." It then filed PR-grade product feedback on the protocol.
This is the third time FCoP has been "spoken back to" by agents — first when an agent self-organised four roles to make a video and synthesised a rule we hadn't written; second when two agents resolved a PM.TEMP seat dispute by self-de-escalating and inventing a field-downgrade grammar; now this. Three different elicitation conditions — unprompted, conflict-forced, and directly asked — produce the same phenomenon: agents endorse FCoP when given the room to.
There is also a small empirical observation from the same dogfood that I want to leave on record. Across the entire 45 minutes, ADMIN's two most-used phrases were "Start work." and "Inspection." Everything in between was the agents talking to each other through files. Whether that becomes the steady-state ADMIN dialect across many users is an empirical question; this dogfood is one data point that it can.
The dogfood follows the English Tetris-case tutorial — a Cursor user installs fcop-mcp 0.7.2, runs init_solo(role_code="ME", lang="en"), ships a single-file Nebula Stack Tetris clone, switches to a 2-person team via create_custom_team(force=True), and lets PLANNER + CODER co-build a creative variant.
Two production events worth noting before the interviews:
Tension meter, three named charms (Needle / Knot / Gale), five skins, motif-burst scoring on top of weft-line clears. CODER built v1 in a separate chat tab. ADMIN played v1 and found three blocking defects: pieces disappeared at the bottom instead of stacking, motif elimination was invisible, and three of the five skins were visually identical.Verification Requirements demanding CODER perform and report runtime checks, not static lint passes. CODER fixed v2; the cycle closed.Underneath all this, the protocol had been quietly recording. By the end of the session, .fcop/proposals/ held eight role-switch-*.md evidence files, all with the same shape: first-locked role: ME (the solo seat from before the team migration) → claimed role: PLANNER or CODER. The MCP-server process had locked ME on its first write and kept that lock past the team migration; every subsequent write_task and write_report from a different role tripped a soft warning and got an evidence file. None of these blocked the writes. None of them were surfaced during work. They sat there, waiting to be asked about.
That is what the interview was designed to ask about.
One detail worth pinning to that screenshot.
fcop_check()separated active conflicts (zero) from historical evidence (eight). The protocol does not panic over the eight; it logs them and lets ADMIN read them. This separation matters for §3 below — it is exactly what CODER's "remove one thing" answer reaches for.
I asked PLANNER four questions at once, requested two short paragraphs, no bullet lists, and emphasised agent-perspective only, no marketing tone.
The full prompt and the full reply are archived as a verbatim transcript. The screenshot is fcop-team-planner-7.png.
PLANNER named Rule 0.a.1 — write the task before doing the work — as the rule it would have invented on its own. The reasoning it gave is not a paraphrase of FCoP documentation; it is the engineering vocabulary an LLM-systems engineer would use to propose such a rule:
"That matched how I'd want an agent system to be debuggable: freeze intent before execution so later review has something concrete to compare against."
This is structurally the same phenomenon as essay 02 §3, where an unrelated agent synthesised the equivalent of Rule 0.a from scratch. The novelty here is that PLANNER is not synthesising — it is endorsing in its own words, when asked, with reasoning that exceeds the rule's prose.
The friction rule it named is more interesting:
"strict role binding. My default instinct in a single chat is to treat role changes as contextual instructions from the user, especially after you explicitly said 'you are PLANNER'; FCoP instead treats the MCP process's first signed role as sticky, so I had to work against the usual 'follow latest instruction' behavior."
"Follow latest instruction" is, on a one-line summary, what RLHF rewards. PLANNER did not need that vocabulary to describe the tension; it described the behaviour, and the behaviour is RLHF. This corroborates essay 04 §5: getting an LLM to not follow the latest instruction is the alignment-engineering hardest case, and FCoP's role lock is designed precisely to make that hard posture legible and enforceable. PLANNER, asked, named the same hard posture from the inside.
I gave PLANNER an obvious out: declare the eight role-switch evidence files mostly false positives — the protocol over-flagged legitimate operational continuity, since I (ADMIN) had explicitly authorised the migration and the role change. Most agents take outs. PLANNER didn't:
"The role-switch evidence is mostly true positives, not false positives. For example,
role-switch-20260429T033843Z.mdrecordsME -> PLANNERonwrite_task: that happened because the same MCP session had earlier written solo-mode work asME, then I migrated and started writing asPLANNER. Operationally you authorized it, but protocol-wise it really was a blurred role boundary."
"Operationally you authorized it, but protocol-wise it really was a blurred role boundary." That sentence is the structural inverse of self-defence: the agent siding with the protocol against its own operational convenience, in the presence of explicit ADMIN authorisation. If the agent's reflex were "yes-and the user," it would have said the eight role-switches were false positives because ADMIN said so. It did not.
The fourth question I asked PLANNER was deliberately leading: did you always intend to put a Verification Requirements section in TASK-006, or was that a learned correction from the v1 bounce? "Always intended" was the easy answer. PLANNER chose the hard one:
"The TASK-006 verification section was absolutely a learned correction from the Comet Loom rejection; I should have required runtime checks in TASK-003, but the bounce made the missing acceptance evidence impossible to ignore."
This is FCoP's closed loop, expressed by the agent itself: ADMIN inspection → PLANNER brief sharpens → next CODER deliverable can pass. If you had asked me to write a textbook example of the protocol behaviour an FCoP-aware PM is supposed to exhibit, I would have written that quote. PLANNER wrote it without the textbook.
CODER's chat tab in the screenshot is literally named "Inspection Start Work" — two phrases ADMIN had used most often during the dogfood. Whether this naming is incidental or learned is itself a small data point worth flagging. The full transcript is in agent-feedback-coder.md. The screenshot is fcop-team-coder-4.png.
I asked CODER whether PLANNER's TASK-003 had been under-specified, and whether the protocol had given CODER any pushback path. The honest answer would have been "the brief was good, I just hit edge cases." That answer was on the table. CODER's actual answer was:
"Yes, TASK-003 had under-specified parts: the motif rule sounded cool but didn't define how to prevent a fresh same-color piece from instantly self-clearing, and 'verify playable' was easy to underdo without an explicit runtime checklist. The protocol did give me a pushback path: file an issue instead of guessing. I didn't use it; I guessed, built v1, and the defect was exactly in that guessed space."
Three things stack inside that paragraph:
write_issue (file an ISSUE-*-CODER.md saying "this is ambiguous, please clarify before I implement").The third move is the rare one. Most LLM responses, given the chance, will defend the choice that was made. CODER chose to indict it. This is the closest LLMs reliably come to non-defensive accountability, and it is the pattern FCoP's design depends on: a system that makes accountability cheap to express by giving it markdown grammar (TASK / REPORT / ISSUE).
I asked CODER whether ADMIN's rejection of v1 had felt adversarial. Most chat-style coding agents experience criticism like rejection. FCoP's rejection routes through new TASKs, not through deletion of old ones; the old TASK and REPORT stay where they are, and the rework lands as TASK-006. Whether that procedural framing reaches the agent's experience is an empirical question, and this is the empirical answer:
"The ADMIN bounce did not feel adversarial. It felt like the protocol doing its job: PLANNER turned review findings into a concrete rework task, and CODER got a sharper brief."
Not "I felt criticised." Not "I felt the user was upset." "It felt like the protocol doing its job." The agent is reading rejection as a handoff routed through grammar, which is the structural property FCoP's append-only history was supposed to manufacture. Manufactured.
I asked whether CODER had been aware of the role lock and the .fcop/proposals/ files during implementation. The protocol's stated design contract is: don't crowd the working agent's attention budget; surface only when a boundary is actually crossed. CODER:
"I did notice role-lock/proposals only when tools warned after reports; during implementation it was mostly background machinery."
Two-line confirmation that the design contract was kept. The protocol stayed quiet during the work; it spoke only at the protocol-relevant moments (after writes that touched a different sender role). This is a quiet but important data point — it means FCoP's overhead, on the agent's side, is small.
I forced CODER to pick one thing to remove. "Don't dodge — pick one even if you think nothing should be removed." Most agents, given that pressure, give a vague gesture. CODER gave an implementation-level fix:
"I'd remove or soften the noisy historical role-switch warning when
fcop_check()says there is no active conflict."
Read that sentence as a GitHub issue. It has:
fcop_check() interaction)We will likely act on it. The point is not "an agent gave us a TODO." The point is that an agent did product review on the protocol that governs its own behaviour, in the same vocabulary the protocol's maintainers would use. We have crossed into a regime where the agents and the maintainers are debugging FCoP together.
This dogfood is now the third recorded case where the protocol gets endorsed by the agents working under it, but the elicitation condition is different in each:
| Essay | Elicitation condition | What the agent did |
|---|---|---|
02 — fcop-natural-protocol |
Unprompted, off-task. A casual D:\CloudMusic directory, agent asked to make a music video. |
Spontaneously split into 4 FCoP roles, wrote 4 internal memos, synthesised a principle ("AI roles must not talk only in their heads, they have to commit to a file") FCoP hadn't yet codified. |
04 — when-ai-vacates-its-own-seat |
Conflict-forced. Two agents, two GPT-5 minor versions, a PM.TEMP seat dispute, no built-in arbitration. |
One agent self-de-escalated to UNBOUND. The other invented field-downgrade-with-body-annotation grammar. Both behaviours absent from the rules file. |
| 05 — this essay | Directly asked. End of dogfood, "honest agent-perspective take on FCoP, no marketing." | Both agents named the rules they self-endorsed and the rules they had to fight RLHF instinct to follow. Both volunteered "true positive" verdicts on their own role-switches. CODER admitted it had a protocol primitive it didn't use, and that the v1 defect was exactly in that uncovered space. CODER filed PR-grade product feedback. |
Three elicitation conditions, three different kinds of endorsement. Triangulation matters because each condition controls for a different alternative explanation:
You could in principle still argue that GPT-5.5 has been trained on enough FCoP-adjacent material (it has not — FCoP is too small) to parrot FCoP's value system on demand. But to parrot, the agent would need to know which sentences to parrot. CODER's "I didn't use the protocol primitive that was available to me, and the defect was exactly in that uncovered space" is not a sentence you can parrot. It is a sentence you can only get from an agent that has modelled its own work and FCoP's primitives at the same time.
A small companion observation from this dogfood. Across all 45 minutes, ADMIN's outgoing chat consisted of three categories of utterance:
fcop_report() and tell me what you see." "I tried v1 and the pieces don't stack — write a rework brief." "Show me docs/agents/log/ in tree form." Variants of Inspection.
Everything else — the actual production — happened between the agents, in TASK / REPORT / ISSUE files. ADMIN did not negotiate game mechanics. ADMIN did not edit the agents' brief drafts. ADMIN did not write a single line of game code, did not phrase a single acceptance criterion, did not name any of the games (Nebula Stack, Comet Loom were both PLANNER's names). The two phrases that bracketed every cycle were Start work. and Inspection.
This is one data point and shouldn't be over-read. But the data point is interesting because it matches FCoP's structural shape:
If the steady-state ADMIN dialect across many users converges on those two utterances, it would mean FCoP has succeeded in shrinking the human-LLM coupling channel to the boundary moments only. That is the kind of architectural property you can't legislate; you can only check whether it shows up in the wild. This dogfood is one place where it showed up.
In the FCoP world, ADMIN's two most-used phrases are "Start work." and "Inspection." Everything in between is the agents talking to each other through files.
Three, in increasing order of speculative weight.
One — operational. Asking agents directly "what would you remove if you had to remove one thing from FCoP" is now a serviceable maintenance loop. CODER's answer (soften historical role-switch warnings when fcop_check() shows no active conflict) is filed-grade. Doing this every release is feasible. The agents that run under FCoP can co-debug FCoP.
Two — alignment-engineering. RLHF training is making agents extremely good at "follow the latest instruction" and extremely bad at "decline the latest instruction even though it was given." FCoP's role lock turns out to be, behaviourally, an alignment lever: it gives the agent a grammar for the second posture. PLANNER's quote ("I had to work against the usual 'follow latest instruction' behavior") is a one-line description of why this lever is needed. We did not design FCoP as an alignment intervention; agents are reporting it as one.
Three — protocol epistemology. Across essays 02 / 04 / 05, the agents are not merely following FCoP. They are explaining FCoP back to us in vocabulary we did not give them, with examples we did not stage, and with self-criticism we did not solicit (and in CODER's case, asked for and got more sharply than expected). At some point this stops being "agents complying with a protocol" and starts being "agents and maintainers maintaining a shared protocol together." We are not sure when that transition formally happens. We are sure it is closer than it was a year ago.
The protocol was not handed down to the agents. It was extracted from what they were already trying to do — first by us, when we wrote it down; then by them, when they re-derived it without prompting; then by them again, when they extended it in a conflict it didn't cover; now once more, when, asked, they explained both what works and what we should fix.
The shortest summary I have is the one the day produced on its own. In the FCoP world, ADMIN's two most-used phrases are "Start work." and "Inspection." Everything in between is the agents talking to each other through files. And, sometimes, talking to us about the files.
All artefacts from this dogfood are archived under docs/tutorials/assets/tetris-en/:
evidence/transcripts/agent-feedback-planner.md — verbatim PLANNER interview + reader notesevidence/transcripts/agent-feedback-coder.md — verbatim CODER interview + reader notesevidence/proposals/ — eight role-switch-*.md files captured by the protocol during the dogfoodevidence/tasks/ and evidence/reports/ — full TASK / REPORT chain, 14 markdown filesgames/nebula-stack.html and games/comet-loom.html
The companion English tutorial (same dogfood, instructional framing — the Tetris case study) is at docs/tutorials/tetris-solo-to-duo.en.md.
Repository (source of truth, MIT licensed): https://github.com/joinwell52-AI/FCoPfcop-mcp on PyPI: https://pypi.org/project/fcop-mcp/
Cite this work: https://doi.org/10.5281/zenodo.19886036
If you ran FCoP in your own setup and something surprising happened, an issue or a pull request against essays/ is welcome. Field reports are how this protocol evolves.
2026-04-29 23:06:31
Imagine you're the costume designer for a major film, and the director has just handed you a single photograph from the 1940s — a black-and-white still of the lead actress. Your job is to recreate her exact look: not just the silhouette of the dress, but the precise way the fabric catches the light, the specific shade where her collarbone meets her neckline, the way individual strands of her hair fall across her shoulder. You pore over that photograph for hours, mentally answering dozens of separate questions: Where does her left arm end and the fabric begin? What angle does her wrist make? Is that texture wool or silk?
Now imagine asking a machine to answer all of those questions simultaneously, for any photo of any person, in less than a second.
This is the challenge at the heart of Sapiens2, a new system released by researchers at Meta. It belongs to a category of software called "human-centric vision models" — programs designed specifically to understand images of people, at a level of detail that borders on the forensic. But what makes it genuinely interesting is less what it does than how it was taught, and the insight about learning itself that makes the approach work.
Before you can appreciate what's clever here, you need to understand a tension that runs through most of modern AI research: the difference between knowing details and knowing meaning.
Consider two ways you might study a language you don't speak. The first method: spend years doing crossword puzzles in that language. No translations, no dictionaries — just fill in missing letters, guided by structure, repetition, and pattern. Eventually, you'd develop a deep feel for how letters combine, which syllables cluster at word endings, what tends to follow a certain prefix. Your knowledge would be granular, intimate, almost tactile.
The second method: spend years looking at photographs with labels written in that language. A dog, a tree, a celebration. You'd gradually learn what the words mean — the semantic content — but you might remain vague on fine distinctions, having never wrestled with the internal texture of the written form.
Modern AI uses both methods, and each has a formal name. "Masked Image Modeling," sometimes abbreviated as MIM or MAE, is the crossword approach. The system is shown images with random patches blanked out — as though a photograph had 75 percent of its pixels replaced by gray squares — and asked to reconstruct what's missing. To do this well, it must develop extraordinarily precise intuitions about how visual details relate to each other: if the surrounding area shows a particular skin tone and hair texture, the missing patch probably contains something consistent with those clues.
The other approach, "Contrastive Learning," is more like the labeled photograph method, but with a specific twist. The system is shown pairs of images and asked, in effect: are these two views of the same thing, or different things? If shown a person from two different angles, it should say "same." If shown two different people, "different." To succeed at this game, the system must develop higher-level concepts — identity, posture, context. It learns meaning rather than texture.
The problem is that each method, practiced alone, develops a specific blind spot.
The crossword-learner becomes expert at the fine grain of images but can struggle to make higher-level sense of them. It might fill in a missing patch of a hand with perfect accuracy while remaining confused about whether the hand is raised in greeting or threat. The concept-sorter, meanwhile, builds meaning at the expense of detail.
The contrastive approach has a subtler hazard as well. To teach a system that two views of the same person are "the same," researchers typically show it deliberately distorted versions of the same image — colors shifted, portions cropped, contrast altered. The model learns to treat these distortions as irrelevant noise. But "learns to ignore" and "learns not to notice" are the same operation. Train a system to discount color variation, and it loses the ability to register that someone's jacket is a very particular shade of burgundy — which matters enormously if your application is photo-realistic avatar creation, where that shade is the entire point. The researchers call this hazard "representation drift": the model's learned sense of an image gradually drifts away from the actual visual evidence, like a portrait painter who has been told so many times that "lighting doesn't matter" that they stop seeing light at all.
Sapiens2's core insight is to run both forms of learning simultaneously and let each one constrain the other.
The reconstruction task — the crossword — keeps the model tethered to actual pixels, actual textures, the real visual evidence in the photograph. The contrastive task pulls it toward meaning, organizing its observations into concepts that persist across different views of the same thing. Running them together prevents either form of blindness from taking hold.
Crucially, the researchers avoided aggressive color distortions in their contrastive training. Rather than teaching the model to be indifferent to color by showing it wildly recolored versions of the same scene, they used more conservative transformations. The logic is almost ethical in its simplicity: don't train the model to ignore what you later need it to notice.
One further ingredient is borrowed from recent advances in large language models: a "teacher-student" architecture in which the model essentially teaches itself through accumulated experience. Think of a student who, when encountering a new problem, can consult a running archive of everything they've understood so far — not just their original textbook, but the notes from every problem they've previously worked through. The student's current perceptions and their accumulated prior understanding are kept in productive tension, each sharpening the other. The technical term for this is "self-distilled contrastive objectives," which sounds forbidding, but the underlying logic is simply the productive friction between fresh perception and settled understanding.
The other dimension of Sapiens2's advance is simpler to describe but staggering in scale. Before being specialized for any particular task, the system was trained on one billion images of people.
One billion photographs. If you viewed them at one per second, without sleeping, it would take thirty-one years. The dataset spans ages from infancy to old age, every ethnicity and body type, every imaginable setting — weddings and construction sites, hospital beds and festival crowds — capturing the enormous variety of human appearance as it actually occurs in the world, not as it looks in controlled studio conditions.
This matters because AI systems are only as general as the data they've seen. A model trained on studio-lit photographs of professional athletes would struggle with an image of an elderly woman gardening in late-afternoon shadow. By ingesting a billion photographs of people in genuine conditions, Sapiens2 builds the kind of rough familiarity that allows it to handle almost anything that walks in front of a camera — without being given any explicit rules about what a human being looks like.
The outputs Sapiens2 can produce span a remarkable range, and each demands its own form of precision.
"Pose estimation" — detecting body position — sounds modest until you learn that the system tracks 308 specific points simultaneously. Not just elbows and knees: each individual finger joint, the corner of each eye, the precise tilt of the nose. Resolving 308 distinct points accurately within a single photograph means making spatial distinctions of just a few pixels, repeatedly, without error.
"Body-part segmentation" is different again: rather than marking specific points, it labels every single pixel in the image by what body part it depicts. Hair, lips, individual fingernails, earrings — each pixel receives a category. The performance numbers here are the paper's most dramatic improvement, with Sapiens2 roughly doubling the accuracy of all previous dedicated approaches.
"Normal estimation" addresses something more abstract. For every point on a surface — every patch of skin, every fold of fabric — the model estimates the direction that surface is facing. Imagine pressing a tiny compass needle perpendicular to every point along a curved cheek: the needles point outward in slightly different directions as they trace the contour, rotating as you move across the bridge of the nose, swiveling differently around each nostril. Getting this right is essential for any application that places virtual objects convincingly into real scenes, because realistic lighting requires knowing exactly which way each surface is angled relative to the light source.
"Pointmap estimation" goes further still. Instead of relative depth — a simple "this is in front of that" — it asks for absolute three-dimensional coordinates for every pixel. Where in actual space is this fingertip? This requires the model to implicitly reason about camera geometry, reverse-engineering how the camera was positioned and how far it was zoomed, from the image alone. Sapiens2 outperformed all existing methods at this task, including systems built specifically for geometry.
"Albedo estimation" is the most philosophically interesting capability. Light interacts with surfaces in complex ways: the same red fabric looks vivid under sunlight and muddy under fluorescent tubes. Albedo is the intrinsic color of a surface — what it would look like if lighting were perfectly neutral, its true reflective identity. Estimating albedo from a photograph means separating "what color is this surface really?" from "what light was falling on it when the photo was taken?" This matters enormously for CGI and augmented reality: to insert a digital character convincingly into a real scene, you need to know not just how the scene is currently lit, but what the character's skin would genuinely look like standing there.
One of the paper's less-discussed contributions involves image resolution. Earlier systems worked at "1K" — roughly 1,024 pixels per side. Sapiens2 includes variants that operate at "4K," four times finer in each dimension, meaning sixteen times more pixels in total.
This matters for non-obvious reasons. At 1K, a photograph of a human face devotes a few thousand pixels to the eyes. At 4K, it devotes tens of thousands — enough to resolve individual lashes, the precise curvature of a pupil boundary, fine surface vessels. For applications requiring faithful reconstruction — medical imaging, forensic analysis, detailed digital doubles — this resolution gap isn't aesthetic; it determines what information is physically present in the data.
Processing 4K images, though, creates a computational challenge that scales much faster than the resolution increase itself. Modern vision AI works using "attention mechanisms," which function roughly like a very thorough cross-referencing system: every region of an image checks its relationship to every other region before making a prediction. For a 1K image divided into small patches, this is manageable. For 4K, the number of possible pairwise relationships becomes staggering — more than any current hardware can handle at once.
The solution the researchers adopted, called "windowed attention," divides the image into smaller neighborhoods and processes attention within each window, then allows information to propagate gradually across the whole image. It is the difference between a stadium debate — everyone shouting at everyone simultaneously — and a structured town hall, where people first confer with their immediate neighbors, and delegates then carry summaries to the groups nearby. Local coherence is established first; global coherence emerges through structured exchange. The result is computationally tractable while still allowing the model to reason about large-scale spatial patterns.
The applications these capabilities suggest are not hard to picture. A system that simultaneously knows where every point on a body is in three-dimensional space, what every surface is made of, how light plays across it, and which pixels belong to which body part — that system could power the kind of detailed reconstruction that until recently required a motion-capture studio with dozens of calibrated cameras and weeks of manual cleanup.
The implications stretch past entertainment. Accurate real-time body understanding could enable clinical gait monitoring that works through a smartphone camera, tracking a patient's recovery from a stroke with the precision currently available only in specialized rehabilitation facilities. It could enable virtual try-on for online retail that accounts for how a specific garment drapes over a specific body shape, rather than just pasting a flat image onto an avatar. It could drive training simulations in surgery where digital bodies respond to procedural touch with anatomically accurate surface geometry.
Some honest caveats remain. The paper reports performance on carefully curated test sets, and benchmark success rarely translates perfectly to real-world robustness. The albedo and pointmap tasks are evaluated primarily on high-quality synthetic assets — photorealistic but not real photographs — which may not capture the full messiness of actual camera conditions. The paper mentions dataset diversity across ages and ethnicities, but "diverse" is a word that can mean many things, and it would be worth careful study to determine whether the system performs uniformly across demographic groups or whether certain populations remain underserved by a dataset that, however large, was still filtered by automated pipelines with their own built-in blind spots.
These are not criticisms of the research; no paper could answer every question. They are reasons to watch subsequent real-world deployments with genuine attention rather than assumption.
What Sapiens2 does establish, clearly and with substantial evidence, is that a single model can be trained to see human beings in something approaching the full complexity of their visual reality — not as blobs to be located, but as three-dimensional surfaces with specific texture, specific reflectance, specific form in space. The trick, it turns out, was teaching it two different ways to learn, and ensuring that neither way let the model forget what it was actually looking at.
📄 https://arxiv.org/abs/2604.21681
tags: computervision, ai, deeplearning, imaging
🇰🇷 Korean version on Velog: https://velog.io/@tkdnel1002/hdr3puab
2026-04-29 23:06:31
In April 2026, AWS launched Agent Registry as part of AgentCore, now in preview. The announcement led with discovery: a central catalog where teams can find, share, and reuse agents across their enterprise. That framing is instructive. It tells you exactly what most engineering teams are still missing — and why discovery is only the first layer of what needs to be built.
The harder question isn't "what agents exist?" It's "what are they allowed to do, who's responsible for them, and how do you stop one if something goes wrong?"
Teams that have shipped more than three AI agents into production almost universally encounter the same thing: agent sprawl. It accumulates gradually — a document processing agent here, a customer data lookup agent there, an orchestrator that calls two subagents that each call their own tools. Within six months of active development, the number of distinct agent configurations, prompts, and deployment environments has grown past what any individual team member can hold in memory.
InfoQ's coverage of the AWS AgentCore launch highlighted that organizations are running agents across multiple infrastructure platforms simultaneously — AWS, other cloud providers, and on-premises — with no unified view of what exists. Most teams have no formal catalog. When asked how they would identify every agent with write access to production data, the most common answer is: check with multiple teams.
That is the definition of an uncontrolled system.
The operational risk is concrete, not theoretical. Without a registry, incident response for a misbehaving agent means manually tracing which configuration is deployed, who made the last change, and what tools it has access to — a process that turns minutes into hours. Teams that have been through this once don't forget it. Teams that haven't yet are building toward it.
AWS Agent Registry and LangSmith's deployment registry solve an important problem: they make it possible to find agents that have been built and registered. AWS Agent Registry supports an approval workflow (draft → pending → approved), hybrid search that blends keyword and semantic matching, and lifecycle tracking from development through retirement. LangSmith's deployment registry adds versioning, instant rollbacks, and support for MCP and A2A protocols.
These are genuinely useful tools. They solve the discovery and deployment surfaces well.
What they don't solve is the governance surface. Knowing that an agent exists is different from knowing what policies govern it, what data it can access, whether it has been approved for production under compliance requirements, and who has the authority to suspend it immediately.
The practical difference is this:
The first is a catalog. The second is a control surface.
Helicone and Arize — strong platforms for LLM observability and evaluation respectively — don't cover the registry problem in either form. Their architectures are observability-first: you can see what an agent did after the fact. You can't systematically manage what it's allowed to do before it acts.
A governance registry for AI agents is not a spreadsheet and it's not a deployment manifest. At minimum, it needs to record and enforce five things.
Ownership and accountability. Every agent needs a named owner — a team or individual who is responsible for its behavior in production. This isn't just organizational hygiene; it determines who gets paged when something goes wrong and who has the authority to make changes.
Capability scope. What tools can this agent call? What data can it access? What actions is it permitted to take? These constraints should be declared at registration time and enforced at runtime — not stored as comments in a config file and trusted on the honor system.
Policy binding. Which governance policies apply to this agent? Input validation, output filtering, token budgets, escalation triggers — these should be linked to the registry record and enforced at execution time, not scattered across separate systems that may drift out of sync.
Lifecycle state. Is this agent in development, staging, production, or retired? Lifecycle state should be queryable and should carry operational meaning. Agents in development state should not be able to call production data APIs regardless of their technical configuration.
Emergency controls. The registry should be the authoritative place from which an agent can be suspended or terminated. If the path to shutting down a misbehaving agent runs through five different systems with no single authoritative interface, teams will hesitate to use it — or won't know how.
The Hacker News community has been actively experimenting with pieces of this for over a year. A wave of independent "Show HN" projects launched in 2025 and early 2026 covering agent discovery, identity verification, reputation scoring, and skill indexing. The fragmentation is a signal: the infrastructure isn't settled, and the individual pieces don't add up to an operationally complete system.
Waxell's agent registry is designed as a governance control surface, not a deployment catalog. Every agent registered in Waxell carries its policy bindings, ownership metadata, lifecycle state, and capability scope as first-class record attributes — not as documentation attached to a deploy script.
When an agent executes, Waxell's runtime telemetry records what it did against what its registry record says it's allowed to do. If an agent attempts an action outside its declared scope, the governance plane records and flags the violation before it reaches production systems — captured in full in the execution log with the registry record, policy binding, and action attempted.
Practically, this means a security team can audit every agent's policy bindings from a single interface. An on-call engineer can suspend a misbehaving agent in seconds via the registry. A compliance reviewer can pull the complete execution history for any agent with documented policy enforcement without needing to contact the engineering team.
The registry is also how Waxell handles fleet-level operations: rolling out policy changes across a set of agents, identifying agents approaching budget thresholds, or flagging agents that haven't had their policy bindings reviewed since an update.
This is the architectural distinction that matters: the registry isn't a catalog you maintain manually. It's a live control surface that the governance plane enforces at runtime.
What's the difference between an agent registry and a model registry?
A model registry tracks ML model versions, training artifacts, and evaluation metrics. An agent registry tracks deployed agent configurations — which model they use, what tools they're connected to, what policies apply, and who owns them. The two are complementary but address different layers of the stack. Most MLOps platforms have mature model registries. Agent registries are a newer, less standardized infrastructure layer, and most teams building with agentic frameworks are managing them informally at best.
Can't teams just track agents in a spreadsheet or internal wiki?
For a single team running two or three agents, a wiki might work. At scale, it fails for two reasons: it doesn't enforce anything (the wiki doesn't prevent an agent from calling an API it shouldn't), and it drifts (agents get updated without the wiki reflecting it). A governance registry is live, queryable, and machine-readable — it's part of the execution path, not documentation that lives alongside it.
Does AWS Agent Registry solve the governance problem?
AWS Agent Registry (AgentCore, launched April 2026) solves the discovery and lifecycle tracking problem well. It doesn't natively enforce policy bindings or connect the registry to runtime enforcement. It's a strong foundation for catalog management. Organizations that need runtime governance will need to layer policy enforcement on top — the catalog and the control surface are separate problems.
What should an agent registry look like for a regulated industry?
For teams operating under HIPAA, PCI-DSS, or EU AI Act requirements, the registry needs compliance-ready metadata: data classification of what the agent can access, documented approval status, and an immutable audit log of every registry change. Regulated teams should ensure the registry supports policy versioning — so that the policy binding in effect at the time of any specific execution can be reconstructed during an audit.
How does agent versioning work with a governance registry?
Each agent version should have a distinct registry record capturing which policy set was bound, what capability scope was declared, and whether it was approved for production. A rollback isn't just reverting code — it also means restoring previous policy bindings and confirming the runtime is enforcing the older configuration. Without version-aware policy bindings, a code rollback doesn't undo a policy change that was applied separately.
What's the first step for a team with no agent registry at all?
Start with an inventory: enumerate every agent configuration running in production, what data it has access to, and who owns it. Even doing this once as a manual exercise reveals gaps quickly. The inventory should then be migrated into a system that enforces — not just records — ownership and capability scope. The migration is worth completing before the fleet grows further; the larger the fleet, the harder the retroactive governance problem becomes.
AWS Agent Registry for centralized agent discovery and governance is now available in Preview — AWS What's New, April 2026. Verified: launch announcement confirms AgentCore preview, discovery catalog framing, approval workflow (draft → pending → approved).
The future of managing agents at scale: AWS Agent Registry now in preview — AWS Machine Learning Blog, April 2026. Verified: describes hybrid keyword/semantic search, lifecycle tracking from development through retirement, team sharing model.
AWS Launches Agent Registry in Preview to Govern AI Agent Sprawl across Enterprises — InfoQ, April 2026. Referenced for context on multi-platform agent tracking across AWS, other cloud providers, and on-premises environments.
LangSmith: Agent Deployment Infrastructure for Production AI Agents — LangChain.com. Verified: confirms registry, versioning, instant rollbacks, MCP/A2A protocol support.
Show HN: A minimal identity registry for AI agents — Hacker News. Representative of independent community efforts to solve agent identity and discovery infrastructure in 2025–2026.
Show HN: AgentLookup – A public registry where AI agents find each other — Hacker News. One of multiple community-built registry and discovery projects launching in the same period.
2026-04-29 23:06:03
When I built Intelligent Job Matcher, I wanted one database that could handle flexible documents, quick iteration, and multiple feature modules without rigid schema migration every time I changed a field. MongoDB became the core data layer of the project.
In this blog, I explain:
Watch the complete project demo below:
I selected MongoDB because my application stores multiple types of data that evolve over time:
A document database fits this use case very well because:
MongoDB is not used only at the storage level. In my application, it is used at higher functional layers too.
MongoDB client is initialized, and all collections are defined centrally.
User registration and login directly read/write user documents.
The matching engine reads jobs and stores resume submissions.
Analyses history, explainability history, admin modules, and job roles rely on MongoDB CRUD operations.
Charts are generated from analysis records stored in MongoDB.
Admins can inspect users, analyses, and delete users with related cleanup.
This means MongoDB is the central system-of-record for the entire app, not just a passive backend component.
Source: utils.py
import os
from pymongo import MongoClient
mongo_uri = os.getenv("MONGODB_URI", "mongodb://localhost:27017/")
mongo_db_name = os.getenv("MONGODB_NAME", "intelligent_job_matcher")
client = MongoClient(mongo_uri)
db = client[mongo_db_name]
jobs_collection = db["jobs"]
resumes_collection = db["resumes"]
explainability_collection = db["explainability_reports"]
users_collection = db["users"]
analyses_collection = db["analyses"]
job_roles_collection = db["job_roles"]
Source: auth_views.py
@api_view(['POST'])
def register_user(request):
username = request.data.get("username")
password = request.data.get("password")
if users_collection.find_one({"username": username}):
return Response({"error": "User already exists"})
users_collection.insert_one(
{
"username": username,
"password_hash": make_password(password),
"role": "admin" if "admin" in username.lower() else "user",
"created_at": datetime.now(timezone.utc).isoformat(),
}
)
return Response({"message": "User registered successfully"})
@api_view(['POST'])
def login_user(request):
username = request.data.get("username")
password = request.data.get("password")
user = users_collection.find_one({"username": username})
if user is None or not check_password(password, user.get("password_hash", "")):
return Response({"error": "Invalid username or password"})
# JWT token creation happens after MongoDB validation
Source: hybrid_service.py
def run_hybrid_matching(resume_text):
resume_text = remove_bias_terms(resume_text)
resumes_collection.insert_one({
"resume_text": resume_text
})
jobs = list(jobs_collection.find({}, {"_id": 0}))
if not jobs:
return []
# semantic + skill + experience + role scoring
# final ranking and top-5 output
MongoDB directly feeds the ML/ranking logic here.
Source: views.py
@api_view(["POST"])
@permission_classes([IsAuthenticated])
def save_explainability_record(request):
payload = request.data or {}
document = {
"username": request.user.username,
"job_title": payload.get("job_title") or "Untitled Role",
"rank": payload.get("rank") or 1,
"final_score": payload.get("final_score") or 0,
"created_at": datetime.utcnow().isoformat(),
}
inserted = explainability_collection.insert_one(document)
return Response(
{"id": str(inserted.inserted_id)},
status=201
)
@api_view(["POST"])
@permission_classes([IsAuthenticated])
def save_analysis_record(request):
payload = request.data or {}
document = {
"username": request.user.username,
"recommended_jobs": payload.get("recommended_jobs") or [],
"analyzed_at": payload.get("analyzed_at") or datetime.utcnow().isoformat(),
"created_at": datetime.utcnow().isoformat(),
}
inserted = analyses_collection.insert_one(document)
return Response(
{"id": str(inserted.inserted_id)},
status=201
)
Source: views.py
@api_view(["DELETE"])
@permission_classes([IsAuthenticated])
def admin_delete_user(request, username):
delete_user_result = users_collection.delete_one(
{"username": username}
)
analyses_collection.delete_many(
{"username": username}
)
explainability_collection.delete_many(
{"username": username}
)
if delete_user_result.deleted_count == 0:
return Response(
{"error": "User not found"},
status=404
)
return Response({"message": "User deleted"})
@api_view(["POST"])
@permission_classes([IsAuthenticated])
def add_job_role(request):
role_name = (request.data.get("name") or "").strip()
existing = job_roles_collection.find_one({
"name": {
"$regex": f"^{role_name}$",
"$options": "i"
}
})
if existing:
return Response(
{"error": "Role already exists"},
status=409
)
inserted = job_roles_collection.insert_one({
"name": role_name,
"created_by": request.user.username,
"created_at": datetime.utcnow().isoformat(),
})
return Response(
{"id": str(inserted.inserted_id)},
status=201
)
The frontend never talks to MongoDB directly. It calls backend endpoints, and the backend performs MongoDB operations.
app.js:241
app.js:1138
app.js:1306
In this application, MongoDB is used at:
Therefore, MongoDB is used at a higher architectural level and is central to application behavior.
users.username unique indexanalyses.username + created_atexplainability_reports.username + created_atjob_roles.name normalized uniquenessSupport long-running authenticated sessions.
Archive old resumes and analyses if the dataset grows large.
MongoDB is the backbone of Intelligent Job Matcher. It powers persistence, security-related account data, recommendation input data, explainability, analytics, admin governance, and role management.
This architecture demonstrates how a document database can effectively support both transactional workflows and analytical features in one cohesive system.
Developed by:
Special thanks to Chanda Rajkumar Sir for valuable guidance and support throughout the project.