Корпоративный маразм вокруг ИИ

Summary of technological concepts & product/market points

• AI systems are effectively prompt-driven “pipelines,” but the surrounding tooling is vendor-specific

  • A common pattern across platforms is a cycle where a neural network is called periodically:
    • collecting data such as prompt + memory/extra context
    • combining it into a system prompt plus user prompt
  • From the model’s perspective, the interaction is basically:
    • input prompt(s) → text output
  • Everything else—how skills, files, code, memory, etc. are represented and stored—is specific to the vendor/tool.
  • The speaker criticizes repos that package plain-text “prompt collections” (and “skills”) as if they’re complete products, questioning the value of that packaging.

• Prompting is framed as “task description quality,” not just model capability

  • The key to effective usage is how well the task is specified (similar to giving clear technical assignments to humans).
  • The model will not “go figure it out” like a person; it may:
    • generate clarifying questions (more interactive workflows), or
    • proceed using assumptions learned during training.

• Code generation quality problems come largely from orchestration/context preparation

  • The speaker cites an interview with a Harness (HarnessPy) developer.
  • While models are powerful, the main problems are often in how context is prepared and passed to the model (efficiency and correctness of the tooling/orchestration).
  • This can lead to errors and require iterative fixes.

• Vendor lock-in (“venderlog”) is a major operational risk

  • Platforms can become “centers of control” because users depend on them, including:
    • restrictions
    • price increases
    • blocking access (examples mentioned include reports about Claude blocks without support)
  • The speaker suggests avoiding tight coupling so you can switch tools when needed.
  • Example of changing commercial models:
    • A provider (Anthropic mentioned) moves agent systems off the standard subscription into credit-based usage (e.g., ~$20/month grants monthly credits, then pay per token).
    • This is perceived as causing order-of-magnitude cost increases and forcing rework.

• Value of “open” approaches: switching between models

  • Open platforms (OpenCode / open hardware mentioned) reduce dependency:
    • you can use Claude today, OpenAI tomorrow, etc.
  • Example: adding NVIDIA model access via an account token enabled free usage.
  • A small experiment described:
    • uploaded a picture
    • performed simple editing/cropping
    • the model was able to build a working product end-to-end, though paid options may be better.

• Fundamental limitations persist across models

  • Even strong models can fail at simple logic due to:
    • training-data gaps
    • probabilistic behavior
  • Example (“car wash test”):
    • instruction: wash a car; the car wash is 50 meters away
    • the model provides incorrect reasoning about avoiding harm/environment or time
  • The takeaway: if these issues aren’t handled, fully automated systems can miss errors.

• Real-world generated code often requires backend controls, retries, and rollback logic

  • The speaker describes hands-on debugging:
    • generated code used a loop to repeatedly execute calls until a condition
    • a failure in the first handler prevented the second handler from being called properly
    • this could crash the system and leave artifacts, causing subsequent failures
  • Fix approach:
    • move operations into a separate handler / single request
    • implement backend control with checks for success/failure
    • add rollback behavior and extra bookkeeping
  • The speaker also notes the ongoing need to correct variable names/constructs for maintainability, since models may not produce code humans can easily reason about later.

• Automation hype is criticized: many AI projects never succeed

  • The speaker claims statistics indicate most neural-network-assisted projects never earn money and are discarded.
  • Mentions a trend of “garbage projects” and running agents without stopping or evaluating failures.
  • Clarifies stance: not anti-AI, but anti-hype—AI should be used with engineering discipline.

• Some marketing claims vs. security reality

  • Mentions press/leadership claims (Antropic/OpenAI referenced) about AI replacing jobs and increasing dependence on GPT among younger generations.
  • For security testing, cites a story about a long-developed utility (“Kurul” mentioned):
    • when run with MITOS, only a small vulnerability was found
    • implying it’s “just marketing”
    • suggesting such tools often find mostly code bugs—useful but limited.

Key takeaways (as implied “review/analysis” points)

• Models may be good, but systems engineering matters most:
  • prompting quality
  • context preparation
  • orchestration
  • backend safety controls
• Vendor lock-in and shifting pricing/subscription terms are operational threats; open/switchable tooling is safer.
• Probabilistic models can fail even on simple logic—don’t assume correctness.
• Generated code typically needs human-like engineering practices:
  • testing
  • fallbacks
  • rollbacks
  • maintainable structure
• AI product/security claims can be over-marketed compared to real-world impact.

Main speakers/sources

• Main speaker: the video author (unnamed in subtitles; speaks in first person)
• Referenced interview source: a HarnessPy (Harness) developer
• Referenced companies/tools:
  • Harness
  • Claude / Anthropic
  • OpenAI
  • Antropic (likely intended as Anthropic)
  • OpenCode / Open Code
  • NVIDIA
• Referenced utility/security example: creator of a tool called Kurul, and a MITOS/MITS mention (spelled as in the subtitles)