DEV Community: Marceli Pawliński

Sloth Mode: local Gemma turns a brain dump into one small next step

Marceli Pawliński — Thu, 22 Oct 2026 08:37:51 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady. 🦥

Pay the electricity bill tomorrow. Read a chapter when I have time. I already tidied the desk.

A to-do list can hold all three. I still have to decide what matters, what can wait, and what no longer needs doing. On a tired day, organising the list becomes another task on the list.

I built Sloth Mode to make that first decision smaller: put rough notes in one place, let a local Gemma model suggest a plan, then choose what to do with it. The private notes can stay on the computer doing the thinking.

What I Built

Sloth Mode is a task companion for the loose ends you capture before you know what to do with them. Gemma suggests a priority, category, short summary and next action for each selected note. Each suggestion points back to its original note, so you can check the wording before accepting it.

It is for someone who wants help starting without first maintaining an elaborate productivity system. The model drafts the organisation; the person can edit, ignore or act on it. Sloth Mode does not send messages or execute the suggested tasks.

There are three ways to explore it:

Route	What happens	What you need
Quiet Lab	An illustrative, rules-based preview of the interaction	A browser; no account or download
Native Gemma	Real Gemma 3 GGUF inference through a local Go companion and `llama.cpp`	Windows preview or experimental Linux build; separate model/runtime download and explicit browser pairing
Browser Gemma beta	An experimental Gemma 4 E2B path using WebGPU/LiteRT-LM	Compatible hardware/browser and an approved model download of about 2 GB; wider compatibility is still unverified

An optional account holds a separate list of tasks you explicitly save there. Signing in does not silently upload the local inbox or grant access to the companion.

Demo

Try the guest workspace →

Start with Quiet Lab and its sample notes. It is the quickest way to understand the interaction, and it is labelled as a preview: it does not call Gemma.

Watch the actual local model run

Download the uncut 41-second recording (MP4, 1.7 MB)

The recording shows a browser paired with the real Go companion, Gemma 3 4B Q4_K_M running through llama.cpp, and the resulting suggestions. It then checks editing, export and reconnecting after a reload. Clicking Plan to seeing results took 25.063 seconds, including model loading and UI polling, with four CPU threads and zero GPU layers. The files were already installed.

The lab report due before 4 PM today and the borrowed book due tomorrow both become Do next. Optional reading becomes Save for later; an already submitted form becomes No action. Gemma still drops timing from the first two suggestions. The status points to their original notes so the person reviewing the plan can catch it.

This uses a labelled local copy of the workspace, fictional notes and the production pairing/planning handlers. It is actual model output, with no mocked planning responses, cuts or speed changes. It does not demonstrate a clean installation, model download or machine-wide offline operation. The recording notes, raw responses and reproduction steps make that boundary explicit.

The earlier promotional overview remains available:

This is a promotional overview, separate from the real-model recording above.

Trying the native path

Get the refined Windows preview and SHA-256 under Artifacts → SlothMode-Windows-Preview. GitHub may require a login. This is an unsigned candidate from PR #34; you can also build from that source.
Install the companion for your Windows account. Open Setup & Pairing, then pair the browser you trust.
Separately approve the Gemma model and runtime download. Use fictional notes for your first plan and review the suggestions.

The native model download is several GB, depending on the quantization. An account and Ollama are not required. The judges' quickstart includes an opt-in real-model test for a machine with those files installed.

On 24 October I also refined the installer. Its old preview clipped text and made it too hard to see what would happen next. The new candidate in PR #34 separates installation, browser pairing and the optional model download, with readable status and a layout that fits the monitor. The linked candidate passes Linux, Windows and cloud CI plus CodeQL checks. A full clean-profile installation and pairing run for this candidate is still pending.

The actual native UI in a safe layout fixture. This image demonstrates the interface, not a completed installation or inference run.

Code

Source for the tested Windows candidate · Repository main

The Go companion is in connector/, the Windows installer in installer/, the browser workspace in web/, and the reference account service in cloud/. Application code is MIT-licensed; Gemma weights and the runtime retain their own terms.

The first commit is dated 20 October 2026, inside the Week 3 build window. The installer refinement and evaluation files are reviewable separately from main. The live website is deployed separately too; cloning the reference account Worker does not recreate every production account binding.

How I Built It

Keep the private work on the computer

The native path is straightforward:

Browser workspace
  -> explicit pairing with 127.0.0.1
  -> Go companion reads selected local notes
  -> Gemma 3 GGUF runs through llama.cpp
  -> validate structured suggestions and original note IDs
  -> show the plan for a person to review

Model weights and runtime archives are downloaded separately after approval and checked against expected hashes. The local service binds to loopback. A cloud sign-in is not a replacement for pairing with that service.

The validator checks IDs and structure before accepting a plan. It can reject an invented or duplicate note ID. It cannot prove that a fluent summary kept every important detail.

Valid JSON is not a good plan

The first three-note run made the bill less urgent and treated optional reading as requiring no action. Explicit priority rules and examples helped, but another run paired an actionable bill with “No action needed.” That was a useful reminder to check both the label and the proposed action.

On 24 October I froze 12 new fictional notes and their expected priorities before inference, then ran the baseline and candidate once each with the same existing model, four CPU threads, zero GPU layers and temperature zero.

Check	Baseline	Candidate
Matches the predefined priority	9/12	12/12
Repeats recognised timing in the summary or next action	0/9	1/9

Restoring explicit priority rules helped this small set. The second row is the unresolved problem: correct labels can hide missing details. A limited English phrase check now flags actionable suggestions that omit recognised timing and points back to their source notes. All seven such omissions in the candidate's recorded output trigger that warning. It does not calculate dates, understand every deadline or repair the model's wording.

The frozen inputs, raw candidate output and scoring method are public. Categories were not scored. These 12 examples are functional checks, not a representative accuracy benchmark or a measurement of effort saved.

The older evaluation is a different 12-note set: its baseline matched 12/12 priorities, while a timing-preservation experiment fell to 11/12. Those historical inputs and outputs remain published, including their missing prompt snapshot. I keep them separate from the new frozen comparison.

Keep suggestions attached to the right draft

A person can edit a note while a local model is still thinking. Applying the old answer to the new wording would make the plan misleading. The companion now checks the entire input snapshot under the storage lock before saving suggestions. If any input was edited, completed, deleted or already classified, it rejects the batch without saving a partial plan. Capturing an unrelated new note is allowed. Regression tests cover those cases and confirm that rejected batches leave the notes file unchanged.

Setup deserves the same care

A local model is not useful if getting it running feels like another project. The installer refinement uses explicit font roles, consistent backgrounds and DPI-aware fitting. Installation and update work run off the UI thread, failed replacement can restore the previous app, and starting a process alone does not count as success: the installer checks the companion's local health response.

The new candidate passes 12 installer tests, connector tests, Windows builds and static analysis. Text fitting and window bounds are checked at multiple scales; the native layout, Tab focus and Escape were also inspected. Those checks do not substitute for installing the candidate on a clean profile. The verification report distinguishes them.

Final preparation also caught a Q6 output-format failure: Gemma combined priority and category as now/work. I replaced the shorthand examples, constrained decoding to the expected schema, and retested the failing fictional note through the live site. The acceptance notes include a three-note CPU run and distinguish an existing-profile upgrade from clean-install and offline testing.

On 25 October, the final local Windows build passed an existing-profile upgrade, normal exit and relaunch, live-browser reconnect and real Q6 CPU inference with a fictional note. The installed executable matched its packaged checksum; personal notes and the launch-at-sign-in setting were unchanged. The model still omitted timing from that note, and the live UI flagged the omission beside its source. The final installed-build report and synthetic output record what passed. This was not a clean-profile or network-off test, and the separately compiled CI download was not installed in that run.

Why Does Open Innovation Matter?

For a private task inbox, where the model runs matters. Open-weight Gemma and llama.cpp let the companion process the notes locally, without a hosted inference account or a per-prompt API bill. There are still costs: memory, storage, electricity and the initial download.

It also lets me inspect the prompt, change quantization and runtime settings, and repeat the same fictional cases. The deadline failure above is visible in the published output. Someone else can study it or change the handling rather than trusting a screenshot of the best result.

After downloading the model and runtime, native inference can run without an internet connection. Earlier Windows previews have an owner-reported successful offline/restart/persistence check. That is one person's report on older builds; the final local build has passed the upgrade and CPU checks above, while independent clean-profile and offline acceptance remain open. The hosted website and account services continue to need connectivity.

The Lazy Payoff

The effort I want to remove is the sorting between “I should remember this” and “here is one thing I can start.” Gemma drafts priorities and next actions so I have something small to review.

