• Organizing Data Instead of Just Storing It
• Arrays: Ordered Collections
• Learning That Arrays Have Types
• Sorting and Reversing
• Dictionaries: Looking Up Information
• Sets: Unique Values Only
• Enums: Fixed Choices
• Debugging Taught Me As Much As Coding
• A Bigger Picture Is Starting to Form
• Looking Ahead
• Day 3 Code

Organizing Data Instead of Just Storing It

The first two days were focused on learning Swift's basic building blocks.

Variables.

Constants.

Strings.

Booleans.

Today felt different.

Instead of learning new data types, I learned how Swift organizes information.

As programs become larger, storing a single value isn't enough.

Sometimes you need a list of names.

Sometimes you need to look up information using a key.

Sometimes duplicate values don't make sense.

And sometimes a value should only ever be one of a fixed number of choices.

Swift has different collection types for each of those situations.

Understanding when to use each one was easily the biggest lesson of today.

Arrays: Ordered Collections

The first collection type I explored was the array.

Arrays store multiple values while preserving the order they were added.

var names = [
    "Steve Jobs",
    "Steve Wozniak",
    "Tim Cook",
    "Elon Musk"
]

Accessing values is straightforward.

print(names[0])

Arrays use zero-based indexing, so the first element is always at index 0.

Along the way I experimented with a number of built-in array methods.

Adding values:

names.append("Sundar Pichai")

Counting values:

print(names.count)

Searching:

print(names.contains("Tim Cook"))

Removing values:

names.remove(at: 2)

Clearing everything:

names.removeAll()

What stood out was how descriptive Swift's API is.

Methods like append(), contains(), and removeAll() explain exactly what they're doing.

There's very little guesswork.

Learning That Arrays Have Types

One interesting thing I learned is that arrays aren't limited to integers.

Swift can infer the type automatically.

var temperatures = [23.4, 26.8, 31.5]

Or I can declare the type explicitly.

var people: [String] = []

I also discovered two equivalent ways of creating empty arrays.

var characters = Array<String>()

and

var characters = [String]()

The second version is simply shorthand.

Both create exactly the same type of array.

Sorting and Reversing

Swift also provides methods for organizing data.

Sorting an array is as simple as:

print(alphabets.sorted())

One thing that confused me initially was reversed().

print(alphabets.reversed())

Instead of printing a reversed array, Swift returned a ReversedCollection.

After learning why, it actually made sense.

Rather than creating an entirely new array immediately, Swift returns a lightweight view over the original collection.

If I really want a new array, I can convert it.

print(Array(alphabets.reversed()))

Small implementation details like this show that Swift often favors efficiency alongside readability.

Dictionaries: Looking Up Information

The next collection type was dictionaries.

Unlike arrays, dictionaries don't use numeric indexes.

Instead, they store values using keys.

let truth = [
    "Swift is fast": true,
    "Swift is easy": true
]

Accessing a value looks like this.

print(truth["Swift is fast"])

I also learned that dictionary lookups return optional values because a key may not exist.

Providing a default value avoids dealing with missing keys.

print(truth["Swift is fast", default: false])

One mistake I made during today's lesson was trying to store multiple singers inside a single dictionary using identical keys.

[
    "Name": "...",
    "Name": "..."
]

Swift simply replaces the earlier value because dictionary keys must always be unique.

The correct solution was using an array of dictionaries.

let singers = [
    [
        "Name": "Elizabeth Woolridge Grant",
        "Nickname": "Lana Del Rey"
    ],
    [
        "Name": "Taylor Swift",
        "Nickname": "Taylor"
    ]
]

That was a good reminder that choosing the right data structure is just as important as writing the code itself.

Sets: Unique Values Only

Sets felt similar to arrays at first.

The biggest difference is that sets automatically remove duplicate values.

var breeds = Set<String>()

breeds.insert("Labrador")
breeds.insert("Labrador")
breeds.insert("German Shepherd")

Even though "Labrador" was inserted twice, it only appears once.

Another important characteristic is that sets don't preserve order.

If ordering matters, arrays are the better choice.

If uniqueness and fast lookups matter, sets are often the better option.

It's another example of Swift providing specialized tools for different situations.

Enums: Fixed Choices

The final topic today was enumerations, usually shortened to enums.

Enums define a fixed set of possible values.

enum Weekday {
    case monday
    case tuesday
    case wednesday
    case thursday
    case friday
    case saturday
    case sunday
}

Instead of using strings everywhere, Swift lets you work with meaningful values.

var day = Weekday.monday

day = .friday

I also learned about raw values.

enum Singer: String {
    case taylorSwift = "Taylor Swift"
}

