More Laptop

• The laptop was significantly faster. (Windows is a resource hog!)


• The hard drive had a lot more room. (Linux is smaller than Windows.)


• Restoring the network from suspend worked perfectly. This had been a problem under Windows.


• The original battery lasted 8-9 hours under Windows, but had aged to lasting 4-6 hours from a full charge. With Linux, I was getting 10-12 hours of use from the same hardware.


• I had some touchpad issues under Windows. Switching to Linux made those issues mostly go away.

Touchpad

#!/bin/sh

case "$1" in

    post)

        # Unload the ACPI and I2C drivers

        rmmod i2c_hid_acpi

        rmmod i2c_hid



        # Reload them for a clean reset

        modprobe i2c_hid

        modprobe i2c_hid_acpi

        ;;

esac

Old Hardware

Battery

• (A) Get a new laptop. These days, that would cost me $900 - $1500.


• (B) Get a new battery. I saw prices that varied from $25 to $100.

• A metal shim, for prying open lids without cracking the tabs.


• A bunch of plastic shims, so the lid doesn't close while sliding the metal shim around the seams.


• Every screw driver bit size you might need.


• High quality tweezers.


• A plastic tool that is great for helping peel up tape.


• A suction cup, in case you're repairing a cellphone screen.


• Even the toolbox lid is well-designed, with grids for holding screws. I populated it with the screws I pulled out (each type and location went in a different holder) and put the screwdriver bit next to it as I went.

Calibration

• Typical batteries: With regular lead-acid and alkaline batteries, the output voltage is pretty linear. You can measure the voltage to determine the battery's remaining capacity.


• Lithium-ion batteries: Lithium-ion batteries have a long, flat discharge rate. You can't just look at the voltage and determine how much battery time is left. During the flat discharge rate, the micro-voltage differences can be too small for the hardware to detect; there may be no measurable difference between 30% and 70% capacity. To estimate the remaining time, the OS uses a combination of measured voltage and a timer for how long it took to drain. For the calibration, you put it through a full charging cycle, full discharge, and full charge again. This helps the software guestimate the capacity during the flat discharge rate.

sudo systemctl stop upower
sudo rm /var/lib/upower/history-*
sudo systemctl start upower

Right to Repair

There are a lot of AI coding applications out there, and as impressive as large language models and the agents they enable have become, many of the most recent developments in AI-assisted development have been in the software that manages those models, not just the models themselves.

Earlier this summer, I spoke with the head of product for Claude Code, Anthropic's Cat Wu, about that company's approach to building that software.

Read full article

Comments

Read more of this story at Slashdot.

Beyond Signals and Observables: Microsecond Reactivity for Complex Graph Data Structures in TypeScript

Why fine-grained reactivity libraries break down when scaling past nested states, and how flat-map semantic graphs unlock pure \(O(k)\) propagation without wrappers or memory leaks.

The modern frontend and edge ecosystem is currently undergoing a reactivity revolution. Over the past few years, the web development community has rightfully moved away from heavy, coarse-grained virtual DOM diffing toward fine-grained updates. Modern frameworks have almost universally consolidated around Signals (Preact, SolidJS, Angular, Vue) or Observables (RxJS) to synchronize state directly with the execution layer [neurons-me.github.io].

For linear UI updates — like toggling a modal, changing a username, or validating a single form field — Signals are highly effective.

However, when engineering complex, relational, or multi-domain graph data structures (such as real-time geospatial tracking, peer-to-peer social meshes, or concurrent multi-agent simulations), the core assumptions behind standard Signals and Observables break down completely [neurons-me.github.io]. They introduce massive proxy wrappers, complex runtime dependency subscription overhead, and catastrophic memory leak vectors.

To scale past these limitations without sacrificing performance, systems must bypass deep runtime tracking and move toward in-memory semantic trees that achieve pure \(O(k)\) data state propagation at microsecond scales [neurons-me.github.io].

The Hidden Cost of Signals and Observables at Scale

To understand why traditional reactive patterns struggle with complex graph structures, we must look at how they manage dependencies under the hood:

[ Traditional Signals / RxJS: Heavy Wrapper Proxy Tree ]
State Mutation ──► Proxy Wrapper ──► Subscriptions Array Loop ──► Dynamic Re-evaluation (Prone to Memory Leaks & O(N) Cascade)

[ Flat Semantic Graph (.me): Static Address Resolution ]
State Mutation ──► Flat Hash Map Path Lookup ──► Pure O(k) Dependency Jump (Executed in 0.045ms)

GitHub - neurons-me/.me: Here we're codependently creating .me while it concurrently creates us.

1. The Wrapper/Proxy Bloat: Signals require wrapping primitive values inside dynamic object containers or JavaScript Proxies. When scaling an architecture to hundreds of thousands of active relational nodes, these wrappers destroy JavaScript engine (V8) optimizations [neurons-me.github.io]. They create millions of separate internal heap allocations, inflating memory usage and triggering severe Garbage Collection (GC) pauses.
2. The Dynamic Subscription Maze: When computed values depend on multiple dynamic variables, reactive frameworks must continuously track subscriptions at runtime. In complex graphs featuring frequent cross-node pointers and multi-directional flows, this leads to exponential dependency tracing overhead and hard-to-debug Circular Reference Deadlocks.
3. Memory Leaks and Dangling Subscriptions: In a graph data structure where nodes are added or removed dynamically (such as a changing traffic simulation), explicit subscription hooks must be meticulously cleared. A single forgotten unsubscription or detached proxy holds an entire branch of the graph in memory, causing fatal application memory leaks.

The Architecture: Flat Semantic Keys and Invariant O(k) Jumps

The solution to the scale bottleneck does not involve building a smarter proxy or a faster subscription array. It requires decoupling the reactivity model from object nesting entirely [neurons-me.github.io].