I have not measured minutes saved per day or run a multi-user study. My evidence is narrower: a real browser-to-model recording, predefined fictional examples with their failures, a working guest preview, and owner experience on one Windows environment. A useful next study would compare manual sorting with assisted sorting on the same fictional backlog, including review time, mistakes and setup cost.

This is still a public beta. Signed installers, independent native security review, wider Linux/GPU coverage, a clean-install recording and independent offline acceptance remain unfinished. Browser Gemma is experimental. The release checklist keeps those gaps visible.

Prize Categories

Best Use of Gemma. Gemma does the native task planning, with its suggestions tied to the notes that prompted them. The browser beta explores a separate Gemma execution path; the no-download preview is clearly labelled as illustrative.

If that sounds useful, try the guest workspace or report what breaks using fictional notes. I wanted a tool that makes the next task feel smaller. That is the test I want Sloth Mode to pass.

A Browser Automation CLI Is a Security Boundary, Not Just a Convenience Tool

Marceli Pawliński — Sat, 10 Oct 2026 13:59:43 +0000

I like tools that make tedious tasks shorter. One of my projects, browser-harness, is a command-line wrapper around browser automation: open a page, extract text, take a screenshot, fill a form, or run JavaScript in a page. Building it exposed different parts of how browsers work.

But reviewing a browser tool through a security lens raises a less comfortable question: who gets to decide what the browser is allowed to do?

That matters even more when an AI agent is choosing commands. An automated workflow might accept the next URL or instruction without questioning it.

This article is a review of the design trade-offs visible in my public repository, not an announcement that I've fixed them all. The standalone project is kept for reference; its README points to system-automation for newer development.

The convenience is real

The CLI exposes commands such as open, text, screenshot, fill, cookies, and exec. Those operations look like small, separate utilities, but they share something important: each is acting with the authority of a browser process.

Screenshots can capture sensitive information; cookies can reveal sessions; forms can change remote state. Page JavaScript gives the caller access to the live document and browser APIs.

Those capabilities are useful. The problem is treating them as interchangeable without distinguishing observation from action.

Read-only is a useful distinction, but not a guarantee

For an agent, I would start by dividing browser operations into three groups:

Observation: read a page title, extract visible text, inspect public metadata.
Potentially sensitive observation: screenshots, cookies, authenticated page content.
State-changing or privileged actions: form submissions, clicks that trigger transactions, downloads, arbitrary page JavaScript.

The categories aren't perfect: even a GET request may have side effects, and screenshots can reveal private information. But explicit categories are better than none.

A practical interface could label an action before execution and require an additional approval step for sensitive reads or writes. Logs could then record the action, target origin, category and approval.

A URL is input, not permission

One weakness to watch for in any browser automation interface is unrestricted navigation. If an agent receives a URL from an untrusted page and immediately opens it, the page has influenced where the agent goes next.

An allowlist can reduce that risk. At minimum, normalise and parse the destination before comparing it with the permitted origins:

function isAllowedDestination(input, allowedOrigins) {
  let url;
  try {
    url = new URL(input);
  } catch {
    return false;
  }

  return (url.protocol === 'https:' || url.protocol === 'http:') &&
    allowedOrigins.has(url.origin);
}

This is only a starting point. Real implementations also need to check redirects, DNS and network destinations where relevant, and the difference between a public website and a local or private address. A valid URL is not necessarily a permitted destination.

`exec` changes the trust model

The exec command in my repository is a useful example. It accepts JavaScript to run in the page context. That's flexible for debugging and extracting information, but it also means the caller is no longer limited to a small set of predefined operations.

If the caller is an AI agent that has read instructions from a webpage, the risk is not simply that the agent might make a mistake. The webpage may contain instructions designed to redirect the agent's behaviour. That's a prompt-injection problem crossing into browser privileges.

For a safer agent-facing design, I would avoid offering unrestricted script execution as the default. Prefer narrowly scoped commands with defined inputs and outputs. If arbitrary execution is necessary, keep it behind a separate permission boundary, restrict the environment, and record exactly what was run. Cookie export needs similarly strict treatment.

Headless browser flags deserve attention too

The current public browser.js includes a launch configuration with --no-sandbox. This is common in constrained container examples, but it is not a security improvement. Removing the browser sandbox weakens an important layer of isolation.

A production design should prefer running with the sandbox enabled wherever the environment supports it. If a deployment genuinely requires a different configuration, that exception should be documented and constrained by other isolation measures. Convenience flags can outlive their original justification.