This allows me to access either the enum case itself.

Singer.taylorSwift

or its underlying string.

Singer.taylorSwift.rawValue

Enums already feel like they'll become incredibly useful once I start building real applications.

Debugging Taught Me As Much As Coding

Today's lesson wasn't only about new features.

It also involved fixing several mistakes.

I accidentally redeclared variables.

I misunderstood how dictionaries store multiple objects.

I discovered why reversed() doesn't immediately return an array.

I even learned that enum cases can't contain spaces and that commas inside enum declarations follow different rules than I initially expected.

Every error ended up teaching me something new about how Swift works.

A Bigger Picture Is Starting to Form

After three days, Swift feels very intentional.

Arrays solve one problem.

Dictionaries solve another.

Sets solve another.

Enums prevent invalid values entirely.

Rather than trying to make one data structure handle every situation, Swift provides specialized tools for different kinds of data.

That makes code easier to understand and much safer to work with.

I'm beginning to see that learning Swift isn't just about memorizing syntax.

It's about learning which tool fits which problem.

Looking Ahead

Three days in, and I still haven't built a user interface.

No SwiftUI.

No views.

No buttons.

Just the language.

Surprisingly, I'm enjoying that.

Each day builds another layer of understanding, and it already feels much easier to read Swift code than it did when I started.

I'm excited to see how these collection types eventually fit into real apps.

Three days down.

Ninety-seven to go.

Day 3 Code

The complete code from today's learning session is available here:

• collection-types.swift

• Thinking Beyond Syntax
• Exploring Booleans
• Changing Boolean Values
• Joining Strings
• String Interpolation
• Expressions Inside Strings
• My First Swift Checkpoint
• A Pattern Is Emerging
• Looking Ahead
• Day 2 Code

Thinking Beyond Syntax

Yesterday was about getting comfortable with Swift's syntax.

Today was about understanding how Swift wants developers to think.

The concepts themselves weren't particularly difficult.

Booleans.

String interpolation.

A simple temperature conversion.

Yet every topic revealed something about the language's philosophy.

Swift consistently encourages writing code that's expressive, intentional, and easy to read. Rather than relying on clever shortcuts, it nudges you toward writing code that explains itself.

That became much more apparent today.

Exploring Booleans

A Boolean is one of the simplest types in programming.

It can only be one of two values.

var isMovieGood = false

While that seems straightforward, what interested me more was how naturally Swift lets you work with Boolean values.

For example, checking whether a number is divisible by another number:

let number = 120

print(number.isMultiple(of: 3))

Or checking whether a string ends with a particular word:

let name = "Peter Benjamin Parker"

print(name.hasSuffix("Parker"))

Both methods return either true or false.

More importantly, they read almost like plain English.

Instead of writing complicated conditions, Swift gives you descriptive methods that immediately communicate what the code is doing.

Changing Boolean Values

I also learned two different ways to flip a Boolean.

The first uses the logical NOT operator.

isMovieGood = !isMovieGood

The second uses Swift's built-in toggle() method.

isMovieGood.toggle()

Both achieve exactly the same result.

Personally, I find toggle() easier to read because it describes the intention instead of the implementation.

Small details like this make Swift feel very approachable.

Joining Strings

The next topic was creating longer strings from smaller pieces.

The first approach uses string concatenation.

print("My name is " + firstName + " " + lastName + " and I'm " + String(age) + " years old!")

It works perfectly.

But it also involves a lot of manual work.

Spaces have to be inserted manually.

Numbers have to be converted into strings.

As the sentence grows longer, the code becomes harder to read.

String Interpolation

Swift's preferred solution is string interpolation.

print("My name is \(firstName) \(lastName) and I'm \(age) years old!")

The output is identical.

The difference is readability.

The code almost looks exactly like the final sentence, while Swift automatically converts values like integers into text.

Coming from JavaScript, it reminded me of template literals, but Swift's syntax feels even cleaner because it's built directly into the language.

I can already tell this will become my default way of creating strings.

Expressions Inside Strings

One feature I wasn't expecting was that string interpolation isn't limited to variables.

It can also evaluate expressions.

print("5 × 5 = \(5 * 5)")

Output:

5 × 5 = 25

Anything placed inside \( ) is evaluated before becoming part of the final string.

It's a simple feature, but it makes creating dynamic text incredibly flexible.

My First Swift Checkpoint

The highlight of today's lesson was completing my first checkpoint.

The challenge was simple.

Write a program that converts Celsius to Fahrenheit.

let tempInCelsius = 23.0
let tempInFahrenheit = (tempInCelsius * 9 / 5) + 32

