Chadmandoo

Followed us for Pixel City Bros? You're still in the right place. This account is now Ignibyte — the studio behind PCB. Same crew, bigger mission: we build production software, fast and human-led. PCB is one of the things we make. #GameDev

@MichaelThiessen JSON?

I’m so sick of Markdown right now. It’s amazing for humans and LLMs, but impossible to process or manipulate otherwise. Is there anything that renders like Markdown (for humans) but has a strict structure (like XML/YAML/etc) so it’s easy to manipulate? Ideally, a superset of Markdown, so it “just works” and renders like normal Markdown. But with added structure that makes it easy to parse and verify and manipulate. I’m building my own thing currently but I’d rather not.

We built a codebase where AI doesn’t “figure out” what to write from scratch. It assembles software like LEGO. Reusable bricks. Clear structure. Predictable patterns. The AI chooses the right parts and builds with them. It’s dangerously good. Now I just need to figure out whether to market it, sell it, or open source it for everyone.

@samueljmcd This is what I get frustrated with flooding “fAbLE bUiLt this in oNe pRompT”. You could build what fable did in 8 hours if you went through the unreal and unity tutorial. Moving characters around on a screen in a game and we are at AGI apparently.

AI is creating two classes of engineer. One generates clean code, passes tests, ships features. The code looks senior. The reasoning behind it isn’t. The other spends most of their time asking: what happens when this dependency slows down? What conditions make this fail? Why does this state exist? Writing code used to be a reliable proxy for understanding systems. That relationship is breaking down fast. Producing code is getting cheaper. Reasoning about a system’s failure modes isn’t. Vibe coding gets you to demo. It doesn’t get you to production.

Why is everyone acting like they are unable to do anything without Fable? Get a grip, folks.

e2e during the agent loops are solid. The agent should load the browser and check its work. Then once it’s verified it creates a playwright test for regression. Unit tests + architecture (phpstan, phpmd, phpcs), mutation testing, e2e and playwright will catch most failures during the build. They must be enforced though through hooks otherwise the agent will ignore them if they can.

@bendee983 I prefer mostly e2e tests with unit tests around bug-prone "hot zones". But remember: every bug shipped passed tests and the type checker so you never really are sure. We are always testing in prod.

Prove me wrong. I think the "unit tests is all you need" mentality is wrong. Here's why: Unit tests verify what the LLM-generated code should do, not what it shouldn't. The AI might hallucinate a bunch of nonsense code and functions that have nothing to do with the intent and goals of the application. The code will work perfectly fine but will also be sub-optimal. When it is a bottleneck function (something that runs thousands of times per second), you want it to be fully optimized. Every line of code matters. This is why I think whether AI writes the code or not, you should be able to review and uderstand it, at least the bottlenecks that can cause massive performance issues. Happy to be proven wrong, or share your experience if you've been able to address this.

@inferencegod @bendee983 Adversarial agents are 1 layer and it’s never enough. They don’t catch everything.

@bendee983 I have the solution for you. Crazy haha x.com/inferencegod/s…

Everything I write agentically is 100% unit tested but you are correct it’s not enough. Playwright is the other layer to verify the UI. Every action in a UI should have a playwright test. But going another layer you need architecture tests to ensure good code and mutation testing on your unit tests.

Loops are automated bot work flows you don’t touch. Loop is a well defined process you use over and over. X took 1 tweet from someone claiming agentic looping and completely made up what they think it is. A loop is a repeatable process not letting the AI run over night and build you an app.

“loop” is the worst possible term you guys could’ve come up with for defining the next paradigm of agent work surely we can think of a better name everyone describing what their definition of a loop is are just defining their current workflow the threads that went viral are some larp that made up BS while slapping loop on it LMFAO a couple of REAL insightful scattered definitions of what a “loop” is i’ve seen are - a scheduled run that does an automated daily task without needing to prompt it - capturing bugs/issues the moment they come in and having an agent implement the fix and open a PR - having one agent manage threads of other persistent agents who focus on different projects NONE OF THESE ARE A LOOP! they are all fundamentally different workflows HOWEVER all these workflows share one important concept: the workspace and info available to the agent is so well defined that there is no need to prompt the agent it just needs to do a couple tool searches to grab the right info it needs to complete the task successfully my understanding of what people are defining as a ‘loop’ are essentially agent factories aka the workspace the agent lives in is well defined and navigable for ex. a codebase that has ADRs that the agent can fully read before implementing a fix or access to instructions and references to guide it towards the proper solution these are not loops 😭😭😭

@LyalinDotCom I feel there is some influencer coordinated effort on things. Everything comes in waves in here. Never heard of “OMP” but today have like 5 people posting it’s the best thing ever. Something going on.

