Building a Photographer’s Guide with LLMs

I was planning a photography trip to Bosque del Apache National Wildlife Refuge and started doing what I usually do before a serious shoot: collecting notes on timing, light, locations, gear, access rules, bird behavior, and logistics. At first, the question was fairly practical: could I use LLMs to help plan a better travel experience? But as the research accumulated, the project became more interesting. It was no longer just about preparing for my own trip. It evolved into a reusable photography planning guide for Bosque del Apache, and a useful case study in how LLMs can support more of the product workflow than simply generating text.

The finished guide is here: Bosque del Apache Photo Plan. On the surface, the finished artifact is a travel guide for photographers. But that is not the part I found most interesting.

The more interesting part was the process of turning a messy set of inputs into a usable digital product: research notes, field assumptions, refuge rules, source links, lodging tradeoffs, gear considerations, bird behavior, weather constraints, image rights, itinerary ideas, and photographic intent.

That is a very familiar product problem.

Most product work does not start with clarity. It starts with fragments: user needs, goals, edge cases, constraints, data quality issues, design options, technical feasibility, trust concerns, and a rough idea of the experience you want to create. The work is not just to assemble the pieces. The work is to decide what the thing is supposed to do.

The obvious version of the project would have been generic: go to New Mexico in winter, photograph sandhill cranes and snow geese, bring a long lens, get up early.

That would have been accurate enough, but not useful enough.

A serious wildlife photographer planning a dedicated trip needs a different kind of artifact. They need to know when to arrive before sunrise. They need to think about wind direction, landing behavior, changing light, and whether a lens might be too tight for a snow goose blast-off. They need to understand what to practice before leaving home, which access rules matter, what should be rechecked close to travel, and where assumptions are being made.

So the first product decision was about audience.

The guide was for photographers planning a serious Bosque del Apache trip. Once the audience was identified, it helped shape the rest of the project.

It shaped the information architecture. The guide became organized around field decisions: where to go, when to go, what to bring, what to practice, what rules matter, what images to prepare for, and what logistics to verify before departure.

It shaped the level of detail. For a casual visitor, “bring a camera” may be enough. For a wildlife photographer, gear is not a packing list. It is a field strategy. Lens range, autofocus behavior, exposure discipline, vehicle positioning, panning practice, and low-light readiness all matter because they affect whether the photographer can make the image when the moment happens.

It also shaped the trust model. Not all information in a guide should be treated the same way. Some facts are stable. Some are operational and need to be verified close to travel. Some are reasonable assumptions based on field patterns. Some belong on the page. Some belong in a source trail. Some should only be linked because reuse rights are unclear.

The Hardest Visual Decision: Illustration Versus Evidence

The most sensitive product decision was visual. A good travel guide benefits from photography. Readers want to see the place. They want to understand the landscape, the light, the bird behavior, the scale of the scene, and the kinds of images they might be able to make.

But I had not been to Bosque del Apache yet. I did not have my own field photographs from the refuge. That created a real product and editorial problem.

One option was to rely entirely on external photography. That sounds simple, but it is not. Image rights are complicated. Public-domain images can be useful, but they may not cover the exact planning scenarios I wanted to explain. Licensed images can solve some problems, but they add cost and usage constraints. Linked images can provide reference value, but they do not always support the structure of the guide. And using someone else’s photograph to illustrate a planning concept can blur the line between inspiration, documentation, and endorsement.

So I used LLMs and image-generation tools to create photorealistic planning illustrations for parts of the guide. That choice only works if the boundary is explicit.

The generated visuals are not documentary photographs. They are not evidence that I stood in a specific location at sunrise and captured a specific scene. They are not proof of current refuge conditions, bird density, habitat state, weather, access, or what a photographer is guaranteed to see. Their role is narrower: they are planning illustrations.

They help communicate the kinds of situations a photographer might prepare for: cranes in low morning light, snow geese in chaotic motion, backlit silhouettes, wider environmental compositions, long-lens behavior, exposure challenges with white birds, and the visual rhythm of a winter wildlife refuge. Their purpose is to support preparation, not to document a trip that has already happened.

That distinction is small in wording, but large in trust.

Calling something a “photo” invites one set of assumptions. Calling it an “AI-generated planning illustration” invites another. The reader should never have to guess which one they are looking at.

This is where the moral question becomes more important than the technical one.

The technical question is whether we can generate realistic images.

The moral question is what the reader believes those images represent.

A field photograph carries a claim: someone was there, under real conditions, making real decisions with a camera. A synthetic image does not carry the same claim. It may be useful. It may be visually effective. It may be directionally accurate. But it is not evidence.

So the responsibility is not just to disclose that AI was used. The responsibility is to define the job the AI-generated image is doing.

For this guide, my standard was simple: label synthetic visuals clearly, use them to explain planning concepts, avoid imitating a specific photographer’s work, avoid presenting generated images as observed field conditions, and do not use them where documentary photography is the point.

There are legal and publishing implications here as well. The U.S. Copyright Office has taken the position that copyright protection depends on human authorship, and its 2025 AI copyrightability report says generative AI outputs may be protected only where there is sufficient human expressive contribution, not merely because someone supplied prompts. That makes synthetic imagery different from ordinary original photography when thinking about ownership, licensing, reuse, and downstream publication rights.

There are also broader trust and disclosure issues. The FTC has brought enforcement actions around deceptive AI-related claims, and C2PA is developing an open technical standard for media provenance and Content Credentials. Those efforts point in the same direction: as synthetic media becomes more realistic, transparency becomes part of the product experience, not just a footnote.

That is where I think publishing is headed.