print("""
Temperature in Celsius: \(tempInCelsius)°C
Temperature in Fahrenheit: \(tempInFahrenheit)°F
""")

At first I used an Int.

It worked for whole numbers, but I quickly realized temperatures aren't always whole numbers.

Changing the values to Double made the program work correctly for decimal temperatures as well.

It was a small adjustment, but a good reminder that choosing the correct data type matters just as much as writing the formula itself.

A Pattern Is Emerging

After only two days, I'm starting to notice a recurring pattern.

Swift places a huge emphasis on readability.

Methods like:

number.isMultiple(of: 3)

and

name.hasSuffix("Parker")

read almost like normal English.

String interpolation removes unnecessary complexity.

Methods have descriptive names.

The language consistently encourages code that's easy to understand—not only for the compiler, but also for the person reading it.

That's something I'm appreciating more with every lesson.

Looking Ahead

I'm still nowhere near building apps.

No SwiftUI.

No views.

No buttons.

Just learning the language itself.

It's tempting to jump straight into creating interfaces, but building a solid understanding of Swift first feels like the right decision.

Every concept I learn now will make everything that comes later easier to understand.

Two days down.

Ninety-eight to go.

Day 2 Code

The complete code from today's learning session is available here:

• booleans-and-strings.swift

• The First Lines of Swift
• Variables and Constants
• String Interpolation
• Multiline Strings
• Properties and Methods
• Exploring Strings
• Numbers and Readability
• Compound Assignment Operators
• Discovering Types
• Arithmetic
• What Stood Out Most
• Looking Ahead
• Day 1 Code

The First Lines of Swift

Yesterday was about understanding the roadmap.

Today was about writing code.

Not SwiftUI.

Not iOS applications.

Not user interfaces.

Just Swift.

After spending years building for the web, learning a new programming language feels strangely familiar and completely different at the same time.

Many concepts carry over.

Variables.

Strings.

Numbers.

Functions.

Yet Swift approaches these concepts with a level of clarity that immediately stood out to me.

Rather than trying to do everything, Swift seems focused on helping developers express intent as clearly as possible.

That became obvious within the first few hours.

Variables and Constants

One of the first concepts introduced was the difference between variables and constants.

var age = 18

let firstName = "Peter"
let middleName = "Benjamin"
let lastName = "Parker"

Values created with var can change.

Values created with let cannot.

At first, this seemed like a small distinction.

The more I worked with it, the more I understood why Swift encourages it so heavily.

The language wants you to think about which values are actually meant to change.

If something should remain constant, Swift encourages you to make that intention explicit.

It's a simple idea, but it makes code easier to reason about.

String Interpolation

Once I had some values to work with, the next step was combining them.

let fullName = "\(firstName) \(middleName) \(lastName)"

This creates:

Peter Benjamin Parker

Coming from JavaScript, it felt somewhat similar to template literals.

What I liked immediately was how readable it is.

The code closely resembles the final result.

That theme appears throughout Swift.

Multiline Strings

The next discovery was multiline strings.

let bio = """
Peter Benjamin Parker is a young photographer and science enthusiast from New York City.

After being bitten by a radioactive spider, he gained extraordinary abilities and became Spider-Man.
"""

I ended up liking this feature more than I expected.

The formatting inside the code mirrors the formatting of the final output.

No repeated newline characters.

No awkward string concatenation.

Just text.

As someone who writes a lot of content, that feels surprisingly natural.

Properties and Methods

One of the most interesting things I learned today was the difference between properties and methods.

Consider this example:

let name = "Peter Parker"

print(name.count)

Output:

12

Notice that count doesn't use parentheses.

That's because Swift is simply reading information.

Nothing is being transformed.

Nothing is being calculated beyond retrieving a value that already exists.

Now compare that to:

print(name.uppercased())

Output:

PETER PARKER

Here we use parentheses.

Why?

Because Swift is doing work.

It takes the original string, creates an uppercase version, and returns the result.

This pattern appears throughout Swift:

• Properties describe data.
• Methods perform work.

Once I understood that distinction, many APIs immediately made more sense.

Exploring Strings

With that understanding, I started experimenting with Swift's string APIs.

fullName.count

fullName.lowercased()
fullName.uppercased()

bio.hasPrefix("Peter")
bio.contains("Spider-Man")
bio.hasSuffix("superheroes.")

One thing I noticed is how naturally these APIs read.

For example:

bio.hasPrefix("Peter")

reads almost like a sentence.

The same applies to:

age.isMultiple(of: 3)

Swift places a lot of emphasis on readability, and it shows.

Numbers and Readability

Swift handles whole numbers exactly as you'd expect.

