I was recently on a podcast where we talked about FPF, vibe-coding, decision engineering, and why “steering” AI agents is anything but an intuitive skill. We didn’t get through all the topics, and I promised the listeners a detailed follow-up post. Here it is.

And while we were talking, I realized it was time to resurrect Quint Code. So I did — and fell in love with this tool all over again. But let’s take it from the top.

Code got cheap. Decisions didn’t.

Everyone is vibe-coding right now. And that’s wonderful — even when it’s just a pet project, a weekend tool, or a hackathon prototype. But no, with varying degrees of success people are already building fairly large software systems with AI. The devil is in the details, sure, but one thing is absolutely certain: anyone still dismissing AI-assisted engineering while refusing to actually use these tools has hopelessly, irreversibly fallen behind.

If you’re also interested not just in the intuitive thrill of vibe-coding but in AI-assisted engineering proper, you’ve already run into this more than once: when we bear responsibility for the code, when actual business depends on it — just “vibing” is not a strategy at all.

Here’s the thing — code has always been a small part of the work in IT. Truly competent engineers were never just engineers; to a significant degree they were also managers: modeling the domain, understanding what they were building and for whom, organizing people. There was simply a gap between those who did this kind of work and those who just got grunt work dumped on them.

AI is now eliminating this masking gap, and doing it at a ruthlessly fast pace.
It’s become more obvious: you need to make the right decisions, not just write or generate code.

“Humans steer. Agents execute.”

Just recently (though by singularity standards this is ancient history), OpenAI dropped the harness engineering post — about how they “purely vibe-coded” a large repo. Zero lines of human-written code. Sounds incredibly cool!!!

But I absolutely agree with Anatoly Levenchuk that this article needs an enormous disclaimer: “these stunts are performed by well-trained engineers — do not attempt without proper training.”

The article is woefully short on information about what specific skills are needed for this effective “steering.”
Execution got cheaper and much faster — and it’s precisely steering that became the bottleneck.

After reading the harness engineering article, you might get the impression that this is easy to replicate — just add some integrations, cover it with tests, and off you go…

AI agents, when steered poorly, still frequently make junior-level mistakes. The upside is they make them fast — so we don’t find out about these mistakes a week before release, but almost immediately. This is where the fans of “just cover it with testsss, it can do it all on its own!!! I don’t even review tests anymore! It’s all automatic!” come in.

Yeah, but… I find it hard to believe you’ve never once had to actually review generated code, or verify behavior. Because sometimes you still have to. Sometimes! But when that “sometimes” hits, we immediately land flat on our face, because it turns out we suddenly need to possess certain hands-on competencies. Sure, you can keep going in circles asking AI for help, but do you actually know what to ask? This kind of fumbling can eat up an unforgivable amount of time.

So we’re in a situation where we still need to:

• Not lose focus, not forget to check in time on what’s actually happening in our AI factory.

• Be competent in actual development to verify those results

• Be competent in management and systems thinking to avoid making junior-level mistakes ourselves in decomposition and work distribution across agents

Intuitive approaches don’t work well here. They barely work at all.

Subscribe now

Three classes of problems

Anatoly Levenchuk in his recent posts very clearly defined three classes of problems we’re dealing with right now:

Class 1: “Keep spinning until the tests pass.” There’s a clear correctness criterion, and verifying the answer is cheaper than finding it. Math, algorithms, code with tests. AI agents already handle this class autonomously — they generate variants, run them through checks, headbutt their way to the finish! This is rapidly commoditizing: value shifts from the ability to solve to the ability to frame the problem. You don’t still think framing a problem is “just writing a prompt,” right?

Class 2: Verification costs more than the solution. Real engineering systems — distributed services, platforms, products with users. Here, green tests prove… nothing :)
A system can pass all checks while still being brittle, unable to survive under load, silently drifting from requirements. “We built it” — but did we build the right thing? Verification requires expert judgment, it’s more expensive and slower than the development itself, and it can’t be fully automated.

Class 3: The problem statement itself is the problem. Neither the solution nor the criteria for verifying it are defined — because the problem itself isn’t defined. What to build, for whom, why — all of this needs to be discovered. The only verifier here is reality: the market, users, consequences. You can only verify results by probing — shipping the product into the real world.

Vibe-coding works exclusively in Class 1. Classes 2 and 3 demand a grammar for thinking, reliable methods of reasoning and sustaining attention throughout the entire work cycle.

FPF in one sentence

FPF (First Principles Framework) — a set of engineering principles, a grammar for thinking, or more precisely — an operating system for thinking! FPF structures your reasoning so that it’s hard to miss something important. It’s not an encyclopedia, not a methodology, not tied to any tool. A set of powerful rules. A set of first-principles, SoTA principles!

Quint Code 5.0: what it is and why the interface was rewritten from scratch

Quint Code is a decision engineering system for AI assistants. A set of tools that transforms conversation with your favorite AI agent into a structured engineering process.

Version 5.0 is a complete redesign. The previous architecture (ADI cycle with phases, hypotheses, L0/L1/L2 levels) was right in spirit but wrong in form. Too rigid, too ceremonious — context got overloaded instantly. For medium-sized tasks, the old QC brought nothing but pain and suffering, which is why I myself hadn’t used it for the last 2.5 months!

During that time I was using FPF in ChatGPT and Claude Desktop — works well, very well in fact if you just add the specification to the chat or project context (of course it gets indexed under the hood). But sometimes I specifically needed an agent with filesystem and code access that would understand FPF and could work using its principles at least to some degree. So I made several attempts — like slicing the spec into a skillpack — that was a really painful journey. A skillpack with hooks… I buried that attempt very quickly :)

What changed in Quint Code?

The main shift: from “phase machine of hypotheses” to “problem → decision → decision recorded as a contract.”

In v4, there was a rigid cycle: initialization → hypotheses → verification → audit → decision. This worked for one specific flow but was inflexible. Far from all tasks fit into that conveyor.

In v5 — seven tools, each self-contained. You can use one. You can use all of them. In any order — the system itself suggests what to do next. But if you want to get the most out of engineered reasoning — there’s a protocol, and we’ll go through it below. You can just install it and not use anything explicitly — it’ll quietly start recording knowledge on its own and invoke q-reason when it encounters complex tasks. Already a win! Set it and forget it — the project evolves.

Seven tools

1. /q-note — capture micro-decisions on the fly.

The lightest thing there is. “We decided to use X for Y because latency is critical.” Recorded, linked to files, automatically expires after 90 days. If three months later X is no longer relevant — the system will remind you, and we’ll review; if needed — update the decision/specification! Living documentation, damn it!

q-note is handy because the vast majority of decisions in projects are exactly like this. Small, fast, but six months later nobody remembers why. And we needed some simple tool that wouldn’t drag you through long reasoning cycles but also wouldn’t lose important project information — information about decisions.

2. /q-frame — define the problem before rushing to solve it.

This is where Quint Code already differs most from “just ask AI.” Instead of “how do we do X?” — “what problem are we solving? what are the constraints? how will we know we’ve solved it?”

This isn’t pointless formality. Formality is never pointless! This is that golden moment where 90% of projects could save weeks or months of rework — because without a clear problem statement, you’re building “something,” and you find out that “something” isn’t what was needed at all only when it’s too late, when rewriting will be very painful. Of course, right now Quint Code only frames problems within a single project, but I can already see how this could expand to team development and integrations with various team/company knowledge bases — but that’s a long roadmap.

3. /q-char — define comparison criteria before you see the options.

Here we try to establish selection criteria before generating and comparing variants. This is protection against retrofitting — when you pick criteria to match a variant you already “liked.”

Each comparison criterion has a role:

• constraint — hard limit, must be satisfied (latency < 100ms)

• target — what we’re optimizing (throughput)

• observation — what we monitor but do NOT optimize (Anti-Goodhart!)

Why observation? Goodhart’s Law: when a metric becomes a goal, it ceases to be a good metric. If you optimize throughput — you might silently kill reliability. Observation says: “keep an eye on this, but don’t chase it.”

4. /q-explore — generate genuinely different variants, not three variations of the same thing!

Solution variants should differ in kind, not in degree. “Redis vs Memcached vs in-memory cache” — those are three variations of one approach. “Cache vs CDN optimization vs query redesign” — those are three genuinely different variants.

For each variant, you must identify the weakest link. What limits the quality of this approach? This isn’t about “cons” in the spirit of a standard SWOT — it’s about what will break first! And this is a continuation of the same “story” that begins during /q-frame — with each step of the full cycle we refine, think, converge on a better decision.

5. /q-compare — comparison on the Pareto front.

Now that criteria are defined upfront — apply them to the variants.

Here we look at the Pareto front. We’re not picking “the best option” but rather a set of options where each one can be (and typically will be) better than the rest along one dimension but worse along another.

What remains is your conscious, deliberate choice.

6. /q-decide — record the decision as a contract.

What we get is not a note in Notion, not a frozen ADR file that nobody reads.

We get a contract with four components:

1. Problem statement — why were we deciding in the first place?

2. Decision/Contract — what we chose, invariants (what must ALWAYS hold true?), preconditions, postconditions

3. Rationale — why this and not something else? We preserve the comparison table, the weakest link, evidence requirements

4. Consequences — rollback plan (under what circumstances do we roll back? How? What’s the blast radius if things do go sideways?), plus formal triggers for review, affected files

This isn’t ceremony for ceremony’s sake — it’s a specification that works. Three months from now, when a new engineer comes along and asks “why are we using X?” — there’s a very good chance they’ll find a comprehensive answer!

I wish there was full magic and Quint Code could track any conditions and their changes, but it’s already trying hard — there’s a staleness timer (Until when is this decision considered current? When should we, if not revisit it, at least verify it’s still valid?), and file-tracking is nearly ready.

7. /q-refresh — decisions age, and that’s normal!

Yes, I already started on this in the previous point — any decision has a shelf life. A year-old benchmark, documentation for an outdated version, a decision made under different load, a decision made simply… six months ago. Quint Code strives to track this automatically.

Every decision has a computed trust score — R_eff. It’s a calculated metric: the minimum across all evidence (weakest link principle — the strength of a chain equals the strength of its weakest link), with penalties for context (evidence from a different project is worth less than from the same one).

• R_eff > 0.5 — decision is healthy

• R_eff < 0.5 — decision is stale, needs review

• R_eff < 0.3 — AT RISK, requires immediate attention

When you run /q-refresh — it shows what’s gone stale and offers options: extend (with justification), replace with a new decision, or deprecate. And then it goes and actually investigates what went stale. We’ve got an AI agent here, not a mere chatbot!

Three modes of operation

Quick — for obvious decisions, but where we still want strong reasoning from AI! Define the problem (frame) → decide → record (decide).

That’s the minimum that gives you all the useful artifacts — sweet!

Full — for architectural decisions, and really any decisions where we’re not sure. I recommend listening to your “intuition” more often — far more often than you’d think, your “intuitive” decisions aren’t the best ones! It’s actually fascinating to stress-test your “intuitive” decisions through the full Quint Code cycle:

Frame → Characterize → Explore → Compare → Decide.

Auto — /q-reason. This command is a distillation of the FPF core + the full FPF available as an FTS5 index accessible via CLI — the agent can load any part of FPF on demand! You can also invoke q-reason on any task — the effect will be exclusively positive. In fact it’s not a slash-command but a skill, just like /q-note, so your agent will try to use both at the right time. If you simply give the agent a task and ask it to “think,” this skill will almost always get invoked. This is what the old Quint Code was missing — intellectual horsepower available quickly and nearly for free.

Where FPF isn’t needed, and where it’s indispensable

Don’t bring a sledgehammer to hang a picture frame, friends!

Slow, engineered thinking is NOT needed for:

• “Painting a UI button red”

• Fixing a bug in an endpoint where you need to check field X instead of Y

• Writing a CRUD endpoint that’s the same as an existing one but “slightly different”

• Any other task where the solution is obvious and the cost of error ≈ 0

For any trivial task, Quint Code will tell you right at the /q-frame stage: u

– “Dude, this is trivial — let’s just do it and record the decision.”

But slow, engineered thinking IS needed when the task:

• Is split across people, teams, or AI agents

• Has delayed, noisy, or expensive feedback from the real world (see the problem classes earlier in this post)

• Involves trade-offs between speed, quality, and risk that we need to make explicit — the cost of a wrong call is high

• You “feel” that existing, familiar approaches will break down or fail to handle this task (or you’ve already watched them fail on similar ones)

• The cost of error is above zero at all (and you won’t find out for six months)

Based on all of this, I concluded that FPF is needed in any real, living production environment, which means I need to lower the cost of using the specification and make as many benefits as possible accessible to the broadest number of developers. Which means — time to resurrect Quint Code!

Expectation vs reality