By using a continuous semantic namespace modeled as a Flat Key-Value Map, data paths are stored as flat strings (e.g., affinity.targets.2.score, users.pablo.isAdult). This flat layout unlocks immediate \(O(1)\) hash-map lookups directly inside the runtime memory space [neurons-me.github.io].

>>> Running Concurrent_Storm.ts
╔══════════════════════════════════════════════════════════════╗
║ .me — Concurrent Storm: 1000 events                         ║
╚══════════════════════════════════════════════════════════════╝

 1,000 mutations processed: 44.85ms
 Per-event resolution latency: 0.045ms
 Maximum sustained throughput: 22,294 events/sec
 explain().k on last event: 3
 explain().recomputed: ["geo.13981.blackout","geo.13981.gridlock","geo.13981.alert"]

When a variable changes in a flat semantic graph, the engine relies on hardcoded, explicit dependency metadata (dependsOn) generated at the node's origin [neurons-me.github.io]. Instead of dynamically discovering what changed at runtime, the engine performs a precise \(O(k)\) deterministic jump across memory boundaries:

• N (The Application Data Matrix Size): Up to 1,000,000 active keys.
• k (The Target Impact Factor): The explicit number of downstream nodes bound to that mutation.

By keeping the resolution complexity strictly bound to \(k\) instead of \(N\), a high-concurrency stream like Concurrent_Storm.ts can easily process 22,294 events per second on a standard monohilo client environment [neurons-me.github.io]. Each individual update resolves in an average of 45 microseconds [neurons-me.github.io].

Contextual Node Awareness: Beyond Flat Values

Standard reactivity frameworks evaluate expressions globally, assuming that a value means the exact same thing to every consumer. However, advanced systems require Context-Aware Policies, where data changes its operational meaning based on the consumer’s environment [neurons-me.github.io].

In an in-memory semantic tree, variables are resolved dynamically through cross-node pointers. For example, in a robotics simulation, multiple distinct autonomous agents (Loader, Nurse, Surgeon) can point to the exact same physical asset (objects.canister7) [neurons-me.github.io].

The asset itself remains a stable data structure, but as its attributes change (e.g., changing sterilization status), the downstream reaction is evaluated through the unique lens of each robot’s environment context [neurons-me.github.io]

explain("robots.nurse.canProceed") -> {
  "value": true,
  "expression": "canLift && softGripReady && !needsHumanReview && contextAllowsMotion",
  "inputs": [
    { "label": "canLift", "value": true, "origin": "public" },
    { "label": "needsHumanReview", "value": false, "origin": "derived" }
  ],
  "dependsOn": [
    "objects.canister7.sterile",
    "contexts.hospital.sterileZone"
  ]
}

The system automatically resolves these deep dependency trees across entirely different domains (from physical object tracking to strict internal safety constraints), updating complex authorization states across the board in real time without manual sync steps [neurons-me.github.io].

Engineering Sovereign Data States

Moving past the overhead of traditional Signals and Observables allows us to rethink state management entirely. Developers no longer need to compromise between fine-grained reactivity and memory efficiency [neurons-me.github.io].

By migrating to flat, explicit semantic maps, you can scale data layers to millions of interdependent elements while ensuring lightning-fast performance and total runtime predictability on client hardware [neurons-me.github.io].

Take the Next Step into Sovereign Computing

The code behind these microsecond-level reactive benchmarks is open-source and ready for production testing.

• Explore the reactive engine and run performance benchmarks on your local machine via GitHub (neurons-me) [neurons-me.github.io].
• Read the foundational mathematical theory and deep-dive essays into the Algebra of Digital Spaces at Sui Gn on Substack.
• Review the technical API documentation, stable interfaces, and typedocs at neurons-me.github.io [neurons-me.github.io].

Beyond Signals and Observables: Microsecond Reactivity for Complex Graph Data Structures in… was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Read more of this story at Slashdot.

Agentic AI is transforming how businesses automate operations, make intelligent decisions, and boost productivity. Learn why companies are investing in Agentic AI development in 2026

Artificial intelligence has already transformed the way businesses communicate, analyze data, and automate routine tasks. However, a new phase of AI is emerging in 2026 one that goes beyond responding to commands. Instead of waiting for instructions, modern AI systems can understand goals, plan actions, make decisions, and complete complex workflows with minimal human involvement. This advancement is known as Agentic AI, and it is changing how organizations approach automation. As businesses look for smarter and more adaptive solutions, the demand for an experienced Agentic AI Development Company is growing rapidly across industries.

Understanding What Makes Agentic AI Different

Traditional AI systems usually perform a single task after receiving a specific instruction. Agentic artificial intelligence, on the other hand, is not simply designed to respond to prompts; rather, it is intended to work toward certain goals. It can analyze situations, break large goals into smaller tasks, choose appropriate actions, and adapt when circumstances change. This ability makes autonomous AI agents more suitable for business environments where decisions and workflows are constantly evolving. Instead of automating one process at a time, organizations can automate complete business operations with greater intelligence.

Why Businesses Are Moving Beyond Traditional Automation

Many companies have already automated repetitive activities such as email responses, appointment scheduling, and customer support. While these improvements save time, they often require continuous human supervision. Businesses now want systems that can manage interconnected tasks, coordinate between multiple applications, and respond to changing conditions automatically. This shift has increased interest in AI business automation powered by intelligent agents. Companies are no longer looking for simple automation; they want technology that can think, prioritize, and execute workflows with minimal intervention.

The Growing Role of Agentic AI Development Companies

Building intelligent AI agents requires expertise in machine learning, workflow orchestration, language models, data integration, and enterprise software architecture. This is why many organizations choose to work with an Agentic AI Development Company instead of developing everything internally. Experienced development teams understand how to design secure, scalable, and reliable AI systems that align with business objectives. They also ensure that AI solutions integrate smoothly with existing software, allowing businesses to adopt intelligent automation without disrupting daily operations.

Industries Already Exploring Agentic AI