let million = 1000000
let billion = 1000000000

The problem is that large numbers quickly become difficult to read.

Swift solves this with underscores.

let million = 1_000_000
let billion = 1_000_000_000

The underscores don't change the value.

Swift completely ignores them.

They're simply there to help humans read the code.

I also found it interesting that Swift doesn't care where the underscores are placed.

For example:

let lakh = 1_00_000
let crore = 1_00_00_000

These work perfectly as well.

The compiler sees the same number regardless.

Compound Assignment Operators

Another small but useful concept was compound assignment operators.

Instead of writing:

var age = 19

age = age + 1

Swift allows us to write:

var age = 19

age += 1

Both approaches produce the same result.

The second version is simply shorter and easier to read.

Swift supports several compound assignment operators:

var number = 10

number += 5
number -= 3
number *= 2
number /= 4

These are common throughout Swift code and quickly become second nature.

Discovering Types

Another concept that stood out was type inference.

Consider these values:

let a = 1.2
let b = 5
let c = "Hello, Swift!"

Without explicitly specifying types, Swift automatically understands them as:

• Double
• Int
• String

You can inspect them directly:

print(type(of: a))
print(type(of: b))
print(type(of: c))

Output:

Double
Int
String

This was a useful reminder that Swift is strongly typed while still remaining convenient to work with.

Arithmetic

I also spent some time experimenting with basic arithmetic.

let a = 1.2
let b = 1.000000000003

print(a + b)
print(a - b)
print(a * b)
print(a / b)

Nothing groundbreaking here.

But every language has its own way of handling numbers, and spending time experimenting helps build intuition.

Sometimes the simplest exercises teach the most.

What Stood Out Most

The biggest lesson from Day 1 wasn't variables.

Or strings.

Or numbers.

It was how intentional Swift feels.

Many APIs read like English.

Many language features seem designed to prevent mistakes before they happen.

The language consistently encourages clarity over cleverness.

After years of writing JavaScript and TypeScript, that difference was immediately noticeable.

Not necessarily better.

Not necessarily worse.

Just different.

And that's exactly why I'm excited to keep learning.

Looking Ahead

Today was about foundations.

Variables.

Constants.

Strings.

Numbers.

Types.

Nothing particularly complex.

But every application begins with these building blocks.

Tomorrow the journey continues with more of Swift's core language features.

One day down.

Ninety-nine to go.

Day 1 Code

The complete code from today's learning session is available here:

• Fundamentals.swift

• The Language Behind the Inspiration
• Why Swift?
• Starting Without Apple Hardware
• Beginning with 100 Days of SwiftUI
• Day 0: Understanding the Road Ahead
  • Core Skills
  • Extension Skills
  • Common Mistakes Worth Avoiding
• Looking Ahead

The Language Behind the Inspiration

My programming journey began in 2022.

Like many developers, I did not discover programming through a classroom or a textbook. A friend introduced me to the world of software development, and what started as curiosity quickly turned into something much bigger.

I began where many modern developers begin: the web.

HTML, CSS, JavaScript, frameworks, APIs, deployments, and countless side projects filled the years that followed. Every new project taught me something. Every mistake revealed another lesson. Every challenge became an opportunity to improve.

The code I wrote in those early days was far from perfect.

Looking back, much of it was inconsistent, poorly structured, and held together more by enthusiasm than experience.

But that never really mattered.

When you're just starting, the goal is not to write perfect code. The goal is to build. To experiment. To learn. To discover what excites you enough to keep going.

Over time, something changed.

I became less interested in simply making software work and more interested in how software feels.

How interfaces communicate.

How consistency builds trust.

How thoughtful design removes friction.

How small details create memorable experiences.

Whether it's a button, a transition, a navigation pattern, or a single line of supporting text, I care about how it looks, how it behaves, and how it contributes to the overall experience.

A significant part of that influence came from Apple.

Not the hardware.

The software.

The consistency across products. The attention to detail. The focus on simplicity. The intentionality behind every interaction. The belief that technology should feel approachable, intuitive, and human.

Those ideas gradually shaped the way I think about software.

Many of the design decisions I make today can be traced back to principles I admired long before I ever considered learning Swift.

In many ways, Swift is not where that inspiration began.

It's where that inspiration eventually led.

Why Swift?

Swift is Apple's modern programming language.

Fast.

Expressive.

Safe.

Designed to power everything from command-line tools and cloud services to applications running across iPhone, iPad, Mac, Apple Watch, and Apple TV.

What attracts me most is not just the language itself.

It's the ecosystem surrounding it.

For years, I've admired the way Apple approaches software design. The consistency across platforms. The shared design language. The seamless integration between devices. The idea that software and hardware should feel like parts of the same experience.

