It is a free browser game. Every day there is a new puzzle. Your job is to place a limited number of walls and “pen your pet” in by cutting off every path to the edge of the map. The catch is that you are not just trying to solve the problem, you are trying to find the best possible answer.
If you like short daily puzzle games that reward a little thinking, this game is for you.
Each puzzle gives you a grid with terrain and a fixed wall budget. Water acts as a natural barrier. Sometimes there are “Holes” that can be filled by spending a wall there. Stars add points to your score, and Bees subtract points. Your pet starts at the home tile, and your goal is to trap it inside the largest, highest-value area you can create.
That means the puzzle is part path-blocking problem, part score optimization problem. Sometimes the obvious enclosure is not the best one. Often the best move uses the terrain in a way that allows you to reduce the amount of walls in one area in order to have extra to get something more valuable in another part of the map.
Be careful though, you only get to submit an answer once for each puzzle! You can take as long as you want, but there is just enough pressure to make the final submission feel meaningful.
I ran into another browser puzzle with a similar premise that had the seed of a great idea. I didn’t like some design choices made there, and had some issues with the person who made it. A friend of mine and I had gotten into the puzzle concept though, so I decided to build for us a version of the game I wanted to play.
I wanted something lightweight, easy to play, and easy to open from any device. No install. No account required. No app-store friction. In fact, the project is entirely a static webpage hosted on GitHub. Just load a URL and start playing.
That constraint shaped almost everything about the project.
I haven’t made a proper game in a while. I’ve done plenty of software projects, web apps, tools, and other types of prototype and production code the last couple of years. But games have a different feel to them, it was nice to get back into that mindset again. There’s something satisfying about a system where all the rules interact in interesting ways and you get to watch someone figure it out.
There is a new puzzle every day, but you can go back and play older puzzles with the level selector.
You can change what type of pet you have via your choice of emoji, letting you customize the game for your favorite animal or mythical creature. I added multiple language support, currently just English and Spanish but happy to add more as people desire. There is also a hint system that will let you know if you want if you found the optimal answer already or not, or what exactly the optimal answer is to aspire to. The game is also designed to work well on mobile and desktop, and even in theory should work entirely via keyboard navigation.
These kinds of tweaks mattered to me a lot, not treating this game like a quick throwaway side project but something that could be played and supported for years to come.
It also has optional cloud sync if you want to carry your progress across devices, but the core game works perfectly fine without signing in.
Every map is generated offline and solved before it ever shows up in the browser. Since I wanted the game to be a static webpage, I couldn’t use any dynamic code to solve levels in the backend. There is no backend for the game. The browser loads the map, renders the board, checks the penning logic, and calculates your score on the client side. Hosting is simple, deployment is simple, and the whole thing is easy to inspect because the source is public.
I deliberately kept the stack simple: vanilla HTML, CSS, and JavaScript. That said, I had to cheat a little for level generation. The game uses a Python solver based on Mixed Integer Linear Programming. In practice, that means each puzzle is turned into a math problem with explicit constraints and an objective function, and the solver computes the best possible result for that map. When the game tells you the optimal target, it is not making an educated guess. It is the proven optimum for that puzzle.
That was one of the biggest design goals for me. I did not want a puzzle game where the goal is to find the “best” answer if the “best” answer is fuzzy or not fully knowable. In order to generate levels, I created a GitHub Actions pipeline that runs the javascript and python code to generate maps, then it validates them before they get saved and published. The project checks for things like whether the pet can initially reach the edge, whether the puzzle is too trivial, and whether certain tile placements create uninteresting choices. The validation checks ended up being just as if not more important as the puzzle solver itself.
I also have extensive linting and testing that I am able to run as GitHub Actions pipelines, so no code needs to execute for the user at runtime but I still get the benefits of modern coding tools as part of the build and test process.
It takes a few seconds to make each level, a little longer than would be best for real time level generation. But I didn’t want to make endless scrolling puzzles, I wanted a shared experience where every player sees the same level every day. The game is inherently social in that way, you are meant to share your results with your friends and compare your time and percentage.
As a side effect, this project became a pretty nice example of how far you can get with straightforward web tech if your scope is clear.
I used AI coding agents heavily while building this project.
That helped a lot, but not in the magical “describe a game and receive a finished game” sense that people sometimes imply. The useful workflow was much closer to agent iteration with constant supervision and direction.
The agents were good at accelerating implementation. I was able to get a lot more done than I would have had time for otherwise. They were not good at knowing when a seemingly reasonable approach would create long-term problems. Architecture, edge cases, validation rules, and game-specific behavior still needed careful review. If I had just given it vague instructions, it would make trash.
However, I know how to develop a game, and I was able to describe to the agents section by section the kind of architecture needed to make something stable and maintainable. I still had to review every line of code the agent generated, and often had to send it back to fix the errors it had made or systems it over or under engineered.
Still I had some issues, some bugs were introduced that slipped past me. I was able to track them, fix them, and continue to make what ended up being well over 1,000 unit tests to ensure regressions are minimized in the future. All this ended up reinforcing something I already believed: AI can speed up development, but it does not replace the engineering judgment needed to turn working code into stable software.
Oh and in case you are wondering, my kid made the art!
The whole project is up on GitHub:
The repository includes the game, map data, generation scripts, tests, documentation, and a local level editor if you want to make custom levels. The tile system is structured so new tile types can be added from a single data definition, and the scoring logic is separated cleanly enough that the project could be adapted into other grid-based puzzle ideas.
I like side projects more when they are able to be inspected, see what is going on “under the hood” so to speak. If someone wants to see how the game works, or wants to copy an aspect they like such as the level generation tools or GitHub Actions pipelines, they can fork the code and do it themselves! I would encourage you to build any kind of daily puzzle game you want on top of the structure I have built here.
Mostly, I want to know whether it is fun.
Play a few daily puzzles. See if the puzzle feels fair. Try it on desktop or mobile. Make sure cloud sync is working for you. Use the hints, or ignore them. Tell me where the game gets confusing, what parts it gets interesting, and anywhere it breaks.
If you run into a bug or have a feature request, please let me know. Feedback like that is exactly what helps a project like this get better. Make an issue directly in the GitHub repo, I will review every single one.
Thank you for checking it out, I hope you join me and my friends in trying out the puzzle every day!
Pen The Pet 🐕🦺
Day 41 - Iron - Apr 9, 2026
Score: 100% - Time: 01:46
Hints used: checked for optimal
Play: https://www.avinzarlez.com/penthepet/?date=2026-04-09
We often use the words “code” and “software” as if they are interchangeable. In casual conversation, that usually works. In technical planning and when talking about AI-assisted development, it creates subtle misunderstandings that turn into very practical problems. Mismatched expectations, unclear “done” definitions, and teams talking past each other about what to deliver, or worse, what has or has not already been delivered.
A single Python file is unambiguously code. When code becomes software depends on something much larger than the file itself. When it expected to be used, how does it behave when pushed to its boundaries, how it’s packaged and run, how it’s tested, how it’s documented, and—most importantly—how it will be maintained when requirements and environments inevitably change.
I’ve written both code and software professionally for dozens of different industries over my career. When I say professional, I explicitly mean something that had to survive outside of my controlled development environment, used by people when I am not around, expected to be used long into the future. My experiences have made me increasingly strict about vocabulary—not just because I enjoy pedantry—but because precise language prevents confusing and expensive ambiguity.
The AI era has made this distinction even more important. AI can generate a lot of code quickly. But the real engineering question is often: did we generate code, or did we build software? The difference determines how we test, ship, secure, operate, and maintain what we create.
I want to anchor this discussion in something other than my intuition. Not because standards are perfect, but because they are deliberately written to reduce ambiguity.
IEEE’s software engineering glossary defines code narrowly, as a representation of instructions and data:
“Computer instructions and data definitions expressed in a programming language or in a form output by an assembler, compiler, or other translator.” — ISO/IEC/IEEE 24765:2010 (PDF)
That is exactly how most engineers use the word “code” when they are being precise: source files, compiled forms, scripts, and the literal text or artifacts that drive computation. Code is concrete. It can be copied, diffed, refactored, and compiled.
But when we move to definitions of software, the scope expands. In ISO/IEC/IEEE vocabulary, software includes more than programs:
“All or part of the programs, procedures, rules, and associated documentation of an information processing system.” — ISO/IEC/IEEE 24765:2010 (PDF)
I like these definitions because they make two points explicit.
First, software is not “code only.” It includes procedures, rules, and documentation—things that are essential if the capability is meant to exist outside one person’s head.
Second, software is framed “of an information processing system.” That phrase quietly implies environment and context. Not just what instructions the computer executes, but how it is run, what it depends on, and what it means for it to behave correctly.
This is the key conceptual split I use in practice:
This topic feels philosophical because the boundary between “code” and “software” is not a single line, it’s a gradient. Prototypes become tools, tools become products, products become systems, and systems become platforms.
Frederick Brooks captured the core of this transition in The Mythical Man‑Month. When he distinguishes a program from a “programming product,” he describes a program that has been made robust for other people:
“This is a program that can be run, tested, repaired, and extended by anybody.” — Brooks, The Mythical Man‑Month (“The Tar Pit” excerpt) (PDF)
If “anybody” needs to be able to run it, the code must be packaged, dependencies must be controlled, and execution must be repeatable. If “anybody” needs to test it, you need a test strategy that is not purely institutional knowledge. If “anybody” needs to repair it, the system must be diagnosable—logs, error messages, reproducible failures, and enough structure that debugging is tractable. If “anybody” needs to extend it, the design must be understandable and the interfaces stable enough to build on.
This is not to say “code” can’t be useful but carries different expectations.
In the day-to-day rhythm of building systems, the “act of writing” is often a smaller fraction of the work than people expect—especially who think vibe coding will replace the need for most developers. Software must evolve, be supported, and remain correct under changing constraints.
Google’s Software Engineering at Google expresses this distinction almost perfectly:
“Software engineering is programming integrated over time.” — Software Engineering at Google (Chapter 1)
And in the same chapter:
“Programming is the immediate act of producing code. Software engineering is the set of policies, practices, and tools that are necessary to make that code useful for as long as it needs to be used and allowing collaboration across a team.” — Software Engineering at Google (Chapter 1)
If you’ve ever returned to code you wrote six months ago and felt like it was written by a stranger, you already understand why time changes everything. Now scale that effect across a team, across multiple releases, across customers, and across platforms—and you have a very practical reason why not all “code” is “software.”
At this point, I may sound repetitive saying software is “code plus documentation and operations.” That is true but also understates the more fundamental point: If you use code when what you need is software, you may not realize what is missing until after negative consequences.
This is why this distinction is important in AI discussions. Code generation is accelerating the act of typing. We can celebrate that, but we should not pretend the conceptual work disappears. If I am trying to construct a process, a repeatable system used in business, that can’t just be built upon a piece of code.
Whether that code was handwritten by a human or an AI. If it is going to be part of your normal flow of business, a human needs to understand what exactly is happening. How the system could behave under edge cases. Know what should happen if it fails. We need to be careful not to confuse “more code” with “more software.”
There is a reason “Works on my machine” is a saying. I have seen so many times someone in a project meeting or standup claim something is “Done”, only for it to come out that it wasn’t. Not by the professional standards of software I have explained here. It is easy for someone without experience to think that because the code exists, runs, and maybe even accomplishes the required task, that the task is “done.” Teams need to be clear and up front with what their shared definition of done entails, and what is required to make code robust and stable enough to become part of software.
When I explain AI-assisted development to teams, I try to avoid a simplistic “AI helps you write code faster” narrative. That can be true, but it is also incomplete. AI shifts the bottleneck. When code is produced quickly, the cost of verification becomes more visible. You can generate ten variations of a function in seconds, but you cannot responsibly ship ten variations without understanding what they do, how they fail, how they interact with the rest of the system, and whether they introduce new security or reliability risk.
I can tolerate a different level of rigor when I am writing code myself. I can understand a goal in my head without having each metric of quality thoroughly documented and described in the project management tool. I would be embarrassed to make a pull request with code that only works on the “happy path” and breaks if something unexpected comes up. AI doesn’t have this kind of rigor. Even if you write out strict agent guidance explaining everything that needs to be accounted for, you quickly get to the point where the context of the AI gets overloaded and things might get missed.
It’s much more effective to send out an agent with narrow and specific context and instructions than to try and teach it everything a mid-level or senior engineer would naturally understand and think about. Treat it as a junior developer that needs constant supervision. Junior engineers are valuable! It’s a good thing for your team to have senior engineers spend most of their time supervising junior ones. They often come up with solutions a senior engineer may not have even considered. That doesn’t mean you’d ever trust a junior engineer to ship something that will be used by someone else without that supervision and guidance.
AI doesn’t change the need for junior engineers. It makes it more important than ever to train humans to step into that senior role. To understand the strengths and weaknesses of systems. To not just focus on finding a solution as quickly as possible but determining exactly what questions they need to be asking in the first place.
Where AI code generation can greatly enhance a pipeline is helping developers ensure they are following software engineering best practices in their work. Not just automated checks to ensure unit tests exist, but tasking agents to implement robust unit tests for all the edge cases the developer can think of. A developer can use AI to thoroughly ensure all functions have in-code documentation comments, helping future developers understand what was implemented and why.
These are processes that should always be practiced, but the reality of the real world is that often we don’t have the time to check all these boxes while trying to remain agile and move at a fast pace. Agents can flesh out and run tests while a developer’s attention can shift towards breaking down the next few tasks. The inflexibility of AI can be leveraged as a strength when given the right kinds of narrow well-defined tasks.
One reason teams talk past each other is that “AI-assisted development” can mean several different things. I’ve found that clarity improves immediately when I name which layer is being accelerated.
Sometimes AI is accelerating the creation of code artifacts: a function, a snippet, a script, a refactor. That can be a real value, especially for individual workflows and prototypes.
Other times, AI are set to integration or productization tasks: identify API usage patterns, proposing changes required by dependency upgrades, creating scaffolding for packaging, generating documentation or example usage. The artifacts produced here could still generally be considered “code” taken in isolation, but it begins to touch the boundaries of producing software as things come together. Again, there can be value that AI can help here, but it doesn’t happen automatically.
If you leave the AI to make up what it thinks it needs, it won’t architect proper software. If you take a junior engineer and put them “in charge” of an even more junior AI agent, quality code can be produced. However, the guidance of a senior developer will be needed to guide exactly what and how the AI is prompted.
Instead of saying something was vibe coded, be precise with your language. For example:
Those statements are not just more honest, they are more actionable. They tell you what work is complete and what work remains.
If we’re clear about the boundary between code and software, we can make better decisions on where and what AI can safely be incorporated into our work, what must be validated by human, and what “done” truly means in terms of production ready deliverables.
I think the first time I went in person was 2006. Back when it was in San Jose. Gosh, 20 years is a long time ago, isn’t it?
I didn’t make it every single year over the last 20, but I believe I had at least 13-year unbroken streak there. I don’t remember if I missed 2018 or 2019, but then I stopped going for a few years because of the pandemic of course. Watching the recorded talks is not the same. GDC is one of those events that lives in the hallways as much as it does in the talks. You miss the accidental run-ins, the “Oh my gosh I haven’t seen you in forever!” moments, the late-night conversations that range from a total waste of sleep to life and career-defining moments.
There used to be multiple GDCs. I went to GDC Austin and GDC Next in LA when those were still around. They had a different vibe but still had everything I loved about the event. Over the years, I’ve had the privilege of speaking at GDC multiple times. One of the highest honors I’ve had as a conference speaker. I will always remember those talks. It was so surreal to stand on a stage at a conference you’ve been attending for years, looking out at a room full of developers, and realizing you’re shaping their conference experience. Every time I’ve spoken, I’ve learned more than I’ve taught.
My favorite GDC memory might still be when a side project of mine was featured in the Experimental Gameplay Workshop. That session has always been one of my favorites. Pure creativity, risky ideas that might not “scale” but absolutely matter. Truly games as a medium for exploring art.
This year, though, you can feel a shift. Things are different already, and it is only the first day. The branding is new: “Festival of Games.” Some of it is a cosmetic change, and I’ll see this week how much the audience feels different. There has certainly been a big change on exactly who GDC was for over the years, and who seems to be the intended target audience.
It has always been the case though, if you are learning about something for the first time at GDC, you are probably behind. Back when I ran a game studio, we would always remind each other of that. In an industry has had so many fundamental shifts, one should always learn what they can about what has been done, but take it with the grain of salt knowing the future is likely to be different and unpredictable.
I’m proud of being “old” here. Proud of being someone who’s been a regular for two decades. There’s something meaningful about continuity in an industry that changes so much. I’ve seen trends rise and fall, entire platforms come and go, business models reinvent themselves. Through all of that, GDC has remained this yearly checkpoint. A place to recalibrate.
If you’re here this week, please come say hi. I love the random hallway chats more than almost anything else about this conference. Reach out to me on social media, grab me between sessions, interrupt me mid-break. I’d genuinely love to talk.
Here’s to twenty years of GDC. And to whatever this “Festival of Games” era becomes next.
]]>With AI becoming more embedded in our workflows, it’s easier than ever to build on top of ideas that seem right but might actually be incorrect, or worse perpetuating bias.
This vlog was inspired by this article, which was inspired by this article.
Share your own stories of assumptions you had to question down below. What did you think made total sense, but turns out was completely wrong?
]]>Please, always remember: We have always been here.
]]>