Daniel Noworyta

My website did not sound like me

daniel.noworyta@gmail.com — Sat, 05 Sep 2026 00:00:00 GMT

This afternoon I read my own About page the way a stranger would, and I did not like the guy.

He had a “journey”. Four of them, actually. He wrote that his story was “proof that anyone can turn their dreams into reality”. He said his life had “transformed”. Everything was finished, everything had a bow on it, and none of it was true in the way that matters, because nothing in my life is finished. The job I fought for is being rewritten under me, and the About page did not mention that once.

The homepage was worse. No photo. My name only in the logo. A headline about engineers “thriving in the AI era” and a form. A squeeze page wearing my name.

I have a document called VOICE.md. It is long, and it says exactly what my writing is supposed to be: warm and serious at the same time, told from inside the work, never resolved before it is actually resolved. “Journey” is on its blacklist. So are em dashes. My site had four journeys and em dashes on every page.

I had written the rules, and I had broken every one of them, and I had not noticed for a year.

The page that already sounded like me

There was one exception. The Habits page, where my weight is logged in public every morning. 109.6 kg today, aiming for 94, a dashed line showing whether I am ahead of the plan or behind it. Nobody planned that page as a brand exercise. I built it because a streak nobody can see is easy to quietly drop.

It was the only page on the site that was still in progress. Which is why it was the only page that sounded like me.

That told me what the rewrite had to do. Not polish. Unfinish.

Four pages, seven commits, one afternoon

So I rewrote it, with Claude Code doing the typing and VOICE.md loaded as the brief. The homepage now opens with my face and one line: I started over once. About ends without a bow, on a sentence about not knowing what this job means in three years. Experience got the decade in automotive back, the most important line on that page and the one I had left off. Uses went from product descriptions to one opinion per tool. The blog became Writing, and the three posts that had been handing their search credit to LinkedIn are canonical here now.

Then the thing broke that always breaks.

Wrong facts in the right voice

The model got my life wrong, and it did it with conviction. It wrote the Uses page from a list that was a year stale and described, warmly, why I love a terminal I stopped using months ago and a notes app that is no longer in my stack. It called me a React Native developer. I am a full-stack developer who writes React Native at work.

None of that was the model’s fault. It only knew what the old site told it, and the old site was wrong. But here is the part that stayed with me. I read those paragraphs twice before I caught them, because they sounded like me. Wrong facts in a wrong voice jump off the page. Wrong facts in the right voice walk straight past you.

If you are using these tools to write as yourself, that is the failure to watch for. Not the sentence that sounds like a robot. The sentence that sounds exactly like you and is not true.

The sentence I did not type

Here is what I do not have an answer for.

I did not type “I started over once.” I described the person, handed over the guide, and the sentence came back. I read it and thought, yes, that is exactly it. So is it mine? I wrote the rules it followed. I cut the lines that were wrong. But the sentence that now sits at the top of my site, the one that is supposed to be the most me thing on it, was drafted by a model.

I do not know what to call that yet. I am not going to pretend I do, and I am not going to take the sentence down either.

If you have a site, read your About page tonight as a stranger. Count the journeys. Then check whether the last paragraph is finished, and whether you are.

I still read my About page as a stranger. The difference is that now I recognise the guy. He is not done. He says so. And he is getting weighed tomorrow at seven, before coffee, same as today.

Ship something every sprint - not for the team, for yourself.

daniel.noworyta@gmail.com — Tue, 17 Feb 2026 00:00:00 GMT

Some sprints I ship nothing meaningful.

I do my work. I close my tickets. The board looks clean. But when the sprint ends, I have this hollow feeling, like I moved cards across a board but didn’t move anyone’s life forward.

It bothers me more than it should.

This last sprint was different. I remembered a wish from our customers, something small, something nobody had planned. Drag and drop. A feature that would save them minutes of tedious work every single day.

So I built it. Not instead of the sprint goal, on top of it. And when I finished, I felt something that had been missing for a while.

I felt like I actually mattered.

Two Sprints, Two Feelings

Here’s what I’ve learned after years of sprints: the difference between a good sprint and a forgettable one is rarely about how much code you wrote.

It’s about whether you can point at something and say: this made someone’s work easier today.

That sounds obvious. It’s not. Because most of us, especially senior devs, spend entire sprints buried in infrastructure, refactoring, internal tooling, migration scripts. Important work. Necessary work. But work where the human at the end of the chain is invisible.

And when the human is invisible, the meaning disappears with them.

Code Was Everything, Until It Wasn’t

Earlier in my career, I measured myself by code. Clean abstractions. Elegant solutions. Clever patterns.

That mattered to me. It still does.

But somewhere along the way, I started asking a different question. Not “is this code good?” but “will someone’s Tuesday be easier because of what I shipped?”

That shift changed everything. Not what I build, but why it feels worth building.

The Sprint Goal Comes First. Always. I need to be honest about the tension here.

You can’t ignore the sprint goal. You committed to it. Your team depends on it. Going rogue because you had a “better idea” is not what I’m describing.