Swift sits at the center of that ecosystem.

Learning Swift means learning how those experiences are built.

Another reason is simple.

I wanted something different.

I've spent years building for the web. While I still enjoy web development, I wanted to challenge myself with a new platform, a new set of tools, and a different way of thinking about software.

Swift felt like the natural next step.

It combines modern language design, strong safety guarantees, excellent tooling, and the ability to build for an entire ecosystem using a shared foundation.

Write once.

Adapt across iPhone, iPad, Mac, Apple Watch, and Apple TV.

That idea is incredibly compelling.

Starting Without Apple Hardware

One common misconception is that learning Apple development requires owning Apple hardware from day one.

Eventually, having a Mac becomes important.

But learning does not start with hardware.

Learning starts with curiosity.

I'm currently a third-year student.

I don't own a MacBook.

I don't own an iPhone.

Yet.

What I do have is access to excellent educational resources, documentation, community support, and a genuine interest in learning.

For now, that's enough.

The hardware can come later.

The foundation starts today.

Beginning with 100 Days of SwiftUI

To begin this journey, I've chosen one of the most respected learning resources in the Swift community:

100 Days of SwiftUI by Paul Hudson.

If you're interested in following along:

• https://www.hackingwithswift.com/100/swiftui
• https://x.com/twostraws

Day 0: Understanding the Road Ahead

Interestingly, Day 0 wasn't about writing code.

There were no variables.

No functions.

No SwiftUI views.

No applications.

Instead, it focused on understanding the roadmap.

Core Skills

• Swift
• SwiftUI
• Working with Data
• Networking
• Version Control

Extension Skills

• UIKit
• Core Data
• Multithreading
• Architecture
• Testing

Common Mistakes Worth Avoiding

• Trying to memorize everything
• Shiny Object Syndrome
• Lone Wolf Training
• Using beta software
• Starting with documentation
• Getting lost in Objective-C
• Taking shots at other languages

Looking Ahead

Today was not about building an app.

It was about understanding the journey.

Tomorrow begins with the fundamentals.

Variables.

Constants.

Data types.

Every developer starts somewhere.

Today was my first step into Swift.

And I'm excited to see where the next one hundred days lead.

• The smallest part
• What the model reaches for
• A prompt is a specification
• Three days, one new language, one real product
• The loop that most people run halfway
• What consistency actually requires
• The structure should explain itself
• Context wears out
• The audit nobody runs
• Simplicity is not fewer features
• The part that cannot be generated
• What the work actually asks for

The smallest part

Most people think prompting is the hard part.

It is not.

Prompting is the last step in a long chain of decisions that most people never make. The thinking. The planning. The specification. The judgment about what this thing should actually be. The prompt arrives at the end of all that. It is the instruction, not the thought behind it.

Skip everything before the prompt and the prompt carries nothing. The model fills that space with the most common answer to the most common version of the request.

Averages are exactly what you get.

What the model reaches for

I have noticed something consistent across AI-generated interfaces.

The glowing dots. The floating cards. The gradient that starts indigo and fades into something only slightly different. The hero section that feels borrowed. The layout that could belong to a thousand products and therefore belongs to none of them.

This is not an AI problem. It is a specification problem.

AI does not invent. It completes. When a prompt is vague, the model reaches for the center of everything it has ever seen. It has no way of knowing what is specific about your product, your values, or your taste. It only knows what most people have built before.

So it builds that.

The model was not told what makes this different. So it made something safe.

Safe is average. Average is forgettable.

A prompt is a specification

Before I write a single line of instruction now, I stop and answer a harder question first.

What is this, exactly?

Not a category. Not a rough shape. The specific thing. The version that only makes sense in this context, for these people, with this particular feeling.

What is being built. Why it exists. Who it is for. What it should feel like to use. What it should never feel like. What problem it is solving and what problems it refuses to create. Design expectations. Functional constraints. The things out of scope named as clearly as the things that are in.

A prompt written after all of that is a different kind of instrument. It carries weight. It narrows the possibility space. It gives the model something to be precise about instead of something to average out.

The quality of the output reflects the quality of the thinking that came before it. Almost exactly.

Three days, one new language, one real product

I want to make this concrete, because it is easy to read advice like this and assume it applies to someone else.

I built the platform you are reading this on in roughly three days. I had never written a line of Svelte before I started. I did not know the framework, the conventions, or the patterns. I only knew what I wanted the product to feel like.

That clarity was the most valuable thing I brought to the process.

The workflow had three stages.

