The difference isn't the model they're using. It's not their prompting technique. It's not even their underlying programming skill, though that certainly matters.

The developers succeeding with LLM-augmented development have stopped waiting for the perfect out-of-the-box experience and started building their own tools to solve their own problems.

The Myth of the Perfect Configuration

When Claude Code, Cursor, Windsurf, and similar tools started gaining traction, a cottage industry of "optimal configurations" emerged. GitHub repositories full of system prompts. Blog posts about the "ultimate" rules file. YouTube videos promising 10x productivity if you just copy these exact settings.

I tried many of them. Some helped marginally. Most did nothing. A few actively made things worse because they were optimized for someone else's workflow, someone else's codebase, someone else's pain points.

This shouldn't have surprised me. I've spent two decades watching the same pattern play out with every development tool and methodology. Cargo-culting someone else's Agile process doesn't make you agile. Copying another team's CI/CD pipeline doesn't give you their deployment confidence. Using the same text editor as a famous programmer doesn't make you write better code.

The tool is never the thing. The thing is understanding your own problems deeply enough to know what tool you need.

A Problem Worth Solving

I'd been using Claude Code heavily for several months, and one friction point kept recurring: GitHub issue management.

Not the basic stuff—creating issues, closing them, adding labels. The gh CLI handles that fine, and Claude can drive it without much trouble. The friction was in the relationships between issues.

I work with hierarchical issue structures. Epics contain stories. Stories contain tasks. Tasks might have sub-tasks. When you're trying to keep Claude oriented on what you're building and why, being able to say "this task is part of story #42, which is part of epic #15, which is about the payment system redesign" provides crucial context.

GitHub added sub-issues and blocking relationships over the past year, but they're only accessible through the web UI or the GraphQL API. Every time I needed Claude to help me restructure issue hierarchies or track dependencies, we'd end up in a frustrating dance: Claude would attempt some gh api graphql call, get the syntax wrong, try again, get the escaping wrong, try again, finally succeed, and by then I'd lost my train of thought on the actual problem I was trying to solve.

Worse, if I wanted to grant Claude permission to manage issues autonomously, I'd have to approve Bash(gh api:*) in my settings—which is far too broad. That pattern would let Claude make arbitrary API calls to GitHub, not just issue management operations.

I could have lived with this friction. Most people do. They work around limitations, accept the rough edges, wait for someone else to build a better solution.

Instead, I decided to build the tool I needed.

The Development Process (With an AI Partner)

Here's where things get interesting. I didn't just sit down and write a GitHub CLI extension from scratch. I used Claude Code to help me build the tool that would make Claude Code more effective.

The process started with research. I asked Claude to investigate the GitHub GraphQL API, find the relevant mutations for sub-issues and blocking relationships, and figure out what operations were possible. This took some trial and error—we created test issues, experimented with API calls, discovered that sub-issues require a special GraphQL-Features: sub_issues header, learned that blocking relationships use issueId and blockingIssueId parameters (not the more intuitive names I initially guessed).

Every failed API call taught us something. Every error message refined our understanding. Claude kept notes, I asked questions, and gradually a clear picture emerged of what was possible and what syntax was required.

Then came the key insight: we could wrap all these GraphQL operations in a gh CLI extension. Instead of Claude needing to construct complex API calls every time, it could use simple commands like gh issue-ext sub add 10 42. And critically, I could grant permission for Bash(gh issue-ext:*) without opening the door to arbitrary API access.

The extension itself took maybe 20 minutes to write—a bash script that handles argument parsing, constructs the appropriate GraphQL queries, and presents results in both human-readable and JSON formats. Claude did most of the implementation work while I reviewed, asked questions, and occasionally corrected course.

But the extension was only half the solution. I also needed Claude to know how to use it effectively. So we built a Claude Code plugin: a skill document that teaches Claude about GitHub issue management, comprehensive reference documentation for every command, a setup command that installs the extension, and a session-start hook that reminds users if they haven't installed the extension yet.

The whole thing—research, experimentation, extension development, plugin creation, documentation—took an hour. And now I have a tool that solves my specific problem in exactly the way I need it solved.

Why This Matters

Let me be clear about something: the plugin I built isn't revolutionary. It's a wrapper around existing APIs with some documentation. Anyone could have built it.

But almost no one does.

Most developers treat their AI coding tools as fixed artifacts. The tool does what it does; your job is to figure out how to work within its constraints. If something is frustrating, you either live with it or switch to a different tool and hope it's better.

This mindset made sense when tools were expensive to modify. Writing an IDE plugin used to be a significant undertaking. Customizing your build system required deep expertise. The cost of building your own tools was high enough that it was usually better to adapt your workflow to existing solutions.

But that equation has changed. When you have an AI assistant that can help you build tools, the cost of custom solutions drops dramatically. That time I spent building the GitHub issue extension? I couldn't have done it that quickly five years ago. The research alone would have taken longer than the entire project did with Claude's help.

This creates a flywheel effect. You use AI to build tools. Better tools make your AI assistant more effective. A more effective AI assistant helps you build better tools faster. Each iteration compounds.

The Meta-Skill

The developers I see thriving with AI coding assistants have developed a specific meta-skill: they notice friction, investigate root causes, and build solutions—rather than accepting friction as the cost of using new technology.

This requires a particular mindset:

Treat configuration as code. Your rules files, system prompts, custom commands, and plugins are part of your development environment. They deserve the same attention you'd give any other code you maintain. Version control them. Iterate on them. Share them when they might help others, but don't expect others' configurations to solve your problems.

