buger

This are the examples of Probe Agent one shotting engineering or complex support tasks

buger

A few major ideas to understand:

Code context issue

Modern AI agentic loops, even claude code, quite bad at dealing with large codebases. They use a caveman approach - treat it as text, do some greps, read some context around it, and rely on agent "feeling" that it got enough of big picture. And they are very confidently say they are.

Unless you solve this context issue well, all the AI outputs will be very shallow, with a lot of false positives.

For this I have developed completelly different context engine, which treats code as code, knows about AST and so on https://github.com/probelabs/probe. One query with probe can be equal to 10 loops of claude code, yet with taking less context and having way deeper into your code.

buger

This is super nuanced and depends on what your agent actually does and what “sandbox” needs to mean for your product.

The first questions I think you have to answer

Before picking a tech, I think you need clarity on stuff like:

• Scale: Are we talking “single box POC” or “global, lots of concurrent agents”?
• Deployment: On‑prem install vs cloud SaaS?
• UX / product model: Is it a backend worker (service bus / event-driven), or an interactive chat/web UI where users expect continuity?
• Routing: Single server? Multi-server? Do you need sticky routing per user/session?

buger

{
   "status":"Success",
   "message":"",
   "schema":{
      "id":"https://spec.openapis.org/oas/3.0/schema/2021-09-28",
      "$schema":"http://json-schema.org/draft-04/schema#",
      "description":"The description of OpenAPI v3.0.x documents, as defined by https://spec.openapis.org/oas/v3.0.3",
      "type":"object",
      "required":[
         "openapi",

buger

If we forget about the AI itself, and for each engineering task we need to:

• Do some initial research

• Create initial high-level technical plan, and separate to milestones (like implement BE part, implement FE part, add the Docs, Write Integration tests), etc.

• Start working on each item in the plan

buger

API Gateway guide to SOAP

SOAP is a big and painful topic when it comes to API gateway support. And the reason is that the SOAP protocol itself has a very flexible declarative XML format, and its specifications are unfortunately really vague and leave a lot of things open for interpretation.

In this document, we will try to cover all possible ways how you can integrate SOAP with Tyk API Gateway, from simple pass through to calling WSDL services.

Introduction to SOAP format

A SOAP message is a XML document which is used to transmit your data, and can look as simple as:

buger

buger

Record to file:

rcapd --input-raw "<interface>" --input-raw-engine "pcap" --input-raw-bpf "tcp" --output-file network.pcap

Forward traffic from 1 machine to another:

rcapd --input-raw "<interface>" --input-raw-engine "pcap" --input-raw-bpf "tcp" --output-tcp <ip>:<port>

buger

### Keybase proof

I hereby claim:

  * I am buger on github.
  * I am buger (https://keybase.io/buger) on keybase.
  * I have a public key ASCzaCxRkFIlUa2aRgKqemADKX7wtZTSNs2XhdbMZ4PlLgo

To claim this, I am signing this object:

buger

Fails to get following data: jsonparser.Get(data, " Name","Pid","Photo")