People think code will get better on its own if we just keep hammering agents in circles or throw buzzwordy applied technologies at it. But no. Only decisions get better. This is about upstream quality. Code is always downstream. If the decision is right, the code (even AI-generated) may vary in “applied quality,” but it will most likely stay within the bounds of the right decision — you see what I mean?

If the decision is wrong — no linter and no RLHF loop will save you.

What’s next: Quint Code Roadmap

Codebase Awareness — in progress right now

The biggest problem with the current version: Quint knows about decisions but is blind to the connection between code and specifications.
But I already spoiled that this is nearly solved while I was writing this post!

We’ve addressed this problem at three levels:

Level A — File Drift Detection: when the code under a decision changes — the decision is automatically flagged as potentially stale. QC deterministically identifies WHAT changed (file hashes, diff), and your agent checks and evaluates — is this change IMPORTANT or cosmetic.

Level B — Module Coverage Map: Quint Code tries to understand your project’s structure — what modules exist, which ones are covered by decisions, and which are blind spots. “Module payments/ — 12 files, zero decisions. This is your riskiest blind spot.” Honestly, I’m thrilled about this feature.

Level C — Dependency Impact Analysis: And finally, when module A changes, Quint Code will at some point see this in the dependency graph and flag decisions for modules B and C that depend on A. This is serious cross-module architectural analysis. No tool does this right now — IDEs show code, ADR tools show decisions (and even those might be stale). Nobody connects the two. Quint Code has just started trying to do this; the feature is raw, but even in this form it’s simply magnificent. I’ll do my best to make it as stable as possible.

What else is on the horizon — though no guarantees we’ll get there

A few ideas I’m exploring:

Cross-Project Decision Memory — ~/.quint/global/, a personal knowledge base that grows across projects. You decided “PostgreSQL over MySQL” on project A with evidence for why. On project B, an analogous problem comes up — Quint Code says: “You’ve already made this decision, here are the arguments. But let’s double-check anyway, because this is a different project — different context, trust is reduced, but the idea might still be solid!” In short — every project makes your agent smarter.

Adversarial Verification — before recording a decision, a second pass: counterarguments, checking for self-referential evidence (when the agent cites its own conclusions as proof), attacking the declared weakest link. If the decision survives — it gets verified status. If not — it goes back for rework.

Adversarial Verification is already in the dev branch; the minimal implementation turned out to be trivial — just tweaking the prompt of the
/q-decide command.

Team Decision Sync — multiple engineers collaborating on a single .quint/ database. When Alice and her agent are working on a caching strategy — Bob and his agent will see it. When Bob’s evidence disproves a decision — it automatically goes stale. This is probably the biggest “feature” — obviously it would require building an entire platform around Quint Code.

Decision-as-Infrastructure — decisions stop being documentation in code and move to the infrastructure level. You could build CI/CD gates based on R_eff. PR checks that show which decisions are affected by changes! Essentially, this is a move toward automatically turning test results into evidence that updates the project’s decision base. But this too is a big “feature” — platform territory again.

Conclusion

I’m not sure how to wrap this up — the ambitions are grand, and I really want to make sure this tool actually works, and not just in my own hands.

Just install Quint Code and give it a try — the full cycle or the simplest mode. I’d love to hear your feedback and suggestions!

The most expensive problem in an engineering organization isn’t bugs or speed. It is amnesia. And today almost every modern company is engineering-driven in one way or another :)

By amnesia I mean this: you seem to ship features/products fast, but you keep ending up in archaeology mode, and you have to dig to remember “who even remembers this…”, “where did we discuss it”, “why did we do it this way”.

Knowledge about our systems gets spread randomly across Slack, Jira, Git, AI notes from calls, and finally (worst of all) inside personal heads.

And now we have context graphs. The pitch often sounds like this: “let’s collect decision traces from different places, connect them, and get institutional memory! It will help with audits, onboarding, and finding past decisions…”.

A context graph is a graph built from events/decisions (decision traces), then used for context-based search (often also as a base layer for an AI agent).

Nothing fundamentally new: under different names, this “contextuality” idea has existed in IT and engineering for a long time: audit trail, process mining, data lineage, knowledge graph, ADR/decision log, event sourcing. What’s new is that it’s cheaper now, and people add LLM agents on top.

Great thing, but dont fool yourself: this is not a silver bullet, and there are critical pitfalls here.

Here they are.

1) System entity identification.

“Alex”, “Alexander”, “@alex”, “alex@corp”, “mr.crablex” in Discord - one person or five different people? Until you resolve this formally, your graph will likely already be lying.

2) Age and versions.

Policies change, org structure changes, every decision has an “expiration date”. Does your graph model that? It had better. Otherwise you will apply a precedent from the previous CFO’s era as if it were “eternal truth”.

3) Access and retention.

If you just put “why we rejected candidate/client X” into one layer, and also “forever”, you just created a security and compliance problem. At some point, someone with access (doesn’t matter who) will leak a database dump to places you won’t like.

4) Ethics and incentives.

The moment people understand/think that “big brother writes personal notes on everyone”, they move real discussion into Slack DMs or non-corporate messengers. Graph completeness? Questionable.

5) Mixing facts and explanations.

LLMs love writing beautiful “why” text. If this enters the same layer as real facts, you permanently lose auditability.

It is also important not to confuse “memory” with a real model of how the org works. Decision traces in the format people propose are not “why”. They are just evidence. And until their attributes, identities, and links to other data are verified, they are, strictly speaking, unverified traces.

Evidence is great for “what happened and who clicked the button”, but it does not have to answer “what was going on in people’s heads and in that situation? what led to this click? who decided to click, and based on what, and why exactly then?”. That whole part is about “why”.

So if a graph (or an AI agent on top of it) cannot honestly say “I don’t know”, it will lie confidently, without meaning to.

Many context-graph supporters already admit this key point: “why” is often not verifiable, and in reality we mostly capture “how” - sequence of actions, policies, approvals - and only maybe from that we get closer to “why”.

This is already honest. Let’s spread this honesty in the community: everything above the “how” level should have hypothesis status, not truth status.

Wait, you mean we must model statuses too?! YES.

My point is simple: without explicit context boundaries, a clear term dictionary, system/subsystem invariants, and also preferably versioning for everything that should be versioned, such a graph quickly becomes a pretty dump: more and more data, less and less reproducibility - until reproducibility becomes almost impossible.

In context-graph discussions, lines like “schema isn’t the starting point, it’s the output” sound cool (and in a very narrow research sense can even be true), but as an engineering principle this is a ticking bomb.

Sure, trace collection can start “without schema”.

But rational use of these traces will still require a model, ontology, and contracts! Otherwise you don’t have a “living graph”, you have a living argument about what words in graph outputs even mean.

“Schema at the output” without clarification is a plain lie. The clarifications are these: I believe only a real, persistent AGI could restore a good organizational model from an unstructured, badly modeled graph (a dump), so we could finally do all the things context-graph marketing promises. And this AGI would still need to go talk to directors and employees to clarify and validate many things :)

In the end you get the same model you could build from day one even without any graphs - and then build graphs and all the nice extras around that model.

Here is a free fast test for any “context graph” solution:

• Does it show proofs (sources/links/timelines) for every answer, or only generate a pretty story?

• Can it say “dude, I don’t know, I don’t have enough data”?

• Does it track versioning of nodes (whatever nodes are in this system), or is it “it somehow works” and “schema later”?

• Can it let you reproduce a decision on a snapshot of “how it was back then”, without extra ceremony?

Only after that should you automate memory.

I often see the same problem: engineers spend weeks searching for a solution not because the task is hard, but because there’s no structure for thinking about it. Or there’s no way to focus on that task due to too much routine work.

Context gets scattered, hypotheses are generated chaotically, tested by gut feeling (“seems to work”, “this should just work”), and either never written down or lost in chats, messy drafts, endless “Save for later” in Slack.

The result — either jumping to the first solution that “sounds reasonable” (hello, bias), or analysis paralysis.

This isn’t always, and not necessarily, a skills problem. It’s a problem of missing infrastructure and system for thinking.

I was inspired by the First Principles Framework and made quint-code to try to give this infrastructure to a wider range of developers.

Last Sunday I attended a seminar at Engineers-Managers Workshop where Anatoly Levenchuk was talking about FPF.

What is it? It’s a powerful systems thinking framework — the essence of best practices in systems thinking and first principles. It’s complex, extensive, and incredibly cool.

Anatoly mentioned that even LLMs, which can’t fit the entire FPF in context (it’s 3,348,537 characters, roughly 837,000 tokens), work surprisingly well if you just attach the FPF specification file to a ChatGPT chat.

Anatoly emphasized that he deliberately doesn’t try to “simplify” FPF to code or utilities, because the target audience is much wider than software engineers.

But I’m a programmer :) So I thought — why not?

Meet Quint Code, a tiny FPF-based tool for an engineer’s daily work (and not just programmers!) — on GitHub

What Is It (in simple terms)

Quint Code is a set of commands for the Claude Code CLI agent that turn it into a methodical systems architect.

It guides you through the ADI cycle:

1. Abduction (Hypothesis generation) — throw out options, from boring to radical.

2. Deduction (Logical check) — find contradictions without writing a single line of code.

3. Induction (Empirical check) — tests, benchmarks, research.

The output isn’t a piece of code, but a Decision Rationale Record (DRR) — a document that says: “We chose solution X because facts Y and Z indicate this solution fits. We rejected solution W because tests showed risk N. We need to revisit this decision if load grows 10x.”

It’s just written with some metadata and a bit more formality.

We’ll return to this cycle and look at it in more detail later.

One of the Key Principles: External Transformer

The idea is this: a system cannot transform itself. It needs an external agent.

In our case — that’s YOU.

Claude Code generates hypotheses, finds evidence, writes plans. But we make the decision at each step. The human here is that external transformer. So Quint Code does everything to keep the user from relaxing and skipping uncomfortable questions.

Systems Thinking in Disguise

The first version was just a set of steps, mostly ADI, without additional FPF formalities.

But in version 2.1.0 I went further and hid the complex FPF ontology “under the hood”. The beauty is that you don’t need to know FPF to use it to some degree — the command cycle in Quint Code itself makes you follow the principles.

The cycle looks something like this:

1. Agentic Init & Context Awareness

When you run /q0-init, Claude Code creates a directory structure for FPF work. It also scans your repository to understand context. Yes, like a regular init in agent CLIs, but you’ll likely be taken through an interview to ground the project context even more: — “I see Python and Django. What’s our budget? Expected scale (100 rps or 100k rps)? What are the hard constraints?”

The result is written to .fpf/context.md. After that, any hypothesis is checked not in a vacuum, but with this context in mind. Claude Code will say: “This idea is really cool, but to train such a neural network we’d need a GPU, and the context says ‘low budget‘“.

2. Strict Separation: Method vs Work

FPF has a Strict Distinction principle. In the tool it’s implemented like this: any hypothesis is now split into two parts:

1. The Method (Design-Time) — Plan. Recipe. What do we actually want to do?

2. The Validation (Run-Time) — Evidence. Tests. Logs. What actually happened.

Working with FPF makes it much harder to confuse “I figured out how to do it” with “I proved it works”.

3. NQD (Novelty, Quality, Diversity)

When you run /q1-hypothesize, Quint Code doesn’t just throw a few hypotheses for research — it must classify them:

— Conservative: Proven, reliable solution. — Novel: “Modern”, enthusiastic approach. — Radical: Risky but potentially powerful solution.

This protects against getting stuck on what you already know.

The ADI Cycle Up Close

Phase 1: Abduction — “What are the options? What do we do with all this?” Command /q1-hypothesize.

Instead of jumping to code the first solution that comes to mind, we generate a space of options. Claude Code will suggest 3-5 hypotheses of varying novelty and complexity.

Phase 2: Deduction — “Where’s the logical hole?” Command /q2-check.

We’re not writing implementation yet, nooo, that’s still far off :) At this stage we test hypotheses for logical soundness (together with the LLM).

— “If we start building microservices (hypothesis), and we have 2 juniors on the team (context), 1 mid-level and no infrastructure engineers — we’ll die at the devops stage.”

The hypothesis is rejected before you spent 2 weeks setting up Kubernetes. And then a year and a half suffering from rapidly growing architecture and infrastructure complexity.

Phase 3: Induction — “Talk is cheap. Show me the numbers.” Commands /q3-test (local empirical tests) and /q3-research (external search, like WebSearch and WebFetch on the internet).

Hypotheses that survived deduction we test in battle. Write a prototype. Run a benchmark. Find documentation. If we feel there’s not enough evidence to work with hypotheses, we can use /q3-research, gather external information, and then return to checks via /q3-test more thoroughly.