Pay attention to repeated friction. Every time you find yourself working around a limitation, every time Claude makes the same mistake twice, every time you have to manually intervene in something that should be automatic—that's a signal. You've found a problem worth solving.

Invest in understanding. Before building a solution, make sure you understand the problem deeply. My GitHub issue extension works because I spent time learning exactly how the GraphQL API behaves, what parameters it expects, what errors it returns. That understanding is embedded in the tool and the documentation.

Build incrementally. You don't need to solve everything at once. I started with just sub-issue management because that was my most pressing pain point. Blocking relationships and linked branches came later. Each addition was motivated by a real problem I'd encountered.

Document for your AI partner. Half of building effective tooling is teaching your AI assistant how to use it. The skill documentation I wrote for Claude isn't just for human readers—it's optimized for Claude to consume and apply. Clear examples, explicit command syntax, common patterns and workflows.

The Uncomfortable Truth

There's an uncomfortable truth in all of this: the people who benefit most from AI coding assistants are the people who needed them least.

Experienced developers who already understand their problem domains deeply can direct AI assistants effectively. They know what questions to ask. They can evaluate generated solutions. They can identify when the AI is confidently wrong. And crucially, they have the skills to build custom tools when off-the-shelf solutions fall short.

Less experienced developers often struggle because they're trying to use AI assistants as a shortcut past understanding. They want the tool to just work, to give them correct answers without requiring them to evaluate those answers critically. When friction appears, they lack the context to even recognize that a solution might exist.

I don't have a neat resolution for this tension. AI coding tools genuinely do lower the barrier to building software. But they lower it most for people who've already climbed over that barrier.

Perhaps the best thing experienced developers can do is model this tool-building behavior openly. When you solve a problem by building a custom extension or plugin, share not just the artifact but the process. Show how you identified the friction, how you investigated solutions, how you iterated toward something that worked.

The tools we build are artifacts of our understanding. Sharing them helps. But sharing how we built them helps more.

Getting Started

If you've read this far and want to try building your own Claude Code tooling, here's what I'd suggest:

Start with your actual problems. Don't go looking for things to optimize. Instead, pay attention over the next week. When do you feel friction? When does Claude struggle with something that should be straightforward? Write these down.

Pick the smallest valuable problem. You don't need to build a comprehensive solution. Find something specific and bounded. Maybe it's a single command that automates a repetitive task. Maybe it's a snippet of documentation that helps Claude understand your project's conventions.

Use Claude to build it. This is genuinely effective. Describe the problem you're trying to solve, work through potential solutions, iterate until you have something that works. You'll learn about Claude's capabilities and limitations in the process.

Test it in real work. The best tools emerge from actual use. Build something minimal, use it for a few days, notice what's missing or awkward, improve it.

Share what you learn. Not just the finished tool—the process, the problems, the failed approaches. Someone else has the same friction you do. They might not have realized yet that building a solution is possible.

The GitHub issue management plugin I built is available at https://github.com/jwilger/claude-code-plugins, and the gh extension is at https://github.com/jwilger/gh-issue-ext. You're welcome to use them if they solve problems you have.

But more than that, I hope this piece encourages you to notice your own friction and do something about it. The tools you build for yourself will always fit better than the tools you borrow from others.

I've been trying out different AI-assisted software development workflows recently so I can guide clients and colleagues on which tools and methods to use or avoid. One setup I find quite promising is Goose, an on-machine AI agent that interacts with the system through extensions using an MCP server. When used with a .goosehints file, which gives instructions for a ping-pong pairing, TDD approach to development, I've been quite impressed with its capabilities and how it can be adjusted to fit specific workflow preferences.

As part of my experimentation, I used Goose to help create a small TypeScript CLI utility. This tool takes a CSV file, where each record is a latitude/longitude coordinate pair, as input and outputs a new CSV file that includes the associated business name, website, and telephone number from the Google Places API. This task, having never used the Places API before and not being a regular TypeScript author, would likely have taken me 2-3 hours to complete. With AI assistance, it was done in about an hour. It was a complete, working solution that easily processed a test file with about 10,000 rows. It had full test coverage, and the code quality was decent, if not perfect. Success, right?

The problem is that bugs and low-quality code aren't the only issues that can cause trouble.

In my first attempt at creating this utility, I only extracted the business names from the Places API for each record. A quick check of the Places API pricing showed that I could make 10,000 requests for free, and additional requests up to 100,000 would cost $5 per 1,000 requests. Running an input file with 20,000 rows would cost about $50. I thought this expense was reasonable for the experiment, but I also wanted to avoid unnecessary spending. So, I decided to use a 10,000-row input file to stay closer to the free tier and maybe only spend $5-10 on the extra requests needed during testing.

Once I got the basic version working by refining the solution with Goose, I then asked Goose if I could also include the website URL and phone number for the business in the output. Goose was happy to help and did a great job updating the existing solution, including the tests, without unnecessarily rewriting major parts of the code.

At this point, anyone familiar with the Google Places API is probably shaking their head and laughing at my mistake.

The pricing I was looking at was for their "Place Details Essentials" level of requests. By simply asking for these two extra fields, URL and phone number, the request automatically moved to their "Place Details Enterprise" tier, which is much more expensive. At this tier, you only get 1,000 requests per month for free, and you pay $20 per 1,000 requests for anything beyond that! You can imagine my shock and horror when I received emails from Google later that day saying they had received payments from me totaling just under $2,000.00!