So freaking exhausting, to see big claims about a new fancy funky local model only to find out its broken when you actually try to use it. I am going to blocking a lot more people doing this crap.

I’m not sure there is a need for an agent to update their instructions by themselves. The instruction is the harness and its purpose. The documentation it updates should be architecture docs and specs on the task being built. The improvement loop should be lessons from failures. The failures should be vetted and decided if it’s proven useful. Useful patterns become goldens and part of the corpus. Instructions for particular features should be in the feature acceptance criteria.

Well said. Every time you allow the agent to improve their instructions without human supervision they quickly turn into unreadable mess. I have not found a reliable way to control this effect.

I have so many assets from Pixel City Bros that I literally had to build a website to organize and manage them #Indiedev #pixelartㅤ

@adamwathan Or people building 97 levels of obsidian so they can remember their grandmas contact info and nothing useful.

Feels like we're all just building "things for building other things" and not a lot of "things" anymore.

@ShrinesLegacy What engine did you build this in?

Been doing a polish pass on the mountain maps while my friends work on the Uncharted Lands DLC. 🏔️ #gamedev #pixelartㅤㅤㅤㅤ Shrine's Legacy is available now on all major PC platforms! Links below!👇

This is amazing

Claude /goal without a harness is permission to blow tokens with crappy code.

@DavidOndrej1 You don’t need /goal if you have a harness

if you're not running multiple /goal loops at all times... you really are falling behind

@Justinnealey Exactly. The checks and balances (quality gates) allows AI to correct itself before the human sees the error. I bet a good majority of complaints about AI is because it writes code without checking itself.

@IgnibyteDev That matches my experience. The loop works when it is closer to a supervised workflow than autopilot. The human still owns the judgment calls, but the agent can keep the boring steps moving: read context, make a change, run checks, surface the diff.