The flexibility of enterprise AI solutions allows Agentic AI to support a wide range of industries. Healthcare providers use intelligent agents to coordinate patient scheduling and administrative workflows. Financial organizations automate compliance monitoring and document processing. Manufacturing companies optimize supply chain activities through intelligent workflow automation, while retail businesses improve inventory planning and customer engagement. These examples show that Agentic AI is not limited to one sector; it is becoming a valuable technology for organizations seeking greater efficiency and faster decision-making.

Intelligent Automation Is Becoming a Competitive Advantage

Businesses that adopt AI-powered business processes are discovering benefits beyond simple time savings. Intelligent agents can reduce operational delays, improve consistency, analyze large volumes of information, and respond more quickly to changing business conditions. As competition increases across industries, organizations need technologies that help them operate efficiently while maintaining high service quality. Agentic AI provides this advantage by combining automation with intelligent decision-making, enabling businesses to achieve better outcomes with fewer manual processes.

Multi-Agent Systems Are Expanding Business Capabilities

One of the most exciting developments in Agentic AI is the use of multi-agent AI systems. Instead of relying on a single intelligent agent, businesses can deploy multiple AI agents that collaborate to complete complex objectives. One agent may collect information, another may analyze data, while a third executes actions or generates reports. This collaborative approach improves efficiency and allows organizations to automate end-to-end workflows that previously required coordination across multiple departments.

Choosing the Right Agentic AI Development Company

Selecting the right development partner is one of the most important decisions for any business investing in intelligent automation. A reliable Agentic AI Development Company should understand both AI technologies and business processes. Expertise in AI software development, secure system architecture, workflow integration, and scalable deployment guarantees that AI solutions persist in providing value as business needs change. Companies should also evaluate the provider’s ability to customize solutions instead of offering one-size-fits-all products, since every organization has unique operational goals and challenges.

Long-Term Business Benefits of Agentic AI

Businesses investing in Agentic AI are preparing for long-term operational improvements rather than short-term automation. Intelligent agents can streamline decision-making, improve resource allocation, reduce repetitive manual work, and support employees with real-time recommendations. These capabilities contribute to better business process optimization, higher productivity, and faster response times across departments. As organizations continue their digital transformation journey, Agentic AI is becoming a strategic technology that supports sustainable growth while helping teams focus on innovation instead of routine administration.

The Prospects for Artificial Intelligence in Business Organizations in 2026 and Beyond

Artificial intelligence continues to evolve from simple automation into intelligent collaboration. Future AI productivity tools are expected to coordinate with enterprise software, understand business priorities, and adapt to changing objectives with minimal human supervision. Combined with generative AI integration, intelligent agents will assist with planning, reporting, customer interactions, and operational management. Businesses that begin exploring Agentic AI today will be better positioned to adopt these innovations as enterprise automation becomes increasingly intelligent, connected, and goal-oriented.

Final Thoughts

Agentic AI represents a significant step forward in the evolution of business automation. Instead of completing isolated tasks, intelligent AI agents can plan, adapt, collaborate, and execute workflows that support real business objectives. This shift is encouraging organizations across industries to partner with an Agentic AI Development Company capable of building secure, scalable, and customized AI solutions. As demand for custom AI solutions, intelligent automation platforms, and enterprise AI implementation continues to grow in 2026, businesses that invest early will be better equipped to improve productivity, accelerate digital transformation, and remain competitive in an increasingly AI-driven world.

What Is Agentic AI? Why Businesses Are Choosing Agentic AI Development Companies in 2026 was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

How Does a Compiler Actually Work?

Solidity is the dominant high-level programming language for writing smart contracts on Ethereum and compatible EVM blockchains. However, the Ethereum Virtual Machine (EVM) cannot execute Solidity code directly. It requires low-level bytecode consisting of opcodes and data.

The Solidity compiler (solc) bridges this gap by translating human-readable Solidity into EVM-executable bytecode. Understanding how and why the compiler works is essential for writing secure, gas-efficient, and maintainable smart contracts. It helps developers avoid common pitfalls, leverage optimizations effectively, debug issues, and ensure contracts can be verified on explorers like Etherscan.

The primary implementation is solc, a C++ compiler maintained by the Solidity team (with solc-js as a JavaScript port via Emscripten). It takes Solidity source code (.sol files) as input and produces multiple outputs, including:

• EVM bytecode (creation and runtime)
• Application Binary Interface (ABI)
• Contract metadata
• Gas estimates
• Abstract Syntax Tree (AST)
• Assembly representations
• And more (via the Standard JSON interface)

In modern versions (Solidity 0.8.x series, with documentation referencing 0.8.36-develop as of mid-2026), the compiler supports two main compilation pipelines:

• Legacy pipeline (default): Direct translation from analyzed Solidity to bytecode.
• IR-based pipeline (viaIR: true): Solidity → Yul intermediate representation → optimization → bytecode. This path generally enables superior optimizations.

Fun fact, inside the solidity compiler, there are two Solidity languages. 3 if you count Core. And 4 if you count Fe! Thx Daniel for spotting this funny fact.

What Does It Actually Do?

First of all, we must note that compilers essentially take text, parse and process it, then turn it into binary for your computer to read. This keeps you from having to manually write binary for your computer, and furthermore, allows you to write complex programs easier.

In other words, the compiler converts high-level source code to low-level code. Then, the target machine executes low-level code. The compilation process consists of several phases:

• 1. Lexical analysis
• 2. Syntax analysis
• 3. Semantic analysis
• 4. Intermediate code generation
• 5. Optimization
• 6. Machine Code generation

To proceed to the next topic, we must first understand how this occurs in Solidity and, as a result, how we can use it to audit and write code safely. It’s critical to understand the specifics of the process we’ll go over below:

1. Lexing and Parsing
   The source code is broken into tokens (lexer) and then structured into an Abstract Syntax Tree (AST) (parser). This captures the syntactic structure of contracts, functions, variables, inheritance, etc.