This probably wouldn't have happened if I had been writing this code without AI assistance. I would have needed to review the API documentation for the Places API to find out how to get those two additional fields of data. At that point, I likely would have noticed that this would move me into a different pricing tier. However, since using AI assistance meant I didn't need to look up this information myself, I didn't notice the change. I happily ran my tests and then the entire test file, and I was quite pleased with the output. It was a job well done, and it probably took about an hour less than it would have if I had written the code myself.

This post is not a criticism of Goose specifically; the issue I faced could happen with any LLM-based coding assistant. In fact, I would argue that the better the tool (and the more you trust it), the more likely you are to encounter a similar issue. The problem wasn't with the code itself. I reviewed the code before running it and made sure I understood what each line was doing. What I didn't do was thoroughly consider other factors that a professional software engineer should evaluate, such as the financial cost of running the solution. Thankfully, this was just a personal project and not a client system, so I'm the only one dealing with the consequences. Now imagine if a less-experienced developer made a similar mistake in a production system that processed many more records over a month. The consequences of that decision could be much worse.

While AI-assisted coding tools like Goose can significantly enhance productivity and streamline the development process, they also introduce new challenges and responsibilities for developers. It's crucial for software engineers to remain vigilant and thoroughly review not just the code, but also the broader implications of their work, such as financial costs and potential impacts on production systems. This experience underscores the importance of maintaining a balance between leveraging AI capabilities and exercising professional diligence to avoid costly oversights. As AI tools continue to evolve, developers must adapt and refine their practices to ensure they harness these technologies effectively and responsibly.

The system architecture we were using led me to a realization that has completely changed how I now integrate generative AI features into an application. I've always appreciated event-sourcing and CQRS (Command Query Responsibility Separation) architectures. We were developing this application in Elixir using the Commanded library. In this architecture, whenever a user performs an action that changes the system's state (like submitting an order form), this action is captured as a "command" that shows the intent to change the state. This command is checked and carried out, leading to either an error message or a state-change event. These events are the truth for the entire application's state, and no changes to the system's data happen without a matching event. The system records events in response to the language model's changes, just like those made by human users. Although it's possible to write an event directly to the event stream, the Commanded library makes it much easier to create a simple command that the system can execute, which results in the recording of an event.

It took me longer than I'd like to admit to see how everything fit together. The human user and the language model change the system's state using the same basic process: the command. Once I realized this, I wondered if we were approaching this from the wrong perspective. What are we using generative AI for? In most situations, a language model is creating results that a skilled user could also achieve on their own; we use these models as an aid to help us bridge a gap in either knowledge or efficiency. They aren't a part of the application as much as they are an assistant in working with it.

As I mentioned in an earlier piece about how generative AI is changing UX paradigms, we successfully let the language model control many aspects of an application humans would have previously performed. When creating APEX, a generative-AI-integrated application we made at Artium to help produce product plans that are well-grounded in the needs of the business, we could have taken a different approach to the interaction. We could have had the user click on nodes, click an edit button, fill out a form with the information they wanted in each section, and click "save," and to incorporate generative AI, we could have put a little AI-sparkle button next to the text fields and used the model to fill in just that one piece.

Instead, the primary means of interacting with APEX is via a back-and-forth conversation with "the Artisan." The Artisan isn't just a chatbot that gives you the text to put into a form field; it can also update that text for you in the right spot.

Imagine you're on a call with someone and you’re collaborating on a Google Doc. You read through the text they've just written and suggest changes. Right before your eyes, you see the text change as your writing partner edits the document on another computer. Once upon a time, that felt magical; today, it's mundane.

Using APEX to build a product plan is similar to this style of collaborative editing. The difference is that your writing partner is a language model that understands how to use the application. Sometimes, it offers its own opinions, but it also does what you say verbatim when you are explicit. Sometimes, it produces results you will love; sometimes, you need to iterate on its suggestions.

Witnessing this approach come together, I realized that this is precisely where generative AI can shine when integrated into our applications. I also learned how we can make language models a much more reliable part of our systems.

Rather than treating the language model as an internal component of your system, a better approach is to consider it as just another user sitting at their computer and sending inputs to the system. By treating the output from the language model precisely as if it had been typed into a form by a human user, the solutions to non-deterministic inputs suddenly become clear. It's just form validation.

Build your application as though multiple humans can concurrently and collaboratively edit the same entities. Then, teach your model to control your application. For example, your two human users might have a text chat about the documents they are working on. Treat text responses from the language model the same way; your application code processes the response by executing the same SendMessage command that a human user invokes if they click the send button on a message they typed. If the language model determines it needs to change the title of a document, it must send a message back that your client code can translate into an application command such as UpdateTitle. This command, again, is the same UpdateTitle command that the system will execute if a user clicks an "edit" link next to the title, changes the text, and then hits "save."

How you handle an invalid attempt to change the system data is an essential aspect of this approach. Language models work best with plain, human language. While their ability to run completions of computer code is currently helpful and still improving, typical language models are better at working with good old-fashioned prose. Because of this, you should respond to the incorrect function call in the same way you'd react to the human user: show it the natural language descriptions of the errors.

For example, we have a rule that a document title must be unique in the system. We enforce this invariant at the command execution layer. When a title is not unique, instead of recording a TitleUpdated event, the system responds with an error message: "Another document already uses the title Foo Bar Baz." If the language model sees this error in your response, it will have enough information to correct itself and attempt to execute the UpdateTitle command again with a different title. If, instead, the model receives a machine-friendly error message like "dup_title," there is less of a chance that it will interpret that to mean an error occurred or that it will sufficiently address the mistake.

