Software development
-
Day 29: It's All The Same Problem
We’re twenty-nine days into this. I’ve thrown twenty-eight different time problems at you. Sundials, cesium fountains, leap seconds, Unix epochs, DST, lunar time, the Y2038 bug, calendar drift, time zones in Nepal. Twenty-eight posts. Twenty-eight things that should not be problems but are.
Today I want to tell you the thing I’ve been quietly noticing the whole series and never once called out by name.
They’re all the same problem.
Every single one. Same pattern, twenty-eight times, wearing twenty-eight different outfits. I’m going to name it today. Then I’m going to do something annoying with the schedule, which I’ll get to at the end.
Speed recap (skip if you’ve been reading along)
Week 1, what time is. Philosophers spent a century arguing about whether the present is real or whether all moments coexist. Einstein answered them. Your brain disagrees with both. Your “now” is a two-second hallucination your prefrontal cortex glues together from inputs that arrived at different speeds. Most animals don’t even live on the same scale of now you do.
Week 2, how we measure it. Sundials to water clocks to pendulums to cesium fountains to optical lattice clocks. We measure time to a part in 10^18, the most precise measurement humanity makes of anything. And then we strap leap seconds onto it.
Week 3, how computers handle it. Unix time pretends leap seconds don’t exist. NTP synchronizes the internet to within a millisecond of UTC, mostly because one guy at the University of Delaware refused to let it die. ISO 8601 prevented an entire generation of date-format wars. Time zones aren’t 24, they’re 38 and counting, and at least one sits at +5:45 for reasons.
Week 4, the cracks. Leap seconds crashed Reddit and Cloudflare. DST kills people, measurably, twice a year. Calendars are 2,000 years of patches on patches. The World Calendar almost passed the UN in 1955 and got killed by religious objections. The Hanke-Henry proposal solves the religious problem and has no political mechanism.
Week 5, the punch line. Einstein made “now” frame-dependent. Atomic time and astronomical time have been quietly drifting apart since 1972. Clocks on the Moon run 58 microseconds per day faster than clocks on Earth, and the White House gave NASA a 2026 deadline to figure out what to do about it. Mars’s day is the wrong length, and the people running rovers there go nocturnal in shifts.
Twenty-eight different stories. Each one feels like its own little disaster. Each one is its own little disaster.
OK. Now look at all of them at once.
A pattern emerges
Every single one is the same shape.
Too many time systems pretending to be one.
That’s it. That’s the diagnosis. Let me run it back.
- Wall clock time pretends to be solar time. It isn’t. It’s solar time, offset up to an hour by your time zone, then offset another hour by DST. Three systems. Presented as one.
- UTC pretends to be a uniform atomic timescale. It isn’t. It’s atomic seconds with manual leap-second patches jammed in whenever the Earth misbehaves. Two systems. Presented as one.
- Unix time pretends to be UTC. It isn’t. It’s atomic seconds with the leap seconds quietly deleted. Two systems. Presented as one, with the inconvenient one erased.
- The Gregorian calendar pretends to track the seasons. It almost does. The seasons drift against it at 26 seconds a year. Two systems. Presented as one.
- Earth civil time pretends to be the universal frame. It isn’t. The moment people start living on the Moon it won’t even pretend. Two systems. Presented as one. Third one inbound.
Every outage we’ve documented in this series is what happens when the layers diverge.
The 2012 Linux meltdown was the atomic layer screaming at the civil layer through the leap-second seam. DST mortality is the social layer dragging the biological layer somewhere it doesn’t want to go. Y2038 is the storage layer running out of room to lie about the coordination layer. The 2019 Brazilian DST cancellation broke every calendar event saved in local time, because the saved-time layer disagreed with the rule layer.
It’s the same bug everytime, just dressed up in a different costume.
They’re all just one problem we keep meeting, just at different layers.
What the shape of a fix looks like
I’m not telling you the full answer today. But the shape of it appears when you can see the pattern. The key is to stop letting the layers pretend to be each other.
That’s the whole design I laid out yesterday: one coordination layer underneath, atomic, uniform, no leaps, no zones, no calendars baked in, the thing computers and GPS and finance and navigation already run on, with known relativistic offsets if you leave Earth. Then a thin civil layer on top for humans: local, day-night aware, with the calendar and zones living up here as display only. The civil layer is computed from the coordination layer plus your local context. It’s never stored as the source of truth.
The whole point is that the layers don’t pretend to be each other. The coordination layer doesn’t pretend to track the sun. The civil layer doesn’t pretend to be a database timestamp. When two layers disagree, only the display changes. The stored truth is invariant.
Some flags I’m planting
Before someone accuses me of refusing to commit, three things I’ll say flat out.
Time zones are stupid. Not “annoying.” Not “a useful tradeoff.” Stupid. Thirty-eight of them. One sits at +5:45 because someone wanted to be 15 minutes off from India. Half of Australia runs on a different schedule than the other half. Indiana spent decades arguing with itself about which zone to be in. China is one country and one time zone across five solar hours. The whole point of a time zone is supposed to be “the sun is roughly overhead at noon.” We’re not honoring that contract anywhere. Some American zones put solar noon as late as 1:30 PM in summer. We’re paying the entire complexity cost of having zones and not actually getting the thing zones were invented to do. Time zones are a 19th-century can we’ll keep kicking well into the 21st.
DST is dumb. Day 21 was the whole case. Heart attacks, strokes, car crashes, a 1% increase in residential electricity use, no farmers asking for it, no voters asking for it, no science defending it. We do it because two camps in Congress can’t agree on which fake time to settle on. Not relitigating. Just doubling down.
UTC is on “borrowed time” and it knows it. UTC the protocol is fine. UTC the way it shows up in your daily life has time zones bolted on through the “+5” notation, has DST schedules layered on top, and (currently) has leap seconds duct-taped in whenever the Earth misbehaves. UTC itself is a leaky abstraction. It tries to be the coordination layer and the civil layer at the same time, and the cracks have already begun to appear. Abolishing the leap second was UTC quietly admitting it can’t be both, and after 2035 the civil-display half of its job becomes somebody else’s problem.
Now the things I’m not claiming.
I’m not claiming any one proposed solution is right. Decimal time failed. Swatch Internet Time failed. The World Calendar failed. Hanke-Henry probably won’t pass. The path forward, whatever it ends up being, has to be designed with those failures in mind. Top-down reform fails. Branded reform fails. The thing that has actually worked, where anything has worked at all, is open standards adopted gradually by institutions that found them useful. The way ISO 8601 became universal without anyone forcing it on anybody.
And I’m not claiming this is a five-alarm fire. The system mostly works. The bugs are real but tolerable. Civilization will not collapse if we don’t fix this.
But it was built for an Earth-bound, slower, less precise world, and it’s being asked to do things it was never designed for.
Lunar Coordinated Time is due by the end of 2026. The system that mostly works is going to be asked to do more, and we are going to need a better one.
Tomorrow
OK, first, I need to apologize.
Day 30 would normally land tomorrow. That’s where you would typically end a series called “30 Days of Time”. But tomorrow I’m going to break that promise on purpose, and here’s why.
I’ve been working on something while writing this series. The whole reason this synthesis exists is that this pattern is the thing I’ve been trying to design a solution for. I have a draft of an answer. I have a reference implementation. What I don’t have is anything finalized that I can actually point you toward.
I’d rather get it right than ship Day 30 tomorrow with a half baked idea. I want the Day 30 payoff to be a well thought-out draft of a unified time standard, not a rushed sketch. I don’t know how long that takes. Probably a couple of weeks but maybe longer.
So Day 30 is coming, I promise. No specific date. When it lands, it’ll come with something formalized that’s actually worth pointing you at.
Thank you for sticking with me for twenty-nine days. Day 30 won’t be a manifesto. It’ll be informative, but it will also be a call to action.
So, the most important post in the series is NOT the one I’m not going to publish tomorrow.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
Day 16: How the World Agreed on a Date Format (Except the US)
There is a war that has been quietly raging for about a century, and it is fought over six little characters.
05/06/26In the United States, that is May 6, 2026. In most of Europe, it is June 5, 2026. In Japan, which uses a year-month-day order and frequently uses the imperial calendar, the
05might be read as year 5 of the Reiwa era (2023). In Iran, the entire premise is wrong, because Iran’s official calendar is the Solar Hijri and the current year is 1405.So here we are. A date written by one person and parsed by another is, in the general case, an act of faith.
The most consequential standards effort of the late 20th century was an attempt to end this. It succeeded, sort of. The format it produced,
2026-06-08T14:30:00Z, looks unremarkable now, but it represents a multi-decade campaign to drag the world’s date conventions into a single, unambiguous, machine-parseable shape.That standard is ISO 8601, and the story of how it won is the story of why your API logs look the way they do.
What’s actually wrong with
05/06/26Let me give you the tick of the tock (lay of the land). Every culture has a different intuition about which number comes first in a date, and none of them is wrong.
In the United States, the convention is month-day-year. This descends from spoken American English, “May sixth, twenty-twenty-six,” where the month comes first in speech.
In most of Europe, Latin America, and much of Asia, the convention is day-month-year. “The fifth of June, twenty-twenty-six.” The day is the first specific element.
In East Asia, the convention is year-month-day, written largest-unit-first. This reflects a linguistic preference for going general-to-specific that runs the opposite direction of the English phrasing.
Who is to say which is more correct than another? The problem is that a single string of digits separated by slashes can mean three different things depending on who wrote it, and there is no way other way to tell.
When the ambiguity bites
It’s not just an annoyance.
International travel figured this out the hard way. Across global passport documentation, the convention settled on a three-letter month abbreviation:
08 JUN 2026. It’s unambiguous because no month is named06. The international passport standard (ICAO Doc 9303) mandatesJANthroughDECfor exactly this purpose.In healthcare, patient safety organizations have flagged date ambiguity as a documented source of medication error: a chart that says
7/8/09can be read as July 8 by one clinician and August 7 by another.The shape of the problem is the same across medicine, aviation, logistics, contracts, and customs declarations. Different conventions lead to confusion and errors.
The standard
In 1988, ISO published
ISO 8601:1988. Pick one format, make it unambiguous, make it sort lexicographically, make it machine-parseable, and standardize the world on it.The format they picked:
2026-06-08T14:30:00ZThe choice of
YYYY-MM-DDwas deliberate. Year-month-day is the East Asian convention, but it has a technical property that the other two don’t: it sorts correctly as a string.2025-12-31comes before2026-01-01whether you sort by character or by number.12/31/25and01/01/26do not. For the emerging computing industry of the late 1980s, databases, log files, file systems, this was a decisive advantage.The capital
Tseparates the date from the time. Not pretty, but unambiguous. The trailingZ(informally pronounced “Zulu”) means UTC. This timestamp has no timezone offset, it is anchored directly to UTC.What actually use: RFC 3339
ISO 8601 is too permissive for engineering use.
It allows fractional seconds. It allows omitting components. It allows the basic form (
20260608T143000Z) without separators. It allows week dates and ordinal dates. It allows24:00:00as midnight (this was removed in 2019, then reinstated by amendment, in one of those standards-committee compromises that satisfies no one).So in 2002, the IETF published
RFC 3339. RFC 3339 is a profile of ISO 8601, a strict subset that picks one form and forbids the rest. The basic form is disallowed. Week dates are disallowed. The time component is mandatory. The timezone designator is mandatory.This is what every modern internet API actually uses. GitHub, AWS, Stripe, Cloudflare, OpenAI. They accept RFC 3339, not full ISO 8601. They reject
20260608T143000Zeven though it’s legal ISO 8601.What everyone calls “ISO 8601” in casual conversation is, almost always, RFC 3339.
What ISO 8601 isn’t
A few things worth being clear about:
- ISO 8601 is not UTC. UTC is a timescale. ISO 8601 is a format.
- ISO 8601 is not Unix time. Unix time is the integer
1781055000. ISO 8601 is the string2026-06-08T14:30:00Z. They can represent the same instant. They are not the same thing. - ISO 8601 does not solve leap seconds. The format permits
:60in the seconds field, but what to do with such a value is implementation-defined. - ISO 8601 does not include the calendar system. It assumes the Gregorian calendar. No provision for Islamic, Hebrew, or Buddhist calendars.
The civilizational payoff
There is a sense in which
2026-06-08T14:30:00Zis the most consequential string format in modern computing.While legacy systems still cling to their own formats—HTTP headers use RFC 1123, Git and JWTs use integer Unix timestamps, and X.509 certificates use ASN.1—RFC 3339 has conquered the modern web. It is the default serialization for datetime objects in modern programming languages. It appears in the JSON payloads of almost every modern API (GitHub, Stripe, AWS, OpenAI). It is the standard format for XML’s
xs:dateTime. It is written into millions of cloud infrastructure log lines every second.It is the closest thing modern technical infrastructure has to a universal vocabulary for the question “when did this happen?"
It won because it was unambiguous and sortable, and a single committee was willing to pick one of three equally valid cultural conventions and tell the other two cultures to deal with it. Most international standards die in the negotiation. ISO 8601 survived because the technical advantages of
YYYY-MM-DDwere strong enough to overwhelm the political cost.Us Americans haven’t adopted it (yet). We still write
06/08/2026on bank checks, forms and filings, but the machines we all use are on 8601 and they are doing most of the talking.
Sources
- Japanese era name — Wikipedia — Reiwa began 1 May 2019; Reiwa 5 = 2023.
- Solar Hijri calendar — Wikipedia — year 1405 began 21 March 2026, ends 21 March 2027.
- ISO 8601 — Wikipedia — first published 1988; ISO 8601-1:2019 removed
24:00; the 2022 amendment reinstated it. - ISO 8601-1:2019/Amd 1:2022 — the amendment that put
24:00:00back. - RFC 3339 — Date and Time on the Internet: Timestamps — IETF, July 2002. Profile of ISO 8601 used by most modern APIs.
- RFC 3339 vs ISO 8601 — visual map of which forms each standard accepts; basic form (
20260608T143000Z) is valid ISO 8601 but not RFC 3339. - Machine-readable passport (ICAO Doc 9303) — Wikipedia — ICAO standard requiring three-letter month abbreviations (
DD MMM YYYY) in the visual inspection zone of all passports. - ISMP List of Error-Prone Abbreviations — highlights the risk of ambiguous documentation and dates in medical records.
- RFC 1123 — Requirements for Internet Hosts — specifies the required date format for HTTP Date headers.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
Tomorrow: Unix time, the second-counting system that runs under every timestamp you’ve ever seen, and the rollover problem that hits in 2038.
Programming Software development 30daysoftime Standards Iso8601
-
AI Code Reviewers Won't Save You
Dropping an AI reviewer into your pull request pipeline is just a band-aid. Tools like CodeRabbit or Greptile are great for catching syntax errors or basic anti-patterns, but they can’t assess architectural intent or domain-specific business logic. They’re spell-checkers for code. Useful, sure. But nobody ever said “our codebase is solid because we run spell check.”
AI doesn’t change your engineering baseline. It just accelerates it. If your foundational guardrails are weak, agentic tools will help your team generate technical debt at unprecedented speeds. So the real question isn’t “how do we review AI code?” It’s “how do we build systems that prevent slop from ever reaching production?”
Shift Left, Hard
When engineers use agents to scaffold a new Go service or spin up a SvelteKit frontend, they’re inevitably pulling in generated dependencies or utilizing unfamiliar libraries. Models hallucinate packages. They suggest insecure patterns with total confidence.
Your CI pipeline needs to be ruthless before a human ever looks at the code. Aggressive SAST and SCA should automatically block PRs that introduce vulnerable dependencies or hardcoded secrets. If the agent generates slop, the pipeline rejects it instantly. No discussion.
Make the Agents Write the Tests
Agents are incredibly eager to generate feature code, but humans are historically lazy about writing the tests for it. The influx of AI-generated code means human reviewers can’t possibly step through every logic branch manually.
So flip the script. Use the agentic tools to build the guardrails themselves. Mandate that any generated feature code must be accompanied by generated, human-verified unit tests. If an agent writes a sprawling TypeScript function, the build should fail if the test coverage doesn’t meet a strict threshold. You’re already using AI to write the code. Use it to prove the code works, too.
Context Boundaries Matter
Bloated AI output often happens because the model is given too much context or allowed to generate too much at once. Heavyweight IDEs with aggressive multi-file auto-completion can easily create cascading messes across a codebase.
Define strict architectural boundaries and API contracts upfront. Agents should be tasked with solving small, well-defined, modular problems. “Write a function that parses this specific JSON schema” is a good prompt. “Build the backend” is not. The tighter the scope, the less room for generated nonsense.
Observability Is Your Safety Net
You can’t catch all generated slop at the PR level. Some of it only reveals itself under load. An agent might write a technically correct query that causes an N+1 database issue, or introduce a subtle memory leak that passes all unit tests.
Your ultimate safety net is what happens at runtime. You need an airtight observability stack to trust the velocity AI brings. Logs, distributed tracing, metrics, all feeding into dashboards your team actually watches. When generated code hits staging, you need the immediate telemetry to spot performance regressions before they reach production.
Redefine the Human Review
Because AI makes the “typing” part of coding trivial, the human code review needs to fundamentally shift. Reviewers should no longer be looking for missing semicolons. They should be asking: “Does this component fit our architecture?” and “Did the agent over-engineer this solution?”
Train your senior engineers to review for intent and systemic impact. That’s the stuff AI genuinely can’t do yet. Leave the syntax checking to the robots.
I’d appreciate a follow. You can subscribe with your email below. The emails go out once a week, or you can find me on Mastodon at @[email protected].
-
Your AI Agent Needs a Task Manager
If you’ve spent time working with AI coding tools, you’ve probably hit the compaction wall. Suddenly, your agent knows what it’s currently working on but has completely forgotten the five other things connected to it.
This is the memory problem, and it’s a big one.
The Context Window Isn’t Enough
Your AI agent needs some sort of memory system that lives outside the context window. When you’re working on simple, one-off tasks, the chat-as-workspace approach works fine. You ask a question, you get an answer, you move on. But the moment you’re tackling a complex set of related tasks? It breaks down fast.
I’ve been thinking about this through the lens of a framework I’m calling the Agentic Maturity Model. The short version is that there are distinct levels to how teams and developers use AI agents, and moving between levels isn’t about using “better” tools, but rather it’s a shift in how you approach the work.
Four months ago, there were no real options. The good news? It seems like all the model providers recognize this is the next frontier. Memory and persistence are where I’m looking for the actual progress to happen next.
Claude Code has certainly gotten better in these areas over the last couple of months. They’ve added an auto memory feature in beta. They added a lightweight Tasks system based on a Todo system called Beads built by Steve Yegge. His key idea was that the task state should live outside the context window.
These are meaningful building blocks towards an actual working memory system that persists across sessions and survives compaction.
We’re Almost There
The tooling and harneses we built on top of the LLMs are already changing how software gets built, but where we are headed? Here is what I think:
- auto-improving memory: where the agent learns your patterns, your codebase, your preferences
- persistent task tracking that survives compaction: Tasks, todos, issues, whatever you want to call them. The point is they exist outside the conversation.
When those two pieces come together properly, the workflow for everyone will change again.
Your agent doesn’t just respond to the current prompt. It knows where it is in a larger plan, what’s been done, what’s blocked, and what’s next. That’s the difference between a helpful chatbot and an actual collaborator.
We are so close I can taste the blood in the water, oh wait, that’s mine. ☠️
-
Why Testing Matters
There is a fundamental misunderstanding about testing in software development. The dirty and not-so-secret, secret, in software development is TESTING is more often than not seen as something that we do after the fact, despite the best efforts from the TDD and BDD crowd.
So why is that the case and why does TESTING matter?
All questions about software decisions lead to a maintainability answer.
If you write software that is intended to be used, and I don’t care how you write it, what language, what framework or what your background is; it should be tested or it should be deleted/archived.
That sounds harsh but it’s the truth.
If you intended to run the software beyond the moment you built it, then it needs to be maintained. It could be used by someone else, or even by you at a later date, it doesn’t matter. Test it.
if software.intended_to_run > once: testing = requiredThat’s just the reality of the craft. Here is why.
Testing Is Showing Your Work
Remember proofs in math class? Testing is the software equivalent. It’s how you show your work. It’s how you demonstrate that the thing you built actually does what you say it does, and will keep doing it tomorrow.
Chances are your project has dependencies. What happens to those dependencies a month from now? Five years from now? A decade?
Code gets updated. Libraries evolve. APIs change. Testing makes sure that those future dependency updates aren’t going to cause regression issues in your application.
It’s a bet against future problems. If I write tests now, I reduce the time I spend debugging later. That’s not idealism, it’s just math.
T = Σ(B · D) - CWhere B = probability of bug, D = debug time, C = cost of writing tests and T is time saved.
Protecting Your Team’s Work
If you’re working on a team at the ole' day job, you want to make sure that the code other people are adding isn’t breaking the stuff you’re working on or the stuff you worked on six months ago, add tests.
Tests give you that safety net. They’re the contract that says “this thing works, and if someone changes it in a way that breaks it, we’ll know immediately.”
Without tests, you’re essentially hoping for the best and hope isn’t good bet when it comes to the future of a software based business.
Your Customers Are Not Your QA Team
Auto-deploying to production without any testing or verification process? That’s just crazy. You shouldn’t be implicitly or explicitly asking your customers to test your software. It’s not their responsibility. It’s yours.
Your job is to produce software that’s as bug-free as possible. Software that people can rely on. Reliable, maintainable software, that’s what you owe the people using what you build.
Bringing Testing to the Table
Look, I get it. Writing tests isn’t the most fun part of the job. However, a lot has changed in the past couple of years. You might have heard about this whole AI thing? With the Agents we all have available to us, we can add tests with as little as 5 words.
“Write tests on new code.”
Looking back at that forumla for C, we can now see that the cost of writing tests is quickly approaching zero. It just takes a bit of time for the tests to be written, it just takes a bit of time to verify the tests the Agent added are useful.
Don’t worry about doing everything at the start and setup a full CI pipeline to run the tests. Just start with the 5 words and add the complicated bits later.
No excuses, just testing.
-
Why Data Modeling Matters When Building with AI
If you’ve started building software recently, especially if you’re leaning heavily on AI tools to help you code—here’s something that might not be obvious: data modeling matters more now than ever.
AI is remarkably good at getting the local stuff right. Functions work. Logic flows. Tests pass. But when it comes to understanding the global architecture of your application? That’s where things get shaky.
Without a clear data model guiding the process, you’re essentially letting the AI do whatever it thinks is best. And what the AI thinks is best isn’t always what’s best for your codebase six months from now.
The Flag Problem
When you don’t nail down your data structure upfront, AI tools tend to reach for flags to represent state. You end up with columns like
is_draft,is_published,is_deleted, all stored as separate boolean fields.This seems fine at first. But add a few more flags, and suddenly you’ve got rows where
is_draft = trueANDis_published = trueANDis_deleted = true.That’s an impossible state. Your code can’t handle it because it shouldn’t exist.
Instead of multiple flags, use an enum:
status: draft | published | deleted. One field. Clear states. No contradictions.This is just one example of why data modeling early can save you from drowning in technical debt later.
Representation, Storage, and Retrieval
If data modeling is about the shape of your data, data structures determine how efficiently you represent, store, and retrieve it.
This matters because once you’ve got a lot of data, migrating from one structure to another, or switching database engines—becomes genuinely painful.
When you’re designing a system, think about its lifetime.
- How much data will you store monthly? Yearly?
- How often do you need to retrieve it?
- Does recent data need to be prioritized over historical data?
- Will you use caches or queues for intermediate storage?
Where AI Takes Shortcuts
AI agents inherit our bad habits. Lists and arrays are everywhere in their training data, so they default to using them even when a set, hash map, or dictionary would perform dramatically better.
In TypeScript, I see another pattern constantly: when the AI hits type errors, it makes everything optional.
Problem solved, right? Except now your code is riddled with null checks and edge cases that shouldn’t exist.
Then there’s the object-oriented problems. When building software that should use proper OOP patterns, AI often takes shortcuts in how it represents data. Those shortcuts feel fine in the moment but create maintenance nightmares down the road.
The Prop Drilling Epidemic
LLM providers have optimized their agents to be nimble, managing context windows so they can stay productive. That’s a good thing. But that nimbleness means the agents don’t always understand the full structure of your code.
In TypeScript projects, this leads to prop drilling: passing the entire global application object down through nested components.
Everything becomes tightly coupled. When you need to change the structure of an object, it’s like dropping a pebble in a pond. The ripples spread everywhere.
You change one thing, and suddenly you’re fixing a hundred other places that all expected the old structure.
The Takeaway
If you’re building with AI, invest time in data modeling before you start coding. Define your data structures. Think about how your data will grow and how you’ll access it.
The AI can help you build fast. But you still need to provide the architectural vision. That’s not something you can blindly trust the AI to handle, not yet, anyway.