Adam Warski

@warski.org

Sharing elegant solutions to everyday problems | R&D @ VirtusLab, SoftwareMill | #AI #Scala #FP #Java | Blogger | #OSS developer

Updates in our AI Scala stack: sttp-ai (client for OpenAI, Claude, and other APIs, along with an agent loop): supporting timeouts & retries; Azure OpenAI support chimp (type-safe, boilerplate-less MCP servers and clients): supporting outputSchema in tool definitions

Orca - deterministic, AI-driven development flows - now comes with a shell! Run one of the built-in flows for a deterministic plan-implement-review loop, or create your own flow - by hand or prompting your favourite agent harness.

BildBildBild

My latest strategy for reviewing large amounts of AI-produced code: spot-checks. This will work, assuming that you know the language & ecosystem in which the code is produced (I still sometimes do ;) ).

New features in the latest version of Ox: • `abanonOnInterrupt` for operations which aren't interruptible (e.g. Java's stdin) • resource-only scopes (`resourceScope`) • `computeIntensive` for operations which might monopolize a carrier thread github.com/softwaremil...

GitHub - softwaremill/ox: Safe direct-style streaming, concurrency and resiliency for Scala on the JVM

Safe direct-style streaming, concurrency and resiliency for Scala on the JVM - softwaremill/ox

github.com

Orca update: flow scripts are now language-agnostic. Orca will now auto-detect the commands needed to format, lint (compile) and test a project on first use, using a cheap LLM model. These are the written to `.orca/settings.properties`, where you can adjust as needed.

Bild

Can cleaning up technical debt be automated? Just as we're automating coding? Yes, at least partially - and the more of your codebase is AI-generated, the more frequently it should be done.

Bild

Lots of change in Orca: deterministic, AI-driven development flows! The flows are now restartable - so when there's a mid-flow interruption, e.g. due to an intermittent error, the flow can be continued from the last checkpoint.

Bild

Should code reviews still be a separate stage in the software development process? Code reviews used to be heavyweight: they required involving another human, which is an expensive and slow process.

I might be late to the game, but having a dedicated server for running coding agents is a major life improvement. Dedicated server + tmux + some local/remote ssh config (loosely based on @perevillega.com articles) + scoped GH tokens and you have a secure, always-online sandbox.

Just as we have "mechanical sympathy", soon "code sympathy" might become a non-obvious skill for software engineers: deep, intuitive understanding of how code (or a particular language) works. Question is: how far can you get *without* code sympathy?

An echo from @rustikon.dev: what are you using #Rust for? Tooling / CLIs win with a wide margin, followed by web apps, backend network services & embedded solutions. Evangelism is also strong ;) Does this match your experience? Where do you see most demand for Rust?

Bild

Our AI development stack is shaping up nicely! As a base, using any programming language: * Sandcat to securely run agents, without having to answer tedious questions * Orca to create deterministic development flows

Meet Orca: Deterministic, AI-driven development flows. Orca Flow scripts orchestrate coding agents. No need to try to convince the LLM that reviewing code until all review comments are fixed is a good idea - the script will ensure that's the way it will be done.

BildBild

Maybe we should stop pretending that we carefully review AI-generated code. Not all software is equal. Some of it is critical, but the majority is not. What if we separated human-written & AI-generated code entirely?