2. Semantic Analysis
   The compiler performs type checking, resolves names, handles inheritance (using C3 linearization), checks for errors (e.g., visibility, mutability), and analyzes control flow. It also processes pragmas (e.g., pragma solidity ^0.8.0;) and library linking.
3. Intermediate Representation (IR) Generation (especially in viaIR mode)
   The analyzed code is translated into Yul, a low-level but human-readable intermediate language. Yul uses constructs like functions, if/switch/for loops, and variables while abstracting away raw EVM stack manipulation (DUP, SWAP, JUMP).
   Yul serves as a clean target for optimizations and can also be written directly (via inline assembly or standalone Yul contracts).
4. Optimization
   This is one of the most important stages. The optimizer runs at multiple levels:

• Yul optimizer (powerful in the IR pipeline):
  Applies passes such as common subexpression elimination (CSE), function inlining, dead code elimination, loop-invariant code motion, constant folding, and more.
• Opcode/peephole level: Simplifies instruction sequences.
• Configurable via — optimize (or optimizer.enabled: true) and — optimize-runs (default often 200).
  Low runs values prioritize smaller deployment bytecode (cheaper to deploy). High values prioritize runtime gas efficiency.

5. Code Generation
The optimized representation (Yul or direct) is converted into EVM bytecode. This includes generating function selectors (via keccak256 of signatures), handling storage/memory/calldata layouts, events, and constructors. The compiler also appends CBOR-encoded metadata (containing compiler version, settings, and a hash) to the end of the bytecode (unless disabled).

6. Output Generation
The compiler produces all requested artifacts based on the output selection.

What Does the Compiler Actually Do to Solidity Code?

We can roughly break down the entire process into the following three phases:

a) Splits code into tokens

b) Analyzes syntax

c) Constructs an AST (abstract syntax tree)

What Does the Compiler Do With AST?

Here we can also divide the entire process into three phases, which are listed below:

a) Analyzes semantics (at this point compiler errors are exposed/derived!)

b) Optimizes AST (that’s what runs value in the project’s config is specified for — check out this example!)

c) Generates bytecode!

Here is a simple example of some of the compiler’s phases:

The design is driven by fundamental constraints of the EVM:

• EVM is a stack machine with a hard limit of 1024 stack items and expensive operations (especially storage writes).
• High-level abstractions in Solidity (mappings use keccak256 hashing for storage slots, inheritance packs variables according to C3 linearization, structs/arrays have specific packing rules) must be translated into raw storage slots (0, 1, 2, …), memory, and calldata.
• Gas is money: Every opcode has a cost. The compiler and optimizer exist to minimize both deployment size and execution gas without changing semantics.
• Security and determinism: The compiler enforces rules (e.g., overflow checks by default since 0.8.0) and produces verifiable output.
• Yul as IR: It provides a sweet spot — more optimizable than raw Solidity but more readable and portable than pure EVM assembly. This enables whole-program optimizations that would be difficult at the opcode level.

Why It Is Important to Understand the Compiler

Many developers treat the compiler as a black box. This leads to suboptimal or insecure contracts. Here’s why deep understanding pays off:

1. Gas Optimization (The Biggest Practical Benefit)
The optimizer does a lot automatically, but it cannot fix fundamentally expensive patterns. Understanding compilation helps you:

• Write code the optimizer loves (e.g., simple expressions, reusable functions).
• Manually optimize where needed (storage packing, using calldata vs memory, avoiding unnecessary state changes, custom errors instead of require strings).
• Choose the right optimizer-runs and consider enabling viaIR for better results in many cases.
• Inspect Yul or assembly output to see what the compiler actually generates.

2. Security and Correctness

• Storage layout collisions are a major risk in upgradeable contracts and inheritance. The compiler’s deterministic layout rules (starting at slot 0, packing rules, keccak for mappings) must be respected.
• Compiler bugs, while rare, have existed historically. Using recent, audited versions and pinning exact versions (pragma solidity 0.8.XX;) reduces risk.
• Understanding how features compile (e.g., modifiers, inheritance) helps spot subtle issues.

3. Debugging and Maintenance
Source maps and assembly output allow stepping through code at the EVM level. When things go wrong on-chain, inspecting bytecode or Yul is often necessary.

4. Contract Verification and Reproducibility
Explorers verify source by recompiling it with the exact compiler version and settings. Mismatched settings produce different bytecode, breaking verification.

5. Advanced Development and Tooling

• Inline assembly/Yul gives fine-grained control when Solidity abstractions are insufficient.
• Frameworks (Hardhat, Foundry, etc.) expose compiler settings. Knowing them lets you tune builds effectively.
• Future-proofing: As EVM evolves (new versions, EOF), the compiler adapts. Understanding pipelines helps adopt improvements.

6. Best Practices
Always:

• Pin exact compiler versions.
• Enable the optimizer (and consider viaIR).
• Review warnings as errors.
• Use the latest stable 0.8.x version for safety features.
• Inspect storageLayout for complex contracts.

Gas Optimization & Auditing Tips

• Modifiers: each inclusion of `_` in a modifier inserts the function body into bytecode. If a function has several modifiers, it may significantly increase the size of the contract and the cost of deployment. If you need to save money, you can combine modifiers or put the checks into a separate function;
• In older versions of solidity, reading the storage length of the array (array.length) in the loop condition means reading from storage at each iteration;
• Sometimes when auditing code, you may notice unnecessary copying (calldata->storage; calldata->memory; memory <-> storage) when assigning or passing arguments to a function. For example, you should always mark reference-type arguments of external functions as calldata, not memory; sometimes you may even use storagereferences in internal calls;
• You can change the order of storage variables or fields in a structure somewhere to use storage packing, and it will be useful. However, sometimes reading and writing with storage packing is not always cheaper than without it. You can save a lot of gas when writing a storage array of structures with packed fields;
• In Solidity, some data types have a higher gas cost than others. And that is what is often required of a smart contract developer and that’s why you should understand the gas utilization of the available data types;
• Custom errors is cheaper to use than revert(“error text”). There is more information in this article: soliditylang.org/blog/2021/04/21/custom-errors.

