References:

Some thoughts on LLM coding

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.

Výsledný postup propojení na Saimon 1 BCD

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í.

Poznámka k dalším možnostem

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.

Simulace obvodu

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

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.

Where Kotlin Emits Different Bytecode than Java

Here are the main areas where Kotlin’s generated bytecode diverges from Java’s, and why that matters.

Other Kotlin Caveats for Low-Level Code

This wasn’t an isolated issue. Kotlin differs from Java in other ways that make it risky for core interop code:

Why This Matters for Library Code

A low-level library often deals with:

• JNI JVM bridges
• OpenGL or native rendering loops
• Performance-critical calls that must inline
• Reflection and MethodHandles

All 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.

Why Keeping the Library Core in Java Makes Sense

Strategy: Java Core + Optional Kotlin API

The pattern I adopted (and which many frameworks use):

• Core in Java
  • Predictable bytecode
  • JNI header generation
  • Works with MethodHandle, VarHandle, Unsafe
  • Safe for both Java and Kotlin clients
• Optional Kotlin extensions (-ktx)
  • Extension functions for ergonomics
  • Coroutines (suspend wrappers)
  • Null-safety
  • DSLs for configuration

This is the same model Android Jetpack follows:
androidx.core in Java, androidx.core-ktx in Kotlin.

Takeaways

interesting link: https://www.okoone.com/spark/technology-innovation/why-kotlin-swift-and-ruby-are-dropping-off-the-radar/

References

1. Java SE Docs — MethodHandle and signature-polymorphic methods
   https://docs.oracle.com/javase/8/docs/api/java/lang/invoke/MethodHandle.html
2. OpenJDK Wiki — Deconstructing MethodHandles
   https://wiki.openjdk.org/display/HotSpot/Deconstructing%2BMethodHandles
3. Kotlin Docs — Functions and default arguments
   https://kotlinlang.org/docs/functions.html
4. Medium — Kotlin Function Parameters and Default Values: Behind the Scenes
   https://medium.com/@AlexanderObregon/kotlin-function-parameters-and-default-values-behind-the-scenes-6551fa515fa1
5. Kotlin Forum — Kotlin bytecode on default parameters
   https://discuss.kotlinlang.org/t/kotlin-bytecode-on-default-parameters/6159
6. Kotlin Docs — Visibility modifiers (internal, etc.)
   https://www.digitalocean.com/community/tutorials/kotlin-visibility-modifiers-public-protected-internal-private
7. YouTrack — KT-14416: Support of @PolymorphicSignature in Kotlin compiler
   https://youtrack.jetbrains.com/issue/KT-14416
8. Baeldung — The @JvmStatic Annotation in Kotlin
   https://www.baeldung.com/kotlin/jvmstatic-annotation
9. StackOverflow — How to call a static JNI function from Kotlin?
   https://stackoverflow.com/questions/57117201/how-to-call-a-static-jni-function-from-kotlin
10. The golden age of Kotlin and its uncertain future https://shiftmag.dev/kotlin-vs-java-2392/

Analogové fotky vs iKatastr 3d

porovnání u prototypu zde

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.

Spatial Interactive

Stanislav Sumbera, GIS Vision 2024, 5.3. 2025,GIS Ostrava 2025

• What happens here is more important than what happens now.
• Space is naturally interactive, enabling collaboration and sharing.
• The computer is not behind a 2D glass screen but understands 3D space and interactions within it.
• People learn through observation, collaboration, and play.
• Community Computer
• Projective Augmented Reality (Projective AR)
• Bret Victor – Dynamicland

image sources:https://gislab.utk.edu/tag/ar-sandbox/ , Dyamicland.org, Lightform

• HMD / Head-Mounted Displays – Apple Vision Pro
• Spatial Computing
• Control through advanced gestures
• “Super persistence” of objects – digital objects remain anchored as if truly part of the physical world
• Pseudo-haptic feedback – realism in rendering creates the illusion of tactile response
• Currently at the “UNIX Workstation” stage of the 1980s – showcasing possibilities that will later become accessible to everyone.
• Also bloged here

2. Web, Open Source, and Technology Accessibility

• From Google Maps → OpenLayers → Leaflet → MapBoxGL → MapLibreGL → ?
• Each step represents greater availability, democratization, and accessibility of mapping technology, pushing development forward.
• How difficult was it to render an image in 1993? How difficult was it to share that image with others? And today?
• What is difficult, expensive, yet possible today that will become commonplace in 20+ years?

3. Lifespan of Data vs. Lifespan of Technology

• WMS – Simple for visualization
• Vector tiles – More complex to render (OGC API Tiles, MapBox Tiles, MapLibre Tiles – MLT)
• 3D tiles – OGC 3D Tiles, evolving standards for spatial data
• More aesthetics, smoothness, and artistic expression in maps
• Real-time rendering techniques, such as Gaussian Splat, for next-generation visualization

from Book: Eneterpise SOA by Krafzig, Banke, Slama

4. Scanning Spaces and Objects

• 3D scanning is accessible to everyone
• Spatial Video, Spatial Photo
• 3D scanning is as simple as taking a photo
• Photorealistic scanning

5.Precise Geolocation ~2-10 cm

• VPS (Visual Positioning System) – accuracy < 10 cm
• 5G geolocation
• Affordable high-precision GNSS + RTK/PPP (< 10 cm)
• Accessible VPS from panoramic images, Mapy.cz?

6. AI – Welcome to the Jungle

• NPCs have become “thinking machines” (are we, on other side, turning into NPCs ourselves? aka Jumanji 2 )

Image from Jumanji 2,driver – Mason Pike ?

• The Chinese Room paradox – an English speaker perfectly assembles answers in Chinese following instructions without understanding the Chinese language and symbols meaning.
• AI cannot create true originality but excels at combining and compiling existing inputs – a “super plagiarist” or “super puzzle resolver” ?
• Might replace a significant amount of human (intellectual + routine) labor – in GIS (georeferencing, recognition/classification), programming/syntax, and more
• “Hard work for machines, thinking for people” (Tomáš Baťa) is evolving into “(Pre)thinking* for machines, creativity/ideas for people” (in Czech Language : pre-mýšlení)
• AI model marketplace – grow (cultivate) your unique “thought twin” that integrates into an open AI network.
• Developer Twin: Blog post