{ "componentChunkName": "component---src-templates-post-template-js", "path": "/pl/vibing_harness_and_ooda_loops/", "result": {"data":{"post":{"id":"b09936fc-86cf-57fb-9b0e-9a6092002cdf","html":"

\n \n \n \n \n

\n
\n

Hey, have a look at what I made during the weekend. I had some time, grabbed a beer, turned on the computer and tried to code this feature. If I could do so much during the weekend, how much could you and your team do with it in 2 weeks?

\n
\n

It’s almost a 1:1 quote of what I heard from the startup founder I worked with over 10 years ago. I’m sure that you’ve heard similar phrases from people you worked with. We all know the annoying type of person who doesn’t code anymore but thinks, “I still got it!”. Then they threw a piece of stuff at you to “just fine-tune it a bit and do final touches”. Then they’re the first ones to ask “Why so long?“.

\n

Nowadays, the Internet is full of such people. They shout about what they did with Claude or how much progress LLM tools have made. Some even predict the end of coding. I already wrote that this is wrong perspective. I won’t repeat that, but I want to say that…

\n

Vibing isn’t new and isn’t always an issue.

\n

I’m saying that LLM tools are an appraisal for ignorance. The more ignorant we are of the topic we’re working with, the better we see the outcomes. And that, by itself, is not always bad, as there’s power in ignorance if we focus on getting it done with the simplest tools we have.

\n

Still, this can be terrible if we fall in love too much with what we’ve vibed.

\n

To understand why that “weekend beer” energy is both a superpower and a liability, we need to look at the OODA Loop.

\n

\n \n \n \n \n

\n

Disclaimer, it’s not a competition for Ralph Wiggum Loop. It’s much older and generic.

\n

Military strategist John Boyd developed the OODA loop (Observe, Orient, Decide, Act) for fighter pilots. In a dogfight, the pilot who cycles through these four stages the fastest and most accurately survives.

\n

In software, the “dogfight” is the gap between your intent and the production-ready feature.

\n

OODA loop is built from four steps:

\n
    \n
  1. Observe - This is the intake of raw, unfiltered information. In our world, this means looking at the state of the system.
    2. \n
  2. Orient - This is the most critical and difficult stage. It’s where you filter your observations through your experience, culture, and technical knowledge.
    3. \n
  3. Decide - Based on your orientation, you formulate a hypothesis.
    4. \n
  4. Act - You execute.
    5. \n
\n

Getting back to my favourite founder and LLM-based tools.

\n

The reason founder could build a PoC in a weekend while the team needed more than two weeks is that he bypassed the Observe and Orient phases. He went straight from a vague idea to Act.

\n

If we skip or brush past the observation step, it feels like lightning speed. If the fancy UI grid is there and it does something we wanted, we move on. We’ve outsourced Orientation to our own ego. It’s too easy to assume that because we wrote it, it works.

\n

Observation is the intake of raw data. In a professional environment, our eyes aren’t enough. We need a Harness. If we don’t have automations, tests, integration tests, and pristine traces, we aren’t observing the system; we’re just looking at it. If the inputs are messy, our observation is clouded.

\n

But real engineering, the kind that takes those “two weeks”, is about closing the loop properly. That’s also where we need different perspectives and knowledge sharing.

\n

Orientation is where you process those observations. This is the part where LLMs make us feel smarter than we are. If we don’t understand how a database handles concurrent connections, our “orientation” of a generated script will be shallow. We’ll see code that “looks” right, decide it’s fine, and act by deploying it.

\n

The “I still got it” crowd loves the Decide and Act phases because that’s where the visible progress happens. LLM tools have made these phases nearly instantaneous. We can decide to build a feature and have the code for it in ten seconds.

\n

The problem is that the faster we Act, the faster we need to Observe. If our “Act” phase takes seconds but our “Observe” phase requires a manual weekend of clicking around and drinking beer, our OODA loop is broken. We’re just generating a pile of stuff that we haven’t actually verified.

\n

That’s why the team usually needs more than an imaginary “two weeks”. They are not “fine-tuning” the single-brilliant-dude masterpiece. They are building the infrastructure required to make the OODA loop sustainable.

\n

And to make that possible, they need to run the full loop: Observe, Orient, Decide, Act. And do it multiple times. That takes time, but it’s required to assess the direction, automate what needs to be automated, and ensure they can iterate further and run this loop sustainably. That’s critical for delivering the outcome at the expected pace.

\n

Of course, there’s a danger here, overfocusing on the Orient and Decide can lead to overengineering, building stuff we don’t need. That’s where ignorance can be blissful, especially when we connect it with humility. Being humble about what we don’t know and trying things the easiest way, then learning and making enhancements. Still, humility fails under deadline pressure. The harness doesn’t.

\n

Let me give you…

\n

The example

\n

I’m adding proper Observability and Open Telemetry to Emmett right now. I spent some time working on it and instrumented the first component: Command Handling.

\n

Of course, I had tests to prove it works, but I don’t trust them enough, and I wanted to try it on a real sample, since you never know until you run it. Even the best test suite won’t tell you all.

\n

So I decided to plug it into the sample. See if it works, how ergonomic the API is and how it fits conventions in this area.

\n

To do it, I decided to use Grafana stack and set it up with Docker Compose. So, stable, boring stack. Not going to lie, I vibed the config. Not that there are no docs, but I intentionally wanted to see the typical config people use.

\n

If someone says LLM-based tools are great at proof of concepts, they don’t run the stuff they vibed. If I made the observation based on the initial config, then an oriented decision would be that it won’t work. Of course, then I did the typical back-and-forth, with the LLM tool doing some Linux command Voodoo to make it work. Once. Then, if you try to repeat it, you won’t know how to do it without doing Voodoo again.

\n

Again, that’s not much different from the other stuff we do. I’m sure that you had multiple cases, when someone didn’t use Continuous Deployment tools, but clicked through Azure, AWS, GCP portal, deployed the stack, and then there was no trace on how to set it up again (e.g. to have a different environment for testing or demos for customers).

\n

So, we need a harness, we need a leash to keep our process on track.

\n

How to do the harness? My advice is to start simple. We may ask LLMs to give us shell scripts, and we may ask them to run them multiple times. We also need experience and knowledge of what we want to achieve and the tools we use. It’s fine not to remember all the YAML config to set up the Grafana stack, but it’s not fine not to understand why you even use it, how it relates, and how to set it up.

\n

Still, our first loop can close on the first working solution, even a manually vibed one. But that’s not even a PoC. We need to automate them.

\n

I asked LLM to take notes on what issues it had, and it solved them. Then, based on that, I asked to research how to code it in TypeScript. And to use tools I know, used in past, validating if there are no new more modern ones. For instance, I was a big fan of Gulp.js and Bullseye in the past, but they’re mostly dead. I wanted to have something in the same spirit, using native, maintained tooling.

\n

I ended up with the following tools:

\n\n

Then I asked it to create the script to automate the shell Voodoo they did to make Grafana stack and Docker Compose work.

\n

Essentially, it should:

\n
    \n
  1. Run Docker Compose script starting up services (Grafana, Prometheus, Loki, Tempo, PostgreSQL, etc.).
    2. \n
  2. Wait for them to check when they’re ready (it usually takes some time).
    3. \n
  3. Start the application and make a request.
    4. \n
  4. Check if the predefined dashboard with Emmett metrics appears, and shows expected traces and metrics.
    5. \n
\n

Initial diagnostic tools looked like that

\n
async function fetchWithDiag(label: string, url: string, init?: RequestInit) {\n  const res = await fetch(url, init);\n  if (!res.ok) {\n    const body = await res.text().catch(() => '(could not read body)');\n    console.error(`\\n  ✗ ${label} → HTTP ${res.status}\\n  body: ${body}\\n`);\n  }\n  return res;\n}\n\nasync function diagnoseCollector() {\n  const text = await fetch(URLS.otelCollectorMetrics)\n    .then((r) => r.text())\n    .catch(() => 'unreachable');\n  const emmett = text\n    .split('\\n')\n    .filter((l) => l.startsWith('emmett_') && !l.startsWith('#'))\n    .slice(0, 5);\n  console.log(\n    emmett.length\n      ? `\\n  collector /metrics (emmett lines):\\n  ${emmett.join('\\n  ')}`\n      : '\\n  collector /metrics: no emmett_* lines found',\n  );\n}\n\nasync function diagnosePrometheus() {\n  const json = await fetch(\n    `${URLS.prometheus}/api/v1/label/__name__/values`,\n  )\n    .then((r) => r.json() as Promise<{ data: string[] }>)\n    .catch(() => ({ data: [] as string[] }));\n  const emmett = json.data.filter((n) => n.startsWith('emmett_'));\n  console.log(\n    emmett.length\n      ? `\\n  Prometheus emmett_* metrics: ${emmett.join(', ')}`\n      : '\\n  Prometheus: no emmett_* metrics found yet',\n  );\n}\n\nasync function diagnoseLoki() {\n  const labels = await fetch(`${URLS.loki}/loki/api/v1/labels`)\n    .then((r) => r.json() as Promise<{ data?: string[] }>)\n    .catch(() => ({ data: [] as string[] }));\n  console.log(`\\n  Loki labels: ${(labels.data ?? []).join(', ') || '(none)'}`);\n}\n\nasync function diagnoseDockerLogs(service: string, lines = 10) {\n  const { stdout } = await execa('docker', [\n    ...COMPOSE,\n    'logs',\n    '--tail',\n    String(lines),\n    service,\n  ]).catch(() => ({ stdout: '(could not get logs)' }));\n  console.log(`\\n  docker logs ${service} (last ${lines}):\\n  ${stdout.split('\\n').join('\\n  ')}`);\n}
\n

Are they pretty? No. Can they be improved? Yes. Do they have to be improved at this specific moment? No.

\n

The setup uses test infrastructure

\n
\nconst CLEANUP = process.env['CLEANUP'] === '1' || process.env['CLEANUP'] === 'true';\nconst CLEANUP_AFTER = process.env['CLEANUP_AFTER'] === '1' || process.env['CLEANUP_AFTER'] === 'true';\nconst NO_START = process.env['NO_START'] === '1' || process.env['NO_START'] === 'true';\n\n// ─── configuration ───────────────────────────────────────────────────────────\n\nconst COMPOSE = ['compose', '-f', 'docker-compose.yml', '--profile', 'observability'];\n\nconst URLS = {\n  app: 'http://localhost:3000',\n  prometheus: 'http://localhost:9090',\n  tempo: 'http://localhost:3200',\n  loki: 'http://localhost:3100',\n  grafana: 'http://localhost:3001',\n  otelCollectorMetrics: 'http://localhost:8889/metrics',\n};\n\n// Fresh client per run — avoids stale cart state from previous runs.\nconst SERVICE_NAME = 'expressjs-with-postgresql';\nconst CLIENT_ID = randomUUID();\nconst CART_ENDPOINT = `${URLS.app}/clients/${CLIENT_ID}/shopping-carts/current/product-items`;\nconst CONFIRM_ENDPOINT = `${URLS.app}/clients/${CLIENT_ID}/shopping-carts/current/confirm`;\n\n// Matches the .http file — unitPrice is resolved server-side.\nconst ADD_PRODUCT_BODY = JSON.stringify({ productId: randomUUID(), quantity: 10 });\n\n\nbefore(async () => {\n  console.log(`\\n▶ client ID for this run: ${CLIENT_ID}\\n`);\n\n  if (NO_START) {\n    console.log('▶ --no-start: skipping docker compose and app startup');\n    return;\n  }\n\n  if (CLEANUP) {\n    console.log('▶ --cleanup: killing port 3000 and tearing down stack (down -v)…');\n    await execa('bash', ['-c', 'fuser -k 3000/tcp 2>/dev/null || true']).catch(() => {});\n    await new Promise((r) => setTimeout(r, 500));\n    await execa('docker', [...COMPOSE, 'down', '-v', '--remove-orphans'], {\n      stdio: 'inherit',\n    });\n  }\n\n  const stackReady = await fetch(`${URLS.prometheus}/-/ready`)\n    .then((r) => r.ok)\n    .catch(() => false);\n\n  if (stackReady) {\n    console.log('▶ observability stack already up — skipping docker compose up');\n  } else {\n    console.log('▶ starting observability stack…');\n    await execa('docker', [...COMPOSE, 'up', '-d'], { stdio: 'inherit' });\n  }\n\n  console.log('▶ waiting for backends…');\n  await waitFor(() => checkUrl('Prometheus', `${URLS.prometheus}/-/ready`), {\n    timeout: 90_000, label: 'Prometheus',\n  });\n  await waitFor(() => checkUrl('Grafana', `${URLS.grafana}/api/health`), {\n    timeout: 90_000, label: 'Grafana',\n  });\n  await waitFor(() => checkUrl('Tempo', `${URLS.tempo}/ready`), {\n    timeout: 90_000, label: 'Tempo',\n  });\n  await waitFor(() => checkUrl('Loki', `${URLS.loki}/ready`), {\n    timeout: 90_000, label: 'Loki',\n  });\n\n  // /health returns { status: 'ok', service: 'expressjs-with-postgresql' } —\n  // checking service name lets us distinguish our app from other processes on :3000.\n  const checkOurApp = () =>\n    checkUrl('app /health', `${URLS.app}/health`, async (res) => {\n      const json = (await res.json().catch(() => ({}))) as { service?: string };\n      if (json.service !== SERVICE_NAME) {\n        console.log(\n          `    app /health: service=\"${json.service ?? '(missing)'}\", expected=\"${SERVICE_NAME}\"`,\n        );\n        return false;\n      }\n      return true;\n    });\n\n  const appIsOurs = stackReady && (await checkOurApp());\n\n  if (appIsOurs) {\n    console.log('▶ app already running and healthy — skipping npm start');\n  } else {\n    const portTaken = await fetch(URLS.app).then(() => true).catch(() => false);\n    if (portTaken) {\n      // Port is occupied but not by our app — stale process or unrelated service.\n      console.error(\n        '\\n  ✗ Port 3000 is occupied by a process that is not this app.\\n' +\n          '  It may be a stale version of this app (connected to a wiped database)\\n' +\n          '  or a completely different service.\\n' +\n          '  Fix: run  npm run verify:observability:cleanup  to kill it and restart,\\n' +\n          '  or manually free port 3000.\\n',\n      );\n      process.exit(1);\n    }\n\n    console.log('▶ starting app…');\n    app = execa('npm', ['start'], { stdio: 'inherit' });\n\n    await waitFor(checkOurApp, { timeout: 60_000, label: 'app /health' });\n  }\n\n  console.log('▶ setup complete\\n');\n});
\n

As you see, nothing fancy, the cleanup is even simpler

\n
after(async () => {\n  if (app) {\n    console.log('\\n▶ stopping app…');\n    app.kill('SIGTERM');\n    await app.catch(() => {});\n    console.log('▶ app stopped');\n  }\n\n  if (CLEANUP_AFTER) {\n    console.log('▶ tearing down stack (down -v)…');\n    await execa('docker', [...COMPOSE, 'down', '-v', '--remove-orphans'], {\n      stdio: 'inherit',\n    });\n    console.log('▶ stack torn down');\n  } else {\n    console.log('▶ stack is still running');\n    console.log('▶ to clean up: npm run verify:observability:cleanup');\n  }\n});
\n

Having that we can run tests:

\n
\ntest('successful command returns x-trace-id header', async () => {\n  const res = await fetchWithDiag('POST add product', CART_ENDPOINT, {\n    method: 'POST',\n    headers: { 'Content-Type': 'application/json' },\n    body: ADD_PRODUCT_BODY,\n  });\n\n  assert.equal(res.status, 204, `Expected 204 — body logged above`);\n\n  const header = res.headers.get('x-trace-id');\n  if (!header) {\n    console.error(\n      '  ✗ x-trace-id missing — verify the wrapper app in src/index.ts ' +\n        'adds it via @opentelemetry/api before mounting the emmett app',\n    );\n  }\n  assert.ok(header, 'x-trace-id header missing');\n  assert.match(header, /^[0-9a-f]{32}$/, `\"${header}\" is not a 32-hex trace ID`);\n\n  traceId = header;\n  console.log(`  trace ID: ${traceId}`);\n});\n\ntest('OTel collector exposes Emmett metrics on port 8889', async () => {\n  // Send a few more requests so metrics are definitely recorded.\n  for (let i = 0; i < 5; i++) {\n    await fetch(CART_ENDPOINT, {\n      method: 'POST',\n      headers: { 'Content-Type': 'application/json' },\n      body: ADD_PRODUCT_BODY,\n    });\n  }\n\n  try {\n    await waitFor(\n      async () => {\n        let text: string;\n        try {\n          const res = await fetch(URLS.otelCollectorMetrics);\n          text = await res.text();\n        } catch {\n          console.log('    collector :8889: connection refused');\n          return false;\n        }\n        const emmettLines = text.split('\\n').filter((l) => l.startsWith('emmett_') && !l.startsWith('#'));\n        if (emmettLines.length === 0) {\n          const allFamilies = [...new Set(text.split('\\n').filter((l) => !l.startsWith('#') && l).map((l) => l.split('{')[0]))].slice(0, 5);\n          console.log(`    collector :8889: no emmett_* metrics yet. Present: ${allFamilies.join(', ') || '(none)'}`);\n          return false;\n        }\n        return true;\n      },\n      { timeout: 90_000, interval: 5_000, label: 'emmett metrics on collector :8889' },\n    );\n  } catch (err) {\n    await diagnoseCollector();\n    await diagnoseDockerLogs('otel-collector');\n    throw err;\n  }\n});
\n

I put it into a single file that can be run as a regular Node.js script.

\n

It already showed me (and Claude) that what they initially did wasn’t working if you try to run it multiple times. It also showed that doing a full cleanup and rebuild, and making it reproducible, needs more work.

\n

Is it done? Not yet; it takes too much time and resources to run it continuously throughout the pipeline. The code is a bit messy, so it needs to be organised. It’s segmented into blocks, includes basic automation and tests, and has already gone through some failures to get it done.

\n

Could I do it better? Sure, but that’s not the point. I wanted to show you my findings during weekend vibing (without beer tho),the real, not polished iteration.

\n

The main idea behind OODA loops is not to be perfect, but to iterate quickly, gather feedback as soon as possible, learn from it, develop another theory, and verify it through action.

\n

It’s not about vibing, but it’s also not about analysis paralysis.

\n

I hope you’re now better equipped to think about when vibing — with beer or without, with LLMs or without — actually helps, and when it doesn’t.

\n

Vibe coding is just high-frequency steering. It only works if you have a Harness: a mechanical way to observe and orient, so you don’t steer the whole project into a wall.

\n

Act takes seconds now. Observe takes as long as it always did. Without a harness, you’re not going faster; you’re just making more stuff you haven’t checked.

\n

Harness is not magic, a new discipline, or the next buzzword; I hope I showed you that a bit in this article on what it may look like.

\n

So iterate fast, but wisely remembering to do the full loop. It’s great that LLMs can help us make Acting faster, but we should not skip other steps. We should aim for a fast feedback loop to iterate in the right direction and achieve continuous improvement, to deliver proper value.

\n

Just like Vibing isn’t new, we shouldn’t abandon old engineering practices. We should also not replace collaboration with solitary self-high fives.

\n

Check also:

\n\n

Cheers!

\n

Oskar

\n

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

","excerpt":"Hey, have a look at what I made during the weekend. I had some time, grabbed a beer, turned on the computer and tried to code this feature…","fields":{"slug":"/vibing_harness_and_ooda_loops/","prefix":"2026-04-26","langKey":"pl"},"frontmatter":{"title":"Vibing, Harness and OODA loop","author":"oskar dudycz","category":"Software Architecture","disqusId":null,"useDefaultLangCanonical":true,"cover":{"childImageSharp":{"resize":{"src":"/static/6f23d618ba2fb2ec38a86e77eced2df7/2a4de/2026-04-26-cover.png"}}}}},"authornote":{"id":"295c4649-a20b-5147-9ca5-5cb77fbcfe66","html":"

\n \n \n \n \n

\n

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

\n

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

\n

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

\n

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

\n

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

\n

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

\n

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

\n

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

\n

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

\n

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

\n

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

\n

Cheers!

\n

Oskar

"},"site":{"siteMetadata":{"facebook":{"appId":""}}}},"pageContext":{"slug":"/vibing_harness_and_ooda_loops/","lang":"pl","langKey":"pl","prev":{"id":"3515133d-74bc-50dc-a99a-80e399869b17","fields":{"slug":"/yoda_principle_in_command_design/","prefix":"2026-04-20","source":"posts","langKey":"pl"},"frontmatter":{"title":"Yoda Principle for better integrations","category":"Event Sourcing"}},"source":"posts"}}, "staticQueryHashes": ["2742854296"]}