What I would test before trusting an agent with it

I would build a small test matrix rather than rely on one happy-path demo:

A normal page with a valid title and visible text.
A page that redirects to an origin outside the allowlist.
A page containing instructions that try to change the agent's task.
A form where submission must be explicitly authorised.
An authenticated page containing data that must not appear in logs.
A navigation timeout or browser crash, followed by cleanup.

Those are proposed tests, not results I'm claiming to have run. Each should have an expected decision and an observable reason for it. A blocked action is a successful outcome when blocking was the intended policy.

The lesson I keep returning to

Automation is often described in terms of what it can do. I think the more useful question is what it should refuse to do without additional context.

Building browser-harness helped me understand the mechanics of controlling a browser. Reviewing it this way makes the next design problem clearer: a good agent tool needs capabilities, but it also needs boundaries, predictable failures, and evidence of what happened.

The repository is public if you want to inspect the commands and make your own assessment: marceli1404/browser-harness. I'd be interested in how other developers separate safe inspection from privileged browser actions.

Why a 200 OK Doesn't Mean Your Website Is Healthy

Marceli Pawliński — Fri, 09 Oct 2026 08:57:55 +0000

I used to think that checking whether a website worked was fairly straightforward: send a request, get a successful response, and move on.

The more I work on web tooling, the less useful that definition feels.

An HTTP 200 OK response answers one narrow question: did the server successfully handle this particular HTTP request? It does not tell you whether the website is secure, accessible, fast, searchable, or even useful to a visitor.

That distinction is part of what interests me about building Zenith, a project focused on monitoring and improving websites. A meaningful website check needs to look beyond a green status indicator.

Here are five layers I would examine, and how I'd begin testing them.

1. Availability isn't the same as usability

Try:

curl -I https://example.com

The response can tell you about status codes and headers. It cannot tell you whether a sign-in button works, whether a critical API fails after the page loads, or whether a JavaScript error prevents users from completing an action.

In fact, curl -I makes a HEAD request. Some servers handle HEAD differently from GET, so it's useful as a quick inspection tool, not as complete proof of normal page behaviour.

For a more realistic picture, check more than one endpoint and include an actual browser journey. For example:

Can the homepage load?
Can a visitor navigate to an important page?
Can a non-destructive form validation flow complete?
Does the browser report failed requests or JavaScript errors?

An uptime check is a starting point, not a quality score.

2. HTTPS is necessary, but it doesn't finish the security job

A padlock indicates that a connection is protected by TLS under the browser's trust rules. That's important. It isn't a certificate of application security.

Look at response headers:

curl -sSI https://example.com

Things worth reviewing include:

Strict-Transport-Security: helps instruct browsers to use HTTPS for future connections.
Content-Security-Policy: can reduce the impact of certain injection attacks when configured carefully.
X-Content-Type-Options: with nosniff, can prevent some MIME-type confusion.
Cookie attributes: Secure, HttpOnly, and SameSite matter for session handling.

Presence isn't enough. For example, a CSP that broadly permits unsafe inline scripts may provide less protection than its name suggests. And missing a header does not automatically mean a site is exploitable: context matters.

Also, please don't run intrusive security scans against sites you don't own or have permission to assess. Public response-header inspection and authorised testing are different things from attempting exploitation.

3. Accessibility can't be reduced to one automated score

Automated accessibility testing is excellent at catching certain problems: missing accessible names, insufficient contrast in some contexts, structural errors, and more.

But a passing automated test doesn't mean someone can actually use the interface with a keyboard or screen reader.

A simple manual starting point:

Put down the mouse.
Use Tab and Shift+Tab to move between controls.
Check whether the focus indicator is visible.
Try the main interaction using the keyboard alone.
Verify that errors are understandable and connected to the appropriate inputs.

An interface can look polished and still exclude people. I think that should be considered a functional bug, not just a design issue.

4. Performance depends on the user, not just the server

A fast server response isn't necessarily a fast experience.

There are differences between receiving the initial HTML, displaying meaningful content, and making the page responsive to interaction. Large images, render-blocking resources, third-party scripts, and heavy client-side work can change what visitors experience.

For an initial lab measurement, use Lighthouse in Chrome DevTools. For real-user context, look at Core Web Vitals such as Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift.

I would always record the device, network conditions, URL, time, and measurement method. Otherwise it becomes too easy to compare two numbers that aren't really comparable.

5. Being online doesn't mean being discoverable