The sprint goal comes first. Always.

But here’s what I’ve noticed: most sprints, if you’re focused and intentional, there is space. Not a lot. Maybe a few hours. And the question is, what do you do with that space?

Do you gold-plate something that’s already done? Do you start scrolling? Or do you ask yourself: what’s one small thing I could ship that would make someone’s day?

I don’t always find that space. Some sprints are packed. That’s real. But when I do find it and waste it, I feel it at the end.

The Visualization Test

Here’s what I’d challenge you to try in your next sprint.

Before the sprint starts, close your eyes. Visualize the end of the sprint. Imagine you’re showing your work to the people who use it. What are you showing them?

If you feel excitement, genuine excitement, not obligation, you’re on the right track. Your sprint goal is already user-centric. Run with it.

But if you feel nothing, if the demo in your head is just “we refactored the service layer,” ask yourself one more question: what’s one low-hanging fruit, aligned with the sprint goal, that would make people care?

Not a side project. Not scope creep. One small thing that connects your work to the human on the other side.

Why I Do This

I know my customers. I know how hard they work. I know that sometimes their tools make a hard job harder, and they don’t complain about it, they just push through.

I think about that. Probably more than I should.

And when I can ship something, even something small, even drag and drop, that takes one frustration off their plate, it reminds me why I became a developer in the first place.

Not to write code. To make someone’s work a little more human.

That feeling doesn’t come from closing tickets. It comes from knowing that someone, somewhere, had a slightly better day because of what you shipped.

Ship something every sprint. Not for the team. For them.

Navigating the New Engineering Reality

daniel.noworyta@gmail.com — Wed, 11 Feb 2026 00:00:00 GMT

The industry conversation around AI is currently caught between two extremes: a dismissive “it’s just a better autocomplete” and a panicked “time to learn how to grow vegetables”. But beneath the noise, a structural transformation is happening that goes far deeper than just a new tool. We are witnessing the final collapse of the “specialized assembly line” model of development, and it is fundamentally redefining what it means to be an engineer.

The “Code-Clapper” Era is Over

Historically, IT functioned like an assembly line where an analyst wrote requirements and a developer simply translated them into syntax. That model was already dying, but AI has finally buried it. Today, the “grunt work”—repetitive boilerplate and standard endpoints—is being commoditized. If your value was purely in manual implementation, that value is eroding.

The Review Paradox

AI can generate 1,000 lines of code in seconds, but it often lacks the historical “why” behind a system’s quirks. This creates a paradox: AI-generated code often looks cleaner, but it is harder to review because it “guesses” when it lacks context. As a senior engineer, responsibility doesn’t disappear; it intensifies. You remain the ultimate gatekeeper for every line of code, ensuring that “guesses” don’t turn into expensive production failures.

The New Entry Fee: Garage Experience

Junior developers are facing the steepest climb. Because AI handles entry-level tasks so efficiently, firms now view juniors as long-term investments rather than immediate assets. To break through, you need “garage experience”—demonstrable personal projects and the ability to act as a one-person team using these tools to solve real problems.

Programmers as Conductors

The most important shift you can make is in your self-concept. You are moving from being a performer who executes technical tasks to a conductor of an army of AI agents. The core skill is no longer “how do I write this function?” but “how should this system work?”. Your value now lies in your decision-making potential and your ability to orchestrate complex results.

Strategic Steps for the AI Era

Embrace Role Consolidation: The modern market no longer rewards specialists who stay in a silo. You must be a multi-disciplinary professional who understands the business domain, designs local architecture, and manages quality assurance. AI is the leverage that allows one person to handle this entire lifecycle.
Prioritize Value over Volume (Minimize Waste): Development is “waste” until the point when real users can start using the product. AI can help you write code faster, but “faster waste” is not a business win. Ensure your speed is aligned with the business’s ability to test, deploy, and adopt changes.
Audit Non-Technical Bottlenecks: Writing code is rarely the true delay in software delivery. Focus on identifying and fixing bottlenecks in decision-making, security auditing, and release management. AI speeds up the typing, but it won’t fix a broken organizational process.
Enforce Domain Grounding for AI: Never treat AI as a plug-and-play tool for complex systems. Without being grounded in your specific systems history and business rules, AI will guess, which is a high-risk behavior in professional environments. Always provide the tool with the necessary domain context before implementation.
Cultivate “Decision-Making Potential”: Shift your learning focus from syntax and library functions to architectural patterns and system design. Your seniority is now measured by your ability to critically review AI output and make high-stakes technical decisions that AI cannot yet handle.
The Reality Check: Remember that. If an AI license could truly replace a developer, companies wouldn’t be debating safety and costs—they would be mass-firing. We are in a phase of collective experimentation where human oversight remains the indispensable pillar of trust.

Your value isn’t found in your typing speed; it’s found in your judgment. In a world of AI-generated noise, your ability to make the right decision is the only thing that won’t be commoditized.