Phase 4: Audit — “The weakest link doesn’t mean useless” Command /q4-audit — This is the only optional command you can skip and go straight to step five, but I strongly recommend never skipping it, especially if you’re working on a really complex decision, and/or a decision that could significantly affect your system’s quality.

This phase applies the WLNK (Weakest Link) principle: confidence in the entire solution equals confidence in the weakest piece of evidence. If the benchmark is great but the documentation clearly says “This is a raw API, don’t use it in production” — the solution is probably unreliable.

Audit is the bias-check and WLNK analysis phase. Here Claude checks:

• Are there cognitive biases in the choice?

• Does confidence in the solution match the weakest link in the evidence?

• Congruence — how applicable is external data to your context?

Phase 5: Decision — “Lock it in” Command /q5-decide Claude gathers everything together: context, hypotheses, evidence, risks. But you — the “external transformer” — must choose the winner. This is where that Design Rationale Record I mentioned gets created.

That’s basically it! Besides the DRR, the .fpf project directory keeps collected evidence that will be useful in the future — either for new FPF cycles, or… say, to remember decisions, or write good project documentation.

Real Case: Legacy Monolith, Operational and Technical Debt

The task right now: there’s a legacy monolith and debt in technical and operational decisions. Nothing criminal, typical startup. The load on the team and myself is also “typical” for startups.

After a month and a half of work, I generally understand the main problem areas, but it’s not entirely clear what to tackle first. And the choice must be made so that the effect is maximum — the improvement should be multiplicative.

Although the decision on what to tackle had already been made, I decided to test Quint Code on this exact problem. The task seemed to have a fairly fuzzy context and clearly went beyond just one monolith.

Ran /q1-hypothesize. Claude suggested:

• H1: Fix tests and add them to CI (Conservative)

• H2: Full refactoring to DDD (Radical)

• H3: Implement stronger static analysis (Novel)

/q2-check immediately threw out H2. We can’t slow down development or train the current team on design patterns, because DDD requires high expertise that (according to context) isn’t there yet.

/q3-test: Claude ran existing unit tests. Turns out tests run fast (2s) but fail. Quick setup and run of static analyzer (H3) showed 350+ errors.

In the end, at /q5-decide we chose a hybrid of H1 + H3 (Fix current tests, write new ones and add them to CI + static analyzer baseline that we won’t allow to rise above (by violation count) in future codebase changes). H2 (refactoring) was postponed.

The whole thing took ~25 minutes.

You might say “Well, it was probably obvious what to do anyway, right?”. As I said earlier, yes — after looking at the code and processes I was leaning toward solving the bottleneck with testing and linters. But I was only leaning. After the FPF session the choice was rock solid, backed by evidence and documented.

Using artifacts from Quint Code I created a Story task in Jira and soon it will go into work (to Claude Code itself, for example).

Without this system and artifacts we’d still be scratching our heads.

Why Not SuperClaude, or Some AgentOS?

There are many “combines” like SuperClaude or AgentOS that stuff the context with fat prompts or skills, create 15 “specialized” subagents and try to “think for you”, automate everything. That’s more about vibe coding — “Dear Claude Code, make it pretty”.

Has its place, but that place is very far from engineering.

Quint Code is an exoskeleton, not an autopilot.

1. Minimal Overhead.

Your regular work with Claude Code stays regular. FPF only activates on command. Yes, in the Quint Code repo I share my CLAUDE.md, but more just as an example. I’m pretty sure Quint Code will work well without any additional instructions.

2. No Magic.

You see every step, you think together with Claude Code.

3. Structured Memory.

The session.md file stores the state of your shared thinking during the session itself. Additionally — all hypotheses, their statuses, DRR records, evidences are stored. All connected through metadata in files. Even if Claude (or you) “forgets” the dialog context, it will re-read documents in .fpf and remember: “Ah, we rejected MongoDB because we don’t have an admin”.

By the way, Quint Code has additional commands not related to the ADI cycle:

/q-status — where are we now?

Shows the current cycle phase, list of hypotheses with their statuses (L0/L1/L2/invalid), and suggests the logical next step. Useful when you return to a task after a break, lost the session or “lost the thread”.

It’s more than expected that working on a complex task you’ll get stuck at the /q3-* stage for several hours and forget what that stage even was in Quint Code.

Or you need to continue on Monday… Quint doesn’t just drop breadcrumbs, it leaves whole loaves of bread behind.

By the way, I’ve had cases where after /q3-test there were great scripts that after /q5-decide transparently moved into the main code. Claude Code while working through the Quint Code cycle still follows your instructions in CLAUDE.md regarding coding style and requirements.

/q-query — search through the accumulated knowledge base.

You can search by hypotheses, evidence, past decisions. Filter by confidence level (L0, L1, L2, invalid). For example: “show all verified evidence about caching, we researched something about this last month” or “what hypotheses did we throw out last week on task XXX-123 and why”

/q-decay — check evidence freshness.

Evidence ages: a year-old benchmark, documentation for an outdated version, links to an article about a deprecated API. This command shows which evidence needs to be re-checked or marked as invalid. After all, a decision made on stale data is a decision made blind.

When to Use Quint Code

I’ll say it: these commands can become an invaluable helper in these cases:

• Architectural decisions (database, queue, state management).

• Complex bugs where the cause isn’t obvious.

• Team disputes (need an argued choice) — copy disputes from Slack to a file and set Quint Code on them.

• When the cost of error is high.

Quint Code and FPF are completely unnecessary for:

• “Paint the button red”.

• “Write a sorting function”.

• “Fix the bug in the webhooks endpoint, need to check field X not Y”.

• And other obvious tasks. Please don’t use a cannon to kill a sparrow.

Quick Start

Global install (recommended for personal use):

curl -fsSL https://raw.githubusercontent.com/m0n0x41d/quint-code/main/install.sh | bash -s -- -g

Or per-project install:

curl -fsSL https://raw.githubusercontent.com/m0n0x41d/quint-code/main/install.sh | bash

2. Initialize (Claude will scan the project and ask a couple of questions):

claude
/q0-init

3. Start thinking about your task systematically:

/q1-hypothesize “It seems we shouldn’t use redis for queues because...”

Thinking can be an engineering process. You can debug it, optimize it, and version it. Give it a try!

p.s. Oh, you already guessed that Quint Code can be used not just for software engineering? And that nothing stops you from using MCPs and other tricks in the ADI cycle? You’re welcome ;)

Exception generation. You certainly know what this is and have definitely used it, if you’ve programmed even a little.

Here’s news for you: exception generation is very often bad.

In any situation where a try/except (or try/catch) block is used not for “wrapping” side effects like reading files, going to the network, or in an isolated place around a function (for targeted debugging purposes or simply because “there’s just no other way”) — it’s better to get rid of it.

But why? Because such try/except blocks seriously confuse two “processes”:

• Program execution flow

• Developer’s thought flow who will read this code

Think about it yourself — any instruction in a try/except block can throw an exception.

Does it seem like each such block increases the complexity of our program’s execution flow graph exponentially? It doesn’t just seem so.

Modern static analyzers experience… some difficulties with “invisible execution paths”.

Do not miss out on me; subscribe wherever you want https://linktr.ee/m0n0x41d

Brief historical background.

People started talking about exceptions a very long time ago — in the 40s-50s. The first software implementation appeared in LISP, where there were two functions — ERROR, which was called in case of a program failure, and ERRORSET, which returned, attention — either an error code or NIL.

In other words, this story in LISP is not about the exceptions we have now at all… The concept and implementation evolved, evolved, and developed to the point where instead of error codes we started generating exceptions, namely — creating exception conditions and handling them separately.

The period of mass distribution of exception generation fell on the 80s-90s.

And here’s the result. From a study by Carnegie Mellon from 1999:

Exception failures are estimated to cause two thirds of system crashes and fifty percent of computer system security vulnerabilities. Exception handling is especially important in embedded and real-time computer systems because software in these systems cannot easily be fixed or replaced, and they must deal with the unpredictability of the real world. Robust exception handling in software can improve software fault tolerance and fault avoidance, but no structured techniques exist for implementing dependable exception handling.

I’m writing this article in 2025, and there’s still no structured, reliable, implemented method for exception handling.

Mainstream OOP languages provide the same old try/catch, and frameworks spread several layers of abstractions on top in an even layer, further blurring error boundaries, often providing developers with no ways to handle errors except… wrapping it all in yet another try/catch.

On top of that, exception generation can seriously slow down performance. Here’s fascinating reading from the Java world. Though it’s not limited to just Java — here’s an article about experiments in C++. In Python, especially with 3.11, the situation seems not so dramatic, occurring exceptions slow down code by just 3-5 times.

I’ll just leave this here:

A try/except block is extremely efficient if no exceptions are raised.

They say that once upon a time, long, long ago, the grass was greener and programs were easier to verify. The times before the dominance of exception generation came were the times of Structured Programming — engineers wrote code using conditional operators, loops, and subroutines (functions with one entry and one exit).

Programs flowed, developed naturally “top-down”. Thanks to such determinism, they were easier to read both for people and machines — the first static code analyzer lint was publicly released in 1979. Well, you already know what happened next.

What do we do with all this?

You can act like Google (especially if you write in C++):

We do not use C++ exceptions.

In any other popular object-oriented language you need to… stop using exceptions :)

Or at least don’t bury them deep in code — let the try/catch block wrap a function right where it’s called (outside or inside). Yes, this might add some amount of boilerplate code, but then when exceptions occur, the execution flow will return faster to the deterministically beaten “path”.

Either way, we can find a way to program without using exceptions for flow control.

And you can also remember Golang. No matter how angular and dumbed down it might be, the biggest design decision aimed at strengthening Go code produced by developers is forcing them to handle every error explicitly. Yes, Go has defer/panic/recover, but you’ll have to work hard to twist and mangle the execution flow severely.

And finally — functional programming. Result monad, for example. Curtain. ¯\_(ツ)_/¯

However, I think most developers will find it much easier to simply abandon leaking raise/throw — look at your try/except carefully — maybe you can use if here? Look at raise — how about return?

Why, when talking about AI, do I almost always primarily mean Augmented, not Artificial Intelligence?

What is Augmented Intelligence anyway?

In translation, this would sound like — Augmented, not Artificial intelligence.

It’s quite difficult to establish the authors of the term, because the idea began developing long ago, long before the appearance of transformers, roughly around the same time when AI was first talked about as Artificial (late 60s, early 70s).

Augmented Intelligence is talked about in so many ways — both as a system design pattern, and as an approach to “human enhancement,” productivity improvement. The word Augmented appears in the context of theoretical LLM training methodologies and much more. Someone, for example, would rather remember AR, and someone might even think about Musk’s neuralink.

Therefore, in this post I want to talk about the interpretation from _my_ point of view, why I use this term, and how seriously I take it.

My interpretation lies somewhere based on my experience, and still somewhat gravitates toward a “design pattern,” we just need to figure out the design and pattern of what.

TLDR;

Artificial Intelligence — is about autonomous, independent agents that work completely without humans 🤘🏻
Augmented Intelligence — is about a something like symbiosis of human and AI, where each strengthens the other 👤🤝🏻🤖

In reality, the second (augmented) already works much more often and better than the first, is already much more present here than completely independent artificial. And as technology develops, the symbiosis mindset still looks more appealing than the “exploitation” mindset, even, not if — but when, artificial neural networks become even more cognitively powerful!

Why exploitation? Because Artificial from the perspective of human “collective unconscious” is already fully forming as our species’ relationship to AI as proprietary. Have you seen all those memes about bullying and threats against poor ChatGPT?

Being the boss — might not be bad, but cultivating a boss mindset, in my opinion — is counterproductive.

Let’s return to my experience and move away from science fiction and anthropological speculation.

Mindset matters

I’ve already started talking about mindset, and this is very important. Unfortunately or fortunately, AI is quite limited, especially as soon as we try to apply it in a narrow, vertical niche.

When communicating with things like ChatGPT or Claude, many people get the impression that “it’s very smart,” “it can do almost anything.” This impression forms not only among individuals, but also among companies, entrepreneurs who attempt to build new business with LLM or start a new one altogether.

Even quite experienced engineers and managers can find themselves believing that AI systems are something completely magical, quite simple in terms of implementation — “well, it’s already smart, right? It’ll figure out our mess somehow, and we’ll live happily ever after!”

As a result, another misconception follows — AI-related projects don’t need to be thought through or modeled at all.

In reality, this turns out to be a path to nowhere. Teams lightning-fast encounter difficulties and spend a long time learning the hard way, feeling out what and how LLM can do, and what it can’t, ultimately coming to the fact that people have one language in their heads, the model has a completely different language, we’ll still have to engage in ontological modeling of both the system itself and the language in which we communicate with each other and with the AI agent.