When people hear that we build software with AI agents running in "a loop," they picture the wrong thing — a machine spinning on its own, generating code with nobody at the wheel. That's not what happens. And I know it isn't, because I spent 20 years in the Army watching the right version of this run every single day. We didn't call it a loop. We called it a battle rhythm. What a battle rhythm actually is In Army doctrine, a battle rhythm is "a deliberate daily cycle of command, staff, and unit activities intended to synchronize current and future operations." It is not chaos, and it is not a machine left running unattended. It's a disciplined cadence — plan, prepare, execute, and continuously assess — that keeps a whole organization moving in one direction and keeps the commander informed enough to make good decisions faster than the other side can. The load-bearing words are deliberate and synchronize. A battle rhythm isn't motion for its own sake. It's the structure that turns a hundred moving parts into one coherent operation. Take the structure away and you don't get freedom, you get a mob — fast, busy, and pointed in no particular direction. That distinction is the whole point of this post, because it's exactly the distinction between an AI tool that generates code and a development service that ships systems. The "loop" is the same idea When we say our engineers run AI agents in a loop, we don't mean an infinite while loop — and we don't mean a /loop you kick off in Claude and let run unattended. We mean exactly that kind of battle rhythm: a feedback system with a human commander at the center of it. A pipeline that turns intent into a working system through four phases — planning and design, execution, validation, and learning — expressed as five concrete steps: Plan — translate the objective into a concrete course of action. Work — build it. Test — put it under fire, before it ships, not after. Document — capture what was built and why. Improve — the after-action review that makes the next build better than this one. None of these steps is optional, and none of them runs without the engineer's eyes on it. What follows is what actually happens inside each one, and the piece of Army doctrine it came from — because none of this is theory we invented. It's a system that's been stress-tested under real pressure for a very long time. Plan — the design phase Nothing in the Army starts with action. It starts with the Military Decision-Making Process: mission analysis, then several distinct courses of action developed, war-gamed against each other, and one selected — before a single element moves. The plan is where you do your thinking while it's still cheap to be wrong. Our planning phase works the same way. Before any code gets written, the objective gets turned into an actual design: the architecture, the data model, the interfaces, the constraints, the failure modes we already know to expect. The agents are genuinely useful here — they can sketch alternatives and pressure-test an approach far faster than a person working alone — but the engineer chooses the course of action. A plan an agent likes and a human hasn't blessed is not a plan. It's a guess with good grammar. The discipline of designing first is what keeps the execution phase from turning into expensive flailing later. Work — execution under intent This is the phase people think the whole loop is, and it's the one the Army is most relaxed about by design. Doctrine calls it decentralized execution: once the intent and the guardrails are set, you trust disciplined elements to carry out the mission without being micromanaged through every move. The squad leader doesn't radio for permission to take each step. That's where the agents do the heavy lifting. Given a clear plan and clear boundaries, a fleet of them can build fast — wiring up the system the design already called for. They have initiative: they make the small, local decisions that don't need a commander's sign-off, the same way a good NCO does. What they don't have is authority to change the mission. They execute the plan inside the guardrails; they don't get to decide the plan was wrong and go do something else. When the execution surfaces something the plan didn't anticipate — and it always does — that's not the agents' call to make. It goes back up to the commander. Test — validation, before it ships The Army does not learn whether a plan works by running it for real and finding out. It runs rehearsals and trains against a dedicated opposing force — an OPFOR whose entire job is to attack your plan and expose what's broken — so the failures happen in a controlled environment instead of in contact with the enemy. The saying is train as you fight. You put the plan under fire on purpose, early, where a failure costs you nothing. That's our validation phase, and it's not a step you can skip or soften. Every build runs the quality gates and the security gates — the checks that exist specifically to catch what's wrong before it reaches you. We adjust based on what's actually happening in those gates, not what we hoped would happen. An agent that wrote the code does not get to grade its own homework; the validation is independent and the bar is fixed. Code that doesn't survive contact with the gates doesn't advance, no matter how good it looked when it was written. Document — the operational record In the field, the order is written down. The operations order and the running estimate exist so that the plan, the reasoning behind it, and what actually happened are all on the record — not living in one person's head where they vanish the moment that person rotates out. A unit that can't tell you why it did something can't hand the mission off, and it can't defend its decisions afterward. So we document as part of the rhythm, not as a chore bolted on at the end. What was built, why it was built that way, what was decided and what was deliberately left out — captured while it's fresh. This is what lets a human stand behind the system months later and explain any line of it. It's also the raw material for the last and most important step. Improve — the after-action review This is the step most "AI coding" skips entirely, and it's the one the Army treats as sacred. The After-Action Review is non-negotiable doctrine: you don't finish an operation, you close it out. What was supposed to happen, what actually happened, why the gap, and what we change next time. Rank comes off in a real AAR — the point is the truth, not comfort — and the lessons are captured so the next unit doesn't bleed for the same mistake. Our process does exactly this. Every build teaches the next one. A mistake a project hits once, it doesn't get to hit twice — the lesson goes back into how we plan, what we test for, and where we set the guardrails. This is the difference between a system that gets better with every cycle and one that makes the same class of error forever at machine speed. Without the AAR, a "loop" really is just a machine repeating itself. With it, the loop is how the whole operation learns. Who is actually in command Here's the part that matters most, and it's the part doctrine gets exactly right: mission command. The Army runs on decentralized execution — a commander sets the intent and the guardrails and trusts disciplined people to execute inside them. The commander does not fly every drone or aim every rifle. But the commander is never out of the loop. The entire purpose of the battle rhythm — the update briefs, the sync points, the running assessment — is that the commander always knows where things stand and makes every decision that matters. That's how we run a build. The engineer is the commander. They set the architecture and the intent, then direct a fleet of AI agents to do the heavy lifting inside the guardrails. The agents have initiative; they do not have authority. At every gate — end of planning, end of validation, before anything ships — the engineer is briefed and signs off. Nothing reaches you without a human commander's decision behind it. That is the difference between an AI tool and a development service. A tool hands you autocomplete and walks away. We hand you a finished system that a human stood behind at every step — produced on a rhythm we've run enough times to trust. Why it delivers what it delivers Speed and quality aren't a trade in a good battle rhythm — they're the same thing. The reason a command post can make fast decisions under pressure is that the cadence is already in place: everyone knows the next checkpoint, the information is already flowing, the assessment is already running. You move fast because you're disciplined, not in spite of it. The unit that improvises every move is the slow one; it's spending all its speed on figuring out what to do instead of doing it. That's why we can deliver in days what usually takes a team months, and still walk out with full test coverage and a clean security pass. The rhythm front-loads the thinking, parallelizes the work, catches the failures early, and feeds every lesson back in. We built dlaSOS — a complete cable-ISP operations platform — in about forty hours, zero shortcuts. See it. The takeaway The loop isn't a machine you turn loose. It's a battle rhythm: plan, work, test, document, improve — four phases of one disciplined cycle, run by engineers who command it and stay accountable for every line. The AI is the staff. The human is the commander. And the commander is always briefed. ignibyte.com/lab/its-not-a-… #Loop #Ai

@chongdashu Thanks for the reply. How do you handle animations with multiple frames and keeping it consistent? Does this tool handle that?

@IgnibyteDev Yeah - but can be circumvented with a bit of process

You've vibe coded the game. But what about the sprites? Here's a teaser of Spriterrific -- generate game-ready animated sprites for your games using prompts. Releasing soon! (Thanks to Fable 5 for working through some gnarly bugs before release) Interested? Link in reply.