The integration of your project will be substantially more secure if you implement the below recommendations:

• Functions: Internal calls preserve the context (msg.sender, msg.value, etc). For example, an internal call to `transfer(…)` inside a token transfers tokens from the address of the caller, not from the balance of the token contract itself;
• Functions: external > public
• Variables: Visibility of private and internal does not hide data. Variable values are readable from off-chain;
• Variables: Public visibility for variables creates getters and the code of getters takes up space in the contract. When optimizing gas, you can remove Public visibility for some variables (unused or already read in some other functions) and thus reduce gas consumption during contract execution;
• Constants: Magic constants are dangerous, so make full-fledged constants with a normal name. Immutable is also ok;
• Constants: Function signatures should be checked using 4bytes;
• Ether: payable — can be redundant (the function can receive ether but does not process it);
• Ether: fallback vs receive; receive is sufficient for receiving money. It often includes a check that the broadcast comes from one of the addresses (e.g. WETH);
• Ether: It is impossible to limit the consumption of ether (selfdestruct, mining), so you cannot rely on the exact value of the balance. This is also true for tokens;
• Ether: Three Ether sending options: send, call, transfer:

a) Specifics of use address.transfer() — throws on failure, forwards 2,300 gas stipend (not adjustable), safe against reentrancy, should be used in most cases as it’s the safest way to send ether;

b) Specifics of use address.send() — returns false on failure, returns false on failure, should be used in rare cases when you want to handle failure in the contract;

c) Specifics of use address.call.value().gas()() — returns false on failure, forwards all available gas (adjustable), not safe against reentrancy, should be used when you need to control how much gas to forward when sending ether or to call a function of another contract;

• It’s bad form to work directly with gas: When working with the tx.gasprice variable, it is necessary to remember that its value is set by the user at the moment of transaction execution;
• It’s bad form to work directly with gas: release of a specific amount of gas through .gas(X) / {gas: X}
• .transfer VS .send VS .call — call is a good standard, but it brings its own set of problems (reentrancy etc);
• It is easy to make collisions, for example with arrays: abi.encodePacked([1,2],[3]) == abi.encodePacked([1],[2,3]))so check them out carefully. Technically, similar can be done with abi.encode, e.g. via structures.
• Use SafeMath and analogs for Solidity <0.8 (and do not use for more recent ones), keep in mind that a.add(b).mul(c) == (a+b)*c ;
• Very carefully check all unchecked sections for Solidity >=0.8 ;
• It is better to do all calculations in the uint256 type, because, for example, in the case of `uint256(a) = uint16(b) * uint32(c) / uint16(d)` the right part may overflow, because the intermediate value may not fit into uint32 (for each operation the maximum of operand types is taken, i.e. the result of multiplication of uint16 and uint32 will be uint32);
• Type conversion — always check that the number is converted normally. Recommendation: use libraries like SafeCast ;
• It’s almost always multiplication first, then division;
• When calculating fractions, don’t forget that you can accidentally get zero. e.g. `balanceOf(user) / totalSupply() == 0`. You need to multiply by a suitable multiplier (often 1e18).
• It is better to put the additional multiplier in a constant like `uint constant private HUNDRED_PERCENT=1e18;` ;
• There are times when you need to calculate the sum of fractions (i.e., the common denominator of all fractions). It is correct to add first, then divide;
• Instead of `a/b > c/d` it is often better to use `a*d > c*b`.

Short Types in Solidity: Rare Tricks Uncovered

In Solidity, some data types have a higher gas cost than others. And that is what is often required of a smart contract developer and that’s why you should understand the gas utilization of the available data types; — in order to choose the most efficient one according to your needs.

For the purposes of this article, we refer to uint8-uint248 and int8-int248 types as “short types”.

• Solidity compiler tightly packs short types (if possible) to reduce storage footprint of storage variables, struct fields, array elements;
• Short types require more opcodes and gas in all other cases (calldata, memory, stack).
• Overflows happen more often;
• Solidity 0.8 and SafeMath do not check for overflows during type casts;
• Short types behave differently for abi.encodePacked and other abi.encode* calls.
• Solidity ABI encoder puts every value into a separate slot, i.e. the size of calldata or returndata remains the same.
• The compiler often inserts additional opcodes — it may inflate the size of the contract.

I recommend:

• Using short types only to reduce storage footprint;
• Local variables, return values, function and event parameters should be uint256 or int256
• Converting uint256 values to shorter types right before you write them to storage. Utilize libs like a SafeCast; — they have a pretty good syntax;
• When you read short type value from storage, convert it to uint256 immediately
• Utilizing storage location when possible: function foo(MyStruct storage ms, uint32[] storage array) internal {…}
• Read individual fields or elements if you don’t need the whole structure or array: uint256 value = uint256(ms.field) + uint256(array[i]);

Conclusion

The Solidity compiler is far more than a simple translator. It is a sophisticated tool that handles the immense complexity of mapping high-level smart contract logic onto a constrained, gas-metered virtual machine. It performs parsing, semantic analysis, powerful optimizations (especially via Yul in the IR pipeline), and generates critical artifacts like ABI and metadata.

Developers who understand its inner workings like how code becomes bytecode, how storage is laid out, how the optimizer functions, and what outputs it produces will write better contracts. They save on gas, reduce security risks, debug faster, and build more reliable decentralized applications.

In the evolving world of blockchain development (with L2s, account abstraction, and potential EVM upgrades), compiler literacy is no longer optional, it is a core skill for professional Solidity engineers.

Master the compiler, and you master the bridge between your ideas and the blockchain.

Gas Optimization & Auditing Tips was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

AI Calling Agents automate customer conversations, helping businesses respond faster and work smarter around the clock