Many digital artifacts will combine original work, licensed material, public-domain sources, generated media, structured research, and interactive tools. The question will not simply be whether AI was used. That question is becoming too broad to be meaningful.

The better questions are more specific.

• What was generated?
• What was observed?
• What was sourced?
• What was edited?
• What is being claimed?
• What can the reader verify?
• What should the reader not infer?

For photographers, this distinction will be especially important. AI-generated images may be useful for planning, storyboarding, education, pre-visualization, and explaining technique. But they do not replace the experience of being in the field, reading the light, responding to animal behavior, and making an image under real constraints.

Working on this guide made me more aware of the value of real photography, not less. The generated visuals helped explain the trip I was planning. They did not give me the trip. They did not give me the field experience. They did not give me the images I hope to make when I actually go.

Use AI-generated visuals when they help the reader understand, prepare, or imagine. Disclose them clearly. Do not let them masquerade as documentary evidence. And when the real work is to go into the field and make the photograph, go into the field and make the photograph.

AI-assisted work can make it much faster to research, synthesize, draft, structure, code, revise, and generate alternatives. That is real leverage. But the visual decisions in this project reinforced the larger lesson: speed does not eliminate the need for product judgment. In many ways, it makes that judgment more visible.

The hard part was deciding what deserved to exist in the final experience.

• What belongs on the page?
• What should be summarized?
• What should be linked externally?
• What needs a date check?
• What is a durable photography technique versus a current operational fact?
• What visual material can be used directly, what needs attribution, and what should be treated only as planning inspiration?
• What helps the reader make a better decision, and what only makes the page feel more complete?

Those are product questions. They are also editorial questions. And increasingly, they are AI workflow questions. This is where the project became more than a guide. It became a small case study in using LLMs across different parts of the product workflow.

I used AI not as a single “write the page” step, but as part of an iterative loop: research synthesis, audience framing, information architecture, content drafting, source organization, visual direction, implementation, review, and refinement.

Each step required a different mode of collaboration.

• For research, the value was breadth and synthesis. The system could help organize a large amount of material into themes, identify gaps, and turn scattered notes into a more coherent planning model.
• For product definition, the value was pressure testing. What is the guide actually for? What does the user need before the trip? What decisions are they trying to make? Where would a generic travel guide fail them?
• For information architecture, the value was iteration. Different structures could be explored quickly. The final navigation was not just a set of labels. It was a declaration of what the product considered important.
• For content, the value was acceleration, not delegation. Drafts are easy. Useful drafts are harder. The difference came from repeatedly pushing the material back toward field utility, reader trust, and photographic specificity.
• For implementation, the value was speed through the mechanical parts of building. But the product still needed review: layout, hierarchy, images, language, redundancy, missing context, and whether the page worked as a coherent experience rather than a collection of generated sections.
• For QA, the value was surfacing problems. Some rounds of review were not about adding more content. They were about removing confusion, combining overlapping sections, replacing weak visual treatments, clarifying assumptions, cleaning up language that sounded too internal, and making sure the final guide did not expose the scaffolding used to create it.

A finished product is not the prompt history.

• It is not a research dump.
• It is not a bundle of generated assets.
• It is not a transcript of how the work happened.

The final artifact has to stand on its own. It has to be navigable, coherent, accurate enough for its use case, and useful to someone who does not care how it was made.

That is an important distinction for AI-assisted publishing and AI-assisted product development more broadly.

The novelty is not that a model can generate text. We are past that point. The more useful question is whether LLMs can help an individual or a small team move through more of the product workflow with greater speed and quality.

• Can they help clarify the audience?
• Can they turn research into structure?
• Can they expose missing assumptions?
• Can they generate useful variants?
• Can they help build the artifact?
• Can they support review?
• Can they make the operator more ambitious about what is possible to create?

My experience with the Bosque guide is that the answer is yes, but with an important condition: the human has to keep making the product decisions.

The LLM can help produce options. It can help compress the distance between idea and prototype. It can help turn vague intent into something testable. It can help with the middle of the work, where many projects usually stall.

But it does not know what “good” means unless you define it.

In this project, “good” did not mean comprehensive. It meant useful before a real photography trip.

It meant the guide had to help a photographer make better field decisions.

It meant the page needed enough specificity to be valuable, but enough humility to avoid false precision. A five-day itinerary can suggest a planning rhythm, but it should not pretend to know exactly where the best action will happen on a specific morning. Gear recommendations can be practical, but they should acknowledge uncertainty when the final camera system is not fixed. Lodging guidance can be helpful, but prices, policies, and availability need recheck gates. Refuge rules and access conditions need source discipline because they can change.

That is the difference between content and product.

Content can answer a question. A product has to support a user through a decision.

The more I use LLMs in this kind of workflow, the more convinced I am that the advantage will not come from generating the most material. It will come from turning messy inputs into trusted, structured, usable artifacts.

That applies well beyond travel guides. The same pattern shows up in dashboards, internal tools, customer-facing experiences, research summaries, decision systems, visual essays, prototypes, and playbooks. The workflow is becoming more fluid. An idea can move from notes to structure to working artifact much faster than before.

But faster does not mean easier in every dimension. Less time is spent on blank-page production. More time is spent on intent, judgment, structure, evaluation, and trust.

The Bosque del Apache guide started as a personal photography planning project. It became a useful reminder of how product work changes when LLMs are part of the process.

The future of AI-assisted publishing is not “the machine writes the page.”

It is a tighter operating loop between intent, research, product judgment, editorial structure, visual direction, implementation, review, and release.

The work gets faster.

The judgment does not get optional.

If anything, the judgment becomes the most important part.

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.