Treating generative AI as just another user of your application means that you'll also be well-situated to add human/human or human/human/AI collaboration, should that be desired. It becomes more apparent how to handle errors when you receive invalid data or when the model tries to interact with your application in ways that aren't available to it, such as hallucinating functionality that doesn't exist or isn't permitted. Additionally, much knowledge and experience exists in designing UX for collaborative-editing applications. Rather than reinventing the wheel, we can rely on this existing body of knowledge to guide how we approach UX for generative-AI-enhanced applications.

By changing your perspective on the role that generative AI plays in your application, you can both delight your users and create an application that is more fault-tolerant and easier to maintain.

In my role as a software engineer, I prefer using command-line and keyboard-driven tools. I avoid using the mouse while programming, not because I think "real programmers don't use mice," but because reaching for the mouse is significantly slower for tasks like navigating files, editing text, and running programs. Therefore, you'll often find me in a full-screen terminal window, using tmux (a tool for managing multiple terminal sessions in one window) and vim (a highly customizable text editor). Over time, I've developed a set of configuration tweaks and shell scripts that help me work efficiently. I use a minimalist UI that keeps the code I'm working on in focus, without the distraction of unnecessary UI elements that require mouse clicks.

However, for those unfamiliar with these tools, becoming immediately productive in this environment can be quite challenging. I've been working this way for over 20 years, and I’m still finding new ways to boost my efficiency with vim. Given that I use this application almost daily for long hours as a crucial tool of my trade, the time invested in learning to use it as efficiently as possible is highly worthwhile. That said, I wouldn't suggest that all user interfaces should require this level of expertise to be effective. When I come across a system I'm not familiar with, I really value a simple, intuitive interface that helps me do the right thing.

On the other side of the spectrum, there are people who aren't as familiar with computer technology and can get frustrated by systems, even when those systems are meant to be used with a mouse or trackpad. My wife is one such person. She's not computer illiterate, but she often gets frustrated with websites and applications when she knows what she wants to do but can't find the right buttons to press to make it happen.

Recently, at Artium, I've been involved in building a new product called APEX, where we are exploring a new approach to how users interact with applications. APEX is a tool to help you take an idea for a software product and bring that idea to life by walking you through the process of defining the problem space, refining the product vision and value proposition, and then focusing on the key users of the application and how they will use it. The goal is to arrive at an actionable plan for building the initial version of your product and provide you with the information you need to create a proposal and business plan that will help you launch your product. The primary interaction with APEX involves exchanging messages with a generative AI assistant. However, this is not just an AI chatbot that is generating text in a chat window for you to copy and paste into your plan. Our assistant is actively updating the representation of your product on-screen as your conversation progresses.

This style of interaction represents a pivotal shift from the traditional dichotomy of GUI and command-line interfaces. By adopting a conversational, AI-driven approach, we can create a unified interface that intuitively adapts to the user's expertise level—simplifying the learning curve for novices while providing the depth and efficiency that experts crave. This adaptability showcases how generative AI can transcend the limitations of previous technologies, offering a seamless, inclusive user experience that traditional interfaces have struggled to provide.

While getting ready to launch our open beta for APEX, I asked my wife to try using the application to plan out a product. She was able to get through the entire process, and amazingly, I didn't hear her get frustrated with it even once. She is a registered nurse by trade, and as I mentioned before, she is often frustrated with computer programs; this is not someone who has experience with product design or comes to the table with a high level of knowledge about computer systems. When I asked her about the experience, she told me that she much preferred this way of interacting with a computer because it was just like having a conversation with another person. Rather than having to feel overwhelmed by options or frustrated that she couldn't figure out how to change something, she was able to simply converse with the assistant and watch the updates happen in the display of the product. And there are no "wrong answers" when talking to the assistant. If you misunderstand a question or simply choose to focus on a different aspect of the product, the assistant is able to adjust, guide, and redirect to help you complete your task.

What is amazing to me is that this style of interaction is equally appealing to me as an expert user of the system. While the conversation and guidance of the assistant can be essential for a novice user who doesn't necessarily understand how to approach product planning, as someone who does understand both the process and the types of information that APEX manages, I am able to very quickly create a product plan without ever touching my computer's mouse by simply being explicit with the assistant with my directions. I can directly say "set the product title to MyAwesomeProduct", and it does it. If I say "use Elixir, Phoenix, and LiveView with a Postgres data store", it updates the Technology section without me having to wait for the assistant to ask me about that. If I already have text-based documentation about a product idea (typed notes from a client planning session, for example), I can simply paste those notes into the assistant window and tell it to create a product plan based on those notes.

Despite the promise of generative AI in enhancing UX, several challenges loom. One significant concern is the potential for AI to misunderstand user intent, leading to frustrating experiences or, in worst-case scenarios, harmful outcomes. Ensuring that AI systems can accurately interpret and act on a wide range of human inputs is crucial for their success. Additionally, ethical considerations are at the heart of deploying generative AI in any user-facing application. Issues such as bias in AI responses, transparency in how AI decisions are made, and the autonomy of users in guiding the AI's actions are critical. As we integrate AI more deeply into our lives, ensuring these systems enhance rather than undermine human autonomy, respect user privacy, and promote fairness and inclusivity will be essential. By addressing these ethical challenges head-on, we can harness the benefits of generative AI while minimizing potential harms. Addressing these challenges requires new approaches to software testing to account for the non-deterministic nature of generative AI responses. At Artium, we have also been pioneering the use of Continuous Alignment Testing to ensure that products using generative AI are able to function with a high degree of confidence and safety.