Stage one was planning. I spent the first hour or two with ChatGPT. Not asking it to build anything. Asking it to think with me. I described what I wanted. It pushed back. I refined. It challenged assumptions I had not noticed I was making. By the end of that conversation I had a specification. A real one. Not a list of features. A document that described the product, the audience, the experience, the constraints, and the principles that should govern every decision.

I reviewed that document manually. I edited it. I made sure it matched what I actually intended.

Then I handed it to Claude.

Stage two was implementation. The first output was surprising. Structurally coherent, broadly correct, closer to the vision than I expected. But it was not the product. It was the beginning of the product.

There were issues that only became visible through use. Missing refinements. Hidden inconsistencies. UX decisions that looked reasonable on first glance and revealed their problems on the third interaction. SEO gaps. Accessibility oversights. Edge cases that the model had not considered because I had not specified them.

The first generated version was not something to ship. It was something to respond to.

Stage three was refinement. I used Codex for this phase. Architecture improvements. Type safety. Build stability. Accessibility. Documentation. Naming conventions. Directory structure. The work of making something coherent into something intentional.

This is the phase most people skip. It is also the phase where quality actually lives.

The platform now maintains Lighthouse scores between 90 and 100 across performance, SEO, accessibility, and best practices. Zero build errors. Zero type errors. Zero lint errors. No unused imports, no unused variables, no outdated dependencies.

That did not come from the AI. It came from the hours spent after the AI finished.

The loop that most people run halfway

Vibe coding is a loop.

Most people stop at Generate.

Something appears on screen. It mostly works. It has roughly the right structure, something close to the right idea. The temptation is to keep going. Add more. Prompt on top of the imprecision instead of correcting it.

The result is drift. Each new prompt layers onto something that was never quite right. By the end, the product is structurally uncertain. Fixing it means reconstructing decisions that were never consciously made.

The better habit is to stop at the first output. Inspect it as a real user would. Slowly. Without foreknowledge. What is confusing? What is absent? What is technically present but experientially missing?

Then make one change. Not seven. One.

There is something worth preserving about single-change iteration. The implementation is cleaner. Cause and effect stay visible. If something breaks, the source is close. If something improves, you understand why.

What consistency actually requires

Consistency does not happen because the AI remembered the last session.

It happens because someone wrote down what the product is and what it is not, and then made sure every decision was checked against that.

A design system is not a luxury for large teams. It is the document that keeps the work from becoming incoherent over time.

Typography. Color. Spacing. Component behavior. Animation. Naming. Accessibility. Not as a checklist. As a shared understanding of what this product believes about itself.

When that document exists, every AI tool can be told to read it first. The output becomes more consistent not because the model got smarter, but because it was given less room to invent.

The files I keep in every serious project:

• RULES.md — what the AI is always and never allowed to do
• DESIGN_SYSTEM.md — tokens, type, color, spacing, component rules
• ARCHITECTURE.md — structural decisions, patterns, naming conventions
• IMPLEMENTATION.md — how features are built, not just what they are

None of this is glamorous. But it is the difference between a product that stays coherent across weeks and one that starts contradicting itself by day three.

The structure should explain itself

One of the things I kept asking myself while building this platform was whether a developer returning after ten years could understand it in two minutes.

Future-me is effectively a new contributor. So is every AI tool that opens the codebase. The structure should not require explanation. It should communicate on its own.

The root directory of this platform has three folders.

/
├── src/
├── static/
└── writings/

Source code. Public assets. Articles. Nothing else.

Inside src, there are two more.

src/
├── lib/
└── routes/

Reusable code. Application routes. Still nothing to explain.

Publishing a new post is:

1. Open writings/
2. Create a folder
3. Create index.svx
4. Write
5. Publish

No CMS. No dashboard. No instructions required. The folder structure is the workflow.

Every file lives where its name suggests it should. seo.ts handles SEO. og.ts handles Open Graph. search.ts handles search. A developer should rarely ask where something belongs. The structure should answer automatically.

This is what intentionality looks like at the architectural level. Not clever patterns. Not sophisticated abstractions. A system that explains itself.

Context wears out

Something happens in long AI conversations that I had to learn to manage rather than resent.

The early context fades. Decisions made in the first few messages stop shaping the decisions being made now. The model begins to invent where it once respected. Small inconsistencies appear, then larger ones.

This is not a flaw. It is a condition.

Every five or six significant prompts, I reintroduce the things that matter. The architecture decisions. The design language. The documents that define what the product is. Not because the model forgot. Because the context window is carrying too many other things now, and the important constraints have been pushed to the edges.

Returning to the brief. The brief has not changed. It just needs to be present again.

The audit nobody runs

