konovalov-nk

> what will the future look like, with sophisticated AI agents smart enough to hack into corporate systems?

"Ignorance is bliss" (c) Matrix

Oh, sweet-sweet ignorance.

About 4 weeks ago I've found SSRF and possible RCE on a very real website with a lot of web history the other day. And I traced it to `aws-solutions` org on GitHub that sits very close to real `aws` org. What do you think is happening?

And this website I spotted SSRF on, it seems to be used to manufacture fake news and inject them into "the past".

Why?

So if you see a company you never heard about, and you google it, google will index page and it will show you backdated article as if it was actually released long time ago.

But if you try to look at Web Archive of that article, it doesn't exist... I've been doing this OSINT research for 45 days on different fake recruiters that were spamming me on LinkedIn, and most of those websites with fake news are running Wordpress, classic.

My point is... while this story reeks of marketing, the actual criminals are out there doing whatever they want, and I've been fighting for my life trying to find a job and getting into increasingly large amount of fake recruiters and companies that have zero intent of hiring you.

I wasted 7 weeks on this...

Yeah, you need actual models to understand what is going on.

Basically, when I was using my first version of Coherence to write down what system does on lowest level I found myself imagining in my head database records. And this is exhausting when you have more than 2 tables to think about.

And so I don't want to imagine them, I want DB records represented as entities I can simply render onto screen and look at them while I think how they should interact with each other.

Now, this is topology + domain modeling. Topology/semantics here is describing what happens with those domain models over time, what states they, how they transition, what attributes models might have, and most important — which code symbol describes all of that.

So for example, I am making Job Tracking System. I need to persist Job record. I visualize it as a row in table and I can model it without attaching to code. And then we can say:

- "this entity (job) --(has_attribute)--> status", or

- "job -(described_by)-> class JobRecord",

- "job -(observed_in)-> trace",

- "job -(verified_by)-> job_test.rb".

This gives us useful semantics / description / context / domain knowledge + links it to code + test that confirms model shape, or system state transition, or process, or product behavior.

And you can describe it at any level you want.

If you don't know the implementation details yet, a greenfield project? Well, just start with Product level specs, high level description what users will see.

Is it brown-field legacy monolith 500k LoC? Well, just reverse-engineer intent from code (I even have guide how to do this and I did it on 10k LoC successfully), then align people on that "intent graph", and then connect it into CI/CD so that it becomes default review artifact on EVERY single pull request.

And the key here is to isolate context around domain model we're interested in. Make it minimal but useful to make decisions. And make it easy to pull more [relevant] context, or remove [unnecessary] context.

I still don’t fully know how to avoid tunnel vision once you have only one slice of the graph and models in front of you. E.g. failure mode might be somewhere not even described by a link or something exists entirely outside of the graph.

This would be the next thing to solve.

And meanwhile I'd like to thank you for showing me this problem.

GUI is just sequence of events (mouseclicks, scrolls, keypresses) on top of semantic tree (if we can call div class soup as "semantics"). But we can record it since long time ago and simply compress/remove noise.

TUI is better since it usually operates on keyboard, it's good for visualizing 1d/2d data (which is most of GUIs btw).

CLI is least interactive of them all I'd say and it limits what you can do. Either you have a solved problem that you can trigger with a button push, or you have to input tons of flags to configure behavior, or write a config file and re-use it. To me this seems sub-optimal. I'd rather use voice activation + NLP to let LLM figure out what I want to do, present me with a quick "are you sure? + exact CLI command" and then I can press it.

Forgive me for lengthy text, I was just thinking outloud whether my assumptions about TUI/CLI make sense.

Do you agree?

I've been thinking about this as well.

To me this is optimization problem. How can we solve a problem if we don't understand it? Understanding takes a lot of effort exactly because our minds are wandering through useless context all the time, and not to mention interruption.

I formulate this problem as:

> Optimize for understanding

I know how to approach solving this exact problem. In fact, I've been doing exactly this since March 2026. We need to figure out how to isolate problems and context around them. And so my best bet right now is using graphs. Links can be easily added or removed between two nodes. And context is simply a group of links and/or linked nodes.

Now. What exactly is "understanding"?

To me, this is process when we look at some unpredictable, chaotic system and then creating structure from it. The chaotic system is an entangled, spaghetti-like graph. The ordered one is one we [hopefully] have in our brains, which allows us to act on it. I don't want to repeat entire article I wrote about this so if you want you can find it on my recent project (it's not ready for HN prime-time yet but I'll post demo soon).

But tl;dr we have "chaotic/unknown graph" and "structured/understood graph", and the bottleneck is moving nodes and links between these two.

The faster we understand the world around us, the better we understand why problems appear, and how to fix them. And once I realized this, to me it became clear where we need to move forward: to connect everything together in a way that makes understanding quick.

And fun fact, I already did this: I connected my article to yours.

Well, don't automate your thinking ;)

If you can do this then yes we'll transition to AGI/ASI.

But thinking (and understanding) is still largely human.

Once I did all of that for what I'm doing (I'm just a web dev...), it turned into a rabbit hole so deep I am now questioning reality itself

I'm not kidding though.

I had a mental breakdown multiple times throughout 2 months while I was "writing down in minuscule detail what I'm doing".

I debugged my brain and realized I have OCD (in addition to ADHD) and it made me so happy that I'm now free from this terrible mistake of not making any mistakes at all.

And I never felt so productive in my entire life.

Incredible things will just start happening once you start writing your thoughts.

It doesn't even matter what you are writing. Just write it all down.

All of it.

Lemme give you more signal than this how to automate yourself.

1. Write down everything you do in text. Don't skip any details: thoughts, why, how, who, what, and so on

2. Add details. More details. Even more details.