A search engine has to find, crawl, render where necessary, and understand a page before ranking becomes relevant.

Some straightforward checks:

curl -I https://example.com/robots.txt
curl -I https://example.com/sitemap.xml

Those paths are useful places to look, not universal guarantees. A site may use different sitemap locations, and a successful response does not prove correct content.

I would also review canonical URLs, titles, meta descriptions, redirect behaviour, indexing directives, and whether important content can be accessed without relying on fragile client-side behaviour.

The part I find most useful: evidence before scores

One tempting approach is to merge all these checks into a single score out of 100.

Scores can be helpful for prioritisation, but they can also hide important details. A critical security configuration problem should not disappear because the site has excellent SEO or performance metrics.

For every finding, I think a useful report should answer four questions:

What was observed? Include the exact URL, response, test or reproducible behaviour.
Why might it matter? Explain the consequence without overstating it.
What should change? Give a concrete, proportionate next step.
How do we verify the fix? Repeat the same test, and add a stronger check if needed.

That last point matters most to me. Identifying problems is easy to celebrate. Demonstrating that a change actually solved one is more useful.

I'm still learning how to make these kinds of checks reliable and understandable. Building website tools keeps revealing the difference between what a system appears to be doing and what we can actually verify.

A 200 OK response is good news.

It just isn't the whole story.

I'm Marceli Pawliński. I build and experiment with software, cybersecurity, AI and website infrastructure. My main project is Zenith.

Curiosity Over Comfort

Marceli Pawliński — Tue, 06 Oct 2026 21:47:16 +0000

I’m More Interested in Why Things Break Than Why They Work

I don’t think I became interested in technology because I wanted to build apps.

I think I became interested because I wanted to understand things.

There’s a difference.

When something works exactly as expected, there usually isn’t much mystery left.

You press a button, something happens, and you move on.

But when something breaks, everything becomes more interesting.

Why did it fail?

Was the assumption wrong?

Was the system badly designed?

Did someone trust something they shouldn’t have?

Was the problem in the interface, the network, the database, the user, or somewhere deeper?

That way of thinking has probably shaped most of what I build.

I Like the Parts People Usually Ignore

A lot of software is designed to hide complexity.

That is normally a good thing.

Most people do not care how a request is routed, how authentication is validated, how a database transaction is handled or how an AI model receives context.

They just want the thing to work.

I tend to get interested in the hidden part.

I want to know what happens between clicking a button and getting a result.

I want to know what happens when that process is interrupted.

I want to know what assumptions the developer made and what happens if those assumptions are wrong.

That is part of why cybersecurity became interesting to me.

Security often lives in the gap between what a system appears to do and what it actually allows.

Building Things Is Mostly Discovering What You Don’t Know

One of the strangest things about programming is that the more I learn, the less I feel like I know.

When I started building websites, a website felt fairly simple.

Frontend.

Backend.

Database.

Done.

Then you start learning about authentication, caching, queues, rate limits, browser behaviour, network failures, accessibility, search engines, deployment, monitoring, observability and security.

Suddenly a “simple website” doesn’t seem simple anymore.

The same thing happened when I started experimenting with AI.

At first, the interesting part was the model.

Which one is smarter?

Which one is faster?

Which one can run locally?

Eventually the model became only one small part of the problem.

A model can be extremely intelligent and still be useless if the system around it is badly designed.

It needs context.

It needs tools.

It needs boundaries.

It needs a way to fail safely.

It needs to know what it is allowed to do.

That is where things get much more interesting.

I Don’t Really Separate Learning From Building

I’ve never been very good at learning something just because I’m supposed to know it.

I understand things much better when I need them.

If I need a database for a project, I learn about databases.

If authentication breaks, I learn more about authentication.

If a website is slow, I start learning about performance.

If a deployment fails, I learn what the infrastructure is actually doing.

That process is sometimes inefficient.

I’ll probably make mistakes that someone with more experience would avoid immediately.

But those mistakes normally stick with me.

There is a big difference between reading that something is a bad idea and spending six hours discovering why it is a bad idea.

Zenith Is Really an Excuse to Learn

My main project, Zenith, is technically a website monitoring and improvement platform.

But for me, it is also an excuse to keep exploring problems.

Security.

Performance.

Accessibility.

SEO.

Infrastructure.

Automation.

AI.

Databases.

Product design.

They all meet in one project.

I could probably make Zenith much smaller and easier to build.

That would also make it less interesting.