The impact of generative AI on UX design, as shown by our work on APEX, is clear. By enabling a more natural, conversational interaction with technology, we're doing more than just making applications more accessible and efficient; we're changing how humans interact with computers. This move towards intuitive, adaptive interfaces suggests a future where technology truly serves everyone, no matter their background or level of expertise. As we keep improving and broadening the abilities of generative AI, the potential for innovation in UX seems endless. The evolution from command lines to conversational interfaces is just the start of a UX revolution that will keep growing and surprising us.

I did not and could not have produced APEX on my own in the time that we were able to bring this together. APEX would not have been possible without the team that created it:

• Cauri Jaye

• Ross Hale

• Serena Epstein

• Michael McCormick

• Ryan Durling

• Nick Mahoney

• George Wambold

• Nafisa Rawji

• Mark Whaley

• James Lenhart

• Chay Landaverde

• Gene Gurvich

• Randy Lutcavich

• John Wilger

• and the rest of the Artium team who supported our work

defmodule MyApp.Repo.Migrations.CreateFoos do
  use Ecto.Migration

  def change do
    create table(:foos) do
      add :name, :text, null: false
    end

    create unique_index(:foos, :name)
  end
end

and a module with a changeset validation for the uniqueness constraint, perhaps like:

defmodule MyApp.Foo do
  use Ecto.Schema

  import Ecto.Changeset

  schema "foos" do
    field :name, :string
  end

  def changeset(%__MODULE__{} = foo, %{} = changes) do
      foo
      |> cast(changes, [:name])
      |> unique_constraint(:name)
  end
end

Then, when you run:

result = MyApp.Foo.changeset(%MyApp.Foo{}, %{name: "bar"})
         |> MyApp.Repo.insert()

The Ecto library will attempt to insert your record, and if there is already a record where the name column is set to "bar", Ecto will see the uniqueness constraint violation error produced by the database and turn it into a validation error on your changeset, so that it would look something like:

{:error, %Ecto.Changeset{errors: [name: {"has already been taken", _}]}} = result

Something More Complex

I recently needed to enforce a database constraint similar in spirit to a unique index (if a record were in violation, I wanted the same behavior on the Elixir end of things—the changeset should report that the value for the field "has already been taken") however the criteria for what should be considered "unique" was more complex than what a simple unique index in PostgreSQL would be able to deal with.

Let's pretend we have a project that is managing meeting room reservations. The process for reserving a meeting room is as follows:

1. The customer chooses a room and selects the time range for the reservation.
2. Assuming the room is available at that time, the system places a hold on the room for 24 hours
3. Within that 24-hour period, the customer pays for the room and completes some contractual information that must be signed by both the customer and the facility manager.
4. Once the payment is complete and the contracts are signed, the reservation is confirmed.

Here, then, are the business rules for creating a reservation:

• A room reservation cannot be made for a given room and time-period if there exists another room reservation for that same room with an overlapping time-period and the existing reservation is in a "confirmed" status.

• A room reservation cannot be made for a given room and time-period if there exists another room reservation for that same room with an overlapping time-period, the existing reservation is in a "hold" status, and the existing reservation was created within the last 24 hours.

We decide to store the room reservations in a table defined as:

defmodule Meetings.Repo.Migrations.CreateRoomReservations do
  use Ecto.Migration

  def change do
    create table(:room_reservations) do
      add :customer_id, :binary_id, null: false
      add :room_id, :binary_id, null: false
      add :reservation_starts_at, :timestamp, null: false
      add :reservation_ends_at, :timestamp, null: false
      add :status, :text, null: false, default: "hold"
      timestamps()
    end
  end
end

and ideally, we'd like to be able to model the RoomReservation in Elixir as:

defmodule Meetings.RoomReservation do
  use Ecto.Schema

  import Ecto.Changeset

  schema "room_reservations" do
    field :customer_id, :binary_id
    field :room_id, :binary_id
    field :reservation_starts_at, :utc_datetime
    field :reservation_ends_at, :utc_datetime
    field :status, :string
    timestamps()
  end

  def create(%{} = res_data) do
    %__MODULE__{}
    |> cast(res_data, [:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> validate_required([:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> put_change(:status, "hold")
    |> unique_constraint(:room_id, message: "has already been reserved")
    |> Meeting.Repo.insert()
  end
end

with the interesting bit being the |> unique_constraint(:room_id) line. When a customer tries to reserve a room that is already reserved for the given time period, we want the Meeting.RoomReservation.create/1 function to return with a validation error:

%{:error, %Ecto.Changeset{errors: [room_id: {"has already been reserved", _}]}} =
  Meetings.RoomReservation.create(%{
    customer_id: "0af5716a-c3d2-4d4c-87f5-9fed9b2515d4",
    room_id: "2c0d6242-3585-40cb-be92-a1818c0f4a73",
    reservation_starts_at: DateTime.from_naive!(~N[2020-01-01 8:00:00], "Etc/UTC"),
    reservation_ends_at: DateTime.from_naive!(~N[2020-01-01 17:00:00], "Etc/UTC")
  })

Clearly, according to the business rules for the system, we can't just put a unique index on the room_id column. To the best of my knowledge, an exclusion constraint also won't work here, because of the need to not check against any rows that have a status of "hold" and an inserted_at timestamp that is more than 24 hours ago relative to the current time. It is however possible to use a trigger function to enforce the constraint in the database:

defmodule Meetings.Repo.Migrations.CreateRoomReservations do
  use Ecto.Migration

  def change do
    create table(:room_reservations) do
      add :customer_id, :binary_id, null: false
      add :room_id, :binary_id, null: false
      add :reservation_starts_at, :timestamp, null: false
      add :reservation_ends_at, :timestamp, null: false
      add :status, :text, null: false, default: "hold"
      timestamps()
    end

    execute(
      # up
      ~S"""
      CREATE FUNCTION room_reservations_check_room_availability() RETURNS TRIGGER AS
      $$
      BEGIN
      IF EXISTS(
        SELECT 1
        FROM room_reservations rr
        WHERE rr.room_id = NEW.room_id
          AND tsrange(rr.reservation_starts_at, rr.reservation_ends_at, '[]') &&
              tsrange(NEW.reservation_starts_at, NEW.reservation_ends_at, '[]')
          AND (
            rr.status = 'confirmed'
              OR rr.inserted_at > CURRENT_TIMESTAMP - interval '24 hours'
          )
      )
      THEN
        RAISE "room already reserved";
      END IF;
      RETURN NEW;
      END;
      $$ language plpgsql;
      """,

      # down
      "DROP FUNCTION room_reservations_check_room_availability;"
    )

    execute(
      # up
      ~S"""
      CREATE TRIGGER room_reservations_room_availability_check
      BEFORE INSERT ON room_reservations
      FOR EACH ROW
      EXECUTE PROCEDURE room_reservations_check_room_availability();
      """,

      # down
      "DROP TRIGGER room_reservations_room_availability_check ON room_reservations;"
    )
  end
end

The problem is that instead of that nice validation error on the changeset that we want to get, we instead end up with an unhandled Postgrex.Error exception. We could, of course, simply rescue that exception in our Meetings.RoomReservation.create/1 function and add the error to the changeset ourselves, but that starts to look a little ugly:

defmodule Meetings.RoomReservation do
  # ...

  def create(%{} = res_data) do
    changeset =
      %__MODULE__{}
      |> cast(res_data, [:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
      |> validate_required([:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
      |> put_change(:status, "hold")
    Meeting.Repo.insert(changeset)
  rescue
    error in Postgrex.Error ->
      case error do
        %{postgres: %{message: "room already reserved"}} ->
          changeset
          |> add_error(:room_id, "has already been reserved")
      end
  end
end

TL;DR - It's All About the Raise

Knowing that Ecto.Changeset.unique_constraint/3 works by intercepting an error raised by the database, I set out to see if I could implement the complex unique constraint logic in the database and still be able to use the Ecto.Changeset.unique_constraint/3 validation without needing to modify any Elixir code. Looking at the relevant code in ecto_sql, we can see that the trick to getting the room_reservations_check_room_availability functionality to work with that function is to change the PostgreSQL exception to use the correct error code as well as a constraint name that is linked with the changeset validation. We can redifine the PostgreSQL function as:

CREATE FUNCTION room_reservations_check_room_availability() RETURNS TRIGGER AS
$$
BEGIN
IF EXISTS(
  SELECT 1
  FROM room_reservations rr
  WHERE rr.room_id = NEW.room_id
    AND tsrange(rr.reservation_starts_at, rr.reservation_ends_at, '[]') &&
        tsrange(NEW.reservation_starts_at, NEW.reservation_ends_at, '[]')
    AND (
      rr.status = 'confirmed'
        OR rr.inserted_at > CURRENT_TIMESTAMP - interval '24 hours'
    )
)
THEN
  RAISE unique_violation
    USING CONSTRAINT = 'room_reservations_room_reserved';
END IF;
RETURN NEW;
END;
$$ language plpgsql;

and then add the :name option to our unique_constraint in the changeset validation:

defmodule Meetings.RoomReservation do
  #...

  def create(%{} = res_data) do
    %__MODULE__{}
    |> cast(res_data, [:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> validate_required([:customer_id, :room_id, :reservation_starts_at, :reservation_ends_at])
    |> put_change(:status, "hold")
    |> unique_constraint(:room_id,
                         message: "has already been reserved",
                         name: "room_reservations_room_reserved")
    |> Meeting.Repo.insert()
  end
end

Inevitably, all things do come to an end, and I, along with many other very talented coworkers, was laid off a couple of weeks ago as my (now former) employer struggles to build enough runway to make a pivot into a new area of business. I have no complaints about the action: it was a clearly necessary move, and LivingSocial was very generous with a severance package for everyone affected. In fact, for the first time in my adult life, I have the opportunity to spend a considerable amount of time examining my life and making a considered decision about my next steps without needing to simultaneously worry about earning today's paycheck.

Because I needed to return to LivingSocial the company-provided laptop that I've been using for both work and personal computing for the last several years, one of the first things I did after finding out about the lay-off was to purchase a new laptop. I've been growing more-and-more frustrated with Apple's "walled-garden" approach to OS X lately, so I decided I'd revisit an old love, and ordered a laptop from System76, an Oryx Pro running Linux. For most things, I find the modern Linux desktop perfectly adequate, but there are two pieces of software that I rely upon heavily and have not yet found a suitable replacement: Quicken for personal finance management, and OmniFocus for managing my (rather expansive) to-do list.

It is while searching for a replacement for OmniFocus that I was turned on to the process that I'm going to share with you for figuring out what truly matters in your life and ensuring that you align the way you spend your time with the person whom you really want to be. I can't claim to have invented this method, but hopefully an example of how I've been applying it recently will inspire you to do the same and take charge of your life in a way that brings true clarity to everything you will do from here on out. If you live every moment intentionally, you can transform from a state of constant background-worries about whether you are missing something important into a state of relaxed-action where you can be confident that you are putting your energy into the right work while also remaining flexible enough to change direction as new events transpire.

A System for Intentional Living

In my search for a new task-management system that would work outside of Apple's walled-garden of OS X and iOS, one of the products I evaluated is a web application called FacileThings. This application provides an extremely railroaded implementation of the popular Getting Things Done methodology, which can be nice when you are a person (like me) who would otherwise be inclined to spend nearly as much time fiddling with the configuration of a task-management system as you would...well...actually getting things done. Ultimately, I decided not to use FacileThings, but only because I did not feel like it presented the tasks in a way that really helped me narrow my view down to "exactly what should I be working on right now?" (This is an area where the implementation of Perspectives in OmniFocus has really spoiled me, and I can't find any other system that does this well.)

The one feature in FacileThings that I found extremely useful, however, is the "Perspective" section (not the same use of the word as in OmniFocus). This section is what turned me on to the method I'm describing here via it's guided approach to walking the user through three fairly basic―but extremely effective―steps to help align your effort with the things that matter most to you:

1. Define your purpose
2. Describe your vision
3. Set your goals

Step 1: Define Your Purpose

The first question is, what is your purpose? In other words: why do you exist; what is your unique contribution to this world?

I've often thought about what it is I want to do with my career (I really enjoy the work of building and coaching high-functioning software development teams). I've certainly put thought into what is important to me in raising my children (I want them to be kind, independent adults who are ultimately content with their lives). I've thought about what I want to do with my personal time (I like to race bicycles, go backpacking, and travel). But this, honestly, is the first time I've been asked the question, "what is your purpose," in a way that caused me to step back and examine that question not in terms of how it applies to any one aspect of my life, but instead to find the true, underlying "thing" about which I am passionate across all areas of my life.

After some reflection, this is what I came up with for myself:

My passion is leading groups of people in collaborative efforts to improve the world around us—for ourselves, for future generations, and for other species—and to help develop other leaders who can effectively do the same.

The fundamentally important part of this "Purpose" is that it is immediately applicable to every single action that I might take. I want everything into which I put my effort to result in a tangible improvement to the world. Now, that doesn't mean I am constantly working on, say, "world peace" or "stop the polar ice caps from melting"; even actions as simple as "clean the kitchen", "pick up that piece of trash that someone left laying about", or "smile at the person whose path you cross on the sidewalk" meet this litmus test. The way it is stated, I've even allowed for actions that simply improve the world around me for me (because it's important to take care of yourself, too!)

"Leading," of course, means "doing" in a way that encourages and empowers others to do the same. In this sense, my purpose applies well to both my career and my family-life. As an individual-contributor to software projects, I want the work I do to exemplify software-craftsmanship. As an agile coach or team manager, I want to show people how an environment of respect and consensus can improve the quality of our product as well as our lives. As a parent, I want to demonstrate the kindness and stewardship of our world that I hope my children will exhibit as adults.

Furthermore, I want to help create more leaders who will also do these things. As a consultant or team-manager, it is not enough for me to engage with a team and lead them in my way of thinking without also developing the team's ability to continue and evolve after I am no longer involved. As a parent, I want my children to pass these ideas on to their children and their peers, so that society can benefit at a scale that I could never reach on my own.

So, what is your purpose? Take some time to reflect on it. Write it down somewhere! See if you can summarize it in just one or two sentences that you can apply as a test whenever you are unsure what direction to take with decisions big or small.

Importantly, while your purpose should be broad enough to cover all aspects of your life and so fundamental that it is unlikely to change, don't be afraid to change it! If, in a month, a year, or a decade you feel like your purpose statement no longer fits you, spend the time to reflect and write a new one that does. Nothing in this world will guarantee failure so much as forcing oneself to work against one's true purpose.

Step 2: Describe Your Vision

If you can visualize the whole of spring and see Paradise with the eye of belief, you may understand the utter majesty of everlasting Beauty. If you respond to that Beauty with the beauty of belief and worship, you will be a most beautiful creature. ―Said Nursi

Now that you understand your purpose, how does it shape the person that you will be in five to ten years? Take a moment, close your eyes, and visualize your life in the future. What do you see? What are you doing for a living? What kind of lifestyle do you lead? What is your family like?

When I think about what my life will look like five to ten years from now, here's what I see (more-or-less in order of importance to me):

• I am a parent of successful children. Our children are either currently or well on their way to becoming independent, young adults who are empowered to find their own successes and be content with their lives.

• I am prepared for the future. We are prepared for the future with a financial plan that puts us on the path to a long and enjoyable retirement and have ensured that there will not be disastrous financial or legal issues in the event of Amber's or my unexpected death or inability to work or live independently.

• I have a beautiful, well-maintained home. Our home is well-maintained, has enough space for everyone in the family, is nicely landscaped, and well-decorated. It is a place where we are comfortable living and where we are proud to entertain guests.

• I am a competitive masters cyclist. I am competitive within my age group and category as a racing cyclist and am on track to remain competitive until well-into my old age.

• I am a successful entrepreneur. I have built a successful consulting business with a solid base of customers and referral business that provides lasting financial security for my family and allows me to partially fulfill my purpose via my career.

• I am socially/politically involved. I actively take part in social, civic, and political activities that have a positive impact on the world around me.

There is no "correct" number of vision statements to have. Just try to describe what your life looks like to you. Check that each vision is in line with your purpose; if it doesn't directly contribute to your purpose, it must at least not be in conflict with your purpose. If it is in conflict, check that this is really your vision for your life and not someone else's vision for your life! You only get one shot at this life; be your own person.

Step 3: Set Your Goals

It's OK to have a plan, to invest in your future―for your financial security, your love life, your personal fulfillment, and even your happiness. To have personal happiness as a stated goal doesn't detract from it if you get there. ―Karen Finerman

It's no good seeing where you want to be without a plan to get there. Now that you've visualized the life you want to be living ten years from now, what concrete achievements can help get you there? By setting SMART goals to help realize your vision, you will have a tool to measure your progress towards it. While vision statements reflect the long term outcomes of your life, your goals should generally be things that are achievable within the next few years; they won't necessarily get you all the way to your vision, but they materially move you closer to it. Your goals should be even less set in stone than your vision. As you achieve some goals, and as other life-events occur, you will discover that your goals need to change as well. Never be afraid to change you plan as you get more information.

Important to the "R" (relevant) part of a SMART goal: make sure your goals are related to one (or more) of your vision statements. If you can't find a way to relate a stated goal to a vision, check whether you have a vision that you haven't made explicit and get it written down. If the goal really doesn't apply to your vision of your life, drop it now. This is where being explicit about your purpose and vision really pays off: living your life intentionally means not spending your limited time on things that are not important to you.

As of right now, here are my goals as they relate to each of my vision statements:

• I am a parent of successful children.

  • Children all have defined Purpose, Vision, Goals Just like me, each of our children will establish a habit of defining and reviewing their Purpose, Vision, and Goals, so that I can better help them. Timeframe: end of 2016

  • Children are Financially Responsible Each of our children will understand the basics of managing their finances, including using bank accounts, creating and following a budget, and earning money. Timeframe: end of 2018

  • Children have effective, well-established study/homework habits Children will have effective study and work habits that allow them to achieve their full potential in school. Timeframe: end of 2016/2017 school year

  • Take a family vacation each year While kids are still young, take the entire family on a week-long (or more) vacation each year to a different destination to expose them to different cultures and environments. Timeframe: by end of each year

• I am prepared for the future.

  • Have Investments to Fund Retirement Set up and understand investment accounts to fund our retirement. Timeframe: end of 2017

  • Pay off all debt other than mortgage Timeframe: end of 2020

  • Set up Proper Legal Documentation Ensure that appropriate legal documentation is in place in the event that Amber or I die. Timeframe: end of 2016

• I have a beautiful, well-maintained home.

  • Complete Home Remodel Have extensive remodeling work done on our home to provide enough bedrooms for everyone, update the kitchen, add a home-office and home-gym, and add a MiL suite/appartment. Timeframe: end of 2017

  • House is in a good state of repair The backlog of items needing repair (major and minor) has been cleared out, so that we can focus our attention on new issues as the arise. Timeframe: June 2017

• I am a competitive masters cyclist.

  • Upgrade to a Category 3 Road Racer Timeframe: end of 2018

• I am a successful entrepreneur.

  • Build a stable consulting business Create a business that will provide for our financial needs in the near term. Timeframe: end of 2016

• I am socially/politically involved.

  • Develop and Run Programming Course at FGCS Build on the work already done by Markus Roberts to develop and successfully run a full-year, introductory computer programming course for the students at FGCS. Timeframe: end of 2016/2017 school year

  • Hold a local public office Serve my community by being elected or appointed to and effectively running a local public office. Timeframe: end of 2020.

Living Each Moment with Intent

Now that you understand your purpose, have visualized your future, and have planned some concrete goals to help get you there, you have the tools you need to live intentionally. The next time you have a task on your plate, and you have that nagging feeling that you don't want to do it, think about how it relates to this hierarchy of goals, vision, and purpose. If it works against your purpose, drop it like a hot brick. Don't waste a moment of your precious time doing something that isn't you. Why would you put effort into making it harder to achieve your purpose in life?

If the task simply doesn't help you meet one of your established goals, consider if it is telling you there is another goal? To which of your visions does it relate? If there is another goal, write it down as such, but consider whether it's something that you should act on right now, or if this is something you should set aside for the future, once more immediate goals have been achieved. Maybe that nagging feeling is just telling you this isn't the right time.

If, after considering your purpose and your goals, the task at hand still doesn't relate to something you are trying to achieve, don't do it! If someone else is asking you to do it, explain to them why it isn't something you are going to spend time on. Perhaps they'll offer some additional perspective to show you how it fits with your goals, or perhaps you will simply have to insist they find someone else to take care of it. Remembering to say "no" to the activities that don't support your goals is the most powerful tool at your disposal to ensure you have the time and energy for the things that really matter to you.

This system has already provided me with a great deal of clarity in my day-to-day planning. Yes, there is still more I'd like to do than what I have time for in any given day, but by being able to quickly evaluate which of my goals any given task supports, I find that I am much better able to focus my attention on the task at hand, safe in the knowledge that it is the right thing on which for me to work at that moment.