3. You will see some patterns. This is algorithm.

4. Extract algorithms into specs/intent graph. But for god's sake don't use markdown as final substrate. At least write BDD/Gherkin.

5. "Sufficiently structured problem becomes the solution"

You're welcome.

I had a few aha moments recently while thinking about this problem (automating easy parts and leaving "hard parts" unsolved).

1. Understanding the world is the bottleneck to thinking.

2. The world is an unbounded system with unpredictable behavior. Chaos.

3. An outcome is a possible state of a system.

4. Formulating an outcome means choosing a future state of the system.

5. That future state may be desired or undesired.

6. Therefore an outcome is not purely objective. It is a consensus problem.

7. Consensus is concentration around a shared outcome.

8. Consensus around an undesirable outcome is maladaptive consensus.

9. Intent is a decision that constrains future system states.

10. One outcome may relate to another. It may also relate to intents.

11. Related outcomes and intents form a problem domain. Or simply: a semantic graph.

12. A graph gives structure to otherwise ambiguous future states.

13. Structure reduces the number of possible interpretations. Or simply: reduces uncertainty.

14. High uncertainty prevents action. Low uncertainty makes action obvious.

15. A problem without structure requires thinking.

16. A structured problem can be acted upon.

17. A sufficiently structured problem becomes the solution to itself.

18. An insufficiently structured problem keeps producing chaos.

19. Problem solving is creating structure from chaos.

20. Therefore thinking is problem solving before the structure exists.

We can automate action. Not understanding.

Therefore we should optimize for it.

I'm exhausted seeing this same mistake happen over and over and over. Why nobody tries to write a spec from existing code is just crazy to me.

The git test suite is a behavioral spec. But at the same time it is not, why? It's archaeological site... I'd say. You can dig, and dig, and dig, and find some truth, but also a lot of historical decisions that doesn't matter today.

Here's the flow I suggest:

- first, reverse-engineer the behavioral intent from tests/docs/code

- build a taxonomy of what git promises

- group that into small "conformance slices"

- hand those slices to agents/humans/whatever

- start writing Rust... Or Visual Basic... At this point it doesn't matter almost

Without this critical layer, agents are optimizing for "make this test green" instead of "preserve this semantic contract". And this is exactly where the funny stuff happens... shelling to real git, hardcoding expectations, implementing sha256 metadata but not the behavior, etc.

Why are we doing stupid things and winning stupid prizes? I have to admit they are impressive, but I STRONGLY believe if we did this in two passes you would have not $15k check but maybe closer to $1-5k.

Who should I talk to, to make this happen? Making the first pass is almost deterministic. LLMs help. The only problem is making sure that YOU understand the spec, and this will be a bottleneck for a while (i.e. can't outsource understanding).

I can guide what exactly needs to happen. I already validated this idea on my own project and it worked: 10k LoC -> 250 acceptance criteria. And you can find it on my GitHub, I even described steps. If you're too lazy here it is:

You need a SCIP graph. Agent goes over it and builds ledger, one symbol at a time, looks at what kind of problem this symbol solves. This leads you to v0 specs, then you can figure out taxonomy, then you try to fit all those thousands of specs into taxonomy / groups that make sense. And that would be v1 spec but you might want to refine it to v2/v3. And then the only thing would be left is figure out what kind of tests those specs should have (e2e/unit/integration/api/whatever). This is tricky part but doable. I'm thinking for git you wanna do e2e specs. Yes, that's a lot of e2e but the purpose is that we build same expectations for git, and then we replace git with grit and spec should still stay green, right?

Hope that makes sense.

I do apologize for a bit of advertising of OSS project that I mention in the article (I think it is relevant because I'm tryna fix one of the largest pains today, at least for myself) but the main point I wanted to share/discuss is how fixing the source of the problem is much harder but often misrecognized/misunderstood maybe. And sometimes even political...

Definitely not all companies want you to do this. They'd rather keep the pipeline going that just makes their positions justified. If you're one of those people I'm curious why would you not want to try and pursue a better goal especially if you have resources to do it.

Especially.

So, things like hiring for example. This is very broken at the moment. But this is also a business for many companies and people. Billions of dollars spent on hiring every year I believe. Just to get right candidate in front of the team.

I want to imagine if suddenly we can solve the unemployment where everyone is happy, and by "happy" I mean their capabilities match the company profile, and they bring sufficient value to the company, or they are at least enabled to learn the skills required to do the job properly and increase their value over time.

Then next thought is, what happens with all those people out there that built their career, their lives around this problem? No more recruiters needed, no more resume writing services, maintaining endless stream of ATS. That's a lot of money. And I wouldn't even be surprised if this would become political at some point. To me this is an insight why we have so many problems today.

Someone might be profiting on this. So to them best interest is to keep this problem unsolved for as long as possible.

I'm thinking about solving hiring, for example.

You just type in some sort of query to find best suited jobs for you, somehow prove your problem-solving ability, get a measurable score on it: purely objective, algorithmic, deterministic way to measure it (kinda like IQ test I guess), no middle-man proxies, no oracles. Apply, then people do maybe a quick interview to see if you can work with the team, cultural fit I mean. The people interviewing you have no way to know how good you actually are before deciding whether to let you in or reject you. But their rejection should be justified, a feedback that you can work on, feedback that everyone can see and improve on.

See, I'm not even qualified enough to answer all these questions but the point is, I'm just thinking through the problem and I see it can be solved to some degree. Just one person digging into it. The more time, effort and attention you spend on something, the more you can solve. Attention is really all you need (reference to one of the first GPT paper).

But if you waste your attention on mopping the floor U+2014 yes your floor is clean but faucet is still broken and the next person living in that same apartment, they would have to deal with faucet again, and again, and again.

And again.