It turns out that humans are needed in AI systems much more than expected… and here we smoothly approach Augmented.

Human as part of the system

As long as AI hasn’t become a recognized or even a form of life, we continue to collectively exist in human society. Knowing or at least suspecting AI’s limitations, and especially knowing about the exceptional potential of this technology, I believe it’s correct to talk specifically about Augmented Intelligence as a way to effectively change our reality and ourselves for the better.

Already now, more and more quality AI systems are appearing, but all these surviving systems are either extremely specific and aimed at performing concrete tasks, or complex systems, workflow pipelines, which necessarily have human(s) who at minimum service the system, but often also perform the role of observer and quality controller.

Moreover, these systems themselves are obviously aimed at being used by end users — people, outside the organization as clients, or inside, if we’re talking about AI Platform.

I’m getting at the fact that even if we consider a scenario of a “very vertical” agent/AI system — it was still modeled, created by people, and serves people. Whatever AI is, however we consider it — it’s already closely linked with our large and small systems.

What about systems that still manage to be “without LLM,” and which might even manage to remain so for a long time, due to business specifics — here it still makes sense to talk about Augmented, because the efficiency of people working in such organizations can (and often already does) accelerate thanks to rational use of neural networks in their work.

Two scenarios of AI usage

If we consider from the end user’s perspective, AI has now become that very magic box, with which the user can start becoming very stupid (Artificial Intelligence mindset — the user almost completely delegates slow thinking to LLMs, and their cognitive abilities degrade), or develop, learn, get smarter, accelerate their work on routine tasks with the help of LLMs, quickly get feedback, strictly evaluate it — delegate a lot of fast thinking to LLM so it happens even faster, some selected part of slow thinking, but continue to make decisions intermediate and final, as well as apply mental effort to the task independently (Augmented Intelligence mindset).

What’s next?

I think there’s nothing wrong with creating more and more AI products, agents to help human agents or other AI agents.

Wherever the evolution of artificial neural networks goes, I’m completely uninterested in speculating about doomsday and other “analytical” nonsense — obviously, we won’t stop anymore, and benefits are still manifesting more than harm.

Yes, there seems to be a threat of depriving many people of physical labor, well, maybe it’s time to work more with brains and create? Or maybe on the contrary, more jobs will appear, of completely new quality, but which will still have to be adapted to in an Augmented manner?
I don’t know, in this blog I’m not going to waste my and your attention on these reflections, there’s too much such material, and if you’re interested — you’ll easily find it.

As I already said — Augmented Intelligence is about cooperation of different agents, strengthening each other. I want to believe that in this “design pattern” we’ll start building systems in which we not only better cooperate with LLM, but also as human with human.

Therefore, in my blog I write specifically about designing such “symbiotic” systems — where AI strengthens humans, at least even with the result of work on assigned tasks.

I believe that the conversation about Augmented — is grounding in reality, in understanding systemicity and interconnections. This is a path of thinking toward the conversation itself and efficiency overall. The conversation about Artificial — is too ephemeral, often speculative and entertaining, simply because it happened that way, while focusing on artificiality looks like directing attention only toward LLM, whereas in the conversation about Augmented we don’t forget about ourselves, and about other agents that will work in our system.

If you’re building AI systems and want them to actually work in reality and in production — welcome.

Introduction

In a world where we’re constantly offered new task management apps, time management techniques, and approaches to increase productivity, many of us find that despite all these tools, our real effectiveness barely changes.

We implement GTD, practice Pomodoro, use Kanban boards, read about Atomic Habits and Japanese Kaizen — but somehow we continue to feel overwhelmed and not productive enough, and often abandon these ideas altogether.

The main problem is that most productivity methods operate in a vacuum — they offer systems for organizing tasks but don’t address the fundamental question: what exactly are we spending our time on in reality. Without this basic understanding, even the most advanced methods remain just theoretical constructs that can’t significantly change our lives.

In this article, I propose a radically different approach to productivity, based on collecting and analyzing primary metrics — objective data about how your time is actually distributed.

We’ll look at the two most important resources – time and attention.

By honestly applying the practice I’m suggesting, you’ll be able to:

• See the real picture of your time expenditure without illusions or self-deception

• Identify hidden sources of time loss that you might not be aware of

• Create a personalized, convenient productivity system based on your preferences

Also from this article, you’ll learn:

• Why without primary metrics, any productivity system is almost certainly doomed to fail

• How I came to realize the importance of measuring time through personal experience

• A simple and flexible system for categorizing time that you can start using

• How to implement time tracking without turning it into an additional source of stress

• How to analyze the collected data and use it for real productivity improvements

Don’t worry — I’m not suggesting you become obsessed with every minute of your life. Instead, I’ll share a balanced and fundamental approach.

But all this will only work if you’re truly ready to finally see where your precious time is actually leaking away.

Why we need primary metrics

Primary metrics are extremely important whenever we truly strive to change any process for the better. Today we’re looking at our own lives and work on any projects as the process.

But first, I’ll tell you my path to the proposed system.

For quite a long time, I used todo lists and something resembling GTD. The everyday life of a family with a small child in rented housing in a foreign country can be quite unpredictable, but todo lists have increased my productivity over the past year and a half.

The more tasks I delegated to my todo list, the more computing power remained in my brain to perform work tasks more focused.

And I started to perform much more of them, so much so that I began to overwork in unhealthy proportions.

When I realized that overworking was a big problem, I started using time tracking to account for the time I spend on work. This was a purely intuitive decision; I was tired of overworking.

Although such tracking didn’t become a habit right away, over the course of several months I started working a reasonable amount of time.

But I didn’t feel like I had more resources for my own projects. I was still responding to any new ideas like this - “when would I ever have time for that?”

I spent most of my working time in focus periods, measuring them using the pomodoro method.

I was doing a lot, but I wasn’t doing it productively. Although all work tasks were moving forward, almost all of my projects looked as if they were standing still. I didn’t have time to regularly write a blog, think through and develop my side projects. I only had time to work, create new tasks for myself, study software engineering, and do something else in bits and pieces.

The problem turned out to be that I wasn’t trying to specifically ask myself the question - “where am I spending my time” and honestly find an answer to it.

The answer came through primary metrics. How do you collect these metrics?

Track time.

Wait. But wasn’t I measuring the time I spent on work? Yes, I was, but the goal wasn’t to collect metrics and understand where, what I’m actually spending time on, but simply to stop overworking.

And I achieved this goal, but didn’t achieve an overall improvement in productivity and quality of work across all my areas.

I filled all the other time (outside of work) with tasks that I managed to grab from the first or second priorities of my todo list.

Everything changed when I became familiar with the idea about the importance of primary metrics, the importance of grounding any ideas and theories in reality.

In fact, the applied methodology of productivity and work organization is not so important. It’s not important in the sense that there are many such methodologies, and different methodologies are well suited to different people.

But no methodology will work properly if you don’t realize what you’re actually working with, what’s really happening? How much work and resources are being spent? How productive is it in terms of progress toward the result?

Our most valuable resource is time, and in order to take a step into a more productive future, you need to understand where you’re spending this resource. Then you can choose whatever methods you like (or even develop your own) and use them effectively.

Perhaps you’re already scared now, and you have thoughts like this - “it’s absolute madness to track every activity by the hour! I’ll go crazy, I’ll just waste more time constantly recording these time intervals!”

You’re absolutely right – just trying to track where you spend your time without a system is difficult, will cause a lot of stress, and might be the opposite of the idea of efficiency.

That’s why I’m writing this guide article for you.

Time categorization system

Today I’m offering you a categorization system that will help you collect metrics without much effort.

Good news:

1. It’s not difficult; you already have everything you need to get started

2. You don’t need to mark the time minute by minute, and you probably won’t be able to. A drift of 15-30 minutes is more than acceptable to begin with

3. I’m not suggesting you become a productivity maniac and track time for the rest of your life (this is an optional habit, and you’re free to decide in the future whether you need it or not)

Bad news:

1. You’ll have to work independently with what you discover. I’m not giving you a fish, but a fishing rod.

As you can see - there seems to be more good news, right? :)

First-class abstraction

A good abstraction in software engineering is one that generalizes rather than specifies.

So, to get closer to a breakthrough in productivity, I suggest you try tracking how much time in your life you spend, divided into the following categories:

• Productive time

• Investment time

• Body maintenance

• Everyday life and rest

• Time wasted

Let’s understand what these categories are.

Productive time

Productive time is time you spent on focused work on specific tasks (like work tickets from a Kanban board). This is time spent on tasks that bring you closer to achieving some already outlined, planned, and specific goal. For example, strategic planning can also be included here - because it’s aimed at moving somewhere, it’s clear which direction to “dig,” we actually have a task like “Research X to understand how to do Z for project Y.”

Investment time

This is time you spend on self-education, general research work (searching for new ideas and opportunities), or on your side projects.

Investment time is called that - not only because learning and research are truly investments in your future but also because in case of urgent need, this time can be “sacrificed” in favor of productive time to complete a project or deal with some work emergencies.

Body maintenance

Sleep, food (quick preparation, but not fast food). Normal food that can be prepared and consumed in a reasonable time, not 2-3 hours. If you decided to prepare a lavish dinner for a celebration in the middle of the week - such time is more related to “Everyday life and rest.”

In general, the body maintenance category can be omitted from time tracking altogether, especially at the beginning, or if you have other monitoring sources (smartwatch/bracelet).

But we’ll come back to this.

Everyday life and rest

Everyday life and rest are all activities related to maintaining the home, paperwork, taking/picking up a child from kindergarten, and other routines.

Perhaps this category will be the first candidate for finding “time wasted.” Well, or at least you’ll have something to grab onto and start asking yourself questions like “what was I doing here for SIX hours? What kind of everyday life is that?”

We should strive for a system where the everyday life and rest category is not used to plug holes in your schedule, except for emergencies like hospital visits, or household chores that cannot be rescheduled from the middle of the work schedule to another time.

It’s better not to mix productive and investment time with other activities because, according to Kahneman, the brain takes quite a long time to get into slow thinking - 20 minutes! This means if you work on a difficult intellectual task using the pomodoro method, you’ll just be warming up during the first pomodoro! It’s not very productive to jump up and go on errands after that.

You can start by tracking in this category all the time that doesn’t fall under all other categories.

Be vigilant, “all other” means including the one below!

Time wasted

This category is for time that you “invested” in nonsense that brings you nothing (or almost nothing) useful in the long run.

By default, it’s not assumed to deliberately spend time (for hours) on nonsense. This category is rather designed for rewriting blocks of time (in whole or in part) from productive or investment time, during which we worked inefficiently or were distracted.

Of course, it’s also worth considering a scenario where you’re in a position of personal growth, where you’re already aware that you’re wasting time on nonsense, but this nonsense is so pleasant to you and allows you to seemingly rest well that you can’t get rid of it yet. This is normal! No judgment!

In this case, you can purposefully spend time on nonsense, so that later in the context of the week you can see how much goes there. Perhaps such a metric will help you stop doing this nonsense.

In general, it’s entirely your subjective matter to determine what is nonsense for you and what is everyday life/routine/rest. The topic of quality rest is a candidate for a separate article, subscribe! < INSERT LINK TO LINKS PAGE >

Practical implementation of the system

How to use this and what to do with it?

The categories presented above are a starting point, a framework on which I suggest you build your own approach to measuring your real time expenditures.

Here is a key point about composure and mindfulness.

Measuring metrics by itself gives almost nothing; you need to have a goal, and after collection, analyze these metrics.

The goal can be formulated very simply, for example - “I want to manage to do more!”, or more specifically “I want to stop spending so much time on nonsense”, or even “I want to find time to start doing X”, where X can be anything - learning a new profession, or pursuing a hobby.

Tools for collecting time metrics

Here, for example, is what a report looks like in my chosen time tracker for the week:

32 hours on Saturday is certainly a lot!

I definitely remind you again - you don’t have to be a time tracking maniac if you don’t like it / don’t need it / find it difficult. Look, I even have some errors here, that’s normal!

Maniacal tracking by too detailed categories exhausted me literally in a couple of days; eventually, I started using general categories, even for rest.

It’s important to say again about composure, about mindfulness - to the extent of understanding, be honest with yourself when tracking Rest / Everyday life. You must ruthlessly catch yourself trying to infiltrate obvious nonsense into any category other than the “nonsense category”!

If it’s difficult for you here too, resort to studying metrics, for example, screen time, which, as far as I know, all modern smartphones collect in a convenient format.

If you see in the metrics that you spend a lot of time on nonsense - this is very important, that’s exactly what we’re looking for here! We’re interested in how things are in reality, remember? So record everything honestly!

On my graph, it’s clear that Investment Time is more than Productive. Does this mean that I worked on tasks for 7 hours a week? No, investment time consists almost entirely of research tasks.

