A picture is worth thousands of tokens. A rough map of AI gambling zones in software development.
References:
The Dark Addiction Patterns of Current AI Chatbot Interfaces
Artificial intelligence addiction: exploring the emerging phenomenon of addiction in the AI age
How AI assistance impacts the formation of coding skills
AI Safety Label: Original picture on the left is from random walk in Las Vegas, right AI modified.
AI coding agents are useful. However I keep wondering whether trade-off is limitation in knowledge flow inside teams. A team can become faster at producing output while becoming worse at building shared understanding. And that shared understanding depends not only on what the team knows, but also on the social fabric through which knowledge moves : trust, explanation, mentorship, disagreement, and shared ownership. If that weakens, the long-term cost may be larger than we think. I think of it as the risk of “team knowledge depreciation”: trading long-term learning and collective understanding for short-term gains in speed.
This is, in some sense, a more grounded follow-up to my earlier , over-excited post “Developer Twin”.
1. AI may optimize for local speed while weakening global understanding. A patch gets written faster, but fewer people understand why it exists, which trade-offs were made, and what it may affect elsewhere. Individual throughput and collective intelligence are not the same thing.
2. The biggest risk may not be code quality, but knowledge flow. Teams do not work only because individuals are smart. They work because knowledge moves between people and gets recombined into a shared view of the system.
3. A team does not need everyone to understand everything. But it does need a healthy way to reconstruct the whole together. That shared reconstruction may become weaker if too much work shifts from human-to-human exchange to human-to-AI interaction.
4. Documentation can serialize rules, but not fully transmit judgment. Skills, playbooks, prompts, and agent instructions can capture explicit knowledge. They do not fully capture the painful experience from which engineering judgment is formed.
5. Mentoring a person compounds. Steering an AI often does not. When you invest in a junior engineer, the team may get that investment back over time. With current AI systems, much of that effort is spent in the moment.
6. Faster delivery can hide a weakening learning culture. A team may ship more while learning less. Over time, that can turn into a quiet form of knowledge capital depreciation: accumulated expertise is consumed faster than it is renewed. The deeper question is what kinds of team behavior AI quietly rewards, and what kinds it replaces.
7. The real challenge is not just building faster systems, but preserving the human mechanisms that make learning possible. Speed matters. But so do explanation, mentorship, disagreement, review, and shared ownership.
Updated on 31.3. – less words. Also added AI usefulness map here : https://blog.sumbera.com/2026/03/28/ai-usefulness/
Mám doma starší stavebnici Logitronik 01, která už má po letech nespolehlivé kontakty. Zkusil jsem proto převést jednu z jeho základních úloh (invertor / NOT) na stavebnici Saimon 1 – školní verze (DEC/BCD) … z aukra
Saimon je mechanicky i elektricky velmi pěkně zpracovaný.Celá stavebnice působí moderně a nadčasově, je robustní a počítá i s chybami při zapojování – například má základní jištění proti přetížení. To z ní dělá vhodnou platformu nejen pro výuku, ale i pro opakované experimentování bez obav z poškození
K vyzkoušení jsem zvolil z Logitroniku 01 obvod č. 3 “Logický člen “NOT” jako invertor.” Obvod samotný byl jednoduchý, pro převod schématu jsem použil ChatGPT5.2 – občas otravného “robodruha”.
Při řešení zapojení mi také pomohla konzultace přímo s autorem stavebnice. Upozornil mě, že nad spínači jsou zdířky 110–115 na rezistory,které lze jumperem nastavit jako pull-up nebo pull-down, aby při rozepnutí spínače nebyl vstup „ve vzduchu“. Zároveň upřesnil, že k integrovaným obvodům je nutné přivést +5 V, zatímco zem je rozvedena přímo na plošném spoji.
Zapojení funguje stejně jako původní úloha na Logitroniku a lze stejným způsobem převádět i další logické obvody.
IO-2 NAPÁJENÍ-+5V,
+5V-116,
117-62-63,
117-93,
92-0V,
64-95,
94-0V
Chat GPT 5.2 umí porozumět schématům, dokonce zaznamenal i ručně dokreslené napájení a ground. Dokáže poměrně dobře vysvětlit základní koncepty v elektronice a doplnit tak mezery, které se např v původním Logitroniku nevysvětlují.
Při tomto převodu se ukázalo, že je praktické mít možnost se průběžně doptávat na detaily zapojení a interpretaci schémat. Nabízí se proto myšlenka jednoduchého Custom GPT zaměřeného přímo na stavebnici Saimon, které by pracovalo s ověřenými podklady (mapa zdířek, příklady zapojení) a sloužilo jako interaktivní náhrada stručného návodu.
Do podobného rámce by šlo zařadit i jednoduché ukázky principů učení, například základní analogový nebo diodový perceptron, kde je „učení“ realizováno změnou zapojení a zpětnou vazbou, nikoli softwarem.
Na strance https://falstad.com/circuit/circuitjs.html zadejte File/Import from text a můžete si obvod také nasimulovat :
vložte tento text:
$ 1 0.000005 10.20027730826997 54 1 50 5e-11
s 304 64 304 144 0 1 false
r 304 144 304 272 0 3300
w 176 272 304 272 0
v 176 176 176 144 0 0 40 6 0 0 0.5
w 176 64 176 144 3
w 176 272 176 176 0
w 176 64 304 64 0
w 304 144 384 144 0
r 384 144 384 208 0 330
d 384 208 384 272 2 default-led
w 384 272 304 272 0
153 384 144 560 144 0 1 5 5
r 560 144 560 208 0 330
d 560 208 560 272 2 default-led
w 560 272 384 272 0
9. album od Maxmiliána Šumbery s názvem Letní imprese je nově k dispozici na Audiomack. Skladby Duo pro hoboj a klavír No.1 “Ametystové červánky” a Rozkvetlé louky se umístily ve zlátém pásmu soutěže XIII. Múzy I.Hurníka 2025. Navíc první z nich dostala také zvláštní cenu v kategorii instrumentální hudby.
Disclosure: AI-assisted content — consult with an organic-developer.
When building low-level libraries for the JVM — especially those that interact with JNI, rendering engines, or MethodHandles — the exact bytecode emitted matters. Recently I hit a limitation in Kotlin that reminded me why the JVM world still needs Java for certain things.
Here are the main areas where Kotlin’s generated bytecode diverges from Java’s, and why that matters.
| Area | Java | Kotlin | Takeaway |
|---|---|---|---|
| Signature-polymorphic calls | Emits correct signature for MethodHandle.invokeExact | Falls back to (Object[])Object, causing mismatches | Keep these calls in Java |
| Default parameters | No defaults → use overloads | Generates synthetic $default methods with bitmask | Avoid defaults in public APIs for Java clients |
| Companion objects / @JvmStatic | True static methods | Methods live in $Companion unless annotated | Use @JvmStatic or plain Java for static APIs |
| Internal visibility | Package-private supported | internal compiles to public + metadata | Don’t rely on internal for cross-language encapsulation |
| SAM interfaces | Any functional interface = lambda | Only fun interface supports SAM; lambdas may create synthetic classes | Define callbacks in Java for performance |
| Nullability | All references nullable | Annotations encode nullability, JVM doesn’t enforce | Explicit null checks needed in low-level code |
| Suspend functions / coroutines | N/A | Compiles to (Arg, Continuation) → Object | Keep coroutines in Kotlin wrappers, not core API |
This wasn’t an isolated issue. Kotlin differs from Java in other ways that make it risky for core interop code:
| Area | Java | Kotlin limitation |
|---|---|---|
| JNI declarations | static native boolean render(int, int) | Needs @JvmStatic in a companion object; generates synthetic names |
| JNI header generation | javac -h works directly | No header generation for Kotlin sources |
| Checked exceptions | Enforced at compile-time | Kotlin ignores them (all unchecked) |
| Raw types | Allowed (List) | Always requires generics (List<*>) |
| Wildcards | ? super, ? extends supported | Only in / out; cannot express everything |
| Default params | Not supported (overloads instead) | Compiles to synthetic $default methods |
| Static members | static keyword | Requires @JvmStatic in object/companion |
| Suspend functions | N/A | Compiled to Continuation-based state machines, awkward for Java callers |
A low-level library often deals with:
MethodHandlesAll of these require predictable bytecode and signatures. Kotlin often inserts synthetic classes ($Companion, $DefaultImpls, $WhenMappings) or adapts signatures in ways Java clients (and JNI) do not expect.
| Benefit | Why It Matters |
|---|---|
| One language to maintain | Single codebase, easier contributor onboarding, faster builds |
| Interop for everyone | Java APIs work in all JVM languages; Kotlin clients lose nothing; Java clients stay safe from Kotlin-only features |
| JNI friendliness | Direct mapping of Java types to JNI (int → jint, boolean → jboolean); javac -h header generation works; avoids $Companion/$DefaultImpls surprises |
| Bytecode predictability | No synthetic baggage ($Companion, $default, $WhenMappings); avoids mismatched signatures; JIT optimizes exactly as written |
The pattern I adopted (and which many frameworks use):
MethodHandle, VarHandle, Unsafe-ktx)
suspend wrappers)This is the same model Android Jetpack follows:androidx.core in Java, androidx.core-ktx in Kotlin.
| Point | Why |
|---|---|
| MethodHandle support | Java compiler emits exact signatures ((int,int)boolean), Kotlin falls back to (Object[])Object, causing runtime issues |
| Bytecode predictability | Java produces direct, predictable bytecode; Kotlin adds synthetic constructs and indirections |
| JNI compatibility | Java maps directly to JNI types and header generation; Kotlin introduces complications |
| Best practice | Keep the core in Java for stability and performance; add Kotlin wrappers for ergonomics (DSLs, coroutines, null-safety) |
interesting link: https://www.okoone.com/spark/technology-innovation/why-kotlin-swift-and-ruby-are-dropping-off-the-radar/
MethodHandle and signature-polymorphic methodsinternal, etc.)Po skoro 30 letech od ‘obyčejné’ klavírní verze je tu verze orchestrální. Překvapivě bohatá a rozšiřující původní námět. Zvláště střední a závěrečná, epicky znějící část, se mi velmi líbí. Orchestraci z původní skladby vytvořil a vhodně rozšířil Maxmilián Šumbera.
Night runner, my favourite one released ! I love the uncommon accents forming a distinct rhythm, interleaving with a faster pulse — like a heartbeat echoing the rhythm of feet hitting the ground in that first minute.
Realita vs. iKatastr 3d. Vizuální srovnání pomocí fotek z terénu.
porovnání u prototypu zde
This is another nice half-frame camera — the Olympus PEN-D. It has an uncoupled meter and a smart way of setting aperture and shutter speed together. Works great and produces nice photos. Compared to the Canon Demi EE28 , it’s a bit bulkier, mostly due to the faster Zuiko 1.9 lens.
It features a Copal leaf shutter, fully mechanical, so no batteries are needed. Focusing is manual via a distance scale. Zone focusing works well once you get a feel for it.
Shutter speeds range from 8s to 1/500s.
I gave a presentation where GIS might evolve in 20 years from now as part of the GIS Ostrava 2025 conference on 5.3. 2025. it was great to see again colleagues ! get eye-contact with audience and not just virtual applause. Also nobody was showing physically thumbs-up or red heart (in that case I would call emergency), rather real spoken (I mean real sound wave based ) comments, real talk and smiles. That was the main topic of the talk – Spatial Interactive – with people, tech, discoveries. Step out of the ‘glass-illusion’ trap.
Stanislav Sumbera, GIS Vision 2024, 5.3. 2025,GIS Ostrava 2025
image sources:https://gislab.utk.edu/tag/ar-sandbox/ , Dyamicland.org, Lightform
from Book: Eneterpise SOA by Krafzig, Banke, Slama
Image from Jumanji 2,driver – Mason Pike ?