<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en_US"><generator uri="https://jekyllrb.com/" version="3.10.0">Jekyll</generator><link href="https://danielbernal.co/feed.xml" rel="self" type="application/atom+xml" /><link href="https://danielbernal.co/" rel="alternate" type="text/html" hreflang="en_US" /><updated>2026-03-28T13:29:44+00:00</updated><id>https://danielbernal.co/feed.xml</id><title type="html">Daniel Bernal</title><subtitle>Not done yet</subtitle><author><name>Daniel Bernal</name></author><entry><title type="html">The Work</title><link href="https://danielbernal.co/writing/the-work.html" rel="alternate" type="text/html" title="The Work" /><published>2026-03-28T00:00:00+00:00</published><updated>2026-03-28T00:00:00+00:00</updated><id>https://danielbernal.co/writing/the-work</id><content type="html" xml:base="https://danielbernal.co/writing/the-work.html"><![CDATA[<p>I can play around an entire day with Claude and walk away feeling productive. We’ll architect something. Refactor. Explore approaches. I’ll have artifacts, PRs, discussions that feel like deep work.</p>

<p>And then, ship it. Or not.</p>

<p>This is the actual problem with AI tools. Not that they make us lazy. They make procrastination feel like progress. Before, if I spent eight hours scrolling, I knew I was fucking around. Now I can spend eight hours “validating ideas” and “thinking through architecture” and convince myself I’m working.</p>

<p>It’s the same dopamine hit but with a better cover story.</p>

<p>It’s everywhere. Discord full of half-assed apps that shipped in twenty minutes. X threads bragging about features nobody asked for. Everyone’s racing to show velocity. Nobody’s asking if any of this should exist.</p>

<p>Building fast doesn’t make the world better. It makes it louder. Every feature you ship without knowing who it’s for is just more noise. Another app nobody opens. Another demo that dies in a GitHub repo. We’ve got AI now, so everyone’s a builder. Great. We don’t need more builders. We need fewer people building pointless shit.</p>

<p>The velocity is the distraction. It lets you skip the only question that matters: who is this for, and why does it need to exist?</p>

<p>FlowDeck forces me to answer that. Either it goes to users or it doesn’t. Either someone finds it useful or they don’t. The AI can help me build it faster, or it can help me avoid shipping for three more weeks.</p>

<p>The tool doesn’t change the work. It just gives you better excuses for not doing it.</p>]]></content><author><name>Daniel Bernal</name></author><summary type="html"><![CDATA[AI tools don't make us lazy. They make procrastination feel like progress.]]></summary></entry><entry><title type="html">So many things at once</title><link href="https://danielbernal.co/writing/so-many-things-at-once.html" rel="alternate" type="text/html" title="So many things at once" /><published>2026-01-08T00:00:00+00:00</published><updated>2026-01-08T00:00:00+00:00</updated><id>https://danielbernal.co/writing/so-many-things-at-once</id><content type="html" xml:base="https://danielbernal.co/writing/so-many-things-at-once.html"><![CDATA[<p>I don’t remember the last time I wanted to do this many things at once.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

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

<p>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.</p>

<p>Its a mess, but that’s the the point.</p>]]></content><author><name>Daniel Bernal</name></author><summary type="html"><![CDATA[The time between idea and something real is gone.]]></summary></entry><entry><title type="html">Beautiful code is a liability</title><link href="https://danielbernal.co/writing/developers-who-survive-2026.html" rel="alternate" type="text/html" title="Beautiful code is a liability" /><published>2026-01-07T00:00:00+00:00</published><updated>2026-01-07T00:00:00+00:00</updated><id>https://danielbernal.co/writing/beautiful-code-is-a-liability</id><content type="html" xml:base="https://danielbernal.co/writing/developers-who-survive-2026.html"><![CDATA[<p>Developers who survive 2026 won’t be the best coders. They’ll be the fastest.</p>

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

<p>They were never product people. Their product was the code. And it just got commoditized.</p>

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

<p>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.</p>

<p>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.</p>

<p>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.</p>

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

<p>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.</p>

<p>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.</p>

<p>We are not competing with AI. We competing with developers who use it don’t flinch.</p>

<p>They’re not waiting for your code review. Or their own.</p>]]></content><author><name>Daniel Bernal</name></author><summary type="html"><![CDATA[Developers who survive 2026 won't be the best coders. They'll be the fastest.]]></summary></entry><entry><title type="html">Why Your iOS Automation Setup Doesn’t Work</title><link href="https://danielbernal.co/writing/why-your-ios-automation-setup-doesnt-work.html" rel="alternate" type="text/html" title="Why Your iOS Automation Setup Doesn’t Work" /><published>2026-01-06T00:00:00+00:00</published><updated>2026-01-06T00:00:00+00:00</updated><id>https://danielbernal.co/writing/why-your-ios-automation-setup-doesnt-work</id><content type="html" xml:base="https://danielbernal.co/writing/why-your-ios-automation-setup-doesnt-work.html"><![CDATA[<p>I spent months trying to make AI coding assistants work with iOS development. It was painful.</p>

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

<p>Building an app and running it on a simulator requires orchestrating three separate tools:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>xcodebuild <span class="nt">-workspace</span> MyApp.xcworkspace <span class="se">\</span>
  <span class="nt">-scheme</span> MyApp <span class="se">\</span>
  <span class="nt">-destination</span> <span class="s1">'platform=iOS Simulator,name=iPhone 16,OS=18.1'</span> <span class="se">\</span>
  <span class="nt">-derivedDataPath</span> ./build build

xcrun simctl boot <span class="s2">"iPhone 16"</span>
xcrun simctl <span class="nb">install</span> <span class="s2">"iPhone 16"</span> ./build/Build/Products/Debug-iphonesimulator/MyApp.app
xcrun simctl launch <span class="s2">"iPhone 16"</span> com.example.MyApp
</code></pre></div></div>

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

<p>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.</p>

<p>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.</p>

<p>So I built something that was.</p>

<p>I’ve been working on <a href="https://flowdeck.studio">FlowDeck</a> 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. <code class="language-plaintext highlighter-rouge">build</code>, <code class="language-plaintext highlighter-rouge">run</code>, <code class="language-plaintext highlighter-rouge">test</code>, <code class="language-plaintext highlighter-rouge">clean</code>, <code class="language-plaintext highlighter-rouge">logs</code>, <code class="language-plaintext highlighter-rouge">stop</code>, <code class="language-plaintext highlighter-rouge">context</code>, <code class="language-plaintext highlighter-rouge">init</code>. Each does one thing. Structured outputs. Predictable errors.</p>

<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code>flowdeck run <span class="nt">-S</span> <span class="s2">"iPhone 16"</span>
</code></pre></div></div>

<p>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.</p>

<p>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.</p>

<p>The toolchain fragmentation is Apple’s problem. I got tired of waiting for them to fix it.</p>]]></content><author><name>Daniel Bernal</name></author><summary type="html"><![CDATA[Apple ships five different command-line tools for iOS development. They don't talk to each other. This broke my AI-assisted workflow, so I fixed it.]]></summary></entry></feed>