AI and the Future of Programming

daniel.noworyta@gmail.com — Tue, 13 Jan 2026 00:00:00 GMT

I love handcrafted code. I love the elegance of a well-designed function, the satisfaction of a clean abstraction, the quiet pride in a system that works because you understood every line. That romance with the craft never left me.

But I can no longer pretend we have time.

I left my automotive career to fulfill my dream: becoming a software developer. I know what it means to start over, to bet on yourself, to learn a new craft from scratch. That journey meant so much to me that I started a YouTube channel to help others make the same transition to show them the path I’d walked.

But the path is changing faster than I expected.

What I Built in Hours, Not Weeks

A few months ago, I had a problem: I needed to track my finances. Before AI, I would have searched for an existing app, compromised on features I didn’t need, and lived with limitations that didn’t fit my workflow. Or I would have spent weeks, maybe months building something myself, learning the full stack piece by piece, debugging late into the night.

Instead, I built a fully functional full-stack application in TypeScript. With AI assistance, what would have taken me weeks took hours. The app works. It does exactly what I need. It’s mine.

I want to be clear about what this means. The code that came out wasn’t sloppy or prototype-quality. It was production-grade. It worked.

The bottleneck has shifted. Writing code is no longer the hard part. Understanding what needs to be built, knowing how the pieces should fit together, being able to evaluate whether the output is correct; these are the skills that matter now. Typing was never the point. It was always about thinking. But now the ratio between thinking and typing has changed dramatically.

Why This Matters

I know there’s noise in the market. Stock prices swing wildly. CEOs make grandiose claims. The hype cycle churns through excitement and disappointment in predictable waves. It’s tempting to dismiss all of this as another bubble, another overpromise, another technology that won’t live up to the marketing.

Ignore all of that. Watch what the tools actually do.

The shift I’m describing isn’t about valuations or investor sentiment. It’s about capability. The underlying technology has crossed a threshold, and it’s not going back. Every month it gets better. Every month the gap between what you could build alone and what you can build with these tools widens further.

The programmers who will thrive are the ones who can isolate problems cleanly, communicate intent precisely, and hold accurate mental models of complex systems. The skills haven’t changed, but the leverage they provide has been multiplied.

The Opportunity

I remember when I was learning how to code, staring at tutorials late at night, dreaming about what I could become. I wanted to be a full-stack machine, someone who could solve any problem with code. Need a backend? I’ll build it. Need a frontend? Done. Database, API, deployment? All of it. No limitations, no waiting on others, just pure capability to turn ideas into reality.

That dream always felt distant. There was so much to learn. So many frameworks, languages, patterns, best practices. Years of work just to become competent across the stack, let alone masterful.

Now that dream is within reach.

A single developer with domain expertise and clear vision can prototype in days what would have taken months. The barriers to building have dropped, and they’re still dropping. You don’t need a team anymore. You don’t need to specialize so narrowly that you can only build half of what you imagine.

For me personally, this means more building, not less. The things I always wanted to create but couldn’t justify the time investment, now I can build them. Side projects that would have taken years can happen in weeks. The constraint was never ideas. It was always time and energy. That constraint just loosened significantly.

The Concerns

I’d be lying if I said I’m not worrying.

There’s an obvious centralization risk. The most powerful models are controlled by a handful of companies. The infrastructure required to train them is extraordinarily expensive. This isn’t a technology that emerged from a garage; it came from organizations with billions of dollars in computing. That concentration of capability in few hands is genuinely concerning, and I don’t have easy answers.

Job displacement is real. We can debate the timeline and the extent but pretending it won’t happen is a fantasy. Some roles will disappear. Some people will be fired. The junior developer is learning the ropes by writing simple features. What happens to that path when a senior developer with AI tools can do the same work in a fraction of the time?

I don’t think the market will solve this by itself. We’ll need political and social responses: better safety nets, retraining programs, perhaps more radical rethinking of how we distribute the gains from increased productivity. These are not technical problems, and technologists shouldn’t pretend they are.

What Programmers Should Do Now

If you’re a working programmer, here’s my honest advice.

Don’t refuse reality. I understand the instinct. These tools threaten something we’ve built our identities around. The years spent mastering a craft, the hard-won expertise, the quiet knowledge that you can do something most people can’t, it’s painful to watch that advantage erode. But refusing to engage won’t protect you. It will only leave you unprepared.

Test these tools seriously. Not for five minutes. Not with a toy example that confirms your skepticism. Spend weeks with them on real problems. Push them. Find their limits. Develop an accurate model of what they can and cannot do. Your livelihood may depend on this knowledge.

And remember why you started coding in the first place.

It wasn’t because typing syntax was fun. It wasn’t because you enjoyed the mechanics of compilation. It was because you wanted to build things. You had ideas in your head, and you wanted to make them real. That’s the fire. That’s what drew you in.

That fire is still there. And now you can build more.

The joy was never about typing. It was about the building. And now, if you’re willing to adapt—you can build more than you ever imagined.