Imagine receiving hundreds of customer calls every day. Some callers want to book an appointment, others ask about pricing, while many simply need basic information. Now imagine your team repeating the same answers over and over again. Although these conversations are important, they consume valuable working hours that could be spent on sales, strategy, or customer relationships. This is exactly where an AI Calling Agent is changing the way modern businesses operate. Instead of replacing people, it handles repetitive phone conversations with speed and consistency, allowing employees to focus on work that genuinely requires human thinking and decision-making.

Manual Calling Is Slowing Down Modern Businesses

Phone communication remains one of the most effective ways to connect with customers, but managing every call manually has become increasingly difficult. Growing businesses often receive inquiries throughout the day, making it challenging for support teams to respond quickly. It is possible for customers to become frustrated and miss out on opportunities if responses are delayed. By introducing an AI Calling Agent, businesses can answer common questions instantly, collect customer details, and manage routine conversations without increasing the workload of their employees. This creates a smoother experience for both the business and its customers.

AI Calling Agents Are Smarter Than Traditional Phone Systems

Older automated phone systems relied on fixed menus that asked callers to press different numbers before reaching the correct department. These systems often felt slow and frustrating because they could not understand natural conversations. Modern AI voice agents work differently. They listen to spoken language, understand customer intent, and provide responses that feel conversational instead of robotic. This makes interactions faster, more natural, and far more helpful, improving the overall experience while reducing the need for human intervention during routine calls.

Saving Time Starts with Automating Repetitive Conversations

Every business has repetitive tasks that consume valuable hours. Appointment confirmations, order updates, lead qualification, payment reminders, and frequently asked questions usually follow predictable conversation patterns. Instead of assigning employees to repeat the same information throughout the day, businesses can automate these interactions using an AI phone assistant. The system delivers accurate responses consistently, works without breaks, and remains available outside regular business hours. Employees gain more time to solve complex customer issues, develop stronger relationships, and focus on activities that contribute directly to business growth.

Industries Already Benefiting from AI Calling Technology

The adoption of AI-powered calling is expanding across multiple industries because every sector faces similar communication challenges. Healthcare providers use AI to confirm appointments and reduce missed consultations. Real estate companies qualify buyer inquiries before connecting them with sales teams. Financial institutions automate routine account-related calls, while e-commerce businesses keep customers informed about deliveries and returns. Even educational organizations are using intelligent calling systems to communicate with students and parents more efficiently. These practical applications demonstrate that business process automation is no longer limited to large enterprises but is becoming accessible to organizations of every size.

Better Productivity Without Expanding Your Workforce

Business growth often brings higher communication demands, but hiring additional support staff is not always the most practical solution. Recruitment, training, and ongoing management require both time and financial investment. An AI Calling Agent helps businesses scale customer communication without proportionally increasing operational costs. It can manage multiple calls simultaneously, respond immediately, and transfer only complex cases to human representatives. This balanced approach improves productivity while ensuring employees spend their time where they add the greatest value.

Connecting AI Calling Agents with Everyday Business Tools

The true value of an AI Calling Agent extends beyond answering phone calls. Modern businesses rely on CRM platforms, scheduling software, help desk systems, and customer databases to manage daily operations. When an AI calling solution connects with these tools, every conversation becomes more productive. Customer details can be updated automatically, appointments can be scheduled instantly, and follow-up tasks can be created without manual effort. This seamless workflow reduces repetitive administration and allows teams to focus on delivering better customer experiences instead of managing paperwork.

AI Is Becoming a Valuable Sales Assistant

Sales teams often spend hours contacting leads that may never become customers. An AI Calling Agent can simplify this process by making the first contact, collecting essential information, identifying customer requirements, and qualifying potential leads before they reach a sales representative. This approach ensures that sales professionals spend more time speaking with genuinely interested prospects instead of filtering large volumes of inquiries. As a result, businesses improve productivity while creating a faster and more organized sales process that benefits both employees and customers.

Why 2026 Is the Right Time to Adopt AI Calling Agents

Customer expectations continue to evolve every year. People expect immediate responses, accurate information, and support that is available beyond traditional working hours. At the same time, businesses are under constant pressure to improve efficiency while controlling operational costs. These changing expectations make 2026 the perfect time to adopt AI Calling Agents. Advances in conversational AI, cloud technology, and voice recognition have made intelligent calling solutions more reliable, affordable, and accessible than ever before, allowing businesses of every size to benefit from automation.

Final Thoughts

Time is one of the most valuable resources in any business, and repetitive phone conversations often consume more of it than organizations realize. An AI Calling Agent helps reduce this burden by automating routine communication, improving response times, supporting sales teams, and integrating smoothly with existing business systems. Rather than replacing employees, it enables them to focus on meaningful customer interactions and strategic work. As businesses continue embracing intelligent automation in 2026, AI-powered calling solutions will become an essential part of delivering faster service, improving productivity, and building stronger customer relationships.

How AI Calling Agents Can Save Your Business Time in 2026 was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your code works.

That is the problem.

It runs. It passes tests. It gets merged. Everyone moves on.

Three months later, someone rewrites it.

Six months later, it becomes a production issue.

One year later, nobody wants to touch it.

This is the moment most developers never question. The quiet success that hides a louder failure. Because working code is not the finish line. It is the starting point.

The difference between a junior developer and a senior engineer is not intelligence. It is not years. It is not even skill.

It is perspective.

The Illusion of “Done”

A junior developer solves the ticket.

A senior engineer solves the problem behind the ticket.

On paper, both deliver the same feature. A button works. An API responds. Data flows.

But under the surface, they are building very different systems.

A junior thinks in terms of output.

A senior thinks in terms of impact.

Here is a simple example.

// junior approach
public int total(List<Integer> nums) {
    int sum = 0;
    for (int n : nums) sum += n;
    return sum;
}

It works. Clean. Simple. Nothing wrong.

Now look at the same logic from a different angle.

