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")

buger

Step 17/30 : RUN pip3 install grpcio
 ---> Running in b6d303f4091c
Downloading/unpacking grpcio
  Running setup.py (path:/tmp/pip_build_root/grpcio/setup.py) egg_info for package grpcio
    
    Installed /tmp/pip_build_root/grpcio/sphinx_rtd_theme-0.1.10_alpha-py3.4.egg
    Searching for sphinx>=1.3
    Reading https://pypi.python.org/simple/sphinx/
    Best match: Sphinx 1.5.2
    Downloading https://pypi.python.org/packages/e3/87/e271f7f0d498c7fdaec009c27955401d18ef357c0d468e1eb2be36bdc68c/Sphinx-1.5.2.tar.gz#md5=8a3068cd5dda49622b7eb5132d616e19