I like projects that slowly force me outside what I already know.

Open Source Changed How I See Programming

Building your own projects gives you complete control.

That is both useful and dangerous.

If something is badly designed, you can always rewrite everything around it.

Open source removes that freedom.

When you contribute to someone else’s project, the question is not:

“How would I build this?”

It is:

“Why did they build it this way?”

You have to understand before changing.

You have to work with existing conventions.

You have to think about the people who already depend on the code.

I like that.

It makes programming feel less like writing instructions for a computer and more like working inside a system built by people.

I’m Still Figuring Out What I Want to Become

I’m interested in computer science, cybersecurity, AI and systems engineering.

That is a fairly wide answer.

For now, I’m okay with that.

I don’t think I need to decide exactly what I want to specialise in yet.

I would rather keep following the problems that make me curious.

The common theme seems to be systems.

Not just how to build them, but how they behave when something unexpected happens.

That could mean security.

It could mean infrastructure.

It could mean AI systems.

It could end up being something I haven’t discovered yet.

The Goal Isn’t to Know Everything

I used to think being good at technology meant knowing the answer.

Now I think it is more about knowing what to do when you don’t.

Can you break a problem apart?

Can you find the part you don’t understand?

Can you test your assumptions?

Can you admit when an idea was wrong?

Can you keep going when the first solution doesn’t work?

That matters more to me now than memorising every framework or programming language.

Technology changes too quickly for that anyway.

There will always be another tool.

Another language.

Another model.

Another platform.

The useful part is learning how to learn.

And preferably building something interesting while doing it.

I’m Marceli Pawliński.

I build software, experiment with AI, contribute to open source and spend an unreasonable amount of time trying to understand why things behave the way they do.

Most of the time, the best place to start is when something breaks.

About Me: Building, Breaking and Learning Through Software

Marceli Pawliński — Tue, 06 Oct 2026 21:33:56 +0000

About Me: Building, Breaking and Learning Through Software

Hi, I’m Marceli Pawliński.

I’m a student from Scotland interested in computer science, cybersecurity, artificial intelligence and software engineering.

Most of what I know has come from building things, breaking them, fixing them, and then realising there was probably a better way to build them in the first place.

How I Got Into Computing

Computers have been part of my life for as long as I can remember.

Over time, that turned from simply using technology into wanting to understand what was happening underneath it.

I started experimenting with programming, websites, servers, local AI models and cybersecurity.

The more I learned, the more interested I became in what happens when systems stop behaving the way they are supposed to.

That is probably the part of computing I enjoy most.

A system working correctly is useful.

A system failing in an unexpected way is interesting.

What I Build

My main project at the moment is Zenith.

Zenith is a platform designed around one idea:

Monitor, improve and grow your website.

It brings together website monitoring, security checks, performance analysis, accessibility, SEO and growth opportunities.

Building Zenith has pushed me into areas I probably would not have explored otherwise, including:

Cloudflare Workers
databases
authentication
queues
APIs
scheduled jobs
browser automation
security headers
rate limiting
website auditing
AI-assisted analysis

It has also taught me that building a product is very different from building a feature.

A feature can work perfectly on its own and still make no sense inside the wider system.

Open Source

I also spend a lot of time on GitHub.

My GitHub is a mixture of personal projects, experiments and contributions to other repositories.

One project I’ve been working on is browser-harness, where I’ve been exploring how AI systems can interact more reliably with websites and browser interfaces.

I also enjoy contributing to existing open-source projects.

Working on someone else’s code is very different from starting from an empty file.

You have to understand why something was built a certain way before deciding how to change it.

Sometimes a useful contribution is only a tiny fix.

That is still valuable.

AI and Local Models

I started properly experimenting with large language models around 2023.

Since then I’ve worked with tools and models including:

Ollama
llama.cpp
LM Studio
Qwen
Llama
DeepSeek

At first I was mainly interested in the models themselves.

Eventually I became more interested in everything around them.

How does an AI use tools?

How do you give it permissions safely?

How does it interact with browsers?

How do you handle memory?

How do you stop an automated system from doing something it shouldn’t?

How do you make it reliable when the real world is unpredictable?

Those questions are much more interesting to me than simply asking which model has the highest benchmark score.

Cybersecurity

Cybersecurity is another major interest of mine.

I especially like looking at the difference between how secure something appears and how secure it actually is.

A polished login page does not necessarily mean the backend is secure.