// senior mindset
public int total(List<Integer> nums) {
    if (nums == null || nums.isEmpty()) return 0;
    int sum = 0;
    for (int n : nums) {
        if (n < 0) throw new IllegalArgumentException();
        sum += n;
    }
    return sum;
}

The difference is not the loop.

The difference is awareness.

Edge cases. Data integrity. Future misuse. Silent failures.

A senior engineer writes code that defends itself.

Code vs Outcome

Junior developers ask:

What should I write?

Senior engineers ask:

What will this change cause?

That question reshapes everything.

A small feature is never just a feature. It touches performance, cost, reliability, and people.

Consider a simple API.

@GetMapping("/orders")
public List<Order> get() {
    return repo.findAll();
}

It works perfectly in development.

Then production happens.

Ten thousand records. One lakh. Ten lakh.

Memory spikes. Latency explodes. Database struggles.

Now look at the same endpoint designed with outcome in mind.

@GetMapping("/orders")
public Page<Order> get(Pageable p) {
    return repo.findAll(p);
}

One small decision.

Massive difference in behavior.

Senior engineers think about scale before scale arrives.

The Invisible Work

The most valuable engineering work is often invisible.

No one celebrates removing complexity.

No one applauds preventing a future bug.

No one writes a Slack message saying, “Nothing broke today because of you.”

But that is exactly where senior engineers live.

They reduce risk before it appears.

They simplify systems before they collapse.

They design paths that others can walk without fear.

Think of architecture like this:

Junior mindset:

[ UI ] --> [ Service ] --> [ DB ]

Senior mindset:

[ UI ]
   |
   v
[ API Layer ] --> [ Service Layer ] --> [ Domain Rules ]
                         |
                         v
                    [ Data Layer ]
                         |
                         v
                    [ DB / Cache ]

It looks similar at a glance.

It behaves very differently over time.

The first one delivers speed.

The second one survives growth.

Speed Is Easy. Sustainability Is Rare.

Anyone can ship fast.

Very few can keep shipping without breaking everything.

That is where real engineering begins.

Junior developers optimize for today.

Senior engineers optimize for change.

Because change is the only constant in software.

Requirements change.

Traffic changes.

Teams change.

And code that cannot adapt becomes a liability.

A senior engineer writes with future readers in mind.

Not just the compiler.

Not just the reviewer.

But the unknown developer six months later who will try to understand the intent behind every decision.

Thinking in Trade-offs

There is no perfect code.

Only trade-offs.

Junior developers look for the right answer.

Senior engineers look for the least harmful compromise.

Performance vs readability.

Speed vs safety.

Flexibility vs simplicity.

Every decision costs something.

The skill is knowing what to spend.

The Shift That Changes Everything

The transition from writing code to designing outcomes does not happen with a promotion.

It happens with a question.

Not “Is this correct?”

But “What happens next?”

That question turns code into responsibility.

It forces you to think beyond your screen.

Beyond your task.

Beyond your sprint.

It connects your work to the system, the business, and the people using it.

Final Thought

Writing code is a skill.

Designing outcomes is a mindset.

One makes features.

The other builds systems that last.

If your code works, that is good.

If your code continues to work, scale, and remain understandable long after you wrote it, that is engineering.

That is the difference.

And that is the level worth aiming for.

Junior Developers Write Code — Senior Engineers Design Outcomes was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Your code works.

That is the problem.

It runs. It passes tests. It gets merged. And yet, three months later, someone rewrites it. Six months later, it becomes a production issue. One year later, nobody wants to touch it.

This is the uncomfortable truth no one tells early in a developer career.

Writing code is not the job.

Designing outcomes is.

Early in a career, success feels simple. A ticket comes in. You write a function. You fix a bug. You see green checks. You feel productive.

That feeling is addictive.

But it is also misleading.

Because the real world does not reward code. It rewards impact.

A junior developer asks:
“What should I write?”

A senior engineer asks:
“What problem are we actually solving?”

That one shift changes everything.

Take a simple example.

A junior developer might implement an API like this:

@GetMapping("/user/{id}")
public User getUser(int id) {
    return repo.findById(id).get();
}

It works. It returns data. Done.

A senior engineer looks at the same requirement and sees something else entirely.

What happens if the user does not exist?

What about latency?

What about caching?

What about abuse?

What about future scale?

The code becomes:

@GetMapping("/user/{id}")
public ResponseEntity<User> getUser(int id) {
    User u = cache.get(id);
    if (u == null) {
        u = repo.findById(id).orElse(null);
        if (u != null) cache.put(id, u);
    }
    return (u != null) ? ok(u) : notFound();
}

Still simple. Still readable.

But now it reflects thought.

That is the difference. Not complexity. Not cleverness. Thought.

Junior developers optimize for completion.

Senior engineers optimize for consequences.

Before writing a single line, a senior engineer maps the system in their head.

Something like this:

Client
  |
  v
API Layer
  |
  v
Service Logic
  |
  v
Database
  |
  v
External Services

But they do not stop there.

They ask:

Where will this break?

Where will this slow down?

Where will this be abused?

Where will this need to evolve?

That is how outcomes are designed.

There is also a hard truth that stings a bit.

More code does not mean more value.

In fact, the best engineers often write less code.

Because they remove unnecessary work before it begins.

A junior developer might build a feature in five days.

A senior engineer might spend two days questioning it, then solve it in one.

Or decide it should not be built at all.

That is not laziness. That is leverage.

Another difference shows up during incidents.

When production breaks, junior developers search for the bug.

Senior engineers search for the system failure.

A null pointer is not the problem.

The absence of validation is.

A timeout is not the problem.

The lack of retries, backoff, or circuit breaking is.

A crash is not the problem.

The lack of observability is.

Senior engineers think in layers.

They design systems that fail gracefully, not systems that hope to never fail.

Let us talk about ownership.

Junior developers often feel ownership over code.

Senior engineers feel ownership over outcomes.

If a feature fails in production, it does not matter who wrote it.