And of course, I couldn’t have tracked all this if the process wasn’t convenient.

Not an advertisement at all - I use free toggl. There are web, desktop, and mobile clients that synchronize normally, and as you can see in the screen above - you can build a pretty convenient categorization by “projects”.

But why so little Wasted Time? Why do I need to track time if I’m already a productivity cyborg? No! Not a cyborg!

As I’ve already said - before I started collecting these metrics, I had no time for any projects… Time tracking didn’t help me spend less time on nonsense; time tracking helped me understand that I have problems with focus! And with focus not in terms of distraction to social networks, but with overloading myself with too many parallel tasks! We’ll talk about this further.

But for now, let’s get back to tracking.

The good news is that you already have everything to start tracking time. You definitely have a clock somewhere, even if you have a prehistoric button phone in your pocket.

If you’re an active gadget user, even better! You can choose from dozens, if not hundreds (if not thousands!) of applications for time tracking, with pomodoro, todo lists, and the like.

But don’t rush! Maybe you already have too many such applications; more on this later.

Just choose and start! Follow only the basic provisions of the framework and adapt it to yourself.

Let’s outline an action plan:

• Set a goal for yourself, give yourself a clear “direction” - why are you doing this at all.

• Figure out convenient category names for you, as long as they follow the general idea of division described above.

• Choose a way to start collecting metrics - an application on your phone, a notebook for handwriting, anything!

• Collect metrics for at least 7 days in a row

• Analyze the result

• Find oddities, inconveniences, improve categories if necessary, and repeat the collection of metrics.

Instead of one week, you can collect metrics for two, or a whole month. If you suddenly find it simple and natural to start tracking time constantly in one format or another - don’t be scared, you’re not a maniac! Go ahead!

In any case, once you find a system that’s comfortable for you, it will be very useful to conduct such a weekly audit of your productivity at least once a quarter, or once every six months.

It’s also possible that after two such measurements, you’ll feel that you never need them again, you’ve understood everything, and you’ve “ramped up” into effective and mindful work throughout life. Great, if you don’t want to measure anymore - don’t measure!

Just don’t forget about such a wonderful mechanism; perhaps it will come in handy when you start working on a new project, or get a new job, and suddenly find yourself overly tired and buried under a mountain of endless tasks, which are all urgent and needed to be done “yesterday.”

The temptation to fall into specifications

At some point, an excellent thought may visit you - why don’t I start monitoring my time in more detail?

For example - here I seem to be staying in the recommended categories, but I’ll record how much time I spent working on project A, how much on calls for project B, how much time I ran on the treadmill, how much I worked with weight, how much time I spent preparing a salad, and how much I cooked borsch.

Although sometimes such detail can help - for example, I found that sometimes I got stuck in the shower for 20 minutes - there’s still a strong risk of getting confused, falling into excessive details, overcomplicating the process.

I suggest sticking to the most generalized categories.

Understand, you don’t need to know how much total time per week you spend preparing salads. Your main task is to find out as accurately as possible how much time you actually work and how much time you actually spend on nonsense.

From these metrics, you can delve into questions like “why so many tasks? Are they all really urgent and relevant?”, or “why so many calls? Is it true that they’re all productive…?”, and so on.

You can always go into any detail, as long as the metrics are collected at all. And it’s by no means certain (rather the opposite) that it will actually benefit you to track time separately for each work task. That’s madness.

Depending on your main activity and lifestyle, the proposed categories may seem too general or not quite correct.

It’s perfectly normal to slightly specify or rename them. For example, your categories might look like this:

• Writing blog articles (investment time)

• Writing code / solving work routine (productive time)

• Learning (investment time)

• Exercising (everyday life and rest)

• Reading books / articles / blogs (everyday life and rest)

• Doing nonsense (Nonsense!)

Or like this:

• Working on client projects (productive time)

• Studying new trends and design tools (investment time)

• Creating works for portfolio (investment time)

• Household chores and personal life (everyday life and rest)

• Aimless scrolling of social networks (time wasted)

Note that in both of these examples, I completely omitted tracking body maintenance, and that’s perfectly normal.

If you have a fitness bracelet or some kind of smartwatch that tracks how much you sleep, then consider that you already have a metric about sleep.

Pay attention to the quality of your sleep and rest! If you don’t sleep, then no tracking will save you!

Meals and their preparation may naturally be visible in the calendar or between records of time spent, so they can also be omitted (just make sure that lunch doesn’t turn into scrolling news/TikTok for another 40 minutes on top.)

As you can see - there’s plenty of space!

The main thing is that your categories follow the division into productive and investment time, healthy routine and everyday life, and finally a category for nonsense.

The Nonsense category is needed even if you’re super successful and mindful and don’t spend more than 30 minutes a week on nonsense. Just by stopping to even consider that such a category exists, you’re already giving nonsense more chances to seep into your life.

From collecting metrics to action

Analysis of the data obtained

Analyzing the collected metrics is a slightly more complex process.

When you start measuring time, you’ll have the opportunity to study the proportions of your time investments across days or, even more effectively, an entire week.

However, the numbers themselves won’t give much — in parallel, it’s necessary to develop the ability to work qualitatively and rationally directly at the moment of performing tasks.

This means increasing the level of composure and efficiency in each work session, which, combined with the analysis of time metrics, will give results.

This is exactly the reason why I included mentions of TODO lists and pomodoro practice in this article in the Primary Metrics section (and other places).

If you don’t start developing your composure in the moment, you’ll have nothing to record in wasted time.

I’d like to tell you that you can neglect composure, but unfortunately, that’s not the case. You need some additional mechanism that will help you determine what time was wasted and what wasn’t. And the main mechanism here is your responsible attentiveness to your own life activity.

Let’s look at a couple of examples of how to determine time wasted in vain. It sounds simpler than it might seem.

For example, you have a scheduled zoom call with colleagues. If the call was productive, in the sense that 2/3 wasn’t small talk, and after the end of the call, it became clear what to do next. This understanding is expressed purely in the subjective feeling of “we agreed about X, now I need to do A and B”, against which there is simultaneously a rather bright and terribly vague feeling of “What were we talking about? Why did we gather? What should I do next, huh?”

If you catch yourself on option 2 - boldly record the time of such calls as wasted.

Right now, you probably don’t have almost any mechanisms to influence the regularity and quality of such calls, especially if you’re an individual contributor, not an operational manager. A large number of such “vague” calls is a serious indicator of problems with processes and probably overall productivity in the organization, so I can only suggest that you focus on areas where you can manage your time, and subscribe to me, as I will definitely continue to write about productivity and systems thinking.

Another example. Let’s say you’ve decided that, like me, you’re comfortable working on tasks using the pomodoro method to fight distractions - we turn on the timer and for 25 minutes, no TikTok!

If you really didn’t get distracted - excellent! The pomodoro goes into productive or investment time depending on the work you were doing. Now you can space out for five minutes, or rest well :)

If you did get distracted, and significantly so, for example, you read emails for five minutes or more - this is definitely time wasted. I prefer to send all 25 minutes to the “trash,” which is both cruel and simpler than cutting out 5-8 minutes from a pomodoro. Besides - then during analysis, these blocks will attract your attention and you’ll be able to reflect better.

From metrics to action: task management

Now that we’ve figured out how to collect time metrics, the logical question is what to do with the freed-up time and how to organize your tasks.

After all, the ultimate goal of collecting metrics is not just to know where time goes, but to learn how to use it more effectively.

And here lurks a terrible devil.

Have you ever caught yourself having 500 interesting articles you want to read, and 48 projects you really want to start doing? While 10 of them are already in progress.

Please remember my story, which I wrote at the beginning of the article - in the previous year, I almost didn’t waste time on nonsense, I worked a lot. But I didn’t become more productive. Therefore, in addition to collecting metrics, you also need to learn focus, concentration on what’s important, concrete matter.

There are also a bunch of methods for this, but I’ll suggest you simply think and show rationalism. When you start collecting metrics and figure out where you’re spending time, this will be especially useful if you suddenly find yourself in the same situation I was in - buried under a pile of tasks, multiple projects, and so on.

First - throw away all the tools you’re already using, keep only one. Paper planner, todo application, obsidian with some plugin where there’s a calendar and daily tasks - choose something that will be convenient for you or at least seem convenient (you can always change).

But don’t go crazy; for tasks, you need one tool. Or at worst - one for work, another for all personal projects for purely logical separation.

If you’ve been using multiple applications, then looking a little closer, it will become clear what you really used - in one of them there will be the most tasks, notes, visible activity. Great - that’s it. It’s already convenient for you.

Now clean your planner of garbage that steals your attention and time.

Perhaps, like me, you started at some point to use the todo list as a repository for notes, reading lists, and so on.

REMOVE EVERYTHING from your TODO list that doesn’t relate to tasks you’re currently working on - work and your projects, it doesn’t matter. Leave only what you can’t remove, something that’s already somehow in progress, or is about to be taken into work and can’t be canceled anymore.

There are two possible scenarios here:

1. You threw out all the garbage and everything became crystal clear; it turns out everything isn’t so bad, and you only have 1-2 projects in progress, and you were only wasting time on nonsense

2. And more likely - Everything is terrible, you have 4-5 or more projects simultaneously, and a bunch of small tasks that logically don’t relate to any projects but take away a lot of your resources.

So, for those who found themselves in the second scenario - consider each of your tasks, and ask yourself a specific question:

1. What is this task, to which project does it belong? Is it clear at all what it is and when it needs to be done? If not - then you forgot to throw away some reminder or note that has no place in a TODO list. Do it!

2. If it’s still a clear task, then ask yourself what its essence is, what benefit and to whom will it bring - what will it affect in the real world? How well is it worked out? Does it really need to be dealt with right now?

3. Congratulations, you’ve either identified a valuable task, or found garbage again. There’s still a chance that you’re looking at something potentially useful - send it to the archive or some watch later on YouTube. The main thing is to clear up the planner.

Focus – that very composure

Okay, we’ve got a clearer understanding of where our time goes and how to organize tasks. But there’s one more critically important element, a universal tool of productivity in any business - the ability to focus.

Without this skill, even the most accurate metrics and perfectly organized task lists won’t bring the desired result.

I have good news for you! If you’ve read to this point without scrolling and in one sitting - you probably have good focus! The main thing is to clear out the garbage and collect metrics :)

Multitasking is a myth. It’s not the path to success; it’s the path to nowhere.

You need to learn to concentrate ON ONE thing, at every moment of time and on any scale.

Note that throughout this article, I’ve repeatedly mentioned the word composure. Your quality and composed attention is insanely important always, at any stage when we start to live purposefully, not just somehow.

Without composure, everything will always be “just somehow”

This may sound too stupid, but the longer you concentrate on one thing, the more results you’ll achieve.

I’m not suggesting you necessarily concentrate on one thing for your entire life, but that’s also an option. Imagine if you choose the meaning of your life - knitting scarves and hats. Every day you learn to knit, becoming better and better.

But that doesn’t mean you’ll only knit.

For example, at some point, you might want to knit for family and friends, and then it comes to mind to start earning from this - take it for sale.

And here you seem to have one goal and one business, but now “side quests” appear like:

1. Learn marketing

2. Develop a personal brand

3. Set up social media

And so on, but globally - the goal is one.

Many people for this reason jump from one thing to another, can’t find themselves. Because they didn’t set any of their undertakings as a goal, didn’t plan to thoroughly try and understand whether they need it or not, but started doing something in an emotional impulse inspired by others’ opinions.

The point is that concrete goal setting is also a skill from the category of composure.

And nevertheless, if you’ve chosen something more complex than knitting, for example, an engineering career - there can be many sub-goals that you can spend your whole life on.

That’s why it’s especially important to focus on one thing.

One brain definitely won’t be enough for this, in the sense of the brain itself. That’s why I’m telling this whole story about metrics - we need to constantly be reinforced by breadcrumbs from reality, so as not to forget what and why we’re doing, where and why we’re going, and who we are in general.

If you don’t know at all what you need, regardless of how old you are - just start consciously choosing things and trying to do them, until you get bored, until you start understanding that you don’t get satisfaction from what you’re doing.

Just try, the main thing is to start doing at least something!

The secret is that by focusing on something for a week-two-month, you’ll still learn something useful - it won’t be wasted. At the very least, you can learn composure! :)

The main thing - stop wasting your life on complete nonsense and terrible dispersion!

Okay, it’s time to finish this lyrical digression.

Why it’s so hard for us to concentrate

The modern world creates unprecedented conditions in which it’s increasingly difficult for our brain to maintain concentration.

First, we’ve evolved so that we can effectively process a limited amount of information. But modern technologies create a data flow that causes terrible cognitive overload, making it difficult to process and remember important information.