A website having HTTPS does not mean everything behind it is configured correctly.

A security feature existing does not mean it has been implemented properly.

That way of thinking has changed how I approach software development in general.

Instead of only asking:

“Does this work?”

I also try to ask:

“How could this fail?”

Learning Outside School

I’m currently studying subjects including Maths and Computer Science, but a lot of my technical learning happens outside the classroom.

I experiment with my own infrastructure, contribute to GitHub projects, build websites, run local AI models and work through technical certifications.

I’ve also completed learning in areas including AI literacy and introductory cybersecurity.

I like structured learning, but I learn best when I can actually use something.

Reading about databases is useful.

Designing one badly, discovering the problems and then fixing it teaches you something different.

What I Want to Do

Long term, I want to work somewhere around the intersection of:

AI, cybersecurity, systems and computer science.

I’m still figuring out exactly what that looks like.

That is partly why I build so many different things.

Every project gives me a slightly better idea of what I enjoy, what I’m good at, and what I still need to understand.

Right now, I’m focused on improving Zenith, contributing more to open source and continuing to build projects that force me to learn things I don’t already know.

If something breaks along the way, that normally makes it more interesting.

Find me

GitHub: github.com/marceli1404

Website: marcelipawlinski.co.uk

Zenith: zenith.me.uk

I’ll be writing here about software development, cybersecurity, AI, open source, website infrastructure and whatever I happen to be experimenting with next.

Building Zenith: What I’ve Learned From Turning Side Projects Into Real Software

Marceli Pawliński — Tue, 06 Oct 2026 21:30:18 +0000

Building Zenith: What I’ve Learned From Turning Side Projects Into Real Software

I’ve built a lot of small projects over the years.

Some lasted a few hours. Some turned into GitHub repositories I still work on. Others eventually became part of something much bigger.

Zenith is probably the best example of that.

What is Zenith?

Zenith started from a fairly simple idea:

What if checking the health of a website didn’t require five different tools?

A website can be online and still have plenty wrong with it.

It might have:

weak security headers
accessibility problems
poor performance
broken redirects
missing SEO metadata
bad configuration
opportunities for growth that nobody notices

Zenith is my attempt at bringing those things together.

The goal is simple:

Monitor, improve and grow your website.

Rather than treating security, performance, SEO and accessibility as completely separate problems, I wanted to build something that looks at a website as one system.

That idea has changed quite a bit while I’ve been developing it.

And that has probably taught me more than the original idea ever did.

Building Things Changes How You Think

When I first started programming, getting something to work felt like the main objective.

If the page loaded, the API responded and the button did what it was supposed to do, that was a success.

I don’t really think that way anymore.

Now I usually start asking questions like:

Why does this work?

What happens when it doesn’t?

What happens if someone sends a request the interface never expected?

What happens when ten thousand requests arrive instead of ten?

That shift has made security and systems engineering much more interesting to me.

A login page can look completely secure from the browser while the backend behind it has serious problems.

A security header can exist while being configured in a way that makes it almost useless.

A website can score well in one audit while still giving users a terrible experience.

The interesting part is normally somewhere underneath the surface.

The Stack Behind Zenith

A lot of Zenith has been built around Cloudflare infrastructure.

I’ve experimented with things including:

Cloudflare Workers
D1
R2
Queues
scheduled jobs
rate limiting
authentication
bot protection
browser-based website analysis

One thing I like about this architecture is that it forces me to think about software differently.

Instead of having one large server doing everything, you start thinking about individual services, boundaries, failures and communication between components.

That introduces new problems.

But those problems are interesting.

What happens when a scan fails halfway through?

What gets retried?

What should be stored?

How much should be trusted?

What happens if one part of the system becomes unavailable?

Those are the kinds of questions I want to get better at answering.

Open Source Has Been Just as Important

A lot of what I’ve learned has also come from GitHub.

My profile contains a mixture of personal experiments, website tooling and contributions to other projects.

One project I’ve been experimenting with is browser-harness, which explores ways of making browser interaction easier for AI systems and automated agents.

I’m particularly interested in the gap between:

“An AI model understands what it should do.”

and

“The AI model can reliably interact with a real application and actually do it.”

Real websites are messy.

Forms behave differently.

Interfaces change.

Authentication exists.

Errors happen.

Pages contain information intended for humans rather than machines.

Making AI systems interact reliably with that environment is a surprisingly interesting engineering problem.

I’ve also spent time looking through existing open-source projects, fixing smaller issues and submitting contributions.