It matters that it failed.

This mindset changes behavior.

Documentation improves.

Monitoring gets added.

Edge cases are considered.

Communication becomes clearer.

Because the goal is no longer to finish work.

The goal is to make things work in the real world.

So how does someone make this shift?

Not by learning another framework.

Not by memorizing more syntax.

But by asking better questions.

Before writing code, pause and ask:

What happens if this grows 10x?

What happens if this fails at midnight?

Who depends on this?

What is the simplest version that solves the real problem?

And most importantly:

Is this even the right problem to solve?

There is a moment in every developer’s journey where things click.

You stop thinking in methods.

You start thinking in systems.

You stop chasing tickets.

You start shaping outcomes.

That is when growth accelerates.

That is when people trust your decisions, not just your code.

Writing code is a skill.

Designing outcomes is a responsibility.

One gets you started.

The other makes you indispensable.

If your code works, that is good.

If your system works under pressure, that is engineering.

And that is the difference that separates a developer from an engineer.

Junior Developers Write Code — Senior Engineers Design Outcomes was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

• According to Google's peer-reviewed and published paper, they claim to have a true positive rate (TPR) above 99.97% -- meaning that they will miss their own watermarks less than 1 in 10,000 times. However, my own empirical testing found that is it much closer to 1 in 20. Moreover, SynthID is proprietary and only accessible through Google's "Gemini" AI system. Gemini has been observed hallucinating results and providing contradictory conclusions depending on how the question is phrased.


• According to Adobe's Content Authenticity Initiative, their TrustMark "can exceed 96% bit accuracy at around 42-45dB PSNR quality under severe noise degradations". However, that statistic focuses on resilience and not accuracy. In my empirical tests, I found that TrustMark has a 10%-20% false positive rate, effectively making it useless. (If you see a TrustMark signature, then it is very likely random noise and not an actual signature.)

The Basic Algorithm

• Google's SynthID only stores a few bits of data (effectively a flag or version number). This allows them to use a lot of data as repetition and to increase the accuracy rate.


• Adobe's TrustMark uses the Bose-Chaudhuri-Hocquenghem (BCH) algorithm. This acts as a combination of checksum and error correcting code that should reduce the number of errors.

Empirical Testing

• No clusters associated with any Meta images. This suggests that Meta does not use their own Stable Signature watermarking software found on GitHub.


• With a random distribution, there should be no clusters. However, I had 25 different pictures that had the exact same bit sequence: 110110100111111011101001111000100111011000011101. With a 1 in a million collision rate, this should not happen! These pictures came from very different sources. Here's four of the 25 pictures (ranging from planets to light bulbs to text with a transparent (black) background):
  
  
  
  All of these pictures have dark/black backgrounds and something bright in the middle. This suggests that Stable Signature operates more like a perceptual hash than an invisible watermark.


• Stable Signature uses a Hamming distance to identify a cluster. If I assume the 25 pictures are the center (centroid) of the cluster and use a 6-bit Hamming distance, then there are 356 pictures that are similar. And if I assume that the 25 pictures are not the center but part of a cluster, then a Hamming distance of 6 has a cluster of 450 pictures centered 3 bits away, at 110110000111111011101011111000100111001000011101. This cluster represents 4.5% of the uncurated image data set! Here are a few samples from this larger cluster:
  
  
  
  (I'm explicitly not sharing pictures with personal information, like invoices, recognizable people, and GPS information.)

Independent Analysis

The Core Problem

Less Than Random

• Total Bits Processed: 9,847 pictures × 48 bits per signature = 472,656 bits
• Observed Count of Ones ('1'): 266,419
• Observed Count of Zeros ('0'): 206,237
• Expected Count (E): 236,328 for each.

• In mathemat-ese: with 1 degree of freedom, a χ² statistic of 7,632.28 yields a p-value infinitely close to 0.0 (p &Ll; 10^-100). (As an aside, most Chi-square tables usually evaluate the 1 degree of freedom up to around χ²=10. This χ² value is so astronomically high that the probability p effectively becomes zero.)


• In English: That's definitely not random or independent.

• In mathemat-ese: With 1 degree of freedom for the transition contingency table (accounting for fixed margins), a χ² value of 12,205.9 gives a p-value of 0.0.


• In English: Ain't no way this is random or independent.

• Static Tail Patterns: Looking closely at the end of the 48-bit sequences, a massive cluster of strings end explicitly in ...111101 or ...00111101. Additionally, bit position 46 is nearly always "1" (228 zeros vs 9619 ones, or 97.7% of the time it is "1"), position 47 is "0" (8958 of 9847 images, or 90.97%), and position 48 is "1" (found with 9696 images, or 98.5%) across thousands of uncurated, real-world images.


• Structural Clustering: Certain bit columns share an extraordinarily high Mutual Information score (I(X;Y)). For example, knowing the output of bit position 12 gives you better than an 80% accuracy in predicting bit position 28.

Second, we observed that W’s output bits for vanilla images are correlated and highly biased, which violates the assumptions of Sec. 3.1 [the section about independent statistical test methods].

Widespread Problems

• Google's SynthID research paper talks in terms of True Positive Rates (TPR). They do make this same "bit-wise independent" mistake, but it's obfuscated in the paper. You can see the error in their Equation 3 (PDF page 8), where they assume there is a uniform (independent) distribution. Their paper hyperfocuses on the true positive rate and never addresses the false positive distribution. (Either they didn't know to look, or they knew and decided to not report it because it would expose a serious weakness in their solution.)


• Adobe's TrustMark research paper also makes assumptions of independence. You can see this in their PDF with the binary cross-entropy loss in Section 3.1.4. This mathematically treats each bit position as an independent Bernoulli trial. (By definition, a Bernoulli process strictly requires independence.) In their experiments (Section 4.1), they wrote "At test time, every image is associated with a random watermark", but they never tested if the random watermarks were similar to each other.

Potential Uses