That’s why your attention is truly invaluable resource, second in value only to time. And it should also be treated precisely as a resource, for a very simple reason - attention and time are very closely linked!

Second, multitasking is a disgusting myth. The brain cannot process multiple tasks simultaneously. Instead, it quickly switches between them, which requires significant energy expenditure and reduces work efficiency. With each such switch, we not only sag in productivity but also increase the probability of errors.

Third, the problem with dopamine. Notifications and social networks exploit the brain’s dopamine reward system; this is also no secret. These things are literally created in such a way as to rob you - steal your attention!

Each new notification causes a small surge of dopamine, which creates an addiction to constant small “rewards” and disaccustoms us from the long concentration necessary for deep work. The endless feed is generally a complete mess about which I don’t even want to talk.

The constant flow of information leads to brain burnout. Symptoms include:

• Deficit of composure/attention - very difficult to concentrate on one task

• Decision-making paralysis (even simple ones)

• Dependence on technology to perform basic cognitive tasks - for example, a person doesn’t even try to add 17+8 in their mind and immediately reaches for a phone calculator

• Chronic stress and anxiety

• Sleep disturbance - seems like you didn’t drink coffee, and you’re physically tired as a horse, but it’s very hard to fall asleep

Recognizing all these signals and problems is the first step to restoring control over your attention (and life!)

The good news is that time tracking and developing awareness about where your concentration is really going can help with this trouble.

There are other useful practices that can help with attention training, but the article is already too long, so I’ll tell about them another time.

And besides - I sincerely believe that grounding in metrics, which we’re considering today, can give enough impetus for you to start solving this problem yourself (if it exists). Awareness, knowledge about the catastrophe won’t let you close your eyes further.

I hope you haven’t chickened out.

Conclusion:

We’ve examined three keys to real productivity:

1. Collecting primary time metrics through a simple categorization system;

2. Effectively organizing tasks in a single space;

3. Developing the ability to focus on one thing until it’s completed.

Collect metrics! I believe you can do it!

This article turned out very large, and perhaps a bit chaotic in places, because the topic is simultaneously very important and very extensive. And too… personal! Because I experienced a qualitative leap in productivity when I discovered my specific problems - task overload.

Without time tracking, I wouldn’t have seen what was already in the most visible place. So if I could force you to take away at least something from this article, at least one thought, I would force you to remember not about time categorization, but about grounding in reality.

Please, don’t live exclusively in your head!

Subscribe to my social networks; I write about systems engineering, neural networks (human and non-living), software engineering:

https://links.ivanzakutnii.com

In previous letters about Systems Thinking in the context of learning about rational work, we discussed what focus means, what mastery is, and the main problem—the gaps between reality and our subjective ideas.

The short conclusion – rational work can only happen where there is grounding in reality.

Many insights from masters across different practical fields are based on this idea, but everyone talks about it in their language. Systems thinking and engineering pursue a more specific goal – to develop an understanding of first principles and mastery in applying them, regardless of the practical field.

As a reminder, by grounding we mean a process in which we try to base on reality any of our ideas, transformations/optimizations in a company, and by the end of the day – any other kind of activity.

Plus, without any popular and good methodologies and best practices, we can achieve excellent progress just by relying on fundamental principles.

Let's define a basic practical methodology with which any long-term grounding and vision of reality will begin.

Pay attention to the long term. Once we have achieved some mastery in focus and responding to “Cognitive Noise,” we can begin to think and speak in the right direction.

The problem with just "thinking and speaking" is that the results of such a process quickly escape from our heads, and next time we'll have to "think and speak" almost from scratch – and it's, in fact, far from certain that it will be as fruitful as the first time!

Basic Methodology

When you, as a person with decision-making power (director in a company, head-of-something, or these decisions concern you personally and your life) are about to make decisions, first thing you are necessarily got to do is to sit comfortably and write down all entities and processes in the real world that your decision may affect, trying to understand how it will be affected and to what extent.

This "how and to what extent" is practically impossible to track if we don't establish the entities that will change, and there can be so many things that it's simply impossible to remember them all in your head. This is another reason why you need to write things down.

You definitely need to write down and externalize the results of your work into the real world so that later there will be something to continue working with, clarifying and improving this physical representation of reality. At this first stage you can write without trying to do it immediately in some efficient format – we will study the best methodologies in the future. You just need to write, write somehow in terms of form, but as detailed and grounded in the reality as possible in terms of content.

It's easier to look at your own activities, and they will likely involve fewer people than in the organization or team where you work – at minimum your family, so you can start practicing this way.

The main thing is not to consider some made-up cases – this will bring almost zero practical benefit, because the disconnect from reality here can be phenomenal.

We are learning how to ground into reality, so what is the meaning of grounding into non-existent cases, which most likely comes from internal subjective ideas? Useless work.

Thats why it's highly desirable to start attempting to ground in your work or business as soon as possible – the bigger the "situation" for modeling, the better – the more useful experience we can extract.

When "developing grounding" for situations and decisions in a large company, we need to trace all "entities and effects" at all scales:

• How the decision will affect the company, and what will change in its main work, outcome?;

• How it will affect departments or divisions (if they exist) - how will their work change? what will speed up (or slow down)? Will communication between departments suffer from your innovations?;

• What and how will change at the team level;

• And finally – how the changes will affect individual employees.

Analyzing possible consequences as thoroughly as possible, we will start identifying all the hidden problems that we might not have thought about at all, faster and faster.

If we're talking about a company, then this is of course just a starting point. We can't ground ourselves qualitatively alone.

Thats why this grounding process in the company will spread to other people in it. Thus, based on our initial attempt to ground, we should continue the process by talking to a bunch of people, checking our written assumptions, clarifying them, and grounding our model even more and better. This is the way.

The problem is that we still can sit down to write something "off the top of our heads" based on our subjective representations 😁

For example, we have a reformative idea, and we have representation about what departments, teams, employees there are in the company, representation about how they work, possibly even about their problems and needs. It's very difficult to understand what these ideas are based on; most likely they somehow formed on their own during our time working at the company. It's far from certain that these ideas have any real basis if we don't constantly-periodically communicate with all departments, managers, and employees for the purpose of grounding.

Additionally, we have an subjective idea of how and what our reform will affect. This can be very, very vague, but pretend to be "rational" until we start grounding it too.

There's nothing stopping us from pouring all these ideas onto paper, especially if we're good at writing, but they will remain subjective.

Something similar happens when a high-ranking boss says, for example – we're implementing pure scrum.

Okay, but… without any additional definitions, goals and at least somehow clear instructions. Then managers enthusiastically run to implement this idea without asking clarifying questions (what if the Boss will think I'm an idiot and fire me?), pushing unclear tasks lower and lower.

Who is doing what, and for what purpose in such a scenario – is completely vague.

Writing this post, I remembered a real-life story. At one of my previous jobs long ago, a colleague told me that when he worked as a system administrator at a factory, they had a Microsoft Server with an MSSQL database, everything worked well year after year, and was even occasionally updated 😂. One day the director comes in and says – "We need Ubuntu."

Literally, that's practically the entire useful payload he put into the order - “We need Ubuntu.”

To the natural questions - "Why? What for?" followed answers like – "We need Ubuntu. Ubuntu is cool."

Need I say that the only rational way out of this situation the storyteller found was to quit? Without the skills we're studying in Systems Engineering, it's almost impossible to communicate with such a director and explain to him all the potential difficulties. It's like rolling a d20 with significant penalties – the chances of success are extremely low.

Lacking of data and being scared.

The next key idea – information about reality is almost always lacking.

This is (again) about not only work in organizations but also our subjective representation of ourselves. Try to trace how many of your ideas are not based on primary data, but are based on something like: "that's how people think," "it goes without saying," "everyone on social media says so," "mom taught me that," and so on.

By primary data, we will mean metrics from the real world that haven't yet gotten into anyone's "head" and haven't been processed or transformed in any way.

This can be difficult, and also – it can be scary to even think about it.

Most likely both scary and difficult! 😨

The brain understands what it's facing – a lot of work for collecting and evaluating primary data, comparing this data with subjective representation…

The process that could (will!) potentially greatly shake our precious, very stable (in the coordinate system of our already "default" ideas) picture of the world and ourselves in this world.

The process of collecting this data not only boring, slow, it is literal danger for this lazy fellow inside. And it knows it.

But the result is definitely worth it.

Don't listen to these signals, you're not a trembling creature and deserve to change your life and the lives of people around you for the better.

And in the end, it's not that difficult to start collecting metrics of reality, you can sacrifice, for example, the constant grabbing of your phone to watch short, stupid videos and spent some time writing down and finding good software for time tracking and writing notes :)

Just make a brave decision... That's the only thing that might be hard.

Lets put it that way – if you want changes, changes definitely for the better, you may need to bring your system of subjective ideas into a threat, the new way of thinking (and living) where priorities needs to be restructured toward reality, rather than subjective hallucinations.

The scientific rational approach is based on this readiness to accept this "new" reality and continue to exist in it, when it is confirmed with metrics from the real world.

Wrapping up with a silly picture :)

Mostly, awareness of the gap between reality and a situation (our subjective perception of the situation) happens intuitively.

This is a very fast process, it's even more like a feeling.

Such tasks are processed by fast S1 thinking according to Kahneman, which compares facts/features related to the evaluated phenomenon, and facts/features from some "database" that is filled with our explicit and implicit subjective experience throughout life and work in subject areas.

S1 thinking according to Kahneman is an automatic, fast, and intuitive way of thinking. It works without conscious effort, based on associations and heuristics, allowing us to react almost instantly to situations. This thinking requires little energy, is based on habits/experience, and is highly susceptible to cognitive biases.

When fast thinking finds inconsistencies, we feel it as something vaguely "something's not right", "they're talking/suggesting nonsense", or on the contrary, when this thinking finds consistency, matching – "I feel in my heart that this is the holy truth, everything is correct!"

It's very important to pay attention to both of these feelings, especially the feeling of wrongness. Anatoly Levenchuk in the SSM courses suggests an interesting term for this feeling: "jitter." I'm introducing it here because I like it, and I plan to use it further. Distinguishing jitter is important because it's a clear indicator of some inconsistencies of perceptions with reality or perceptions with perceptions—both need to be fixed.

Basic intuition develops kind of "on its own along the way", although it can and should be improved (trained).

Master's sense

Master's sense is another type of intuition that doesn't develop entirely on its own, and even rather the opposite.

Such intuition is the process of transition from unconscious incompetence to unconscious competence, where the latter is exactly the "master's sense".

There is a "competency square" that perfectly displays the path through which this type of intuition develops:

At the very beginning of work in a new subject area, when we're just learning, we can't even say what we don't know. This is unconscious incompetence. Gradually, we develop skills, and mastery, until this mastery is elevated to automatic application.

At this stage, we begin to notice inconsistencies in our own or others' words (spoken or written), documentation, and other sources of information.

If we have a problem with emotions and self-control, then having such a degree of applied mastery, one can start "getting angry at the surrounding idiots", but this is a big problem and a topic for a separate conversation. In any case - pay attention if you notice such consequences of jitter in yourself, this is a destructive pattern and generally a sign that you need to work on basic mastery of composure. There can be many reasons, both biochemical (simply problems with hormones that you don't know about or know, but don't allocate enough strength and attention to fight them), and psychoneurological. The latter seems to be easier to work through, but this most likely requires professional help.

“Fundamentally first” skill of catching jitter

Both types of intuition are needed and important, it's useful for us to both know about them and consciously develop them.

Timely awareness of jitter is one of the basic types of applied mastery of composure that's very important for us to hone.

The problem here is that we can too often either not be aware of these inconsistencies, or let them "in one ear and out the other". Such skipping happens because we don't realize how important an indicator this jitter is, and we don't know how to work with it at all.

Well now, I hope, we've realized the importance. But how to work with it?

Ground the gap.

By grounding, I mean that we should base our reasoning on real-life metrics, not just on our subjective ideas, which are often based on other ideas or on some vague concepts. Even if these ideas were initially based on real metrics, they tend to become obsolete, so we need to continuously gather fresh reality metrics and update our reasoning. That's basically the essence of Data-Driven Development.

But of course we are far from world where everybody understand that, and already completely aware of it. Thats why we should train a skill of catching jitter, so we will be able to ground the gap. How so?

You can start by catching semantic patterns in communication with colleagues, and in communication with "yourself".

Such communication patterns may include:

• Vague, confused answer to a question - answer without confidence, with stumbling, hesitations. Lack of confidence and specificity in the answer may, and often indicates, that the words are little connected with reality;

• Phrases like "seems possible", "well in principle we'll do it", and "theoretically doable" sound - the loudest signals of a break with reality, require immediate intervention.