After a long implementation session there is usually a version of the code that works but is not clean.

Dead functions. Components that were replaced but never removed. Logic refactored in one place and not updated in two others. Patterns that drifted from the design system. Naming that was consistent in week one and is not consistent now.

The code runs. But it is carrying weight it should not be carrying.

An audit is not extra work. It is the work. It is the part where the product stops being a series of accumulated decisions and starts being something deliberate.

Check for inconsistency. Remove what is no longer used. Verify that existing patterns are respected and not quietly replaced by new ones. Ask the AI to find logic that is being duplicated where it should be shared.

Then run the quality pipeline. Not as ceremony. As proof.

Simplicity is not fewer features

There is a definition of simplicity I keep returning to.

Simplicity is not fewer features. It is not less capability. It is not reduced functionality.

Simplicity is the absence of confusion.

The goal is maximum capability with minimum confusion. A system where functionality can increase and complexity remains understandable. Where the user does not need instructions. Where the developer does not need instructions. Where future-me does not need instructions.

The system itself should communicate how it works.

I borrow a question from the way certain companies approach product decisions. Before adding something, ask: would it be better to simplify instead? Before adding a setting, ask: would it be better to improve the default? Before shipping a screen, ask: would a person understand this in six seconds without help?

Most things that seem necessary turn out to be compensations for something that was not thought through clearly enough earlier. The feature that patches the gap in the flow. The setting that covers a decision that was never made. The complexity that exists because simplicity required more judgment than was available at the time.

That judgment is almost always available. It just requires stopping long enough to use it.

The part that cannot be generated

AI can write the code. It can produce the layout, the component library, the routing logic, the full working application in a fraction of the time any of that used to require.

What it cannot do is care whether the result is good.

It cannot look at a finished screen and feel that something is slightly off. It cannot sit with the product long enough to notice the friction a real user would find in the first thirty seconds. It cannot decide this version is not good enough, even though it technically works.

That part belongs to the person building it.

The difference between software that feels considered and software that feels generated is not the model. It is not the prompting technique, the tool, or the number of iterations.

It is whether the person building had enough taste to recognize mediocrity and enough patience to refuse it.

What the work actually asks for

AI is leverage. It is not authorship.

It generates options. The judgment about which option belongs is still yours.

It accelerates production. The standards that production is held to are still yours.

It fills specification with output. The specification itself, the thinking about what is worth building, how it should feel, why it should exist, that remains the most important part of the process. And it cannot be delegated.

AI reduced the time it took me to build this platform. That saved time did not go back into my pocket. It went into the quality of the work. Into the audit. Into the documentation. Into the decisions about what to remove. Into reading the codebase as a stranger would and asking whether it made sense.

That is where the product became something I was proud of. Not during generation. After it.

The products worth building are not the ones generated fastest.

They are the ones where someone cared enough to stop, repeatedly, and ask whether it was good yet.

Taste. Judgment. Patience. Attention to detail.

These are not soft skills. They are the bottleneck.

And they are the part worth protecting.

• The expensive thing
• The first hour
• A slower kind of progress
• Noise with a professional face
• Small boundaries
• Design needs silence
• Code needs it too
• The room after finishing
• What I want to keep

The expensive thing

Attention is the most expensive part of the work.

Not time. Not tools. Not the number of windows open on a screen.

Attention.

It is the part that lets a rough interface begin to make sense. It is the part that notices when a sentence is almost right but still carrying too much weight. It is the part that can sit with a strange bug long enough to stop treating it like noise and start seeing its shape.

Most of the work I care about asks for that kind of attention.

And most of the day tries to take it away.

The first hour

The first hour matters more than I want it to.

If I begin the day by reacting, the day usually keeps that shape. Messages become the map. Small requests become the weather. I can still get things done, but the work starts to feel borrowed from everyone else's priorities.

So I try to keep the first hour plain.

No dashboard tour. No inbox archaeology. No pretending that checking five tools is the same as understanding the day.

Just one surface. One task. One decision that would make the rest of the day easier.

That sounds small, but it changes the texture of the work.

A slower kind of progress

Some progress looks unproductive from the outside.

Reading the same paragraph three times.

Renaming a thing until it stops lying.

Moving one button and then moving it back.

Deleting a clever solution because the simpler one finally became visible.

These are not delays. They are part of the work. They are how the work becomes less accidental.

The mistake is treating attention as something that only matters during execution. It matters before execution. It matters while choosing what not to do. It matters when deciding whether a problem is asking for code, design, writing, or nothing yet.

The best work often begins as a refusal to rush the wrong version of the answer.

Noise with a professional face

Not all noise looks like noise.

Some of it looks useful.