Those smaller changes are useful because they force you to work inside someone else’s decisions.

You can’t redesign everything.

You have to understand the project first.

Sometimes the best contribution is only a few lines of code.

AI Got Me Interested in Systems, Not Just AI

I first started seriously experimenting with large language models around 2023.

Since then I’ve tried different local models, inference tools and hardware setups.

I’ve used things like:

llama.cpp
Ollama
LM Studio
Qwen
Llama models
DeepSeek models
local GPU inference

At first, most of my attention was on the models themselves.

How large are they?

How much VRAM do they need?

How quickly can they generate tokens?

How good are they at coding?

Eventually I became more interested in everything surrounding the model.

Routing.

Tool use.

Memory.

Security.

Permissions.

Browser interaction.

Infrastructure.

APIs.

Failure handling.

A capable model by itself isn’t necessarily a capable system.

The engineering around it matters just as much.

I Still Build Things That Fail

A lot of my projects don't work perfectly the first time.

Sometimes the architecture is wrong.

Sometimes I massively overcomplicate something.

Sometimes I build a feature and later realise it shouldn't exist.

Sometimes I rewrite something that technically worked because I finally understand why the first version was bad.

I think that is one of the best parts of building your own projects.

There’s nowhere to hide.

If your database design is terrible, eventually you have to deal with it.

If your authentication flow is badly designed, you eventually discover why that matters.

If your interface is confusing, real users will find things you thought were obvious completely incomprehensible.

Every failure exposes something you didn’t understand before.

What I’m Working Toward

I’m particularly interested in the overlap between:

computer science, cybersecurity, artificial intelligence and distributed systems.

Zenith happens to touch nearly all of those areas.

There’s website analysis.

There’s infrastructure.

There’s security.

There’s automation.

There’s data.

There’s AI.

And most importantly, there are plenty of problems I still don’t know how to solve properly.

That’s probably why I keep working on it.

I don't just want to know how to make software work.

I want to understand why it works, where it breaks, and how to build it better the next time.

You can follow my projects on GitHub:

github.com/marceli1404

And Zenith is available at:

https://zenith.me.uk

I’ll be writing more about the architecture behind Zenith, security mistakes I’ve found while building web applications, local AI experiments, and the things I learn from contributing to open-source projects.

If you work on similar things, I’d love to hear what you’re building.

DEV Community: Marceli Pawliński

Sloth Mode: local Gemma turns a brain dump into one small next step

What I Built

Demo

Watch the actual local model run

Trying the native path

Code

How I Built It

Keep the private work on the computer

Valid JSON is not a good plan

Keep suggestions attached to the right draft

Setup deserves the same care

Why Does Open Innovation Matter?

The Lazy Payoff

Prize Categories

A Browser Automation CLI Is a Security Boundary, Not Just a Convenience Tool

The convenience is real

Read-only is a useful distinction, but not a guarantee

A URL is input, not permission

exec changes the trust model

Headless browser flags deserve attention too

What I would test before trusting an agent with it

The lesson I keep returning to

Why a 200 OK Doesn't Mean Your Website Is Healthy

1. Availability isn't the same as usability

2. HTTPS is necessary, but it doesn't finish the security job

3. Accessibility can't be reduced to one automated score

4. Performance depends on the user, not just the server

5. Being online doesn't mean being discoverable

The part I find most useful: evidence before scores

Curiosity Over Comfort

I’m More Interested in Why Things Break Than Why They Work

I Like the Parts People Usually Ignore

Building Things Is Mostly Discovering What You Don’t Know

I Don’t Really Separate Learning From Building

Zenith Is Really an Excuse to Learn

Open Source Changed How I See Programming

I’m Still Figuring Out What I Want to Become

The Goal Isn’t to Know Everything

About Me: Building, Breaking and Learning Through Software

About Me: Building, Breaking and Learning Through Software

How I Got Into Computing

What I Build

Open Source

AI and Local Models

Cybersecurity

Learning Outside School

What I Want to Do

Find me

Building Zenith: What I’ve Learned From Turning Side Projects Into Real Software

Building Zenith: What I’ve Learned From Turning Side Projects Into Real Software

What is Zenith?

Building Things Changes How You Think

The Stack Behind Zenith

Open Source Has Been Just as Important

AI Got Me Interested in Systems, Not Just AI

I Still Build Things That Fail

What I’m Working Toward

`exec` changes the trust model