• Too long, drawn-out answer to a quite specific, almost closed question - the person answering the question either didn't understand the question, then we need to clarify it ourselves. If after clarifying the question the answer is still too vague - we need to pay more attention;

• And conversely, too quick an answer to a question which (as we know) requires some analysis and reflection - for example, the universally loved task size estimation, the developer instantly replies "I'll do it in two days";

• Vague phrases without grounded specifics - "We're making a digital product", which one? "we're developing fintech API" - which one? What features? "We're producing packaging" - what kind? Cellophane bags? Cardboard boxes? Dry cast iron containers with spheroidal graphite for radioactive rods?

These are basic examples to start with. With the development of mastery of attention to jitter, we develop our signals, we can say that we fill that "database" for intuition, which we talked about earlier.

Next time, we'll talk more about "grounding," "reality," how to see them, and what might block a clear view. If you found the material even a little valuable, please support me with a subscription. I'm really happy for every new subscriber ❤️‍🔥

Subscribe now

Either they disagree with me or think I'm out of touch with the progressive world of LLM-driven development, that I don't know how to do prompt "engineering". I don't know 🤷‍♂️

A couple of times people have already DM'd me asking - which model am I actually using in Cursor, maybe I'm clicking something wrong here, and instead of Sonnet 3.7, default is selected?

I perfectly understand the mainstream excitement about LLM-driven development, it's easy to reconstruct, and for the most part, I sincerely share it.

Cursor (with Anthropic models) greatly speeds up development, routine coding, generating large fixtures based on models, simple functions "in a vacuum" and so on. It helps to factorize code chunks faster, and move them around better than just renaming in an IDE and manual copying.

Subscribe now

Dear colleagues, I criticize LLMs mostly to spark in you the desire to think with your head, a spark that's already absolutely priceless nowadays.

I sincerely wish that you wouldn't "become stupid at breakneck speed" and catch yourself spending 20 minutes poking at prompts when the LLM doesn't understand you, trying this way and that to stuff files into the context - instead of finally writing code yourself properly, according to your understanding.

Furthermore, I strive for you not to forget that starting from middle+ and especially from a senior belly size position at work, your activities will consist less and less of writing code and more and more of making architectural decisions and puzzling out processes.

Tasks will become increasingly complex in terms of their systemic nature and dependencies, they will involve more and more other agents, people or bots - it doesn't matter, these tasks won't get particularly easier.

If you think that most of an engineer's job (especially if the engineer is adept at systems engineering) is just writing code, drawing UML/Mermaid diagrams, making architectural decisions, and so on – it is not.

The less you are a coder-programmer-individual-contributor, and the more you are an engineer, the more your work will resemble that of a professional detective in some good psychological thriller.

Dude, we've got a body, could be murder.

The main engineering work, if we're talking about mature, result-oriented, and reasonable engineering – feels like detective work, in a quite a mystically complicated case.

You need to interrogate all witnesses, and you also need to interrogate the main suspect (oh, I mean the main stakeholder), whom, by the way, you still have to find because it's not always clear who it is in each specific case.

Besides, you probably have a bunch of "police officers" working with you, some of whom are alcoholics and drug addicts might be extremely inconsistent in their beliefs and difficult to communicate with.

But even if everything is in perfect order with subordinates, each of them individually finds common ground with you – they all see the world in their way, have their own opinion on the project, opinion on who the main suspect is, opinion on what the solution and the ultimate goal should be, while rarely finding this common ground with each other as well as they do with you.

It turns out that the job of such an engineer-detective is not only to punch faces in alleys and drink single malt whiskey with tormented eyes but primarily to make all strategic decisions on solving the case, get all colleagues and suspects to talk to each other in common language, put them in their places, in the sense that the case successfully moves toward resolution and everyone is happy with their work, and the bosses with the clearance rate.

LLMs are simply not capable of such detective work, and in my stupidity, working with Cursor for some time, I stubbornly tried to communicate with it in such an engineering language (well, it's interesting to test the limits, right?), because it seems that's why they gave the ability to add different files for context in the chat... 🤔

After adding all related modules, describing architectural issues in quite detail, Cursor too often starts to seriously drizzle.

Interestingly, switching to the tab with regular Sonnet, and asking a question in almost the same format, but apparently without some "project context" (that Cursor might somehow collect under the hood) often gives sensible answers.

For this reason, I stopped struggling and tried to ask flatter, more specific requests, more and more often in chat mode, not "composer/agent", just the same way I was working with Sonnet, before I had started to use Cursor.

Besides that, and this is very important – an LLM will never "argue" with you.

All your instructions, right or wrong, the LLM happily takes to work, leading you down an increasingly crooked path. So if we don't have a circuit braking mechanism in our mind for self-reflection, to at least somehow try to check our hypotheses regarding some piece of project design before blindly giving them to the LLM to work on - we're completely screwed.

Here I had the thought that I maybe could stuff something like - NEVER AGREE RIGHT AWAY with my hypotheses in `.cursorrules`, but I sense that this might only make things even worse.

If you ask the LLM very specifically, as flat as possible, precisely, but moderately detailed (roughly as a good senior assigns a task to a good junior) - the results are almost always impressive.

Enthusiastic moans might scare with the potential volume of new shit code and the new speed of generating this crappy code. But they don't scare, because there's already more than enough of such code. We did train LLMs on something after all :)

Everyone is happy - both programmers, who now have to think even less, and business owners, who don't care about clean architecture, technical debt, and stuff – as long as the features are delivered faster and more money flows in.

My line is very simple, and not even bent – in both the old and new LLM world, the one who trains their main "muscle" won't be lost.

You need to think.

Stanford guys continue the "Let's make LLMs friendly with each other" arc.

Overall, the concept is certainly excellent, and humanity will sooner or later reach some impressive solution here thanks to the synergy of accumulated research, as usually happens.

What raises questions for me is that they've again arrived at an approach where a "large, smart, expensive cloud model" generates pieces of code, which "local, small, cheaper, and less intelligent" Minions execute locally, for example on data from PDF documents, and then return results to the big model to generate an answer.

Well, it's generally cool, except for one big issue - How strongly this still reeks of terrible non-determinism.

First, from the user's perspective - what about security? By what means and in what environments will these models run locally? In Ollama? Okay. Do we trust the code generated by LLMs?

Not. I don't trust it.

Despite all the benefits in speeding up work and accelerating by mortal reasoning with various excellent tools like Claude - I don't believe that such "protocols" will be viable and *successfully* adopted even somewhat widely in the near future.

Subscribe now

Now, if we develop a specific product with locally running models that clearly "understand" their responsibilities and capabilities (tool-calls?), process the user's request (potentially understanding it better than the user themselves), and then when necessary, reach out to an LLM, perhaps providing the results of their work and the original request to predict the final answer - well... that sounds interesting! Very much so!

Second, from the developer's perspective of such a system - how do you even debug this? Is the complexity of such a non-deterministic system justified? I won't elaborate here as it seems obvious.

The deeper you dig into this, the more purely practical problems arise which, in my opinion, are better solved through familiar and proven methods.

Third, attempting to communicate even with small pieces of code, I mean not tool-calls, but as in the work above - this is already some kind of minimal engineering. And LLMs are not ready for engineering.

Understand me correctly, even Cursor with its latest update, when it tries to "analyze" previous results in a loop - analyzes complete nonsense. It might suggest you delete migrations, simply mindlessly - Let's regenerate it! Or blatantly hallucinate methods and classes from imported packages that don't exist. It now can suggest the user execute a command in the project directory (in the terminal) and continue working with the response from this command.

The result is the same.

Just don't. I see your objections coming. Some too many people go crazy praising the qualities of LLM assistant code.

And there's a small number of computer science folks and folks who have been coding for 20+ years already. These people admit all the true benefits of coding with LLMs, while mercilessly criticizing its possibilities for software design.

I'm in this camp, even though I'm not a degreed scientist, and not yet an old folk (Am I?)

Debugging with Cursors goes similarly - often with simple stuff, type inferences and other things Cursor can handle well, but as soon as we encounter debugging a problem of even slightly more complex order, where you need to reason about 2-3 dependencies - it hits the glass ceiling of its "cognitive capabilities."

And yet - these are all very cool things! Magical! I am fully in love with machine learning and neural models of all sizes. They greatly help and speed up work! And this is indeed an applicable informational technology, computer science discipline of a New World. No Doubt.

However, at the current time, LLMs cannot analyze or think **logically** to any significant degree.

All the "thinking" we currently observe in modern LLMs is a desperate attempt, a respectable attempt, to somehow make LLMs generate "intermediate tokens."

The first attempts (well, basically those we're observing now) - of intermediate reasoning in natural, human language - shatter to pieces.

This is now known as the tokenization problem - For LLMs, reasoning in our languages is limited by the discreteness of the tokens they form. What results is that the quantization of the meaning space of the problem being solved happens in these very tokens - wherever the temperature coincides, that's where we fall.

In real, human analysis, logic and reasoning don't work like that.

In this light, these two works seem more interesting to me:

DroidSpeak:

Large Language Models (LLMs) are increasingly employed in complex workflows, where different LLMs and fine-tuned variants collaboratively address complex tasks. However, these systems face significant inefficiencies due to redundant context processing of the shared context. We propose DroidSpeak, a framework that optimizes context sharing between fine-tuned LLMs derived from the same foundational model. DroidSpeak identifies critical layers in the KV cache and selectively recomputes them, enabling effective reuse of intermediate data while maintaining high accuracy. Our approach balances computational efficiency and task fidelity, significantly reducing inference latency and throughput bottlenecks. Experiments on diverse datasets and model pairs demonstrate that DroidSpeak achieves up to 3x higher throughputs and 2.6x faster prefill times with negligible accuracy loss compared to full recomputation.

And Byte Latent Transformers:

We introduce the Byte Latent Transformer (BLT), a new byte-level LLM architecture that, for the first time, matches tokenization-based LLM performance at scale with significant improvements in inference efficiency and robustness. BLT encodes bytes into dynamically sized patches, which serve as the primary units of computation. Patches are segmented dynamically based on the entropy of the next byte, allocating more compute and model capacity where increased data complexity demands it. We present the first flop controlled scaling study of byte-level models up to 8B parameters with 4T training bytes. Our results demonstrate the feasibility of scaling models trained on raw bytes without a fixed-vocabulary. Both training and inference efficiency improve due to dynamically selecting long patches when data is predictable, along with qualitative improvements on reasoning and long tail generalization. Overall, for fixed inference costs, BLT shows significantly better scaling than tokenization-based models, by simultaneously growing both patch and model size.

In short, DroidSpeak - making it so models communicate with each other without tokenization; Byte Latent Transformers - is also about abandoning tokens in favor of byte representations.

Both approaches create a more "adequate" space for model reasoning, a less discontinuous space - got rid of tokens and "think" in continuous vectors!

In addition to this, continuing to train models on mainstream codebases with CRUDs and so on, as the practice has shown - doesn't increase the quality of either generated code or "thinking" at all (meaning from the point where we are already.)

On the other hand - training models in logical programming using a language like Prolog looks very, very promising.

I want to believe that these directions will be completed and won't die out. And this belief comes without much effort.

In Uncle Bob's interpretation, LSP sounds like this:

Functions that use the base type should be able to use subtypes of the base type without knowing about it.

In even more simple language:

To safely use inheritance, you must ensure the ability to correctly pass a child object to methods/functions expecting a parent object.

Subclasses should extend, but not change the observable behavior of the parent class.

By behavior, we mean not only method signatures but also that state changes in the subtype must be **compatible** with state changes in the parent class. This is an important point.

So, in addition to the basic formulations, today I offer you to link LSP in your mind with the following phrase:

Don't surprise other programmers!

Surprise in engineering is very, very bad

In everyday life, emotions are very important, especially pleasant surprises.

They cause a big emotional response, and the event is better imprinted in our memory than ordinary hustle.

Surprise in programming is almost always an unpleasant surprise.

Last time, we talked about OCP from the perspective of functional programming and in general. In this post, I said that I feel a strong kinship between these two principles.

Here it is - in the responsibility for our modules and interfaces.

Breaking Changes are always trouble, we must avoid them at all costs if our system/module/library has even one user!

And "user" here can be not only another programmer or end-user but also another sub-system that depends on us.

I will never get tired of repeating this because I've seen too many such damn surprises.

A man's word is his bond

Adhering to the interface contract is good. That's essentially what LSP is about.

At the same time, adhering to contracts is good not only in OOP, but also in FP, and in programming in general. You just need to understand what a "contract" is in your context.

In the world of functional programming, there's something called type classes. But it's not really about types and not about classes either.

A type class is more like an "interface" that indicates that something can perform this method on this class. And the class here is a blurry concept, and you shouldn't immediately associate it with your favorite OOP.

Here's the key difference from "regular" interfaces in OOP, which are explicitly linked to a class and state - "this class can have such methods" - A type-class is a slightly more independent entity.

Type classes are probably fully implemented only in Haskell, in the sense of the purest and most complete implementation of the concept.

Nevertheless, our beloved interpreted languages have similar tools.

For example, in Python, there's singledispatch in functools, which is an implementation of dynamic dispatching based on the first argument.

This is not @overload, with singledispatch, Python checks types at runtime and chooses the right function.

Unfortunately, singledispatch is not supported by type checkers, but there's dry-python made by Nikita Sobolev that does the same thing, only with a sleek style, and mypy understands it.

In short, a proper implementation of a type class is a set of functions that the compiler or interpreter deals with. In some sense, it's similar to pattern-matching, but at a much lower (or higher :) level.

Why do you need to know all this? I don't know. To not break your own and other users' legs?

We have tons of ways to program systems correctly. Tons of languages, tons of paradigms. All this variety of methods can be confusing, drive us into implementation details, and turn us into crazy keyboard monkeys.

It doesn't matter what language you write in, and what programming paradigms you believe in. Instead, as I mentioned earlier, I offer you to focus on clear engineering and human principles:

1. Don't surprise other engineers.

2. Looking at the interface, take full responsibility for implementing all its invariants, pre-conditions, post-conditions, and other promises.

Subscribe now

Share

Leave a comment

Again, like the other principles from SOLID, this one sounds quite understandable:

Software entities should be open for extension but closed for modification.

This principle was provided to us by the respected Bertrand Meyer, through his book “Object-Oriented Software Construction” back in 1988.

Initially, the idea was largely about starting to approach interfaces responsibly and stop breaking them, bringing suffering into the lives of clients.

Subscribe now

Mr. Bertrand introduced us to the concepts of an Open Module and a Closed Module.

A module is considered open if it's available for extension - we can add fields to data structures, new methods/functions, and so on.

And a module should be considered closed when it already has users! For example, it's already being used by other modules. A closed module already has a clearly defined interface in terms of description.

When we start talking about this in the context of the OOP "world," the very essence is very similar to the idea of LSP - don't break the parent class, override methods -- inherit and add _new_ features.

Following OCP, we can extend or change the system without modifying already written code.

In "popular development," OCP is immediately associated with OOP and inheritance.

Look at two articles in Wikipedia about OCP - in English and Russian. If you don't know one of the languages, it's enough to simply translate with Google Translator, even such a translation will be enough to see the difference. This is either stupidity or cyber sabotage :)

