Jekyll2026-01-09T00:20:26+00:00https://danielbernal.co/feed.xmlDaniel BernalNot done yetDaniel BernalSo many things at once2026-01-08T00:00:00+00:002026-01-08T00:00:00+00:00https://danielbernal.co/writing/so-many-things-at-onceI don’t remember the last time I wanted to do this many things at once.

Some idea hits at midnight and by 2am there’s a working prototype. One side project becomes three. A chat turns into code before I can even finish my coffee.

There’s no friction anymore. The days or weeks between idea and something real don’t exist anymore. One prompt, some iteration, and suddenly it’s clickable.

I used to filter ideas by effort and complexity. “That would take too long”, “I’ll have to learn XYZ first”. Had valid reasons to let something die almost all the time. Now nothing takes too long, and I’m drowning in my own enthusiasm.

Terminal windows everywhere with things I forgot I started. Projects half-alive waiting for attention. Things I shipped last week I haven’t touched since.

It’s crazy, but It’s also the most alive I’ve felt building things in years.

I don’t know if this pace is sustainable or if I’m just riding a wave that will crash. But right now, I’d rather have too many things calling for attention than spend another decade filtering myself before I start.

Its a mess, but that’s the the point.

]]>
Daniel Bernal
Beautiful code is a liability2026-01-07T00:00:00+00:002026-01-07T00:00:00+00:00https://danielbernal.co/writing/beautiful-code-is-a-liabilityDevelopers who survive 2026 won’t be the best coders. They’ll be the fastest.

The best coders I know are scared. Not publicly, but In long threads defending practices that won’t matter in eighteen months.

They were never product people. Their product was the code. And it just got commoditized.

While they’re fighting about how AI doesn’t write elegant code, they ignore it writes working code. In seconds.

They ignore average code shipped fast beats perfect code shipped next month. It always did. The difference now is that “today” means minutes, not months.

Folks advocating for clean abstractions and proper patterns aren’t wrong about their craft, but they’re wrong about what matters today. They’re protectin a status quo that valued their expertise, except that expertise is devaluing very fast.

And yeah. There’s “the other” crowd. The ones who use AI but then spending hours “fixing” its output. Refactoring stuff code to meet their standards. Adding abstractions. Making it beautiful.

They missed the point entirely. Code is not art. Code is not craftsmanship anymore. It’s disposable

It will be regenerated next week when requirements change. That refactor It becomes debt the moment it gets to Github. It does not make sense to polishing something that was never meant to last.

Our energy should be on deciding what to build. Understand what users actually need. Know when to cut scope. Ship something embarrassing and learn from it.

We are not competing with AI. We competing with developers who use it don’t flinch.

They’re not waiting for your code review. Or their own.

]]>
Daniel Bernal
Why Your iOS Automation Setup Doesn’t Work2026-01-06T00:00:00+00:002026-01-06T00:00:00+00:00https://danielbernal.co/writing/why-your-ios-automation-setup-doesnt-workI spent months trying to make AI coding assistants work with iOS development. It was painful.

Apple ships five different command-line tools. xcodebuild handles compilation. simctl manages simulators. devicectl talks to physical devices (but only iOS 17+). xcrun finds and runs Xcode tools. xcode-select switches between Xcode versions. Each has its own flag syntax, its own output format, its own failure modes.

Building an app and running it on a simulator requires orchestrating three separate tools:

xcodebuild -workspace MyApp.xcworkspace \
  -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 16,OS=18.1' \
  -derivedDataPath ./build build

xcrun simctl boot "iPhone 16"
xcrun simctl install "iPhone 16" ./build/Build/Products/Debug-iphonesimulator/MyApp.app
xcrun simctl launch "iPhone 16" com.example.MyApp

Four commands. Hardcoded paths. A destination string that breaks if you don’t have exactly that simulator version. And this is the happy path.

When I started using Claude to help me build iOS apps, I hit a wall. It would generate xcodebuild commands that looked right but failed. It didn’t know which simulator runtimes I had installed, which devices were connected, or where my derived data lived. I’d paste the error back. It would try something different. Still fail. Twenty minutes debugging a build command instead of building the app.

The fragmentation exists because Apple built these tools over fifteen years for different purposes. CI systems adapted by wrapping everything in Ruby. Fastlane became the standard because it hid the complexity. But Fastlane wasn’t designed for AI agents.

So I built something that was.

I’ve been working on FlowDeck for the past few months. It’s a CLI that wraps all of Apple’s tools into a unified interface designed for AI agents. Eight verbs instead of eighty-four flags. build, run, test, clean, logs, stop, context, init. Each does one thing. Structured outputs. Predictable errors.

flowdeck run -S "iPhone 16"

Same result as those four commands above. Figures out the workspace, boots the simulator, builds, installs, launches. If something fails, it tells you why with an error code the AI can actually parse.

The interface shapes what’s possible. A fragmented interface means fragmented AI capabilities. A unified interface means I can finally build iOS apps with Claude the same way I’d work on a web project.

The toolchain fragmentation is Apple’s problem. I got tired of waiting for them to fix it.

]]>
Daniel Bernal