Building Arcol can be somewhat intense.

The long term vision for the product - the world’s first truly collaborative architectural design tool embedded with useful, autonomous intelligence, making the people designing and building the physical world fundamentally more successful and productive - certainly can’t be accused of being unambitious. The technical problems intrinsic to building that future require careful design and intentional approach: geometry, graphics, real-time data sync, the ineffable complexity of modeling the ambiguity of the physical world and the human processes that happen within it. And every time we ship a feature, our users clamor for ten more. Building in such a context requires careful planning, intentional prioritization, and deliberate execution.

So in exact opposition to those constraints, last month the team punted the roadmap and took an Interlude - a maker week crossed with a game jam - where we unleashed ourselves and our coding agents on experimentation and open-ended prototyping and exploration.

The Idea

Maker week style events have been a staple of my career personally for a long time, going back as far as flying out to join a Dropbox Hack Week the winter before I started as a new grad there, but Arcol Interlude was the brainchild of Paul, Arcol’s CEO. He envisioned a maker week crossed with a game jam, an invitation to the team to spend a week working on whatever Arcol-related projects inspired them - but with a goal of intentionally using, learning about, or integrating AI into the product.

During our conversation about how to make the Interlude happen, one thing was clear: we were strongly aligned that the goal should not be shipping anything that the team built. In fact, it should be the opposite: push people to build experimental and exploratory things, to pick a direction and run with it, with a goal of learning as much as possible. A week where everyone built and polished a small pet feature that we shipped the following release cycle would be a failure; instead we wanted to have a week where we got to find out what happened when the whole team sprinted down different paths unburdened by constraints like code quality, test rigor, edge cases, security considerations, and all the rest of the tedious and delightful details that go into really shipping.

When I suggested this, Paul gave me a look as if he was confused why I had bothered to say something so self-evident out loud - but it can be counterintuitive, so it’s worth a digression on why this is a critical dimension of running something like an Interlude week productively. It’s true by giving the team the directive to not try to ship you guarantee that none of the code written will ever see the light of day - so your customers will never derive direct benefit from it. But unconstraining the team from the burden of shipping means that your team will:

• take on technical experimentation outside of the context of the real product, and evaluate new frameworks, languages, integrations, technical architectures and so on that would be conceptually impossible to “ship”.

• work on projects that they doubt are possible or advisable, either because of scope, technical limitations, or just because they aren’t sure they’re a good idea to actually give to users - and sometimes surprise themselves when it works out!

• walk away from the week feeling satisfied that they learned and accomplished something, regardless of whether the organization ends up actually prioritizing the specific feature they built [1].

At the end of the week, a lot of code will be quietly sequestered on Github branches, never to reach main. But the flip side is that the team has built a large amount of knowledge and context very quickly which can then be deployed against real, shippable projects in the coming months and years! Building things “for real” is hard and takes time [2], and an EPD ("Engineering, Product, and Design") team equipped with extra context that they acquired outside the constraints of building for real will move faster than one without. The team already knows that the architecture they prototyped out at Interlude has performance bottlenecks. The team already knows that a particular interaction looks good on paper and feels clunky in practice. The team has already tried that open-source framework and discovered that it solves that one problem way better than expected. And while of course the team can prototype and experiment in the context of a project with a real user-facing deliverable, the concrete goal of shipping will bias everyone to reach for the safe ideas and the happy implementation path.

And let’s be honest: it’s often more fun to chase wild ideas and write throwaway code than it is to build carefully. Carving out space for the team to just have fun is a good thing from time to time, especially on a team distributed between multiple geographic locations who can’t easily do organic social events [3].

How did it go?

The team built some absolutely awesome stuff. We’re shipping none of it [4], at least for now.

We experimented with a variety of new technology ideas and product features and produced some absolutely incredible demos. To give a sense of breadth, some of the ideas worked on:

• prototyping five different architectures for data ownership and handling in our rendering pipeline, and getting clear performance data

• image generation and AI manipulation pipelines directly inside Arcol’s Boards presentation layer

• using LLMs to analyze sites and generate reports about projects inside the Arcol product (there were a few folks who tackled different flavors of and approaches to this, in fact)

• putting high fidelity 3d imagery inside Arcol projects

But experimentation isn’t always successful - or if it is, it wasn’t particularly ambitious experimentation. And since we learn more from our failures than from our successes, here are a few things we tried that didn’t work well:

• chat is clearly the wrong interface to an LLM in the context of architectural design. The messiness and ambiguity of real-world design problems is very different than authoring code or blog posts, and conveying enough information to an LLM via a chat window to accomplish even simple design tasks is exhausting and slower than just doing it directly. Even worse, that’s not a problem of insufficient intelligence that goes away as the models get better (unless LLMs start literally reading our minds) because it’s a question of specificity and conveying information, not just acting on it.

• having LLMs make decisions about geometry - like how to generalize a particular edit to a floor plan to the rest of the floor plan - is still quite unpredictable. Geometric and spatial reasoning in general is, perhaps intuitively, difficult for a “language” model.

• introducing UX to communicate a hierarchy of elements inside an Arcol project is, at best, a highly divisive feature concept internally.

But knowing those things sets us up for success when it’s time to work on those kinds of problems for real in the product - so we can skip past trying to build a chatbot for Arcol “for real” and go straight to other ideas.

Overall, the sentiment on the team was that the week was a success. We’ve emerged from the Interlude energized and equipped with better information about the path forward. Some projects we’ll revisit soon, others will sit on the back burner for longer - and that’s okay.

Some thoughts on our brave agentic coding future

It’s 2026, and as a Head of Engineering I’m now legally required to talk about AI coding.

Arcol Interlude wasn’t just an EPD event; the whole company joined in. This is common to these kinds of events, but one of the (typically unspoken) unfortunate truths about them is that it’s much harder for folks outside of EPD to engage fully in this kind of week, and they can feel left out. There are a number of logistical reasons [5] but one of the core problems is that the barrier to entry to working in a codebase is typically quite high, even for folks with a technical background outside of EPD. Most of the time, while engineers can jump into building a new feature or trying something out quickly, folks outside of EPD would spend their whole week just getting set up and oriented, or simply wouldn’t try to write any code at all. And while there are plenty of non-coding maker week projects that are interesting and worthwhile, it’s an undeniable limitation that previously did not have a great answer.

Arcol Interlude was the first time I’ve participated in an event where this particular problem felt fundamentally solved. Everyone - not just EPD - got to write code and build in the product directly, and were able to engage in product exploration and prototyping, because they were able to leverage tools like Claude Code and Codex to work directly in our codebase. The barrier to entry dropped precipitously and is now nearly non-existent.

This is one of the fundamental unlocks that agentic coding gives us, and potentially the one that I’m most excited about - giving folks outside of the engineering team the ability to prototype and tweak directly in the codebase, no intermediate steps needed. Being able to tell computers what to do, and have them listen, has always felt like a superpower, and now that superpower is more accessible than it has ever been. We’re already exploring how to do more of this, like Mike prototyping directly in the dev environment instead of in Figma and Kyle writing the analytics events he needs directly instead of round-tripping through a backlog ticket for an engineer to pick up. That in turn gives the engineering team more time for deep focus and execution. It’s not a panacea, but it does feel like it fundamentally changes the fabric of how technical work is getting done for the better.

Closing thoughts

This Interlude process is something every team would benefit from. It doesn’t need to be a big production [6] - you just need to give your team permission to explore. You’ll be impressed by what they accomplish!

Footnotes

[1] This is an unfortunate pain point at the end of many corporate maker week style events - not all projects that are shippable from a technical quality perspective necessarily align with the company’s product vision, and thus get mothballed. That’s inevitable and fine, as long as expectations are clearly set, and people can make the choice about what to work on with that in mind - but emphasizing “shippability” in a maker week is essentially an abdication of responsibility for prioritization by company leadership that sets people up to feel bad despite doing good work.

[2] Coding agents have accelerated the process of writing and shipping significantly, but this principle still holds - LLMs are a force multiplier for what’s possible, not a whole-cloth unlimited replacement for human effort.

[3] We have been known to love a game of Timeguessr over Zoom though.

[4] Not quite true: we did ship a cool new internal dev tool that will help new hires hit the ground running faster. But nothing is shipping to users.

[5] External obligations exist; support tickets still have to be answered, candidates are still applying, people are still clicking “Get a Demo” on your website [7]. Your office manager is doing their normal job even harder because of the extra events and goings-on. And that’s not to mention the awkwardness of telling people who are compensated on a quarterly quota program to take a week to stop and work on “whatever they want”.

[6] The time from idea, or at least Paul sharing the idea with anyone else, to kickoff was twelve days in our case.

[7] Engineers are also still getting paged and your infrastructure has to keep running, though since a maker week style event typically means fewer things are being deployed and changed in prod, there’s less of that than normal. For Arcol Interlude we took the week off from our typical release cadence.