Well, with OOP everything is clear. We have a parent class, or even an Abstract base class from which we inherit, and implement logic. Child classes reuse "basic" logic or extend it. All this is so that we can sleep peacefully and not touch the already working, original implementation.

Easy Peasy, everybody knows that.

What about the pure, functional world?

Programming functionally, we can follow OCP using higher-order functions and composition.

A higher-order function is a way of drawing a boundary between one behavior of the system and its remaining part. A way of abstraction, if you will.

This is a kind of alternative to inheritance because by passing other functions as parameters to this higher-order function of ours, we can change the highlighted behavior.

Of course, "internal" recursive calculations implementing some logic in terms of OCP are closed "modules," closed for extension. This means that we don't have any "inheritance of implementation" as in OOP.

This is not a problem because, thanks to function composition, we can model different behavior.

We do not change the implementation of our functions at all, but we can compose different functional models from them. For example:

In addition, algebraic data types are also very well suited to elegantly follow OCP.

In particular, sum types can be, well... summed, and this kind of naturally implies extensibility without changing what already exists.

An example of a sum type is a Rust enum:

In the future, we can add a new variant here and (most likely) not break the existing implementation. Of course, the Rust compiler will hit us on the head and force us to handle the new variant in all pattern matches.

And that's great!

For this reason, I don't give examples of Enums in Python - no matter how strong Python's type system is, and no matter how many cool, adult things we could emulate on it, there's more hope and faith in static typing.

Of course, all these examples are very close to code, but this doesn't diminish their value for understanding.

Although OCP can be expressed in applied pieces of code, first of all, I want to emphasize this:

OCP, like many other principles of software engineering, should first be considered and understood from a higher, design perspective.

In other words, OCP as a principle at its core has nothing to do with OOP at all. It's a principle of _designing_ software systems, in which we introduce the concept of a "black box" into our field of thinking, which we take as a software module that we can reuse, extend in one way or another in a functional sense, **but without changing its structure**.

In short, let's reinforce - adding a new feature by changing already written code is almost always BAD; Implementing a feature by writing new code (note, I'm not talking about the number of lines of this code) is almost always GOOD.

That's the whole essence of OCP ¯\_(ツ)_/¯

But! OCP is not a silver bullet, and it's impossible to follow it as a holy truth, well, you just can't. In software engineering, there are no such bullets at all, be it SOLID or something else.

In light of today's topic, trying to unreasonably blindly follow OCP, abstracting everything in a row, forgetting about the context of the project domain, and blurring it, we will only bury ourselves under a huge layer of crap code.

We need to remember OCP especially clearly when designing those parts of the system that are most likely to change.

And this, as it seems to me, in turn, means that "these very parts" should be somehow separated from the parts that most likely will not change at all.

Although we would like to believe the first intuitive assumption that this dependency is linear, where each new dependency increases some abstract COMPLEXITY counter by 1, in practice, this is not the case.

It is almost always exponential growth.

Many engineering principles aim to make our systems more reliable in operation and simpler to understand.

In light of the complexity topic, mainstream development recommends developers manage dependencies in the project following a simple rule - "Depend only on what is *really* necessary."

Seems pretty simple. In a more engineering interpretation, we're talking about the I in SOLID, which stands for - Interface Segregation Principle.

Don't be fooled by the definition itself, because ISP implies not only interface dependencies, but also dependencies between libraries, functions, classes, data, and so on.

Like all other elements of SOLID, ISP can be quickly and intuitively understood by somehow experienced developers. However, it seems that applying ISP in practice is much harder than talking about its meaning.

We've all been there - implementing some class, and having the task to implement only specific functionality, like searching by ID, and then we all often get this brilliant idea - "I need to add methods for adding and deleting right away, they'll be needed anyway!"

The mental reasoning from a purely human point of view is understandable and may be justified, for example - it seems very convenient to give another developer/user a larger, richer interface!

Of course, this is already a violation of ISP.

Following the logic above, as a result, already at the testing stage of what we've written, we'll bump into interesting moments - how do we know that to test our functionality we need to test only _this_ search method (mock what's related to it, write fixtures, etc.), and not 2 other methods that we wrote?

Well, it's simple, solely by knowing that currently only _this_ method is used in the implementation!

As a result, we wrote N extra methods and wrote unnecessary fixtures/mocks N times for each, and in the tests themselves we're testing the implementation. The latter point, of course, is always cool at the moment but loses most of the value and essence of testing - testing the behavior of the system.

At this point, I thought that TDD might help us here; when we turn the "default" development process inside out and implement only what we described in the tests. However, nothing still prevents us from showing mindset persistence and immediately writing tests for "extra" methods. See the trap?

Whether with TDD or just test coverage - we need to think not about implementation and test not the implementation, but behavior. Sorry for this sidekick, today we're not talking about testing.

Returning to the topic of ISP, instead of bloating the interface, in our arsenal we have exactly the opposite trick - organizing many small interfaces, each of which provides up to calling just one function/method.

This is a cognitively simple trick for any developer in terms of implementation, and quite valuable in terms of result - now services can declare and explicitly depend only on what they need.

As a substantial bonus - the code becomes more visual and readable, and when writing tests, we may not need to dig into the implementation at all.

In some sense, this approach leaves room for super-impulsive developers to immediately define all the "mini" interfaces for all the "definitely will be needed soon" methods. The main savior thing is not to stuff them into the implementation without necessity and ruthlessly delete them in time during self-code-review when you realize that it's not used in working implementation :)

Ok, Ok! You may keep it!!! Just not stuff them all into the implementation!

Perhaps reading these lines, you already have a question - "What?! Do I need to implement each such interface separately?".

Well, of course not.

In C# and Java, one class can implement multiple interfaces, in Python there is multiple inheritance "for free." In Go... in Go, everything is as flat and explicit as possible (even it's called "implicit implementation") - and interfaces are automatically "stretched" over structures implementing their methods.

In Rust, you can explicitly implement several traits for a structure.

¯\_(ツ)_/¯

With new requirements, for example, initially, we needed to implement search by ID, and now by name or some other field, the approach with "mini" interfaces is still applicable and flexible enough.

At the same time, depending on the language used, we can avoid listing implemented interfaces as separate fields - using generics (Java/C#/Rust), interface composition (Go), and multiple inheritance (Python. Yes, again.)

The approach we've considered, while good, probably causes very mixed feelings among developers who love and constantly use IoC containers.

IoC containers are good for automatic injection of interfaces, and these interfaces almost always... how to put it mildly... "VERY HUGE."

The "mini" interfaces may be far from convenient, beautiful, or justified to inject using containers (underline as appropriate.). Especially when generics have come into use.

Injecting something like a generic interface using IoC containers will inevitably be complex, and opaque, exactly opposite to the clarity and simplicity we, as professional engineers, would love to follow.

In mainstream programming, IoC containers are used as magic boxes to make the developer's life easier by automating the creation of necessary objects.

So, IoC containers make the programmer's life easier (seemingly) but lead to the bloating of interfaces. Bloated interfaces practically automatically lead to leakage of dependencies, and quite often - unnecessary dependencies.

In addition, these dependencies may be completely unobvious when a class receives injections of such interfaces.

As a result, behind the abstraction of the IoC container, we simply blur the real abstraction, lose clear boundaries, lose the ability to simply enough track and reason about real dependencies, and, ultimately, debug the system normally, without risking our mental health.

It turns out that almost any codebase with massive use of IoC containers is one continuous violation of ISP.

And do we just turn a blind eye to this?

In my previous post on this topic, we found a good definition of abstraction - it's creating a mapping from the concrete "messy" world into a clean mathematical representation. When this mapping is "built" correctly, we get a new semantic level where we can reason about the system precisely while maintaining the connection with reality.

DSL naturally follows from correct mapping between concrete and abstract levels, serving as a tool for working in this abstract space

Here's an interesting example from infrastructure code: imagine a (really) complex distributed system with many services and high SLA requirements, running on Kubernetes with all the tools you love.

We can rise above the level of specific Kubernetes manifests (and Kubernetes itself, because we're not interested in Kubernetes per se, but rather in our system that lives in it) to a higher semantic level - let's call it `SystemState`.

Our SystemState could define a formal model of the entire system and its components consistency model.

It might describe:

• Service versions

• Cluster and cloud infrastructure configurations

• Rules for state transitions during deployments

• Message formats in queues

• Distributed database migrations

• <NAME_YOUR_SYSTEM_THING>

Unlike common declarative infrastructure descriptions (helm charts, terraform, GitOps, and whatever else), such abstraction promises to provide guarantees of invariants and correctness of state transitions.

Of course, formally defining it and implementing is a very complex and questionable endeavor - the more dependencies in the system, the more complex the state graph becomes. So while I think it's a good example, it's quite theoretical.

And anyway...

Start with building a healthy modular monolith - you'll have time to split it later!

Looking at existing solutions like Pulumi - it feels that they're moving in this direction, opening a possibility of infrastructure expression at a higher abstraction level (we are not limited by "declarative" tool rules).

I would not be me if I did not note the connection between functional programming and building proper abstractions. FP works well with abstractions, or more precisely, FP's nature is much closer to the nature of "proper" abstractions I am talking about, as it allows reasoning strictly within the chosen semantic level, with less risk of "falling through" to implementation details.

We get this largely thanks to FP's "native" inversion of control, which brings to the table natural protection from recursive implementation diving - the less state spreads across the system, the less our attention unfocus and "abstraction" itself spreads.

Functional approaches allow expressing abstractions more correctly, with less gap between formal model and code, while with mainstream OOP we risk quickly sliding into... implementation details, hierarchical mess leading to well-known confusion.

The topic of abstractions is fascinating and deep.

I greatly enjoy investing time in learning abstract algebra, type theory, and other "fundamentals" that help me better understand this great field. And while I'm far from being an enlightened computer scientist, even touching these matters at a basic level changes (I do believe) my way of thinking dramatically.

But the main thing I've noticed is that we need to try applying this knowledge in practice, as that's the only way to truly master this powerful craft.

No matter how theoretical and non-applied this knowledge may seem (especially at first), I believe it improves both the code we write and our ability to conceive and understand more complex architectural constructs.

If you found such topics interesting or just want to see where my journey goes - consider following.

Wish you a great Journey, thank you.