A new framework announcement. A thread about process. A tool that promises cleaner thinking. A metric that asks to be improved because it is visible. A meeting that exists because the calendar had room for it.

The difficult part is that some of these things are genuinely useful.

That is what makes them dangerous.

The question is not whether something is good. The question is whether it belongs inside this moment.

I have lost more time to useful distractions than useless ones.

Small boundaries

Large systems for attention rarely last for me.

I do better with small boundaries.

• write the first note before opening chat
• keep one scratch file for messy thinking
• close the preview when the problem is conceptual
• open the preview when the problem is visual
• leave a short note at the end of the day for tomorrow

None of this is dramatic.

That is why it works.

A boundary does not need to become an identity. It just needs to reduce the number of small negotiations that happen before real work starts.

Design needs silence

Design is often treated as a visible act.

Screens. Components. Grids. Motion. Type. Color.

But a lot of design happens before anything visible changes. It happens when you notice that a label is doing the wrong job. It happens when you realize the empty state is not empty at all, because it is carrying the user's uncertainty. It happens when the page is technically complete but emotionally too loud.

Those observations need silence.

Not perfect silence. Not some precious studio fantasy.

Just enough space for the thing in front of you to become specific.

Code needs it too

Code also punishes scattered attention.

A bug can look like five different problems when the mind is moving too quickly. A type error can seem annoying when it is actually explaining a broken assumption. A refactor can feel urgent when the real issue is that the boundary was never named clearly.

The work improves when I slow down enough to ask:

What is this code trying to protect?

What does this abstraction make easier?

What does it make harder?

What would I need to understand if I came back here in six months?

Those questions do not take long.

Avoiding them does.

The room after finishing

Finishing a task creates a strange little opening.

There is a temptation to fill it immediately. Start the next thing. Check the queue. Answer something. Prove the day is still moving.

I am trying to leave a little room after finishing.

A minute is enough.

What changed? What did I learn? What should be easier next time? Did the work actually solve the problem, or did it only produce motion?

That pause keeps the day from becoming a blur of completed fragments.

It lets the work teach me something before I move on.

What I want to keep

I do not want a perfectly optimized life.

I do not want every hour turned into a unit.

I want enough quiet to do work I can recognize as mine.

Enough attention to notice when something is off.

Enough patience to let a better version of the idea arrive.

Enough discipline to protect the small conditions that make craft possible.

That is the practice.

Not a grand system.

Just returning, again and again, to the expensive thing.

• A place to think
• Why now
• How it is made
• The stack
• Design as function
• What comes next

A place to think

Writing has always been the clearest way for me to understand what I am making.

This site exists for that reason. It is a personal space for essays, notes, and ideas on design, engineering, and craft. A place to slow things down, give thoughts a proper shape, and return to them with more care than a feed usually allows.

I wanted something focused. Not large. Not loud. Just a writing surface that feels deliberate from the first line to the last.

Why now

I have wanted a dedicated writing space for a while.

The more I work across design and engineering, the more I notice how often the important parts live between the two. The interface decision that changes the code. The technical constraint that improves the design. The small system choice that makes future work easier.

Those ideas need room.

This site is where I want to keep them.

How it is made

The site is built with SvelteKit and SVX.

Each essay lives in its own folder:

writings/
  introducing-writing/
    index.svx

If an essay needs an image, diagram, or supporting file, it can live beside the writing:

writings/my-essay/
  index.svx
  cover.webp
  diagram.png

The folder becomes the URL. The source stays simple. The public path stays clean.

SVX keeps the writing close to Markdown while still allowing Svelte components when a piece needs something more considered than static text.

The stack

The site uses:

• SvelteKit for routing and static output
• Svelte 5 for components
• SVX and mdsvex for writing
• Tailwind CSS for the visual system
• Shiki for code highlighting
• Pagefind for search
• TypeScript for the application layer

The result is a small static site with generated metadata, RSS, sitemap support, syntax highlighting, and search after build.

There is no CMS here. The writing itself is the source.

Design as function

The visual system is quiet, intentional, and text-led.

That restraint is not a lack of design. It is the design. The header, spacing, search, metadata, colors, and motion all shape how the writing is read.

Design is not just what it looks like and feels like. Design is how it works.

That line is the center of this site.

The interface should not simply look minimal. It should make writing easier to publish, easier to read, and easier to return to. It should support attention without asking for attention.

What comes next

This is the first note.

More will follow as the system earns its shape through use. Some pieces will be polished essays. Some will be shorter observations. Some will be notes from building, designing, learning, and changing my mind.

For now, the purpose is simple.

Write clearly. Build carefully. Keep the space honest.